I think in Ada 202X we can invent Limited_Controlled_Interface and 
Controlled_Interface types derived from which could become controlled.

The Limited_Controlled and Controlled types would also inherit from these 
interfaces.

I think, this is backward compatible.

Good idea?

-- 
Victor Porton - http://portonvictor.org

"Robert A Duff"  wrote in message 
news:wcc4mwv731x.fsf@shell01.TheWorld.com...
> "Randy Brukardt"  writes:
....
>> Note that in the OP's example, Janus/Ada does NOT treat the enclosing 
>> record
>> as controlled; each individual controlled object (including components) 
>> is
>> managed separately. I did it that way to make unwinding an object in the
>> face of exceptions during construction easier (each object is registered 
>> as
>> it is constructed, so all successfully constructed objects get finalized 
>> and
>> none that failed get finalized). GNAT, OTOH, does treat each object
>                                                   ^ not
>> individibly and has to go through some handstands so that objects that
>> aren't constructed aren't finalized.
>
> I think you're missing a "not" there.

I don't think so, but I don't claim to understand what GNAT does that well.

> Yes, there are some "handstands",
> but it's not so bad.  I think the only reason it was so hard to
> implement is that it was a re-implementation.  Doing it that way from
> the start would not have been so bad (as is often the case).
>
> The compiler generates a "deep_initialize" procedure for each type,
> which either fully initializes everything, or else finalizes the parts
> that got initialized before an exception.

Initialize routines like that are fiendishly complex (we do initializes that 
way), especially because the combination of discriminant dependent 
components and recursion to handle subcomponents. Trying to include 
finalization in there would have caused madness, at a minimum when something 
goes wrong. (They're literally impossible to debug, and I always find 
something else to do rather than work on those routines. Sorry, Tero. :-)

Also, doing that requires that every call and check be effectively wrapped 
with an exception handler since one has to know the exact point of failure. 
For checks, that's not too bad as the check could be replaced by a branch. 
But for calls, that can be expensive depending on the exception handling 
scheme. (It's probably tractable for GNAT because of the zero-cost exception 
handling, although that is clearly an additional source of complexity; for 
Janus which uses a registration scheme, the cost would be way too expensive 
to use regularly.)

As always with compiler construction, YMMV.

                                           Randy.

"Randy Brukardt"  writes:

> The real problem is that some (many?) implementations include 
> implementation-defined components in types Controlled and 
> Limited_Controlled. (For instance, Janus/Ada includes chain components.) 

GNAT used to do that, but actually only heap objects need to be chained,
and the current implementation does not declare the chain links as
components.  Controlled components and stack objects do not get
chained.  A heap object is allocated with some extra space at negative
offsets, where the chain links are stored.

> Interfaces of course don't have any components; thus making 
> Controlled/Limited_Controlled into interfaces would require the back-door 
> implementation of full MI (since it would require adding components to 
> existing types, meaning that the components could not be assumed at a fixed 
> offset). That is a leap too far.
>
> Note that in the OP's example, Janus/Ada does NOT treat the enclosing record 
> as controlled; each individual controlled object (including components) is 
> managed separately. I did it that way to make unwinding an object in the 
> face of exceptions during construction easier (each object is registered as 
> it is constructed, so all successfully constructed objects get finalized and 
> none that failed get finalized). GNAT, OTOH, does treat each object 
                                                   ^ not
> individibly and has to go through some handstands so that objects that 
> aren't constructed aren't finalized.

I think you're missing a "not" there.  Yes, there are some "handstands",
but it's not so bad.  I think the only reason it was so hard to
implement is that it was a re-implementation.  Doing it that way from
the start would not have been so bad (as is often the case).

The compiler generates a "deep_initialize" procedure for each type,
which either fully initializes everything, or else finalizes the parts
that got initialized before an exception.

Rational uses the same method as GNAT.

- Bob