Boost logo

Boost :

From: Ronald Garcia (garcia_at_[hidden])
Date: 2001-07-21 15:07:47

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)

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.

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at