Re: Prologue and epilogue aspects

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

On 01/02/2018 01:17, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p4sm09$126n$1@gioia.aioe.org...
>> On 30/01/2018 23:02, Randy Brukardt wrote:
> ...
>>> Huh? If there is no implicit finalization, then there is no need for
>>> controlled types at all, as they serve no purpose. (If you want to
>>> explicitly finalize things, you can define any subprogram for that
>>> purpose.
>>
>> "Implicit" meant called upon implicit destruction, e.g. when access types
>> go out of the scope. That thing is not needed. I don't see other reason
>> for the Controlled_Interface to induce hidden components.
> 
> (1) Subpools and mutable types also need lists of some sort to properly do
> finalization.

No, they need not. The rule would be that all explicitly allocated 
objects of Controlled_Interface must be explicitly deallocated.

> (2) The reason for the "out of scope" rules is so that Finalization can be
> used for resource allocation beyond simply memory management. For instance,
> to return device (handles) to the OS when they won't be used any more. We
> felt that there shouldn't be any leaks in that.

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.

> (3) I think you would have to ban nested access types (that can go out of
> scope before program end) that designate type with parts of this kind of
> controlled type, lest the allocation of such objects lead to guarenteed
> storage leaks (one doesn't want to use Unchecked_Deallocation if they don't
> have to).

Of course I would let them leak. No implicit deallocation.

> (4) Chains for all controlled objects work best with exception handling, as
> it isn't necessary to enter every scope to try to clean up objects, and in
> particular, one doesn't have to deal with the horror of partially
> initialized objects (whose initialization was interrupted by an exception).

It is always a controlled object that goes out the scope. All 
dynamically allocated controlled objects are in some kind of controlled 
container or other controlled structure responsible to deallocate them. 
Everything ultimately hooked on some scoped controlled object. That is 
the only sane design, IMO.

> To use your static implementation, you also have to use a static
> implementation of exceptions, and somehow keep track of initialization of
> objects (and every part of such objects) in each scope.

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.

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