Re: Return value of functor object in for_each algorithm
On May 31, 3:17 pm, Jerry Coffin <jcof...@taeus.com> wrote:
In article <5602b353-1abd-411d-965b-
af68c9fdc...@s21g2000vbb.googlegroups.com>, james.ka...@gmail.com
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.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34