Tobias Schwinger wrote:
Joel de Guzman wrote:
Tobias Schwinger wrote:
Joel de Guzman wrote:
Eric Niebler wrote:
Christian Henning wrote: > Hi there, is it possible to have a stateful functor object when using > fusion::for_each() loop. > > I would like to to the following: > <snip code>
for_each takes the function object by reference to const, so you have to const qualify operator() and make the data members mutable so you can change them anyway. IMO, this is a bug in Fusion. There should be an overload of for_each
Tobias Schwinger wrote: that takes a function object by non-const reference. For the function invokers I use by-value parameters and the templates are designed to allow explicitly specified template arguments to use references instead. The reason was that by-value arguments can be more efficient for small function objects (tracking side effects) and function pointers.
...and should've also mentioned STL here :-).
Really? Do you have some numbers to back that?
The effect in the first case (small or stateless function object by-value vs. by-reference) causes the compiler to omit certain optimizations if the scope becomes too wide, so numbers will greatly depend on the subject to optimization. I experienced a factor of ~50 for Fusion fuse/unfuse loopback (trying to apply factorizations to make the test code less ugly) with GCC, for instance. Of course there'll be a threshold somewhere for non-trivial copying...
For the second case (pointer by-value vs. by-reference) there are some (possibly outdated) test results in the CallTraits documentation (you probably know that one).
It might be worthwhile to consider this scheme as an alternative to overloading, especially for algorithms which call back multiple times. Sure. Agreed; also, see below.
Stateful predicates should be supported, and Fusion should be explicit about where and when predicates are copied, so that the state doesn't get messed up.
I agree. This is one of the todo items. Noted and added in the queue. No doubt here. Ok, anyway, for the sake of discussion, the stl for_each is:
template
UnaryFunction for_each(InputIterator first, InputIterator last, UnaryFunction f); Ditto to all the other higher-order algos. What does that tell us?
Plus, if we design things to allow the template argument for the function to be specialized explicitly, we can have no-copy if we want to. We can also add a default argument for default constructible Function Objects.
Looks like Tobias is offering a superior design. What do you think, Eric? Tobias, we'd still need some perf tests to back this up. CallTraits is quite old and the tests there (if there are) might not be relevant anymore. For example, in the fusion fold tests, I see that VC7.1 produces highly optimal code. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net