From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2001-07-20 15:00:51
> The final point in the "disadvantages" swayed me. I believe it would be best
> to remove operator() completely (thereby leaving only operator() const)
> 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.
This statement made me think about an analogy to the
iterator/const_iterator distinction in the standard library. Perhaps
the right distinction here is function/const_function, where
const_function is a handle to a const function object, just as a
const_iterator is a handle to a const iterated-over object.
This will open some different cans of worms (what conversions should be
supplied?) but it would make the issue of stub functions go away while
still allowing users who need const/non-const distinctions in their
function objects to do that. And, it would allow one to use differing
return types in the underlying function object when that is
appropriate, I think... There still might be surprising results at
times, if a user makes the two operator()'s have differing semantics,
but in that case he deserves to have to think about things hard (IMHO,
What do others think? Are there issues here that I've missed in my
rather cursory thinking about the problem?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk