|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-05-01 08:37:20
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.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk