Re: Object/Memory Management

"Sean Middleditch" <[e-mail]> wrote in message > On Sat,
2002-02-> If you are coming from a C++ background, then why not just define
a
> "close" method for your objects?  It can't be any more cumbersome than
> in C++, in which you would have add to explicitly call delete anyhow.

Because, generally speaking, I create objects on the stack, which in turn
dynamically allocate the memory they actually use internally (and free on
destruction).  I generally don't use new to create objects I use within
functions because functions don't have reliable cleanup routines.  C++ can
catch exceptions, but there is no equivalent to "finally" or "ensure."
Creating the objects on the stack ensures that they get cleaned up properly
when they go out of scope.  I've had tremendous success with this way of
doing things.  It's intuitive, it's dependable and best of all you can have
a bad day coding and still not create anything terribly funky.

> It's a choice of: (A) do you want the ease of letting the stack cleanup
> for you, or (B) do you want the ease of never dealing with memory
> management, again, ever.

I'd rather have the stack way of doing things, complete with the automatic
call to finalize.  It's not just an issue of memory management.  That's part
of it, but the main thing to me is the encapsulation that the destructor
provides.  There's more to be done when an object goes out of scope than
just return memory to the system.  Losing that paradigm is a tough bullet to
bite, but I am hearing a lot about how great garbage collection is, so I'm
accepting it for now and I'll just see for myself.  It should be apparent to
me within a month or two how well this memory management system holds up.

I wouldn't say I have a downright good feeling about this memory/destructor
thing...but I have learned ways to work around doing what I'm already used
to doing and I'm trusting all these very smart people not to be leading me
blind off of a cliff.

    Sean