| Cleaning up inherited object classes [message #37181] |
Wed, 03 December 2003 11:28  |
MKatz843
Messages: 98
Registered: March 2002
|
Member |
|
|
Cleaning up is my least favorite activity. Were my living room an IDL
object I'm sure it'd be full of dangling pointer references. Here's a
question regarding objects' Cleanup methods and inheritance.
When an object inherits another object, methods can be overridden. So
what happens to the CleanUp method? It is special.
If my House object inherits the Living_Room and Bathroom object
classes, will a call to HOUSE::CleanUp also call Living_Room::CleanUp
and Bathroom::Cleanup when obj_destroy, self is called?
Let me put that another way. Suppose an object class, A, has pointer
fields. Unless someone tells me otherwise, I assume it's a good idea
two specifically free the pointers in that object's Cleanup routine.
Now, suppose another object class, B, inherits A. B has its own
pointers to clean up as well, so I write that into its cleanup
routine.
It is sufficient to write the Cleanup methods like this?
pro Bobj::CleanUp
ptr_free, self.Bpointer
obj_destroy, self
end
pro Aobj::CleanUp
ptr_free, self.Apointer
obj_destroy, self
end
Will Bobj::CleanUp's call to "obj_destroy, self" also call
Aobj::Cleanup so that self.Apointer can be freed as the object is
destroyed?
Also, does the destruction of an object that contains a pointer field
also inherently free the pointer? or is it necessary to specifically
ask for that in the Cleanup?
Now if I could only get the House::TakeOutTheTrash method to work
reliably my wife would be thrilled.
M. Katz
|
|
|
|
| Re: Cleaning up inherited object classes [message #37263 is a reply to message #37181] |
Wed, 03 December 2003 14:12  |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Wed, 03 Dec 2003 12:28:27 -0700, M. Katz wrote:
> Cleaning up is my least favorite activity. Were my living room an IDL
> object I'm sure it'd be full of dangling pointer references. Here's a
> question regarding objects' Cleanup methods and inheritance.
>
> When an object inherits another object, methods can be overridden. So
> what happens to the CleanUp method? It is special.
>
> If my House object inherits the Living_Room and Bathroom object classes,
> will a call to HOUSE::CleanUp also call Living_Room::CleanUp and
> Bathroom::Cleanup when obj_destroy, self is called?
>
> Let me put that another way. Suppose an object class, A, has pointer
> fields. Unless someone tells me otherwise, I assume it's a good idea two
> specifically free the pointers in that object's Cleanup routine. Now,
> suppose another object class, B, inherits A. B has its own pointers to
> clean up as well, so I write that into its cleanup routine.
>
> It is sufficient to write the Cleanup methods like this?
>
> pro Bobj::CleanUp
> ptr_free, self.Bpointer
> obj_destroy, self
> end
>
> pro Aobj::CleanUp
> ptr_free, self.Apointer
> obj_destroy, self
> end
>
> Will Bobj::CleanUp's call to "obj_destroy, self" also call Aobj::Cleanup
> so that self.Apointer can be freed as the object is destroyed?
>
> Also, does the destruction of an object that contains a pointer field
> also inherently free the pointer? or is it necessary to specifically ask
> for that in the Cleanup?
>
> Now if I could only get the House::TakeOutTheTrash method to work
> reliably my wife would be thrilled.
You need to clean up dynamic memory in each object which contains any,
which means chaining your calls to Cleanup to superclass(es) --- IDL
never chains for you automatically (unlike some languages you may
know), and OBJ_DESTROY is specifically trapped inside Cleanup (it
seems) to avoid recursive calls.
On the plus side, the lovely HEAP_FREE routine RSI gave us with IDL5.3
does a very nice job of cleaning up large data structures with lots of
dynamic data (pointers/objects) tucked into them. Though the manual
warns of inefficiencies, in the few cases I've tested, HEAP_FREE is
actually faster than the explicit alternative, even with thousands of
variables on the heap. I often write a cleanup method as simple as:
pro FooClass::Cleanup
heap_free,self.data
self->SuperClass::Cleanup
end
with the intention of fixing it later. Since I've found it to be just
as fast, and far less error prone, I generally just leave it, unless I
want to preserve some parts of the data (e.g. shared objects/pointers).
JD
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
