Re: Limited returns

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

On Mon, 23 Jun 2008 11:15:23 -0700 (PDT), Adam Beneschan wrote:

> On Jun 23, 10:03 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>>
>> Is there an AI to finally fix a similar problem with pool-specific access
>> types? I mean this:
>>
>> procedure Test_Access is
>>    type T is tagged null record;
>>    type S is new T with null record;
>>
>>    type T_Ptr is access T'Class;
>>    type S_Ptr is access S'Class;
>>
>>    function Factory return T_Ptr is
>>       X : S_Ptr := new S;
>>    begin
>>       .. -- Do something with X
>>       return T_Ptr (X); -- Illegal!???
>>    end Factory;
>> begin
>>    null;
>> end Test_Access;
>>
>> The only workaround is to cast:
>>
>>    function Factory return T_Ptr is
>>       Result : P_Ptr := new S;
>>       X : S'Class renames S'Class (Result.all);
>>    begin
>>       .. -- Do something with X
>>       return Result;
>>    end Factory;
> 
> I don't see an AI for this.  I'm guessing that the problem would be
> that you could specify different pools for the two different access
> types, which would make the type conversion problematic (you'd have an
> access type object that points into the wrong pool, which could then
> cause havoc if you do an Unchecked_Deallocation).

Clearly the conversion should simply raise Constraint_Error when pools
aren't same.

> If the language
> rules said that a type conversion like this were allowed only if the
> storage pools were the same, the problem would then be that, since a
> storage pool rep clause could appear in the private part of a package,
> you could have a situation where you could not tell whether a type
> conversion was legal without peeking into the private part of a
> package you don't have visibility to.  And that's something the
> language designers try very hard to avoid.

It is just like with tags, they too cannot be always statically checked.

> On the other hand, if you're not going to specify a Storage_Pool for
> the types, is there a reason to make them pool-specific?  I'm not sure
> what's gained by doing so.

1. Safety. It guarantees no objects on the stack.

2. If an access type is a generic parameter, then to have it general access
is a stronger precondition than necessary. It would be a bad design.

3. There are important cases when pools are needed. For example, to have a
container of indefinite by-value objects. If you don't want the overhead of
lists of descriptors, a custom pool is the just the way. (In some cases
streams would also work, but pools are more universal and efficient)

4. Pool-specific access could be more efficient.

------------
There is a related problem, that when a pool-specific object is initialized
or finalized, there is no way to get a pool-specific access to it. One have
to use Unchecked_Conversion of a general access type, which is not even
guaranteed to work.

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