Re: [Boost-users] [fusion] Stateful unary functor for for_each loop

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-03-21 15:43:53

Joel de Guzman wrote:
> Tobias Schwinger wrote:
>> Joel de Guzman wrote:
>>> Eric Niebler wrote:
>>>> Tobias Schwinger 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 
>>>> 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 <class InputIterator, class UnaryFunction>
> 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.

Regards,
Tobias