Re: Custom Storage Pool questions

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:sj2008$1cmo$1@gioia.aioe.org...
...
> Random = unrelated to the object's life time.

All objects have to disappear before their type disappears, so the object 
*cannot* live longer than the access type for which it is allocated from. 
Any use of the object after that point is erroneous, so Finalization has to 
happen before it as well.

It's probably a lousy idea to share pool objects (as opposed to pool types) 
amongst access types. The pool object should have the same lifetime as the 
access type (we require that for subpools specifically because finalization 
doesn't make sense any other way). A similar rule should have been enforced 
for all pools, but it would be incompatible (alas).

If you do have a longer lived pool and a shorter lived access type, you will 
end up with a bunch of zombie objects in the pool that cannot be used in any 
way (as any access is erroneous). All that can happen is a memory leak. 
Don't do that.

...
>>> And I suggest doing exactly nothing as opposed to *unsafe*, costly and
>>> meaningless behavior mandated by the standard now.
>>>> Every object in Ada has a specific declaration point,
>>>> initialization point, finalization point, and destruction point. There 
>>>> are
>>>> no exceptions.
>>> Yes, and how it that related to the issue?
>> Because these are the places that finalization (and 
>> deallocation/destruction) are defined to happen.
>
> So? How exactly any of this implies that the place of Finalization can be 
> in a place other than the place of deallocation?

Deallocation is at most a convinience in Ada; it isn't even required to do 
anything. One never can assume anything is actually recovered, so it is not 
a meaningful concept semantically.

OTOH, object destruction happens before the type goes away, and finalization 
happens before that. That is the point here.

                              Randy.