for_each

[Fraser Ross]

Is it wrong to describe for_each as a modifying algorithm? It is
described as one here: http://www.josuttis.com/libbook/algolist.pdf.
transform appears to be the algorithm to use for modifying elements in a
range.

Fraser.

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

[Daniel T.]

"Fraser Ross" <fraserATmember s.v21.co.ukwrot e:

>"Daniel T."

>for_each is a non-modifying algorithm does not explicitly modify the
contents of the container. The functor passed into for_each might, but
the algorithm doesn't.

I think the intention is that although the algorithm doesn't prevent
modification it is expected anyway that the functor does not modify
elements.

The rule of non-modifying vs modifying is amazingly simple. All
modifying sequences algorithms call op= on the elements in at least one
of the sequences it operates on, non-modifying sequence algorithms
don't. As such, for_each is a non-modifying sequence algorithm. The
*algorithm* doesn't modify any of the elements of the sequence (even if
the functor passed in does.)

--
There are two things that simply cannot be doubted. Logic and our
ability to sense the world around us. Doubt those, and you no longer
have anyone to discuss it with, nor any ability to discuss it.

[Pete Becker]

Daniel T. wrote:

"Fraser Ross" <fraserATmember s.v21.co.ukwrot e:

>"Daniel T."

>>for_each is a non-modifying algorithm does not explicitly modify the
contents of the container. The functor passed into for_each might, but
the algorithm doesn't.

I think the intention is that although the algorithm doesn't prevent
modification it is expected anyway that the functor does not modify
elements.

The rule of non-modifying vs modifying is amazingly simple. All
modifying sequences algorithms call op= on the elements in at least one
of the sequences it operates on, non-modifying sequence algorithms
don't. As such, for_each is a non-modifying sequence algorithm. The
*algorithm* doesn't modify any of the elements of the sequence (even if
the functor passed in does.)

sort also doesn't modify any elements, but it's a modifying sequence
operation. That's because it changes the order of the elements in the
passed sequence. That's the distinction between non-modifying sequence
operations and modifying sequence operations.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

[Daniel T.]

Pete Becker <pe********@acm .orgwrote:

Daniel T. wrote:

>"Fraser Ross" <fraserATmember s.v21.co.ukwrot e:

>>"Daniel T."

>>>for_each is a non-modifying algorithm does not explicitly modify
the contents of the container. The functor passed into for_each
might, but the algorithm doesn't.
I think the intention is that although the algorithm doesn't
prevent modification it is expected anyway that the functor does
not modify elements.

The rule of non-modifying vs modifying is amazingly simple. All
modifying sequences algorithms call op= on the elements in at least
one of the sequences it operates on, non-modifying sequence
algorithms don't. As such, for_each is a non-modifying sequence
algorithm. The *algorithm* doesn't modify any of the elements of
the sequence (even if the functor passed in does.)

sort also doesn't modify any elements, but it's a modifying sequence
operation.

'sort' does modify the elements in the sequence. Here is my proof, the
below won't compile because sort needs to be able to modify the
elements, and objects of type Object can't be modified.

class Object
{
Object& operator=( const Object& o ); // I can't be modified.
public:
int v;
Object(): v( rand() ) { }
};

bool operator<( const Object& lhs, const Object& rhs )
{
return lhs.v < rhs.v;
}

int main()
{
vector< Object vec( 25 );
sort( vec.begin(), vec.end() );
}

--
There are two things that simply cannot be doubted. Logic and our
ability to sense the world around us. Doubt those, and you no longer
have anyone to discuss it with, nor any ability to discuss it.

[Jerry Coffin]

In article <da************ *************** *@news.west.ear thlink.net>,
da******@earthl ink.net says...

[ ... ]

'sort' does modify the elements in the sequence. Here is my proof, the
below won't compile because sort needs to be able to modify the
elements, and objects of type Object can't be modified.

class Object
{
Object& operator=( const Object& o ); // I can't be modified.
public:
int v;
Object(): v( rand() ) { }
};

All your code proves is that you're apparently unaware of the
requirement in section 23.1/3 that anything you store in a vector be
assignable.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Daniel T.]

Jerry Coffin <jc*****@taeus. comwrote:

da******@earthl ink.net says...

[ ... ]

