Re: Address of an object

["Adam Beneschan" <adam@irvine.com>]

Dmitry A. Kazakov wrote:
> Both X'Address and Unchecked_Conversion of a pointer to X would not give
> the true address of X (i.e. the address returned by Allocate of the
> corresponding storage pool). For an array type, X'Address is the address of
> the first element, the dope is out.
>
> Is there any better way than this extremely ugly and slow:
>
>    type Fake_Pool is new Root_Storage_Pool with record
>       Location : Address;
>    end record;
>
>    procedure Allocate (...) is -- Never called
>    begin
>       raise Program_Error;
>    end Allocate;
>
>    procedure Deallocate
>              (  Pool            : in out Fake_Pool;
>                 Storage_Address : in Address;
>                 Size            : Storage_Count;
>                 Alignment       : Storage_Count
>              )  is
>    begin
>       Pool.Location := Storage_Address;
>    end Deallocate;
>
>    function Storage_Size (Pool : Fake_Pool) -- Never called
>       return Storage_Count is
>    begin
>       return 0;
>    end Storage_Size;
>
>    function Address_Of (Pointer : Object_Ptr) return Address is
>       Pool : Fake_Pool; -- A controlled object, that must be slow!
>       type Fake_Ptr is access Object_Type;
>       for Fake_Ptr'Storage_Pool use Pool;
>       function To_Fake is
>          new Ada.Unchecked_Conversion (Object_Ptr, Fake_Ptr);
>       procedure Free is
>          new Ada.Unchecked_Deallocation (Object_Type, Fake_Ptr);
>       Ptr : Fake_Ptr := To_Fake (Pointer);
>    begin
>       Free (Ptr);
>       return Pool.Location;
>    end Address_Of;
>
> ?

This sounds highly implementation-dependent.  I don't know what an
Object_Ptr points to; but if it points to something that could be
represented, in some implementations, as discontiguous data, then the
above won't necessarily work---calling the instance of
Unchecked_Deallocation could well cause the storage pool Deallocate
routine to be called more than once.  And then your result will be
whatever was passed to the last Deallocate call, which may or may not
be meaningful.

I don't think there's an implementation-independent way to get what
you're looking for (and, frankly, I'm not even sure there's an
implementation-independent way to *define* what you're looking for).
Assuming that you're interested in only one implementation, perhaps you
can ask the implementors to provide an implementation-dependent
attribute or something to give you what you need.

                                     -- Adam