Re: memory management in Ada: tedious without GC?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Fri, 23 May 2008 19:15:45 -0400, Robert A Duff wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> 1. You don't know exactly the order in which the Finalize of the controlled
>>> component gets called.  So if you access the container object over an
>>> access discriminant, that might be already invalid.
>> 
>> You know something about the order.  Initialize is bottom-up,
>> Finalize is top-down.  And when there are access discrims, the
>> order among subling-components is specified by the RM.
>> 
>> I would prefer a fully defined order, based on the declaration order.
>
> Hmm, that would be even more broken, I think. The language should not
> require more than necessary to implement the programmer's intent.

How does the compiler know the programmer's intent?  Maybe order is
important, maybe not.

>...The order
> of record components or discriminants has no semantic meaning (except when
> representation clauses involved).

It sometimes has meaning -- that's why we have positional-notation
record aggregates.

> The compiler should be able to re-order and even remove them,...

You mean lay them out in memory?  Sure, the compiler should choose an
efficient layout, which is not necessarily the same as the declaration
order.  That's OK, because record layout is invisible, except when
you're doing low-level stuff (e.g. interfacing to something outside
the Ada world).

>... as well as
> initialization of.

There, I disagree.  I see zero advantage to allowing arbitrary order for
the calls to Initialize and Finalize.  And one huge disadvantage -- if
you depend on the order, either on purpose or by accident, you might get
a bug introduced years later, when you switch compilers (or even
compiler versions).  It will be very hard to detect and to fix that
bug!

Consider two finalization actions -- one flushes a buffer to disk,
and the other closes the file handle.

>... Consider a statically constrained discriminant as an
> example. If the compiler could remove it, we would have the problem of
> measurement units solved!

Yes.  I've always wanted to do that optimization.

The strange thing is that most compilers do exactly that for array
bounds, but not for discriminants.  Array bounds are really
discriminants, deep down!  ;-)

>>> 4. The pattern is exposed to multiple inheritance diamond diagram problem,
>>> when such components are added independently.
>> 
>> I don't understand your point here.  Could you give an example of the
>> problem?
>
> type A is limited tagged record ...;
> type B is new A with record
>    -- a controlled component here to handle finalization of A
>
> generic
>    type Some_A is new A with private;
> package P is
>    type C is new Some_A with record
>       -- a controlled component here to handle finalization of A
>
> Now, if P is instantiated with B, finalization of A will be handled twice.
>
> The problem is that finalization in C++ terms is a "virtual" member, while
> record components are "non-virtual". Implementation of one through another
> is IMO fundamentally broken.

OK, I understand the above example (although I don't see a diamond).

My answer is, "So don't do that".  ;-)

Why would you put the finalization for A in B?  Put it in A where it
belongs.  The main reason to add finalization to B is if B adds
new components that need to be cleaned up.  If so, then wrap
those components in a controlled type.

- Bob