Boost logo

Boost Users :

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net