Janus/Ada uses chains for everything; there is no attempt to do anything
else. They make dealing with partially initialized objects (when some
initialization fails) much easier, and are strongly related to the lists of
allocated memory that Janus/Ada uses anyway.

It's easy to deal with a stand-alone controlled object, but when you have
components of dynamic components of dynamically sized object and have to
deal with failures and allocated objects, the headaches just aren't worth it
(IMHO). The cost is insignificant unless you actually have controlled
objects, so you only pay for what you use (to steal a line from a commercial
that runs far too often in the US).

Randy.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:si2ud7$fv2$1@gioia.aioe.org...
> On 2021-09-17 21:46, Simon Wright wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>> Nope, especially because the issue with X'Address being unusable for
>>> memory pool developers is a long standing painful problem that need to
>>> be resolved. That will never happen until a measurable group of people
>>> start asking questions. So you are doubly welcome.
>>
>> There are two attributes that we should all have known about,
>> Descriptor_Size[1] (bits, introduced in 2011) and Finalization_Size[2]
>> (storage units, I think, introduced in 2017)
>
> They are non-standard and have murky semantics I doubt anybody really
> cares about.
>
> What is needed is the address passed to Deallocate should the object be
> freed = the address returned by Allocate. Is that too much to ask?
>
> BTW, finalization lists (#2) should have been removed from the language
> long ago. They have absolutely no use, except maybe for debugging, and
> introduce huge overhead. The semantics should have been either
> Unchecked_Deallocation or compiler allocated objects/components may call
> Finalize, nothing else.
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

There is: Restriction No_Controlled_Types. - Randy

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:si45ls$1goa$1@gioia.aioe.org...
> On 2021-09-17 23:17, Niklas Holsti wrote:
>> On 2021-09-17 23:39, Dmitry A. Kazakov wrote:
>>> On 2021-09-17 21:46, Simon Wright wrote:
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>
>>>>> Nope, especially because the issue with X'Address being unusable for
>>>>> memory pool developers is a long standing painful problem that need to
>>>>> be resolved. That will never happen until a measurable group of people
>>>>> start asking questions. So you are doubly welcome.
>>>>
>>>> There are two attributes that we should all have known about,
>>>> Descriptor_Size[1] (bits, introduced in 2011) and Finalization_Size[2]
>>>> (storage units, I think, introduced in 2017)
>>>
>>> They are non-standard and have murky semantics I doubt anybody really
>>> cares about.
>>>
>>> What is needed is the address passed to Deallocate should the object be
>>> freed = the address returned by Allocate. Is that too much to ask?
>>
>> That is already required by RM 13.11(21.7/3): "The value of the
>> Storage_Address parameter for a call to Deallocate is the value returned
>> in the Storage_Address parameter of the corresponding successful call to
>> Allocate."
>
> You missed the discussion totally. It is about X'Address attribute.
>
> The challenge: write pool with a function returning object allocation time
> by its pool-specific access type.
>
>>> BTW, finalization lists (#2) should have been removed from the language
>>> long ago.
>>
>> Huh? Where does the RM _require_ finalization lists?
>
> 7.6.1 (11 1/3)
>
>> I see them mentioned here and there as a _possible_ implementation
>> technique, and an alternative "PC-map" technique is described in RM 7.6.1
>> (24.r .. 24.t).
>
> I don't care about techniques to implement meaningless stuff. It should be
> out, at least there must be a representation aspect for turning this mess
> off.
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:si4ell$1b25$1@gioia.aioe.org...
....
>> Given that an object can be allocated in multiple independent pieces, it
>> seems unlikely that what you want will be provided.
>
> Such implementations would automatically disqualify the compiler.
> Compiler-generated piecewise allocation is OK for the stack, not for user
> storage pools.

If someone wants to require contigious allocation of objects, there should
be a representation attribute to specify it. And there should not be an
nonsense restrictions on records with defaulted discriminants unless you
specify that you require contiguous allocation. There is no good reason to
need that for 99% of objects, why insist on a very expensive implementation
of slices/unconstrained arrays unless it's required??

....
> No, it is about the overhead of maintaining "collections" associated with
> an access type in order to call Finalization for all members of the
> collection.

How else would you ensure that Finalize is always called on an allocated
object? Unchecked_Deallocation need not be called on an allocated object.
The Ada model is that Finalize will ALWAYS be called on every controlled
object before the program ends; there are no "leaks" of finalization.
Otherwise, one cannot depend on finalization for anything important; you
would often leak resources (especially for simple kernels that don't try to
free unreleased resources themselves).

Randy.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:si77kd$rka$1@gioia.aioe.org...
> On 2021-09-19 12:36, Niklas Holsti wrote:
....
>> Local variables declared in a subprogram are also not explicitly freed
>> (deallocated), yet they are automatically finalized when the subprogram
>> returns.
>
> Local objects are certainly freed. Explicit or not, aggregated or not, is
> irrelevant.

OK...

>> My understanding of Ada semantic principles is that any object that is
>> initialized should also be finalized.
>
> IFF deallocated.

....as you note above for stack objects, all objects are conceptually
deallocated. Whether the memory is actually returned to a storage pool is
irrelevant.

The original Ada model was that Unchecked_Deallocation is something to be
avoided if at all possible (thus the name), one would never want to tie
finalization to such a thing.

Randy.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:si77kd$rka$1@gioia.aioe.org...
....
> 1. It is a massive overhead in both memory and performance terms with no
> purpose whatsoever. I fail to see where that sort of thing might be even
> marginally useful.

The classic example of Finalization is file management on a simple kernel (I
use CP/M as the example in my head). CP/M did not try to recover any
resources on program exit, it was the programs responsibility to recover
them all (or reboot after every run). If you had holes in finalization, you
would easily leak files and since you could only open a limited number of
them at a time, you could easily make a system non-responsive.

You get similar things on some embedded kernels.

If you only write programs that live in ROM and never, ever terminate, then
you probably have different requirements. Most likely, you shouldn't be
using Finalization at all (or at least not putting such object in allocated
things).

....
> 2. What is worse that a collection is not bound to the pool. It is to an
> access type, which may have a narrower scope. So the user could declare an
> unfortunate access type, which would corrupt objects in the pool and the
> pool designer has no means to prevent that.

Pools are extremely low-level things that cannot be safe in any sense of the
word. A badly designed pool will corrupt everything. Using a pool with the
"wrong" access type generally has to be programmed for (as I answered
earlier, if I assume anything about allocations, I check for violations and
do something else.) And a pool can be used with many access types; many
useful ones are.

Some of what you want is provided by the subpool mechanism, but it is even
more complex at runtime, so it probably doesn't help you.

Randy.

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:iqqtskF3losU1@mid.individual.net...
> On 2021-09-20 10:35, Dmitry A. Kazakov wrote:
>> On 2021-09-20 09:05, Niklas Holsti wrote:
>
>
> [snipping context]
>
>
>>> However, your semantic argument (as opposed to the overhead argument)
>>> seems to be based on an assumption that the objects "left over" in a
>>> local collection, and which thus are inaccessible, will still, somehow,
>>> participate in the later execution of the program, which is why you say
>>> that finalizing those objects would "corrupt" them.
>>>
>>> It seems to me that such continued participation is possible only if the
>>> objects contain tasks or are accessed through some kind of unchecked
>>> programming. Do you agree?
>>
>> No. You can have them accessible over other access types with wider
>> scopes:
>>
>> Collection_Pointer := new X;
>> Global_Pointer := Collection_Pointer.all'Unchecked_Access;
>>
>
>
> So, unchecked programming, as I said.

Yup, and when you do stuff like that, you deserve for the compiler to shoot
you in the head.

Randy.

User calls on Initialize and Finalize have no special meaning; they're
igorned for the purposes of language-defined finalization. The fact that
they're normal routines and can be called by someone else means that some
defensive programming is needed. That all happened because of the "scope
reduction" of Ada 9x; the dedicated creation/finalization mechanism got
dumped. Finalization was too important to lose completely, so Tucker cooked
up the current much simpler mechanism in order to avoid the objections. It's
not ideal for that reason -- but Finalize would still have been a normal
subprogram that anyone could call (what else could it have been -- the
mechanism of stream attributes could have been used instead). I don't think
there is a way that one could have prevented user-defined calls to these
routines (even if they had a special name, you still could have renamed an
existing subprogram to the special name).

Randy.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:si9gnb$926$1@gioia.aioe.org...
> On 2021-09-20 10:08, Niklas Holsti wrote:
>> On 2021-09-20 10:35, Dmitry A. Kazakov wrote:
>
>>> No. You can have them accessible over other access types with wider
>>> scopes:
>>>
>>> Collection_Pointer := new X;
>>> Global_Pointer := Collection_Pointer.all'Unchecked_Access;
>>>
>> So, unchecked programming, as I said.
>
> Right, working with pools is all that thing. Maybe "new" should be named
> "unchecked_new" (:-))
>
> Finalize and Initialize certainly should have been Unchecked_Finalize and
> Unchecked_Initialize as they are not enforced. You can override the
> parent's Initialize and never call it. It is a plain primitive operations
> anybody can call any time any place. You can even call it before the
> object is fully initialized!
>
> So, why bother with objects the user manually allocates (and forgets to
> free)?
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

A better solution would be to know the size of those bounds objects and
treat them differently (I've done that). And the next allocation is going to
be the data, so I don't do anything special for them. Probably would be nice
to have an attribute for that. But no one has ever asked for any such thing,
so I haven't defined anything.

Such pools are highly implementation specific, so I haven't worried about
this much..

Randy.

"Emmanuel Briot" <briot.emmanuel@gmail.com> wrote in message
news:44be7c73-f69e-45da-9916-b14a43a05ea3n@googlegroups.com...
>> > If a compiler is allowed to break up an allocation into multiple
>> > calls to Allocate (and of course Deallocate), how does one go about
>> > enforcing that the user's header is only created once?
>> I think one cannot enforce that, because the calls to Allocate do not
>> indicate (with parameters) which set of calls concern the same object
>> allocation.
>
> I think the only solution would be for this compiler to have another
> attribute similar to 'Storage_Pool, but that would define the pool for the
> descriptor:
>
> for X'Storage_Pool use Pool;
> for X'Descriptor_Storage_Pool use Other_Pool;
>
> That way the user can decide when to add (or not) extra headers.

On 2021-09-21 02:37, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:si77kd$rka$1@gioia.aioe.org...
> ...
>> 1. It is a massive overhead in both memory and performance terms with no
>> purpose whatsoever. I fail to see where that sort of thing might be even
>> marginally useful.
>
> The classic example of Finalization is file management on a simple kernel (I
> use CP/M as the example in my head). CP/M did not try to recover any
> resources on program exit, it was the programs responsibility to recover
> them all (or reboot after every run). If you had holes in finalization, you
> would easily leak files and since you could only open a limited number of
> them at a time, you could easily make a system non-responsive.

This is why system resources are handled by the OS rather than by the
application. But I do not see how this justifies "collections."

>> 2. What is worse that a collection is not bound to the pool. It is to an
>> access type, which may have a narrower scope. So the user could declare an
>> unfortunate access type, which would corrupt objects in the pool and the
>> pool designer has no means to prevent that.
>
> Pools are extremely low-level things that cannot be safe in any sense of the
> word. A badly designed pool will corrupt everything. Using a pool with the
> "wrong" access type generally has to be programmed for (as I answered
> earlier, if I assume anything about allocations, I check for violations and
> do something else.) And a pool can be used with many access types; many
> useful ones are.

This is also true, but again unrelated to the point that tying
finalization *without* deallocation to a pointer type is just wrong,
semantically on any abstraction level.

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

On 2021-09-21 02:26, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:si4ell$1b25$1@gioia.aioe.org...
> ...
>>> Given that an object can be allocated in multiple independent pieces, it
>>> seems unlikely that what you want will be provided.
>>
>> Such implementations would automatically disqualify the compiler.
>> Compiler-generated piecewise allocation is OK for the stack, not for user
>> storage pools.
>
> If someone wants to require contigious allocation of objects, there should
> be a representation attribute to specify it.

It would be difficult, because the types are declared prior to pools.
That is when object layout does change.

If the layout does not then you need no attribute.

You can always run a mock allocation to compute overall size and offsets
to the pieces and then do one true allocation. And with stream
attributes you need to implement introspection anyway. So this might
have been an issue for Ada 83, but now one can simply require contiguous
allocation in pools.

> And there should not be an
> nonsense restrictions on records with defaulted discriminants unless you
> specify that you require contiguous allocation.

You can keep the object layout. It is only the question of "trolling"
the pool, no how objects are represented there.

>> No, it is about the overhead of maintaining "collections" associated with
>> an access type in order to call Finalization for all members of the
>> collection.
>
> How else would you ensure that Finalize is always called on an allocated
> object?

I would not, because it is plain wrong. Finalize must be called for each
*deallocated* object.

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

It's ok! I realize I am not great at wording questions, so I just assume
I asked it poorly. If it helps, your response did get me thinking more
about the specifics of contiguous allocation vs not and how it would
affect my design, which didn't even cross my mind before.

On Monday, September 20, 2021 at 7:51:17 PM UTC-4, Randy Brukardt wrote:
> Sorry about that, I didn't understand what you were asking. And I get
> defensive about people who think that a pool should get some specific Size
> (and only that size), so I leapt to a conclusion and answered accordingly.
>
> The compiler requests all of the memory IT needs, but if the pool needs some
> additional memory for it's purposes (pretty common), it will need to add
> that space itself. It's hard to imagine how it could be otherwise, I guess I
> would have thought that goes without saying. (And that rather proves that
> there is nothing that goes without saying.)
>
> Randy.
>
> "Jere" <> wrote in message
> news:96e7199f-c354-402f...@googlegroups.com...
> > On Wednesday, September 15, 2021 at 3:01:52 AM UTC-4, Simon Wright wrote:
> >> Jere <> writes:
> >>
> >> > Thanks for the response. I'm sorry for all the questions. That's how
> >> > I learn and I realize it isn't a popular way to learn in the
> >> > community, but I have always learned very differently than most.
> >> Seems to me you ask interesting questions which generate enlightening
> >> responses!
> > Thanks! though in this case, my question was ill formed after I missed a
> > detail
> > in the blog, so the mistake is on me. I will say I hold back some
> > questions
> > as it is very intimidating to ask on C.L.A. I mean the first response led
> > off
> > with "Not sure what you are expecting" so it is hard to know how to
> > formulate
> > a good question as I always seem to get some harsh responses (which I am
> > sure is because I asked the question poorly). I'm unfortunately a very
> > visual
> > person and words are not my forte and I feel like when I ask questions
> > about
> > the boundaries of the language I manage to put folks on the defensive. I
> > don't dislike Ada at all, it is my favorite language, but I think it is
> > hard to
> > craft questions on some topics without putting forth the impression that
> > I don't like it, at least with my limited ability to word craft.

I think the only thing that misses is scenarios where the compiler vendor
isn't allocating a descriptor/bounds but is still using multiple allocations for the
object. I don't know if that is a practical use, but it is one the RM allows? If
so, it is probably more useful to know if a specific Allocate call is somehow
a unique call relative to the others (the first call, the last call, etc.) so that the
developer could earmark that one to be the one to add the custom header
to.

We can't change the Allocate specification since it is what it is, but is there
any consideration to adding functionality to the root storage pool type,
maybe a classwide function that lets the compiler developer set an internal
flag for that unique allocation and a classwide function for the storage
pool developer to see if that flag was set for the allocation. Or some other
mechanism. It seems like this would need to be some sort of runtime
mechanism if the multiple allocations can occur in the absence of needing
a descriptor or bounds.

Or maybe a generic version of the Storage_Pools package that allows a
header type to be specified, that gives the compiler vendor some
interface that easily facilitates allocating the header along side any object
at the time and place the vendor finds convenient, and provides the
custom storage pool implementer a means of knowing when that happens
so they can initialize the header in the allocate function that creates it.

I'm obviously not a compiler developer so I don't know the practicalness
of any of that. But I think one root problem for a custom storage pool
developer is "when is it safe to make a custom header for my object?".

On Monday, September 20, 2021 at 8:50:41 PM UTC-4, Randy Brukardt wrote:
> A better solution would be to know the size of those bounds objects and
> treat them differently (I've done that). And the next allocation is going to
> be the data, so I don't do anything special for them. Probably would be nice
> to have an attribute for that. But no one has ever asked for any such thing,
> so I haven't defined anything.
>
> Such pools are highly implementation specific, so I haven't worried about
> this much..
>
> Randy.
>
> "Emmanuel Briot" <> wrote in message
> news:44be7c73-f69e-45da...@googlegroups.com...
> >> > If a compiler is allowed to break up an allocation into multiple
> >> > calls to Allocate (and of course Deallocate), how does one go about
> >> > enforcing that the user's header is only created once?
> >> I think one cannot enforce that, because the calls to Allocate do not
> >> indicate (with parameters) which set of calls concern the same object
> >> allocation.
> >
> > I think the only solution would be for this compiler to have another
> > attribute similar to 'Storage_Pool, but that would define the pool for the
> > descriptor:
> >
> > for X'Storage_Pool use Pool;
> > for X'Descriptor_Storage_Pool use Other_Pool;
> >
> > That way the user can decide when to add (or not) extra headers.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:sibvcr$1ico$1@gioia.aioe.org...
> On 2021-09-21 02:26, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:si4ell$1b25$1@gioia.aioe.org...
>> ...
>>>> Given that an object can be allocated in multiple independent pieces,
>>>> it
>>>> seems unlikely that what you want will be provided.
>>>
>>> Such implementations would automatically disqualify the compiler.
>>> Compiler-generated piecewise allocation is OK for the stack, not for
>>> user
>>> storage pools.
>>
>> If someone wants to require contigious allocation of objects, there
>> should
>> be a representation attribute to specify it.
>
> It would be difficult, because the types are declared prior to pools. That
> is when object layout does change.
>
> If the layout does not then you need no attribute.
>
> You can always run a mock allocation to compute overall size and offsets
> to the pieces and then do one true allocation. And with stream attributes
> you need to implement introspection anyway. So this might have been an
> issue for Ada 83, but now one can simply require contiguous allocation in
> pools.
>
>> And there should not be an
>> nonsense restrictions on records with defaulted discriminants unless you
>> specify that you require contiguous allocation.
>
> You can keep the object layout. It is only the question of "trolling" the
> pool, no how objects are represented there.
>
>>> No, it is about the overhead of maintaining "collections" associated
>>> with
>>> an access type in order to call Finalization for all members of the
>>> collection.
>>
>> How else would you ensure that Finalize is always called on an allocated
>> object?
>
> I would not, because it is plain wrong. Finalize must be called for each
> *deallocated* object.

Deallocation is irrelevant. Finalization is called when objects are about to
be destroyed, by any method. Otherwise, you do not have watertight
finalization, and it is near impossible to use it for anything important.

Randy.

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:sibu1t$12ds$1@gioia.aioe.org...
> On 2021-09-21 02:37, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:si77kd$rka$1@gioia.aioe.org...
>> ...
>>> 1. It is a massive overhead in both memory and performance terms with no
>>> purpose whatsoever. I fail to see where that sort of thing might be even
>>> marginally useful.
>>
>> The classic example of Finalization is file management on a simple kernel
>> (I
>> use CP/M as the example in my head). CP/M did not try to recover any
>> resources on program exit, it was the programs responsibility to recover
>> them all (or reboot after every run). If you had holes in finalization,
>> you
>> would easily leak files and since you could only open a limited number of
>> them at a time, you could easily make a system non-responsive.
>
> This is why system resources are handled by the OS rather than by the
> application. But I do not see how this justifies "collections."

Ada programs need no OS; they're really only useful for (abstracted) I/O,
for everything else, they're mainly in the way.

>>> 2. What is worse that a collection is not bound to the pool. It is to an
>>> access type, which may have a narrower scope. So the user could declare
>>> an
>>> unfortunate access type, which would corrupt objects in the pool and the
>>> pool designer has no means to prevent that.
>>
>> Pools are extremely low-level things that cannot be safe in any sense of
>> the
>> word. A badly designed pool will corrupt everything. Using a pool with
>> the
>> "wrong" access type generally has to be programmed for (as I answered
>> earlier, if I assume anything about allocations, I check for violations
>> and
>> do something else.) And a pool can be used with many access types; many
>> useful ones are.
>
> This is also true, but again unrelated to the point that tying
> finalization *without* deallocation to a pointer type is just wrong,
> semantically on any abstraction level.

If you didn't finalize everything, then a system like Claw would not work,
since there would be objects that would have gotten destroyed (when the
access type goes out of scope) and would still be on the various active
object chains. (The whole reason that these things are controlled is so that
they can be added to and removed from object chains as needed.)

Now, you could say that no one should be declaring access types locally in
subprograms -- I'd agree with that, but it isn't Ada.

Even if your semantics only happened for library-level access types, then
you'd still have problems when library-level objects go away. I suppose you
could say those never go away either -- but again, that only makes sense for
programs that never terminate. On Windows, you would have a mess.

Randy.

"Jere" <jhb.chat@gmail.com> wrote in message
news:6a073ced-4c3b-4e87-8063-555a93a5c3f6n@googlegroups.com...
....
> We can't change the Allocate specification since it is what it is, but is
> there
> any consideration to adding functionality to the root storage pool type,

We tried that as a solution for the user-defined dereference problem, and it
ended up going nowhere. Your problem is different but the issues of changing
the Storage_Pool spec remain. Not sure it could be made to work (one does
not want to force everyone to change their existing storage pools).

Randy.

On 2021-09-28 06:31, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:sibvcr$1ico$1@gioia.aioe.org...
>> On 2021-09-21 02:26, Randy Brukardt wrote:

>>> How else would you ensure that Finalize is always called on an allocated
>>> object?
>>
>> I would not, because it is plain wrong. Finalize must be called for each
>> *deallocated* object.
>
> Deallocation is irrelevant. Finalization is called when objects are about to
> be destroyed, by any method.

And no object may be destroyed unless deallocated.

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

On 2021-09-28 06:38, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:sibu1t$12ds$1@gioia.aioe.org...

>> This is also true, but again unrelated to the point that tying
>> finalization *without* deallocation to a pointer type is just wrong,
>> semantically on any abstraction level.
>
> If you didn't finalize everything, then a system like Claw would not work,
> since there would be objects that would have gotten destroyed (when the
> access type goes out of scope) and would still be on the various active
> object chains. (The whole reason that these things are controlled is so that
> they can be added to and removed from object chains as needed.)

I did not say that the pointer type going out of scope should free
objects allocated though it. I said that it should not finalize
anything. It must simply silently die not touching anything.

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

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

> On 2021-09-28 06:31, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:sibvcr$1ico$1@gioia.aioe.org...
>>> On 2021-09-21 02:26, Randy Brukardt wrote:
>
>>>> How else would you ensure that Finalize is always called on an allocated
>>>> object?
>>>
>>> I would not, because it is plain wrong. Finalize must be called for each
>>> *deallocated* object.
>> Deallocation is irrelevant. Finalization is called when objects are
>> about to
>> be destroyed, by any method.
>
> And no object may be destroyed unless deallocated.

Well, if it's important that an allocated object not be destroyed, don't
allocate it from a storage pool that can go out of scope!

On 2021-09-28 09:52, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> And no object may be destroyed unless deallocated.
>
> Well, if it's important that an allocated object not be destroyed, don't
> allocate it from a storage pool that can go out of scope!

That was never the case.

The case is that an object allocated in a pool gets finalized because
the access type (not the pool!) used to allocate the object goes out of
the scope.

This makes no sense whatsoever.

Again, finalization must be tied with [logical] deallocation. Just like
initialization is with allocation.

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:siuigp$bqs$1@gioia.aioe.org...
> On 2021-09-28 09:52, Simon Wright wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>>> And no object may be destroyed unless deallocated.
>>
>> Well, if it's important that an allocated object not be destroyed, don't
>> allocate it from a storage pool that can go out of scope!
>
> That was never the case.
>
> The case is that an object allocated in a pool gets finalized because the
> access type (not the pool!) used to allocate the object goes out of the
> scope.
>
> This makes no sense whatsoever.
>
> Again, finalization must be tied with [logical] deallocation. Just like
> initialization is with allocation.

But it is. All of the objects allocated from an access type are logically
deallocated when the access type goes out of scope (and the memory can be
recovered). Remember that Ada was designed so that one never needs to use
Unchecked_Deallocation.

I could see an unsafe language (like C) doing the sort of thing you suggest,
but not Ada. Every object in Ada has a specific declaration point,
initialization point, finalization point, and destruction point. There are
no exceptions.

Randy.

On 2021-09-29 00:04, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:siuigp$bqs$1@gioia.aioe.org...
>> On 2021-09-28 09:52, Simon Wright wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>>> And no object may be destroyed unless deallocated.
>>>
>>> Well, if it's important that an allocated object not be destroyed, don't
>>> allocate it from a storage pool that can go out of scope!
>>
>> That was never the case.
>>
>> The case is that an object allocated in a pool gets finalized because the
>> access type (not the pool!) used to allocate the object goes out of the
>> scope.
>>
>> This makes no sense whatsoever.
>>
>> Again, finalization must be tied with [logical] deallocation. Just like
>> initialization is with allocation.
>
> But it is. All of the objects allocated from an access type are logically
> deallocated when the access type goes out of scope (and the memory can be
> recovered).

Really? And where is the call to the pool's Deallocate in that case? You
cannot have it both ways.

> Remember that Ada was designed so that one never needs to use
> Unchecked_Deallocation.

Come on. There never existed Ada compiler with GC. And nobody could even
implement GC with the meaningless semantics of "collections" in the way,
killing objects at random. Either with GC or without it, there must be
no such thing as "collections."

> I could see an unsafe language (like C) doing the sort of thing you suggest,
> but not Ada.

How random finalizing user-allocated and user-freed objects is safe?

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?

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

On Wednesday, September 29, 2021 at 1:57:35 AM UTC-6, Dmitry A. Kazakov wrote:
> Come on. There never existed Ada compiler with GC.
Untrue; GNAT for JVM, and GNAT for DOTNET.

> And nobody could even
> implement GC with the meaningless semantics of "collections" in the way,
> killing objects at random. Either with GC or without it, there must be
> no such thing as "collections."
How does this follow?
The 'element' type cannot go out of scope before the collection, and the collection going out of scope triggers its finalization/deallocation.

> > I could see an unsafe language (like C) doing the sort of thing you suggest,
> > but not Ada.
> How random finalizing user-allocated and user-freed objects is safe?
Finalization *isn't* random, it happens at well-defined places.
(And, IIRC, is idempotent; meaning that multiple calls have the same effect as a singular call.)

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

On 2021-09-29 16:41, Shark8 wrote:
> On Wednesday, September 29, 2021 at 1:57:35 AM UTC-6, Dmitry A. Kazakov wrote:
>> Come on. There never existed Ada compiler with GC.
> Untrue; GNAT for JVM, and GNAT for DOTNET.

Neither is full Ada, AFAIK.

>> And nobody could even
>> implement GC with the meaningless semantics of "collections" in the way,
>> killing objects at random. Either with GC or without it, there must be
>> no such thing as "collections."
> How does this follow?

Because the rule disregards any object use. No collector, manual or
automatic can deal with that mess.

> Finalization *isn't* random, it happens at well-defined places.

Random = unrelated to the object's life time.

> (And, IIRC, is idempotent; meaning that multiple calls have the same effect as a singular call.)

Which is obviously not.

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

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

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

On 2021-09-30 02:16, Randy Brukardt wrote:
> "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.

The type of the access type /= the type of object. Only access objects
must disappear and they do.

> It's probably a lousy idea to share pool objects (as opposed to pool types)
> amongst access types.

You need these for access discriminants.

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

Nope, this is exactly how it works with most specialized pools, like
arenas, stacks, reference counting pools etc.

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

So is Finialize.

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

See above, these are different objects of different types. The actual
object type is alive and well (unless killed by some collection).

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