Re: Object/Memory Management

On Sun, 2002-02-24 at 16:22, Sean O'Dell wrote:
> "Sean Middleditch" <[e-mail]> wrote in message
> > Jumping was the one issue I was referring.  The order of destructors,
> > while supposedly a standard, doesn't work on all C++ compilers.
> > Thankfully, the major players (VC++, GCC, Borland C++, Watcom C++) all
> > work right in this regard.
> 
> Yes, but there are bad implementations everywhere.  Don't avoid something
> because someone's compiler somewhere might not do something quite right.

Unfortunately that isn't a choice, sometimes.  You may need those
systems/compilers to work with your product.  If you're sticking to just
Windows, or just Linux, then its a different story.  Compare that to
apps that run on Amiga's, Macs, many many UNIX's, Windows, VMS, DOS, and
so on (mostly network apps), you see where you either avoid the
problematic features, or you end up writing three versions of the same
code.

> 
> > > Since C++ doesn't have a finally statement, or easy to use closures,
> > > the stack based destructor trick is used pervasively.  Many C++
> > > programmers try to take this technique with them when trying other
> > > languages.  Unfortunately, I've only seen it work effectively in C++
> >
> > The stack based destructor still falls apart too easily, especially when
> > errors occur in the destructor.
> 
> This much is true.  Generally speaking, though, if a destructor needs to do
> something of any complication, I stick it in a block with not much else.
> Actually, if I have such activity in a destructor, I make the complicated
> call myself, but the destructor is there to *try* and make sure it happens
> in case someone forgot to make the call.

Well, that was my point.  You were saying you used destructors to save
your configuration data.  I am under the impression that is the *only*
attempt you make to save that data.  Therefor, that data can be easily
lost.

> 
> Here's a great example of what destructors are good for that won't invoke
> the "exception during destruction" issue.
> 
> A hierarchy of objects.  Say I have a parent object with several child
> objects.  Each child object has a pointer back to its parent, and the parent
> has pointers to its children.  The outside world never sees the pointers,
> but will ask the parent to give a reference to a child, and the child for
> its parent.  If a child object goes away for some reason, the destructor
> makes a simple call back to the parent telling it to clear its pointer
> because its leaving.  There's zero chance an error will occur, but it's
> ABSOLUTELY CRITICAL that the parent know the child is leaving.

I know *exactly* what that's like.  And again, in order for the child to
"leave," delete() must be called on it.  (If you're referencing items
off the stack, you are asking for trouble...)  You might as well just
call object.close () on it.  If you're in C++, you can make the method
call delete on itself, *after* the error checking has been performed, so
in the case an error occurs, the object will still be there for you to
use its data after fixing the problem.

> 
> Now, I know in Ruby you don't have pointers.  The child object will forever
> belong to the parent so long as the parent references the child, which it
> likely will unless you deliberately remove the reference.  So, for Ruby,
> this isn't a good analogy.

Well, in a way, everything in Ruby is a pointer.  It's just that you can
never get a danling pointer.  If you want to remove a child from the
parent, where the member "child" in "parent" points to the child, you'd
just set the member to nil.  The reference is gone (just like setting a
pointer to NULL), all set.  If you want a list of children, you'd use an
array, find the child in array, and handle it there.

> 
> And that may be what it is about Ruby.  You just don't need those
> destructors as much.  But in C++, they're oftentimes essential.

Destructors are very useful (if not essential) in C++, but so long only
as they're used for basic resource cleanup... trying to do complex tasks
in a destructor is asking for pain.  Especially when that obscure system
error you weren't expecting occurs... ~,^

> 
>     Sean
> 
>