Object placement and lifecycle using ObjAsm32

Objects are entities that can be located in different places as they are needed. Usually they are instantiated as standalone entities and their lifecycle are determined by the “New??? and “Destroy??? Keywords.
Less obvious are objects placed in resources, better said as part of i.e. a resource dialog. In this case, ObjAsm32 limits the lifecycle between the WM_NCCREATE and WM_NCDESTROY messages sent to those objects.
Objects can also be created as local entities like variables that are created with the “Local??? keyword within a method or procedure. This is achieved using the “LocalEmbed??? macro that reserves the necessary stack space to locate the object instance. The difference to a standalone object is that the instance is not automatically initialized. It is required to use the “$ENew??? or “ENew??? macros to copy the object template to the local instance. Since the instance is automatically freed when the procedure or method is finished, it is not necessary to call the “Destroy??? macro but the “Done??? destructor to free allocated resources!
An object instance can be nested into another object using the “Embed??? macro. This case is different from a local object since the nested object remains alive with the hosting object that controls its initialization and finalization. Like a local object, a nested object should never be disposed using the “Destroy??? macro.
Finally, you can find an object instance in a more hidden place which is in an object that uses multiple inheritance. This topic will be explained in detail in the next ObjAsm32 version.
For a more flexible use of the method invoking, the OCall macro was enhanced to allow not only an instance pointer as first parameter, but also a symbol to the nested object. Internally, the instance pointer was computed avoiding any overhead.

Summarizing, objects can be found in many places where they are required:

  • standalone (heap or any segment)

  • in resources

  • embedded into other objects

  • embedded into methods or procedures

  • in the base structure of multiple inheriting objects (next version)

In the next days I’ll post a short update to show all this possibilities using the Demos and Projects of the current ObjAsm32 package.  8)


Posted on 2005-10-23 13:00:02 by Biterider

in the base structure of multiple inheriting objects (next version)

Multiple inheritance o_O :D
Something like

Object GameEngine, GameEngineID, CD3D_Engine,C_EAX_Audio,C_DInput

If so, that's wonderful :D
Posted on 2005-11-03 16:29:27 by Ultrano
Hi Ultrano
There is no much difference between an embedded object and an inherited object. The key point for MI, as you know, is the instance pointer shifting. I'm not sure if I should do it automatically or not... Currently there is a test version (1.3e) on the net.
I have to say that I'm still the opinion that MI is not an essential issue and the final result can be achieved using alternative ways too.

For the moment I'm working on "early and late binding" and the MI isrunning with a lower priority  :)

Posted on 2005-11-04 00:57:21 by Biterider