Return value of functor object in for_each algorithm

M

mthread

Hi,
I am using a functor object in for_each algorithm. I would like to
know if there is any way for me to find out the return value of the
functor object. I would like to check this return value to carry out
further processing(Say exit the application when return value is -1).
 
M

Maxim Yegorushkin

Hi,
    I am using a functor object in for_each algorithm. I would like to
know if there is any way for me to find out the return value of the
functor object. I would like to check this return value to carry out
further processing(Say exit the application when return value is -1).

std::for_each returns a copy of your functor, after it has been
applied to the sequence. Please see notes at the end of
http://www.sgi.com/tech/stl/for_each.html
 
J

James Kanze

std::for_each returns a copy of your functor, after it has been
applied to the sequence. Please see notes at the end ofhttp://www.sgi.com/tech/stl/for_each.html

I suspect that that's the intent, but it's certainly not
required by the standard. for_each returns some copy of the
functional object; what exactly is unspecified. Thus, for
example, the following would be a perfectly legal
implementations:

template< typename InputIterator, typename Function >
Function
for_each( InputIterator first, InputIterator last, Function f )
{
if ( first != last ) {
f( *first ) ;
++ first ;
for_each( first, last, f ) ;
}
return f ;
}

In general, it's best to make all copies of functional objects
idempotent, using an additional level of indirection if
necessary. For functional objects with mutable state, there are
two more or less standard solutions:

-- The client defines an instance of the state, and passes an
address of it to the constructor of the functional object,
which contains a pointer to it. This is the simplest and
most efficient solution; if there is mutable state which the
client doesn't need to know about, however, it breaks
encapsulation.

-- The functional object defines a nested class type with
state. The non-copy constructors allocate an instance of
the state dynamically, and the functional object uses
reference counting (boost::shared_ptr works fine here,
although other reference counted pointers may be more
efficient) so that copies share the instance of the state.
 
J

Jerry Coffin

(e-mail address removed)>, (e-mail address removed)
says...

[ ... ]
In general, it's best to make all copies of functional objects
idempotent, using an additional level of indirection if
necessary. For functional objects with mutable state, there are
two more or less standard solutions:

-- The client defines an instance of the state, and passes an
address of it to the constructor of the functional object,
which contains a pointer to it. This is the simplest and
most efficient solution; if there is mutable state which the
client doesn't need to know about, however, it breaks
encapsulation.

-- The functional object defines a nested class type with
state. The non-copy constructors allocate an instance of
the state dynamically, and the functional object uses
reference counting (boost::shared_ptr works fine here,
although other reference counted pointers may be more
efficient) so that copies share the instance of the state.

Option C: Consider using std::accumulate instead of std::for_each. Most
times that people want to maintain state across invocations, they're
accumulating something in their functor, and they'd be better off using
std::accumulate to do the job.
 
J

James Kanze

(e-mail address removed)>, (e-mail address removed)
says...
[ ... ]
In general, it's best to make all copies of functional objects
idempotent, using an additional level of indirection if
necessary. For functional objects with mutable state, there are
two more or less standard solutions:
-- The client defines an instance of the state, and passes an
address of it to the constructor of the functional object,
which contains a pointer to it. This is the simplest and
most efficient solution; if there is mutable state which the
client doesn't need to know about, however, it breaks
encapsulation.
-- The functional object defines a nested class type with
state. The non-copy constructors allocate an instance of
the state dynamically, and the functional object uses
reference counting (boost::shared_ptr works fine here,
although other reference counted pointers may be more
efficient) so that copies share the instance of the state.
Option C: Consider using std::accumulate instead of
std::for_each. Most times that people want to maintain state
across invocations, they're accumulating something in their
functor, and they'd be better off using std::accumulate to do
the job.

Good point. There are exceptions, but as you say, most of the
time...

There is one potential problem with accumulate: it uses accu =
accu + value, rather than accu += value. If the accumulator is
expensive to copy, this can be costly. I don't have the figures
handy, but I know that when I designed my SHA-n classes, my
original use, using the hasher directly as an accumulator, was
too slow, and this despite the fact that I had designed the
class to optimize copying (all members basic types, so that
hopefully, the compiler generated copy constructor could be
optimal). In the end, I added a special "hack"; an operator
which implemented in fact += (or the moral equivalent), rather
than +, then returned a dummy type, to pick up a no-op
assignment operator. (There's still the copy into accumulate,
and the copy on return, but they're insignificant if the block
is long enough.) It works with all of the implementations I've
used. And I think the standard can be interpreted as requiring
it to work. But I still feel like it's skating on thin ice.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top