From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-07-20 14:41:42
The question of Boost.Function's operator() and/or operator() const has
reared its ugly head again. It was originally discussed in this thread:
http://groups.yahoo.com/group/boost/message/11482
Another dimension (using binders with Boost.Function) goes against the
conclusion drawn in that thread. I'll recap the problem, solution, and its
problems here:
Boost.Function is a set of function object wrappers for deferred calls.
Should the function call operator be const, non-const, or should both be
supplied?
Currently, the implementation supplies both const and non-const version. The
function object target is then invoked as const if the const version was
used, and non-const if the non-const version was used. Benefits of this
approach are:
- Boost.Function objects can be dropped in without any semantic changes (see
code snippet A, below).
- Allows target function objects to have both const and non-const function
call operators accessible through Boost.Function objects.
Disadvantages are:
- const and non-const function call operators have the same return type, so
one of the most common uses of giving both a const and a non-const operator()
isn't possible anyway (i.e., return a reference-to-T for operator() and a
reference-to-const T for operator() const).
- target function objects _must_ have operator() const defined, even if it
doesn't make sense. One user has been burned by this already (the stub const
version was being called from a const Boost.Function object, but the stub
routine didn't throw an exception or assert to make the problem obvious).
- &boost::function<...>::operator() requires an extra casetto choose const
or non-const operator() (makes it tough to use binders with Boost.Function,
see code snippet B).
The final point in the "disadvantages" swayed me. I believe it would be best
to remove operator() completely (thereby leaving only operator() const)
because
1) Boost.Function can be considered to be a handle or pointer to a function
object, so constness of Boost.Function is disjoint from constness of the
targetted function object.
2) It doesn't force users into creating stub routines, so users can always
pass Boost.Function objects around as reference-to-const without worrying
about triggering a stub.
3) Calls to operator() don't modify the Boost.Function object, so it should
be const.
4) Easier to use binders, see code snippet B.
I'm very leary of making such a semantic change now that Boost.Function is
available, but I do believe that the resulting interface is cleaner and more
consistent. Code snippet A describes the resulting semantic inconsistency
between using a function object directly and using the function object
wrapped in a Boost.Function. Note that both the const and the non-const "do"
_must_ have the same type if "F" is a Boost.Function, so the usefulness of
having const and non-const operator() overloads is diminished already.
// Code snippet A
template<typename F>
struct some_type {
some_type(F fin) : f(fin) {}
int do(int x) { return f(x); }
int do(int x) const { return f(x); }
F f;
};
struct my_function {
int operator(int x) { return x; }
int operator(int x) const { return -x; }
};
some_type<my_function> st1(my_function());
some_type<boost::function<int, int> > st2(my_function());
With the current semantics of Boost.Function, st1 and st2 will have the same
behavior. With the proposed semantic change, a call to st2::do() const will
still call the non-const my_function::operator().
// Code snippet B
typedef boost::function<void, int> func;
std::vector<func> funcs;
std::for_each(funcs.begin(), funcs.end(),
std::bind2nd(std::mem_fun_ref(&func::operator()), 0));
Any comments would be appreciated. It seems that the impact of this change on
users will be very minimal, and the benefits outweight any changes, but I
would prefer some help in this decision.
Doug