Re: Allocators and exceptions

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

On Tue, 11 Sep 2007 12:07:06 -0700, Maciej Sobczak wrote:

> On 11 Wrz, 14:27, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> This error is likely unrecoverable, so you have to reconsider your design
>> which allowed such errors.
> 
> I disagree. The error might be unrecoverable (like broken network
> cable), but might as well be worth retrying with modified parameters
> (like wrong credentials were provided by the user).
> Even in unrecoverable case I might want to gracefully reduce the
> functionality of the system. Sorry, there will be no music today, but
> please enjoy the party anyway - this sort of thing.

Sure, but your design does not allow this. And establishing connection upon
construction is a bad idea anyway.

>> BTW, formally everything is exactly as you wished! Observe, that
>>
>>    new T(-5)
>>
>> creates an object of the type T_Access. This object does not come to
>> existence and the compiler carefully eliminates any traces of this object.
>> Everything is fine!
> 
> Except of the memory leak and the already created other components.

Which is not T_Access's business.

>> What you actually want, but didn't say it, is that T_Access would take care
>> of the things it points to, so its constructor (new) would.
> 
> No. T_Access is not (yet) involved. This has to be handled entirely by
> the allocator, because the whole problem happens even before T_Access
> is assigned to my access variable.

"new" is a method of T_Access, it is not of T. That's the whole point. You
want some intimate relations between T_Access and T. But there is no
unified way to define them. The language offers you only raw pointers. you
have to add some meat to these pointers. The gears Ada has for this job are
quite rudimentary, namely ad-hoc polymorphism (overloaded subprograms). Not
much. If T_Access had a user-defined constructor, you could handle
deallocation of target there upon exception propagation. But it does not.

>>> This is what allows me to keep abstractions and invariants: either I
>>> have the complete object with its guaranteed invariants, or there is
>>> nothing. Anything in between is mess.
>>
>> This is violated upon aggregation of initialized components with side
>> effects. I don't argue that this is good, I only state that this is the
>> current language design and that it would be quite challenging to alter.
> 
> I understand that it cannot be changed. At least not shortly after the
> last standardization iteration. :-)
> 
> But... did I mention that C++ handles this issue correctly? ;-)
> And no, it does not have any super-capable access types. A little bit
> smarter allocator is enough.

Really?

class Foo
{
   Baz * A;
   Bar * B;

   Foo () : A (new Baz), B (new Bar) { ... throw ... }

If initialization of B fails, A will not be freed. After execution of
throw, neither A nor B will be freed. C++ does not handle it correctly, it
just does it a bit less incorrect. (:-))

Ada lacks a consistent unified construction model (one for *all* types).

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