[boost] Re: Exception safety guarantie

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-17 07:14:00

"David B. Held" <dheld_at_[hidden]> writes:

> David Abrahams wrote:
>> [...]
>> It's fair game to:
>>   1. Explain in one place what it means to read elements from an
>> input
>>      sequence and create a new sequence and copy elements to it, and
>>   2. Just say that to_lower_copy gives the strong guarantee, with
>> the
>>      understanding that the algorithm has no control over what the
>>      input sequence does and so any side effects it causes are
>>      outside what's described by these requirements.

Just to be clear, these are not alternatives; they're meant to be
done together.

>> That's the basic tack taken by the standard.  No, it doesn't spell
>> everything out in agonizing detail for each function.  On the other
>> hand, the specification is understandable, and actually is very
>> explicit unless user-supplied operations have very unusual behaviors.
>
> If all the functions which offer the strong guarantee have the same
> form of creating a local and operating on that

The internal form of the documented functions is irrelevant.  It's
their external behavior that matters.

> then I agree that a central explanation is probably best.  I'm a
> little dissatisfied with 2, because it implies that using something
> like an istream iterator will no longer give you the strong
> guarantee, but it doesn't come right out and say so.  

Yes.  It's the strong guarantee "within the scope of control of the
algorithm".

> Probably nobody will assume beforehand that anything else would be
> the case, but it seems that it would be more clear just to say that
> if your iterators or c'tors have side effects, then you no longer
> get any guarantees at all.

Very bad idea.  There's no reason that the algorithm should give up
the basic guarantee in that case.  Consider:

    template <class InputIterator>
    std::vector::assign(InputIterator,InputIterator)

That really gives the basic guarantee with no hidden assumptions.

Now suppose we had written std::vector::assign with copy/swap
internally (it doesn't work that way, but just for the sake of
argument).  It's much more useful to say that it gives the strong
guarantee with the understanding that InputIterator's side effects
are out of the algorithm's control than it is to give up all
guarantees if InputIterator has side-effects.  

In case you think this is an "evil glossing over of detail", there are
actually lots of these assumptions lurking in standard requirements,
but they still work very well.  For example, if incrementing
InputIterator actually had the side-effect of modifying the vector,
how well do you think std::vector::assign would work?  How
understandable do you think the specification would be if all these
kinds of details were actually spelled out?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com