'sort' does modify the elements in the sequence. Here is my proof, the
below won't compile because sort needs to be able to modify the
elements, and objects of type Object can't be modified.

class Object
{
Object& operator=( const Object& o ); // I can't be modified.
public:
int v;
Object(): v( rand() ) { }
};

All your code proves is that you're apparently unaware of the
requirement in section 23.1/3 that anything you store in a vector be
assignable.

What it proves is that sort assigns to items contained in the vector,
thus literally modifying the elements in the container. Exactly what
Pete claimed it didn't do. Well, it does do it, just like every other
modifying algorithm, and unlike any of the non-modifying algorithms.

--
There are two things that simply cannot be doubted. Logic and our
ability to sense the world around us. Doubt those, and you no longer
have anyone to discuss it with, nor any ability to discuss it.

[Kai-Uwe Bux]

Daniel T. wrote:

"Fraser Ross" <fraserATmember s.v21.co.ukwrot e:

>>"Daniel T."

>>for_each is a non-modifying algorithm does not explicitly modify the
contents of the container. The functor passed into for_each might, but
the algorithm doesn't.

I think the intention is that although the algorithm doesn't prevent
modification it is expected anyway that the functor does not modify
elements.

The rule of non-modifying vs modifying is amazingly simple. All
modifying sequences algorithms call op= on the elements in at least one
of the sequences it operates on, non-modifying sequence algorithms
don't. As such, for_each is a non-modifying sequence algorithm. The
*algorithm* doesn't modify any of the elements of the sequence (even if
the functor passed in does.)

Do you have any hint for that in the standard? Please consider:
#include <iostream>
#include <cstdlib>
#include <vector>
#include <algorithm>

class log_assignment {

unsigned long data;

static
bool & do_log ( void ) {
static bool log = false;
return ( log );
}

public:

log_assignment ( void )
: data ( std::rand() )
{}

bool operator< ( log_assignment other ) const {
return ( data < other.data );
}

log_assignment & operator= ( log_assignment other ) {
data = other.data;
if ( do_log() ) {
std::cout << "assignment \n";
}
return ( *this );
}

static
void start_logging ( void ) {
do_log() = true;
}

};
int main ( void ) {
std::srand( 12 );
std::vector< std::vector< log_assignment vec_vec;
for ( unsigned int i = 0; i < 21; ++i ) {
std::vector< log_assignment dummy ( 25 );
vec_vec.push_ba ck( dummy );
}
log_assignment: :start_logging( );
std::vector< log_assignment a ( 2 );
std::vector< log_assignment b ( 2 );
std::cout << "test whether vector assignments trigger logging:\n";
a = b;
std::cout << "test reverse on vec_vec for assignments of vectors:\n";
std::reverse( vec_vec.begin() , vec_vec.end() );
}
On my machine, this outputs:

test whether vector assignments trigger logging:
assignment
assignment
test reverse on vec_vec for assignments of vectors:

Best

Kai-Uwe Bux

[Jerry Coffin]

In article <da************ *************** *@news.west.ear thlink.net>,
da******@earthl ink.net says...

[ ... ]

All your code proves is that you're apparently unaware of the
requirement in section 23.1/3 that anything you store in a vector be
assignable.

What it proves is that sort assigns to items contained in the vector,
thus literally modifying the elements in the container. Exactly what
Pete claimed it didn't do. Well, it does do it, just like every other
modifying algorithm, and unlike any of the non-modifying algorithms.

Wrong. The moment you put something into the container that isn't
assignable, all you have is undefined behavior. Period. The end. You
don't have any proof of anything about any algorithm you might choose to
attempt to apply to the container. Undefined behavior is undefined
behavior, NOT a proof.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Daniel T.]

In article <ee**********@m urdoch.acc.Virg inia.EDU>,
Kai-Uwe Bux <jk********@gmx .netwrote:

Daniel T. wrote:

"Fraser Ross" <fraserATmember s.v21.co.ukwrot e:

>"Daniel T."
for_each is a non-modifying algorithm does not explicitly modify the
contents of the container. The functor passed into for_each might, but
the algorithm doesn't.

I think the intention is that although the algorithm doesn't prevent
modification it is expected anyway that the functor does not modify
elements.

