Re: Controlled types as interfaces

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:imjh3cg11wdr$.1hslpo3a68yxi.dlg@40tude.net...
> On Wed, 20 Aug 2014 15:49:36 +0300, Victor Porton wrote:
...
>> As there is no problem that this record becomes controlled, there are no
>> reason not to make Q controlled despite of T was non-controlled.
>
> It depends on concrete implementations, e.g. some might require the type
> tag being at the record's first address.

That's not exactly the problem, as Ada allows types with conflicting 
representation clauses to be rejected. (This particular problem can already 
happen for interfaces, so there are rules to handle it.)

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.) 
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 
individibly and has to go through some handstands so that objects that 
aren't constructed aren't finalized.

                                                 Randy.