[boost] Re: Exception safety guarantie

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-18 02:12:52

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

> David Abrahams wrote:
>> [...]
>> 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.
>
> It assumes that there are no invariants that require, for instance,
> that all the input is consumed.

I hate to <sigh> because it's rude, but... <sigh>.  I don't know how
to explain this any better.

You have to make a distinction between layers of a system or you
couldn't give sensible guarantees for anything.  Your policy_ptr can
never call operator new if it's been replaced and the whole program
has an invariant that it is never called more than some fixed number
of times.  But of course your policy_ptr can't know anything about the
whole program invariants, so it can make guarantees at its level of
influence and knowledge.

>> [...]
>> In case you think this is an "evil glossing over of detail",
>
> I wouldn't call it "evil"...
>
>> 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?
>
> ...but I guess it's the difference between a theorist and an engineer.
> As a little of both, I would like to simultaneously argue for rigor
> and pragmatism. ;)

Fine, let's factor the niggly stuff needed to make the specification
rigorous out and put it in one place, rather than sprinkling it
through the documentation of each function.

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