[boost] Re: Exception safety guarantie

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-15 08:01:59

Pavol Droba <droba_at_[hidden]> writes:

> Hi,
>
> During the review of the string_algo library, there was a request for better
> specification of exception safety in the lib.
>
> I have put some info into the docs, but I'm not sure if it is correct and sufficient.
> Could some of you, that had lead the discussion about this topic (namely David Abrahams or David B. Held)
> check it out and tell me your opinion?
> I'm open to any suggestions. I want to make it reasonable and correct.
>
> I have written a general paragraph about the basic guarantee here:
>
> http://tinyurl.com/639ex

Should probably link to
http://www.boost.org/more/generic_exception_safety.html there.

> and there are notes besides several algorithms like this:
> http://tinyurl.com/4yqp8

I don't know if you did something special or if it's BoostBook
convention, but the code font is unreadably small in FireFox when I
look at it with normal settings.

  template<typename OutputIteratorT, typename CollectionT> 
    OutputIteratorT 
    to_lower_copy(OutputIteratorT Output, const CollectionT & Input, 
                  const std::locale & Loc = std::locale());
  template<typename SequenceT> 
    SequenceT to_lower_copy(const SequenceT & Input, 
                            const std::locale & Loc = std::locale());

  Notes: If the input parameters satisfy the second assumption about
  exception safety, second variant of this function provides strong
  exception guarantee.

This is way too indirect.  What's "the second assumption about
exception safety"?

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.

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.

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