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

From: Eric Niebler (eric_at_[hidden])
Date: 2007-03-21 20:12:56

Joel de Guzman wrote:
> Tobias Schwinger wrote:
>> 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.
> 
> 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.

Frankly, I think the proposed design (function object passed by value, 
or by reference with explicitly specified template arg) is ugly. It'll 
be ugly both from the user's perspective and in the implementation. If 
by-value is a perf-win in the common case (perf numbers?), then I'd 
prefer by-ref semantics to look like this:

   for_each( seq, ref(func) );

instead of this:

   for_each< Func & >( seq, func );

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com