On Tuesday, March 22, 2016 7:01 PM, Gavin Lambert
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
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