From: Rene Jager (renej_at_[hidden])
Date: 2001-05-02 03:50:31
Peter Dimov wrote:
> From: "Doug Gregor" <gregod_at_[hidden]>
> > I see two options for making it const, each with its semantic problems:
> > 1) Just make function::operator() const, but constness won't be passed
> > through to underlying function objects, so we're dealing with a semantic
> > area.
> With undefined behavior, more or less, unless boost::function uses 'mutable'
> internally. However, in this case, when I bind a boost::function to a
> function object with both const and non-const operator(), it will never call
> the const version.
> > 2) Have both a const and a non-const version, and pass an "is_const" flag
> > that function objects will be invoked as const or non-const and the
> > will be passed through. However, this requires a const version of
> > to be defined for any function object regardless of whether it is used or
> I think this is the least bad option. Most operator()'s are const, and in
> the case where the function object has _only_ a non-const operator(), a
> dummy const version (that throws an exception) will have to be added by the
> > So here's your answer: I dislike both solutions, and could not come up
> > another one very easily. I'm leaning toward #1 because guaranteeing
> > is impossible given the ability to link to free functions.
> I don't see why free functions present a problem; they are always const.
I think there is a difference between the const'ness of a functor and
const'ness of the underlying function/method; just like in the STL: the
function can be const or not, the operator () of the function object is
const having a "const boost::function<int, int> f" IMHO means that
allowed to do "f.clear()", but you can use/call it always since that
affect the state of the functor; during the construction of a functor it
not be possible to combine a const object and a non-const member
function (as in
mem_fun/const_mem_fun) does this sound reasonible or am I totally of
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk