Re: Object/Memory Management

On Sun, 2002-02-24 at 04:22, Sean O'Dell wrote:
> "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.

The stack has that one advantage, yes.  There are a number of ways
around it (you just mentioned one yourself).  However, the stack is just
an ugly hack for bad design.  The stack does *not* in any way guarantee
that those objects are cleaned up.  You can leave functions without
cleaning up (destroying) objects on the stack.  Errors or exceptions can
occur during stack cleanup that you can't catch or deal with.  The order
of object destruction is (in many compilers) not guaranteed.  When you
have multiple objects that use/reference each other all destroyed on the
same fucntion cleanup, you'll start *really* seeing some problems.

Honestly, it doesn't take very much effort at all to add a
c1.close ()
c2.close ()
c3.close ()
in an ensure block or anything - that will guarantee they are closed,
plus give you full exception handling when the saving routine is called.

I believe you mentioned earlier that you are unsure of your code's error
handling and stability, yes?  Well, you have to make some sacrifices
(add three lines of code) in order to make that error handling better.

C++ destructors weren't intended to do anything other than clear up
resources - letting them do otherwise is bad C++ design; too many things
can go wrong during destructors to let sensitive/complex code run in
them.  That's why true destructors don't exist in Ruby... it would make
it too easy for Ruby code to cause the interpreter to crash, which
should never ever ever happen.  ~,^

> 
> > 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.

Well, you are trying to code in a C++ way with Ruby.  That would be like
trying to code the Ruby way in C++.  It just won't work right.

As I stated above, if your code depends on destructors of objects to do
tasks like opening, writing to, and closing a file, in addition to
memory cleanup, I'd expect your application would break down very easily
if an I/O error occured.

> 
> 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.

Ruby is contagious.  Give yourself a week or two, and you'll be dying to
write C++ code with blocks passed to functions, or memory leak free..

Honestly, the stack method of being lazy and letting the compiler do
your cleanup for you shouldn't even be used in C++ programs that require
any kind of stability or dependibility.  Ruby simplifies all that so
much.  It puts the cleanup back in *your* hands, under your control,
where it should have been the whole time.  If you need a file saved, you
control when it is done, and how the errors are handled.

I'm sorry if I sounded like I was attacking your programming style; I'm
not.  It's just that after some 7 years of C++, It's hard-coded into my
head which parts of it I steer clear of, and all its numerous
short-comings.  I used to like programming in nothing but C++, now I
only touch it on projects that are already in C++.  C is even prettier
in that it doesn't lend itself to making too many shortcuts, and you
avoid "bugs" like stack-based object destruction.  ~,^

> 
>     Sean
> 
>