From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-07-21 23:59:04
On Saturday 21 July 2001 04:07, you wrote:
> Douglas Gregor writes:
> > 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?
> Ahh. I've been dealing with this issue in the design of my
> Boost.MultiArray candidate.
> > 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, to me, is the most important part, and has been often confusing
> in figuring out the proper semantics for library-defined
> types that attempt to mimic pointer/reference semantics. If we take
> the analogy of a "pointer to functor", you're fighting with the difference
> 1) functor * p;
> 2) functor const * p;
> 3) functor * const p;
> 4) functor const * const p;
> your current semantics seem to have (=> meaning "is analogous to"):
> functor => 1)
> const functor => 4)
> while the proposed semantics seem to be:
> functor => 1)
> const functor => 3)
I was proposing just:
functor => 1
and an auxiliary function object could (at 'function'
assignment/initialization time) decide if for a particular target function
object instance, it should be
functor => 3
> One pertinent question is, is there a sensible use for a functor with
> semantics 2) or 4). That is, does it make sense to have a functor
> that itself has constness regardless of the constness of that to which
> it refers. If the answer is yes, it may be necessary to have a
> parallel set of types const_functor to go with functor. That way,
> functor will be call operator(), and const_functor will call
> operator() const. I think for these purposes, a function pointer
> could be considered operator() const. Then, functor could be
> converted to const_functor but NOT vice-versa.
I believe the answer is "yes" that it makes sense for semantics 2 or 4,
because a const 'function' object can't have the function object it targets
changed. However, see the reason in my prior post why having parallel
function/const_function won't (and probably can't) work.
> As far as making the semantic change, I vote for doing so. While
> Boost.Function is already "out there", I think that the current
> semantics confusing. If/When these changes are released, A notice
> should go in the Boost Release notes stressing such a semantic
Does Boost have Release Notes?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk