Re: Allocators and exceptions

[Maciej Sobczak <see.my.homepage@gmail.com>]

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.

If we assume that the exception is an unconditional indication of
wrong design, then we might as well drop exceptions from the language
altogether.

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

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

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

--
Maciej Sobczak
http://www.msobczak.com/