Re: Type conversions on pool-specific access types

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

On Thu, 16 Oct 2003 02:43:08 +0100, "Nick Roberts"
<nick.roberts@acm.org> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:7kukov45dif9p7u2ohu6ml29mu9cgu621o@4ax.com...
>
>> Who knows any reason why conversions between pool-
>> specific access types are not allowed, provided that
>> the storage pools are same? Isn't storage pool static-
>> ally known?
>>
>> It is a real pain to use Unchecked_Conversion ...
>
>I think it's also dangerous and unnecessary.
>
>> type Base is new Ada.Limited_Controlled with ..;
>> type Base_Ptr is access Base'Class;
>> for Base_Ptr'Storage_Pool use ...;
>>
>> procedure Foo (Object : Base_Ptr);
>> ...
>> type Derived is new Base with ..;
>> type Derived_Ptr is access Derived'Class;
>> for Derived_Ptr'Storage_Pool use Base_Ptr'Storage_Pool;
>> ...
>> declare
>>    Ptr : Derived_Ptr := new Derived;
>> begin
>>    Foo (Base_Ptr (Ptr)); -- ILLEGAL!
>>
>> I do not understand why.
>
>In this situation, I suggest that you do not need to declare Derived_Ptr,
>since Base_Ptr can -- and generally should -- be used to point to objects of
>type Derived (as well as Base).
>
>   declare
>      Ptr : Base_Ptr := new Derived;
>   begin
>      Foo(Ptr);

Yes, in this case. But consider specialized containers of Derived
descendants:

procedure Derived_Specific (X : Derived);
type Array_Of_Derived is array (...) of Derived_Ptr;

Now you can call Derived_Specific on any element of Array_Of_Derived
without an explicit type conversion. It is also type safe. If I have
only Base_Ptr, I lose that advantage and forced to always work in the
terms of the base type and what is worse, to make casts.

>> Another thing is initialization / finalization of controlled
>> objects allocated on some specific storage pool. It could
>> be a great problem if a pool-specific pointer is required ...
>
>The answer is "Don't do that!"
>
>Finalize should finalise whatever is inside the given Object, and not deal
>in any way with where (in which pool) the object resides. After the
>implementation has called Finalize for the object, it will then -- when
>appropriate -- call Deallocate for the object's pool, in order to deallocate
>the object's storage space from the pool. Do not mess with this mechanism.

Theoretically true, but practically, consider a situation when objects
have to be always allocated in a specific pool. For example, on a
user-defined stack. Further each object has to remove itself from some
list. It is made upon finalization. The problem is that in this case
you cannot use the advantages of thin pool-specific pointers. You have
to switch to thick general-access ones. This would cause cascading
effects leading to abadoning any use of pool-specific ones at all.
Note also that if all that is a generic package, then you have no
choice, because the formal access parameter should either have the
modifier "all" or not.

And of course there is another problem that anonymous access types are
always general-access. I would expect that:

type Object (Other : access Other_Type) is ...

would mean a specific access type. With an ability to say:

for Object.Other'Storage_Pool use Some_Pool;

And for a generic-access type one would have to write:

type Object (Other : access all Other_Type) is ...

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de