Re: Controlled types and exception safety

[Maciej Sobczak <no.spam@no.spam.com>]

Randy Brukardt wrote:

> Right. Such a constructor ought to clean up its mess before propagating an
> exception. If it doesn't, you'll have memory leaks and other such badness.

Sure. This is clear and can be applied to all subroutines, not only 
constructors.


> Ada doesn't really have user-defined assignment; if you
> *really* need that you have to use a procedure.

OK, and now it's bright clear to me. I got an impression that Controlled 
types can buy me the same syntax sugar with the same flexibility in 
exception-safety guarantees that I have with assignment operators in 
C++. It's not bad that they don't - but I have to know it.

> And in any case, what you are asking for would be contrary to the efficiency
> goals of Ada. You're saying that all assignment *have to be* made to
> temporaries.

No. In my first post in this thread I have presented 4 levels of 
exception safety (some practitioners don't count level 0).
It's *me* (the designer of the type) who decides which level and which 
guarantee is appropriate for which operation, and what's more important, 
when it's *worth* its tradeoffs.

Interestingly, in the Stack example there is no performance tradeoff - 
you *have* to do both cleanup and state duplication anyway, no matter 
what's the provided guarantee, but by introducing the temporary object I 
can force the specific *order* of those operations (first duplicate, 
then clean up) that gives me the strong guarantee - which means 
commit-or-rollback. It's a free lunch in C++ and therefore there's no 
reason not to have it in types like string, stack, etc. In particular, 
there's no efficiency loss. OK, you can argue that in this scheme you 
have to first create a duplicate and then destroy the old state, which 
means that for some short period of time we consume more memory (which, 
funny, makes it more likely to fail because of memory shortage :) ) and 
that can result in lower cache hit rates and this kind of stuff. But as 
already said - it's *my* responsibility to judge the tradeoffs for each 
case separately. It's not true that this should be done everywhere.

> Ada's model is that a failed assignment leaves the target corrupt.

Which is equivalent to level 0 in the classification from the beginning 
of this thread. That's OK, as far as everybody knows it.

> In your example of a failed stack assignment, the Adjust routine ought to
> clean up the mess if Storage_Error is raised, and leave the target Stack
> empty.

Which would give level 1 (coherent state, no resources leaked).

> Moral: don't touch the left-hand side of any assignment after it failed
> raising an exception, other than to assign a new value to the *entire*
> value. If you want some other semantics, don't fool yourself and others by
> calling it ":="; use limited types and appropriate copying procedures.

Which is now clear.

The whole subject came from the fact that I want to learn Ada and that 
at some point I decided to write an "obligatory" exercise, which is a 
container or something like this. This led me to posing my questions. As 
usual, I've learnt something about Ada and that's actually what really 
matters. Thank you for all the replies.


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