|
Boost : |
From: Jaakko Jarvi (jajarvi_at_[hidden])
Date: 2004-05-21 10:33:22
On May 21, 2004, at 12:17 AM, Stephan T. Lavavej wrote:
> About two weeks ago I pointed out a fairly serious factual error in the
> Boost Lambda documentation, described here:
>
Here's your earlier message:
>
>
> > [1] Strictly taken, the C++ standard defines for_each as a
> > non-modifying sequence operation, and the function object
> > passed to for_each should not modify its argument. The
> > requirements for the arguments of for_each are unnecessary
> > strict, since as long as the iterators are mutable, for_each
> > accepts a function object that can have side-effects on their
> > argument. Nevertheless, it is straightforward to provide
> > another function template with the functionality
> > of std::for_each but more fine-grained requirements for its
> > arguments.
>
> This is incorrect, as well as having a typo.
> for_each is described as "non-modifying" in the Standard because it
> does not
> inherently modify sequences (contrast copy() and friends). However,
> the
> functor it takes can mutate its argument.
>
> This footnote must be removed.
I'm reading the standard back and forth and I do not agree with you.
I agree with the typo, but not that the footnote is inaccurate, and not
that if it is, it is fairly serious.
25.1.(5)
If an algorithms Effects section says that a value pointed to by any
iterator passed as an argument is modified,
then that algorithm has an additional type requirement: The type of
that argument shall satisfy the
requirements of a mutable iterator (24.1).
The effects clause of for_each does not say that the value pointed to
by any iterator passed as an argument is modified,
which leads me to conclude that a conforming implementation is free to
implement for_each in a way that does not allow
modifications to the values pointed to by the iterators.
What do you mean by "inherently mutating sequences"? Does std::replace
inherently modidfy sequences?
Best, Jaakko
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk