Re: Why C++ is successful

[Matthew Heaney <matthew_heaney@acm.org>]

Jay Martin <jaymmartin@earthlink.net> writes:

> Which turned out to be a technical mistake, because 
> I didn't remember a (non-embedded system) Ada compiler that did
> not implement "Unchecked_Deallocation".   Imagine
> the ridicule from C programmers: "You can call malloc
> but you can't even call free!."

It was probably too conservative, since the RM recommends that an
implementation really support UC.  And all implementations of Ada really
do support UC.

But even if he did use UC in the implementation of his unmanaged forms,
this isn't good enough, since the client would still have to explicitly
Clear the structure prior to exiting the scope of its declaration.
Otherwise a memory leak would occur.  This is what you have to do in the
managed forms too.

I've written an Ada95 data structures library very much like what Booch
provided, that does automatic garbage collection.  It wasn't that hard.

> > The Booch components had a very specific taxonomy.  Only "unmanaged"
> > components expect a garbage collector.  The "managed" forms do their own
> > garbage collection (using a storage manager, another component).
> 
> Which excepting multi-tasking and fixed sized forms, made up for
> roughly half the Booch components, over a 100
> component permutation banking on GC.

His taxonomy provides a menu from which you choose the forms that apply
to your situation.  You are not expected to use all the forms.

The functionality is the same in both the managed and unmanaged forms.
Just stick to the managed forms, and no GC is necessary.

That "roughly half" of his library "banks on GC" in a weak argument,
because you never use that half of the library.

If the fact that half the library goes unused upsets you, then just go
the the directory where you keep the components, and delete the
unmanaged forms.  After you do that, then _none_ of the library will
depend on GC.  And you'll have lots of extra disk space too!