Subj : Re: OO compilers and efficiency
To   : comp.programming
From : Rob Thorpe
Date : Sat Jul 23 2005 06:09 am

Ed Prochak wrote:
> I for one thought that GC was a stupid idea. It makes the OO
> programmers lazy.

Of course if GC is available programmers often use it out of laziness.
There is often nothing wrong with this since programmer time is very
expensive.  It only becomes a problem when speed is important.  In the
embedded environment speed and memory consumption are more important so
it's not so appropriate there.

> The cleanup merely requires some protocols that identify when the
> object has outlived its usefullness. In embedded environments you
> usually know fairly precisely when you are done with something and can
> invoke its cleanup (destructor) methods. I don't see much reason why
> this isn't possible to know in other cases.
>
> The "snail trail" is in the objects already. when I'm done with an
> object I invoke its cleanup (destructor) method which in turn invokes
> the cleanup methods for each child object that it allocated
> (constructed), which in turn invokes . . . methods down to the
> elemental/terminal objects.
>

The problems with the method you outline is that it requires everything
to behave itself perfectly.  Each object must perfectly encapsulate
it's functionality in the way you describe.

The programmer writing the destructor must delete each dynamic object
that they have created.  They must do so the correct order, not
deleting an object that another objects destructor must interact with
before that object can be deleted.

For example, a class creates a "file" object and a "foo" object.  The
file object is passed to the foo object.  Considering this classes
destructor:  Let's say if foo's destructor performs some finalising
action of some sort on "file", this means file must be destroyed after
foo.  Now imagine a  situation, where there are two complex object
"jim" and "sheila", both need destroying, but both were passed some
object "fred".  The destructors of Jim and Sheila both act on fred, so
which of jim and sheila do you delete first?

Now, add threads into the mix.

> When OO was first proposed, I sincerely believed it would help resolve
> some of the memory leak problems our C applications had at the time.
> Instead, OO applications (especially of the C++ flavor) seem to have
> even greater waste and abuse of memory. So much was promised, and so
> little delivered.

That's true, but there's no reason to care that much about a little
waste and abuse of memory on most modern computers.

.