From: Sean Middleditch <elanthis@...>
Date: 2002-02-25T06:26:14+09:00
Subject: Re: Object/Memory Management

On Sun, 2002-02-24 at 16:02, Sean O'Dell wrote:
> "Sean Middleditch" <elanthis@awesomeplay.com> wrote in message
> >
> > 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.
> 
> The order of object destruction *is* guaranteed and works correctly on every
> compiler I've worked with since Turbo C++.

Mainsteam compilers, yes.  I suppose not everyone tries to be as
portable as I like to.  ~,^

> 
> I don't have troubles at all with C++ and I've been programming with it
> heavily for 10 years.
> 
> I don't believe the stack in C/C++ is an ugly hack for bad design.  It's
> been a fantastic way to help manage memory.

For simple management of memory, yes, it works very well.  It sits on
the system layer, guaranteeing the memory is freed, and in good speed,
too.

> 
> > 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.
> 
> That was in Perl, not C++.  Perl's error handling is terrible and I have a
> quite a bit of code that I don't trust because I didn't add error checking
> everywhere possible.

Ah, sorry, I must've misread that.  ^,^

> 
> > 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.  ~,^
> 
> C++ was designed to provide wrappers for resources.  C++ provides for
> object-oriented design.  Resource management is just one of its features.
> There are no official recommendations as to what you use C++ destructors
> for, and I have seen them used for lots of different things with excellent
> results.

Yes, I've used them quite a bit in ways I shouldn't have, either.  The
fact is, the code breaks way too easily.  Especially when you're using
heavily cross-referenced objects, and you have very little control over
when an object goes out of scope.  Then, you have no control over what
order things get destroyed in whatsoever, and you see how trying to do
things like write to files, or call complex procedures, really gets out
of hand very quickly.

> 
> > 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.
> 
> No, because when exceptions occur, the specification is to unwind the stack,
> not longjmp out.  If I have a file object with an open file and something
> throws an exception, when the file object leaves the try block, its
> destructor will get called allowing the file to be closed properly.

And what happens when its destructor throws an exception, while you're
already handling an exception, in a list of objects all needing their
destructors called, each of which is likely to throw an additional
exception because of a bad file permission somewhere?

Had the objects been close and checked individually, the very first
error could have been caught.  The further attempts (which, depending on
the error and your code, could cause data loss or corruption), would
have been avoided, and the impact not nearly as great.  Not to mention
with finer control, you could have caught the first exception, fixed the
error (reset file permissions, save to an alternate file), and continued
on with the rest of the file saves.

All if you manually called the save method or whatever, instead of
letting the stack make its attempt to do it for you.

> 
> > 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.
> 
> Stability is what C++ is very, very good at.  I program with C++ heavily,
> and all the features you are saying cause problems have actually *solved* a
> lot of problems for myself and everyone I've ever coded with.

Any language that sits that close to the sytem breaks down very quickly
with a system error without extensive error checking and handling.  Ruby
and other high level languages sit way above the system level, and thus
tend to run a lot more reliably (assuming their VM's/interpreters aren't
poorly programmed).

You can make any C or C++ program very, very stable, with very attentive
and careful programming.. exactly what these shortcuts that C++
introduces avoids.  C++ is a great language, so long as you only use the
given features (like stack based object destruction) on objects and data
that the method fits.  You don't perform operations that can fail where
you can't handle the failure, whether you're using C++ stack based
object destructor and exceptions or system call wrappers that don't
check return codes.

> 
> > 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.  ~,^
> 
> 7 years seems like a long time to have missed so much in C++.  I don't doubt
> you didn't enjoy programming in it.

Oh, I enjoyed it.  Why else did I stick with it for all that time?  Some
tasks just do not, in any way, belong with C++.  Even C isn't great for
many things.

I've found that the majority of applications work best in either very
low-level, fast code (C) or a very high-level, nice OO language (like
Ruby).  C++ is an attempt to get a mixture of the two, sacrificing here
and there to try and get the best of both worlds.

I've found that it tends not to work that nicely.  Stick with the fast,
portable C, or make use of a *real* OO language.  ~,^


> 
>     Sean
> 
>