Re: [boost] about function.hpp

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
> grey
> > 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
> so
> > that function objects will be invoked as const or non-const and the
> constness
> > will be passed through. However, this requires a const version of
> operator()
> > to be defined for any function object regardless of whether it is used or
> not.
> 
> 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
> user.
> 
> > So here's your answer: I dislike both solutions, and could not come up
> with
> > another one very easily. I'm leaning toward #1 because guaranteeing
> constness
> > 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
the
const'ness of the underlying function/method; just like in the STL: the
member
function can be const or not, the operator () of the function object is
always
const having a "const boost::function<int, int> f" IMHO means that
you're not
allowed to do "f.clear()", but you can use/call it always since that
doesn't
affect the state of the functor; during the construction of a functor it
should
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
track here...

renej