Re: Prologue and epilogue aspects

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

On 02/02/2018 00:47, Randy Brukardt wrote:

> Yes, but you need a list to explicitly deallocate a subpool (as there are
> many objects in the subpool). Or you could just ban the use of subpools, but
> that's madness.

If anybody wanted a sub-pool he would be responsible to make them work 
with his objects.

It is a stupid design anyway. When I must care about bulk deallocation I 
must be even more about bulk finalization.

>> I don't see how the feature would help. The only practical case when it
>> takes effect is when exiting from the program. At that point it does not
>> matter anyway.
> 
> It does if the underlying manager is primitive (as some RTOSes are) and
> there is no automatic closing of handles. (That was the case on CP/M and
> early MS-DOS, if one left files open when a program exited, they never got
> closed at all. Which could lead to data loss or resource exhaustion.)

I would never implement it that way. I don't know who would. If the OS 
does not collect dead resources, a responsible developer would design a 
resource manager for that, because most likely the OS handles would not 
work the way you described. There will be some obscure limitations 
regarding sharing them, contexts where you can create/release them, etc. 
The puny implicit finalization won't work anyway.

>> Of course I would let them leak. No implicit deallocation.
> 
> OK, but that's not the way Ada handles types with Storage_Size specified.

No problem either. It would be a bounded error. The memory would be 
reclaimed as for any plain type, Finalization not called, what you see 
is what you get.

> I'd rather they were illegal (most of the accessibility madness comes from
> allowing such types, and they're nearly useless).

I agree. The problem is that the access type is not a proper type with 
interfaces and classes. The language cannot manage referential semantics 
introduced by the programmer. There is no chance. So, it should leave 
that stuff alone.

Give me a plain pointer with no strings attached. And let me use a 
full-blown referential type in the contexts where an access type is 
expected. That is all, would cut the Ada RM in half, won't it? (:-))

>> Then the scope can maintain a list of objects it initialized. I see no
>> need to corrupt the object representation with list pointers in order to
>> merely roll back the stack.
> 
> That's what I called "fiendishly complex". Sure, it can be done, but you
> have to have a handler in every master with none trivial objects (regardless
> of whether there is any explicit exception handlers, of even if there can
> be). With the exception handing in our compiler, that would be a horrible
> drag on performance even if no handlers were used (state snapshots would be
> needed for each implicit handler, and handlers block optimizations as well,
> so a lot of unneeded checks wouldn't be identified).

I don't see why it so. It is trivial to allocate a list head in front of 
the stack allocated object rather than inside it.

> The only practical way to that is similar to the way that AdaCore does that
> (for both finalization and exception handling), which would be a 2-3 man
> year effort for any compiler vendor that isn't already using that scheme (so
> far as I know, that's most of the non-AdaCore vendors).
> 
> And I doubt that even the AdaCore scheme quite matches to your goals. Plus
> the lack of safety (there now are many ways to get skip finalization on
> objects), I don't see anyone being very interested. It makes more sense,
> honestly, to support full multiple inheritance.

I think almost all programmers are interested in safe initialization and 
finalization *with* rollback. This is the most important feature I can 
imagine. The present state when initialization and finalization is a 
minefield is simply unacceptable.

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