Re: Controlled types and exception safety

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

Relevant Pages

  • Re: Why my application(exe) exit without any information
    ... It mean no exception dialog,no memory illegal access ... Stack corruption is one of the most typical reasons, ... Unhandled C++ exception ...
    (microsoft.public.vc.debugger)
  • Re: How to troubleshoot bugchecks on my own?
    ... To confirm, I would extract the exception record, from the stack, ... memory errors are close to impossible. ... You wrote "- to use verifier ON for suspicious driver". ...
    (microsoft.public.win32.programmer.kernel)
  • Controlled types and exception safety
    ... I can classify the stack's operations by assigning them any of the above four levels, so that I know what can be expected when an exception is thrown for any reason (like inability to allocate more memory, or alike). ... For example, if the Push method of the stack gives me the strong guarantee, then I *know* that by calling this method either the new element will be appended to the stack, or the stack will remain unchanged, so that even if the exception is thrown, I don't have to worry about the stack's internal consistency. ... Since stack can be a dynamic data structure, assigning one stack object to another may involve destroying one existing data structure *and* creating a new one in its place. ...
    (comp.lang.ada)
  • Re: Weird 0x80010105 error
    ... This is memory corruption at its best. ... code is not in the call stack. ... I will try to run my server in the debugger to ... >> I think it's very weird that the exception doesn't occur when I'm ...
    (microsoft.public.vc.atl)
  • Re: How to troubleshoot bugchecks on my own?
    ... not a memory problem. ... From that exception record and context, ... execute the instruction - without a problem. ...
    (microsoft.public.win32.programmer.kernel)