comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: Cleaning up inherited object classes
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Cleaning up inherited object classes [message #37171] Wed, 03 December 2003 20:15
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
Marc Schellens writes:

> Well another way would be to consider it already
> when writing your program.
> I always have the cleanup method just before the
> XX__define procedure. So for every inheritance I immediately add
> the superclass cleanup call and for every pointer the ptr_free (object,
> obj_destroy) function.

Well, yeah. Now I do too. :-)

Cheers,

David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
Re: Cleaning up inherited object classes [message #37172 is a reply to message #37171] Wed, 03 December 2003 18:38 Go to previous message
marc schellens[1] is currently offline  marc schellens[1]
Messages: 183
Registered: January 2000
Senior Member
Well another way would be to consider it already
when writing your program.
I always have the cleanup method just before the
XX__define procedure. So for every inheritance I immediately add
the superclass cleanup call and for every pointer the ptr_free (object,
obj_destroy) function.

marc

David Fanning wrote:
> Ben Tupper writes:
>
>
>> I would defer to other's on the question if a subclass MUST have its own
>> CLEANUP method. I haven't tried it, but I'm not sure that it does
>> (unless it has its own pointers and objects to cleanup.)
>
>
> I'll tell you this, I have spent an *untold* number
> of hours chasing down memory leaks only to find that
> I forget to call a superclass CLEANUP method from my
> object's CLEANUP method! I've done it so often this
> is the *FIRST* thing I look for when I'm chasing
> memory leaks now.
>
> Who says you can't teach an old dog new tricks?
>
> Cheers,
>
> David
>
Re: Cleaning up inherited object classes [message #37177 is a reply to message #37172] Wed, 03 December 2003 12:28 Go to previous message
David Fanning is currently offline  David Fanning
Messages: 11724
Registered: August 2001
Senior Member
Ben Tupper writes:

> I would defer to other's on the question if a subclass MUST have its own
> CLEANUP method. I haven't tried it, but I'm not sure that it does
> (unless it has its own pointers and objects to cleanup.)

I'll tell you this, I have spent an *untold* number
of hours chasing down memory leaks only to find that
I forget to call a superclass CLEANUP method from my
object's CLEANUP method! I've done it so often this
is the *FIRST* thing I look for when I'm chasing
memory leaks now.

Who says you can't teach an old dog new tricks?

Cheers,

David

--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
Re: Cleaning up inherited object classes [message #37179 is a reply to message #37177] Wed, 03 December 2003 12:17 Go to previous message
btt is currently offline  btt
Messages: 345
Registered: December 2000
Senior Member
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.
>
> M. Katz
Hello,


I think you simply call the cleanup method for each superclass.
The following is the way I do it.


PRO House::Cleanup

DoMyOwnCleanUpofLocalPointersAndObjects

Self->Living_Room::CleanUp
Self->Bath_Room::Cleanup

END


Provided that HOUSE was defined this way.

PRO House__Define

struct = {House, $
INHERITS Bath_Room, $
INHERITS Living_Room}
END


If Bath_Room inherits from some other object, such as READING_ROOM, then
it will call that superclass' cleanup method if you have Bath_Room's
cleanup as ...

PRO Bath_Room::Cleanup

self->Reading_Room::Cleanup
END


I would defer to other's on the question if a subclass MUST have its own
CLEANUP method. I haven't tried it, but I'm not sure that it does
(unless it has its own pointers and objects to cleanup.)

Cheers,
Ben
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Active Contours and Snakes! Oh, my!
Next Topic: Re: Active Contours and Snakes! Oh, my!

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 09:14:43 PDT 2025

Total time taken to generate the page: 0.00588 seconds