Boost logo

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 algorithm’s 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