Re: put of access type

["Randy Brukardt" <randy@rrsoftware.com>]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message 
news:4a8cea9c$1@news.post.ch...
> Randy Brukardt schrieb:
>> "Adam Beneschan" <adam@irvine.com> wrote in message
>> news:c9aec6d6-4e9b-4bf6-9586-68a237175c9d@i18g2000pro.googlegroups.com...
>> ...
>>> Also, there's no rule saying that an access value has to be an address
>>> at all.  It's certainly conceivable that an access value may be
>>> implemented as a reference to some storage pool and an offset into
>>> that pool, allowing for the possibility that the memory management
>>> system may just decide to pick up the whole pool and move it to some
>>> other address, without making any of the access values invalid.
>>
>> I think the Ada 95 definition of storage pools would make this
>> implementation hard to make work. (Which is unfortunate, it would have
>> worked fine in Ada 83).
>
> It still works:

I think you missed my point. The definition of the Allocate function for a 
storage pool returns an System.Address. Moreover, there is no notification 
when the access value returned from Allocate is dereferenced or converted to 
another access type. So if Allocate returns an offset rather than an 
address, the compiler generated code to implement .all and to implement 
conversions to anonymous access type is not going to take that into 
account -- it will think it received a System.Address. So this cannot work 
for any user-defined storage pool.

A compiler *could* implement something like this for the default storage 
pool. But that is exactly the case when you need a general implementation, 
so it seems rather pointless. But you can't do this with a user-defined 
storage pool. (I suppose a compiler could provide its own magic storage pool 
with these semantics, but it is unlikely to be worth the effort.)

                                                        Randy.