"David B. Held" <dheld@codelogicconsulting.com> 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