Hi,

What if I want to have a single instance object.

In fact, when there is a template, there is already ONE instance.
For the template itself can be used as a static object, as the documentation says:

In the case we have only ONE object instance in our
application, we can use the object template as static object.
...
The object template can be accessed using a symbol formed
with the object name preceded by the "@" character.
To call a method form the object template, the following code
can be used:

    OCall @Shape::Shape.Init

Or

    OCall offset @Shape::Shape.Init


One way to garantee only ONE instance would be a runtime check in the Init method of the object. For instance, you could use a variable that is incremented, each time the Init method is invoked, and act accordingly. But I don't want to do it at runtime.

At compile time I want to be sure there is only ONE instance: the template! If not, a compile time error has to be generated.

As far as I can see, there are 4 ways to create an instance.
Correct me if I am wrong.

Object1 $Shape {}
New Shape
LNew Object1:Shape
Embed Object2, Shape

How can I force an error at compile time if an instance is created from the template. Is there a compile time counter I can check for?
Or can it be done in another way?

Friendly regards,
mdevries.
Posted on 2006-10-31 02:43:25 by mdevries
Hi
There is another way to create an object on the fly. It is using streams to store and recall them.

I would do the counting as you suggested on RT since it is a really minimal overhead and you will cover all situations, but if you prefers the CT solution, you have to modify the the creation macros to introduce a counter. Currently there is no such counter implemented.

Regards,

Biterider
Posted on 2006-10-31 03:04:42 by Biterider
Hi Biterider,

Thanks for your quick response, as usual.
I guess I am forced to do it runtime at the moment.

if you prefers the CT solution, you have to modify the the creation macros to introduce a counter. Currently there is no such counter implemented.


I prefer the CT solution.
Could this be implemented in a future release or update?

Friendly regards,
mdevries.
Posted on 2006-10-31 03:22:58 by mdevries
If you don't expect any more instances, you can abuse the template of the class object directly.
Biterider does this a lot actually :P

You simply make sure the class is included as usual using MakeObjects or LoadObjects macros, imagine that these macros inject a master copy of each class object, because they do.

Now forget about New() and Destroy, pretend its already instanced, and abuse it as follows:

OCall @ClassName::MethodName,Params
The leading @ means "instanceptr=addr classtemplate"
Don't use New or Destroy for this object.

There are also some handy macros to obtain pointers to named classes and their methods.

Biterider will smack me if I'm wrong anywhere above, I'm quoting from memory.
Posted on 2006-10-31 06:14:47 by Homer
Hi Homer,

Ofcourse the programmer is responsible for what he does.
And if he is aware that an object should be used as a single instance object, everything is ok. He will not instance it more than once.
If you are designing the object yourself, you will know for sure you shouldn't use it more than once.

But what if the object is created by one programmer, and used by another programmer, or used by yourself after a long time?
A little help from the compiler wouldn't do any harm here, isn't it?
It would really be nice to be able at compile time to tell whether the object is being single used.

About the abuse of the template:
If you don't expect any more instances, you can abuse the template
of the class object directly.


OCall @ClassName::MethodName,Params


Isn't that the same as what I quoted from the documentation?
   OCall @Shape::Shape.Init


Friendly regards,
mdevries.

Posted on 2006-10-31 06:49:05 by mdevries
Yes its the same, my bad :P

If instances of class X are created AFTER screwing with the template object, those changes are reflected in the new instances akaik.

About 'abusing' the class template, and addressed to nobody in particular:
You've been warned, so don't whine that you didn't understand the consequences. If you're not sure of the outcome, don't do it! If it's some kind of component or plugin, don't do it!
Shortcuts are not necessarily your friend, you have to understand them, the shortcuts you are familiar with never bring you unstuck..
Posted on 2006-10-31 06:59:41 by Homer