Re: Address of an object

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

On Mon, 18 Sep 2006 06:29:24 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Let P be a pointer to X. Then what I need is the address A, which the pool
>> P'Storage_Pool returned when X was allocated there. This is the same
>> address the pool will receive upon freeing X.
>>
>> ----------
>> The problem behind. What I need is to be able to add some dopes to the
>> objects allocated in *my* pool. new T calls to the pool's Allocate, but the
>> address it returns gets mangled by the compiler, when converted to the
>> pointer P [for example, when T is String]. So, having P I cannot get at my
>> dope. Its address should be
>>
>> A = P.all'Address - Offs
>>
>> where Offs is known, alas, to the compiler only. The compiler must know
>> that, otherwise it couldn't pass that to Deallocate.
> 
> So you want access to some compiler-dependent information; clearly the
> method will be compiler-dependent, since it isn't defined by the language.

No, I don't want to access it. I only want my information.

> What are you going to do with the "dopes" you add? They won't be
> visible from Ada.

That's exactly the goal, because what I want is to extend types in a way
Ada does not support. I wanted to add something to a type without
quarreling with Ada, which mistakenly [OK, that was a political decision]
does not support MI. It was corrected in Ada 2005 but only for pure
interfaces, while I need implementations. There is a vast number of cases
where it might be useful.

It seemed quite easy, thank to user-defined pools. Well, actually it is
spoiled a bit with pointers and generics, but that's another story. The
idea is as follows:

1. You define a pool which eventually takes its memory from some another
pool.

2. When something is allocated in the pool, you just add necessary data to
the allocated object in front of the allocated memory block

3. The interface to this is a generic package, which provides a pointer
type to the objects in the pool. [Unfortunately, the type of the pointer's
pool cannot be made opaque, but that is a minor language problem.]

4. New operations are defined on the pointer type.

It is clean and portable design, because all the functionality is hidden
behind the pointer type. It does not break the type allocated in the pool
in any way.

The only unexpected problem with this is that the compiler mangles pointers
and there seems to be no way to influence or learn how it does this.

I would suggest to introduce a new attribute X'Pool_Address which should
return the address, Unchecked_Deallocation would pass to Deallocate, but...

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