Re: [boost] [Fit] formal review ends 20th March.

Subject: Re: [boost] [Fit] formal review ends 20th March.
From: paul Fultz (pfultz2_at_[hidden])
Date: 2016-03-22 20:33:35

On Tuesday, March 22, 2016 7:01 PM, Gavin Lambert <gavinl_at_[hidden]> wrote:

>
>
>On 22/03/2016 06:55, Paul Fultz II wrote:
>>> Function Objects
>>>
>>> You state that the function call operator is always declared const.  On
>>> what basis do you make that claim?
>>
>> This I plan to discuss more. There are two main reason for this:
>>
>> 1) Mutable function objects are problematic with many surprises. Most of
>> the time `std::ref` should be used instead.
>
>These are not exclusive.  I've often created a "real" function object 
>(custom struct/class) with non-const call operator, and then used 
>bind(ref(func), params...) on it.  This works because bind can call both 

>const and non-const functors and can auto-unwrap ref().  

This doesn't really matter. `reference_wrapper` has a call operator that is
only const. Having a non-const overload for `reference_wrapper` would imply
that the function could change what `reference_wrapper` points to, but it
can't. So there is no reason to have a non-const overload. Same applies to
using `fit::indirect(&f)`.

> The output of >bind() might be a const functor, but its input is not required to be.
>
>(And in some cases using ref() is not possible, as the functor must be 
>returned out of the original scope.  Admittedly this is harder to do 
>correctly with non-const functors than with const ones, but shared_ptr 
>and friends can come to the rescue here, albeit with some minor 

>performance cost.)

With Fit, you can do `fit::indirect(std::make_shared<mutable_function>())` to
turn a shared_ptr that points to a Callable into a FunctionObject.
Additionally, if you absolutely know what you are doing, you can still use
`fit::mutable_` as well.
>
>As I mentioned in the other branch of this thread, my experience has 
>been that any time I want a const functor I use bind() or a lambda, and 
>any time I want a non-const functor I write a custom struct.  Thus, the 
>only times I actually implement operator() myself, it is never const.  I 
>don't know how wide-spread this practice is, but I don't believe it is 
>unique.
>
>
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
>