Re: Address of an object

[Stephen Leake <stephen_leake@stephe-leake.org>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> 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.

I don't understand. You want write-only data?

>> 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.

So you are trying to extend the Ada language. You should be editing
the compiler; that's one of the reasons GNAT is open source.

> 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. 

Actually, that's part of the reason MI isn't in Ada. You must consider
how it impacts the entire language.

> 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.]

So this generic package needs to read the data, from Ada. Or at least
provide a pointer to it, so other Ada packages can read it.

> 4. New operations are defined on the pointer type.

In Ada, or some other language?

> 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.

Read the source code for the compiler. Or ask the compiler vendor.

-- 
-- Stephe