Uninitialization

An object should always be uninitialized before its storage is freed. This is important because it also allows releasing resources and freeing storage not contained within the body of the object. SOMobjects handles uninitialization in much the same way as for initializers: An uninitializer takes a control argument and is supported with stub procedures in the implementation template file in a manner similar to initializers.

Only a single uninitialization method is needed, so SOMObject introduces the method that provides this function: somDestruct. As with the default initializer method, a class designer who requires nothing special in the way of uninitialization need not be concerned about modifying the default somDestruct method procedure. However, your code will execute faster if the .idl file overrides somDestruct so that a non-generic stub-procedure code can be provided for the class. Note that somDestruct was overridden by "Example1" and "Example2" above No specific IDL modifiers other than override are required for this.

Like an initializer template, the stub procedure for somDestruct consists of two sections: The first section is used by the programmer for performing any "local" uninitialization that may be required. The second section (which consists of a single EndDestructor macro invocation) invokes somDestruct on ancestors The second section must not be modified or removed by the programmer. It must be the final statement executed in the destructor.


[Back: Using initializers when creating new objects]
[Next: Using 'somDestruct']