The rule of non-modifying vs modifying is amazingly simple. All
modifying sequences algorithms call op= on the elements in at least one
of the sequences it operates on, non-modifying sequence algorithms
don't. As such, for_each is a non-modifying sequence algorithm. The
*algorithm* doesn't modify any of the elements of the sequence (even if
the functor passed in does.)

Do you have any hint for that in the standard? Please consider:

In the code below. std::reverse calls the assignment op of the vectors
contained in the vec_vec. Note:

int main ( void ) {
std::srand( 12 );
log_assignment: :start_logging( );
std::vector< log_assignment a ( 2 );
std::vector< log_assignment b ( 2 );
std::cout << "test whether vector assignments trigger logging:\n";
a = b;
std::cout << "test reverse on vec_vec for assignments of vectors:\n";
std::reverse( a.begin(), a.end() );
}

produces the output:

test whether vector assignments trigger logging:
assignment
assignment
test reverse on vec_vec for assignments of vectors:
assignment
assignment

>

#include <iostream>
#include <cstdlib>
#include <vector>
#include <algorithm>

class log_assignment {

unsigned long data;

static
bool & do_log ( void ) {
static bool log = false;
return ( log );
}

public:

log_assignment ( void )
: data ( std::rand() )
{}

bool operator< ( log_assignment other ) const {
return ( data < other.data );
}

log_assignment & operator= ( log_assignment other ) {
data = other.data;
if ( do_log() ) {
std::cout << "assignment \n";
}
return ( *this );
}

static
void start_logging ( void ) {
do_log() = true;
}

};
int main ( void ) {
std::srand( 12 );
std::vector< std::vector< log_assignment vec_vec;
for ( unsigned int i = 0; i < 21; ++i ) {
std::vector< log_assignment dummy ( 25 );
vec_vec.push_ba ck( dummy );
}
log_assignment: :start_logging( );
std::vector< log_assignment a ( 2 );
std::vector< log_assignment b ( 2 );
std::cout << "test whether vector assignments trigger logging:\n";
a = b;
std::cout << "test reverse on vec_vec for assignments of vectors:\n";
std::reverse( vec_vec.begin() , vec_vec.end() );
}
On my machine, this outputs:

test whether vector assignments trigger logging:
assignment
assignment
test reverse on vec_vec for assignments of vectors:

--
There are two things that simply cannot be doubted. Logic and our
ability to sense the world around us. Doubt those, and you no longer
have anyone to discuss it with, nor any ability to discuss it.

[Daniel T.]

Jerry Coffin <jc*****@taeus. comwrote:

da******@earthl ink.net says...

>>All your code proves is that you're apparently unaware of the
requirement in section 23.1/3 that anything you store in a vector
be assignable.

What it proves is that sort assigns to items contained in the
vector, thus literally modifying the elements in the container.
Exactly what Pete claimed it didn't do. Well, it does do it, just
like every other modifying algorithm, and unlike any of the
non-modifying algorithms.

Wrong. The moment you put something into the container that isn't
assignable, all you have is undefined behavior. Period. The end. You
don't have any proof of anything about any algorithm you might
choose to attempt to apply to the container. Undefined behavior is
undefined behavior, NOT a proof.

Jerry (and Pete) are asserting that I am wrong? Are you asserting that
(a) there is a non-modifying algorithm that assigns to elements of a
container and/or (b) there is a modifying algorithm that doesn't?

If you are, then state which algorithm it is otherwise accept it.

--
There are two things that simply cannot be doubted. Logic and our
ability to sense the world around us. Doubt those, and you no longer
have anyone to discuss it with, nor any ability to discuss it.

[Pete Becker]

Daniel T. wrote:

>>>

sort also doesn't modify any elements, but it's a modifying sequence
operation.

'sort' does modify the elements in the sequence. Here is my proof, the
below won't compile because sort needs to be able to modify the
elements, and objects of type Object can't be modified.

You're looking at objects, not elements. Remember, STL is value-based.
If the sequence has the same values when an algorithm is finished as it
had at the start, then its elements have not been changed.
Note, also, that if modifying sequence operations get their name because
they modify individual objects, then std::sort is a modifying sequence
operation and std::list::sort is a non-modifying sequence operation.
That elevates implementation details over abstraction, and is not at all
what the STL is about.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.