Re: memory management in Ada: tedious without GC?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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. The order
of record components or discriminants has no semantic meaning (except when
representation clauses involved).

The compiler should be able to re-order and even remove them, as well as
initialization of. Consider a statically constrained discriminant as an
example. If the compiler could remove it, we would have the problem of
measurement units solved!

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de