Boost logo

Boost :

From: Doug Gregor (gregod_at_[hidden])
Date: 2001-05-02 08:35:55


On Wednesday 02 May 2001 04:50, you wrote:
[snip]
>
> 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

I agree that boost::function::operator() should be const on the basis that it
will not affect the state of the boost::function object. However, with the
mem_fun/const_mem_fun example, the user is deciding explicitly whether to use
the const version or the non-const version and cannot change the decision
later.

I'm worried about the passing of constness. For instance, if one were to have
a class like:

template<typename Functor>
struct my_class {
  Functor f;

  void do1() { f(); }
  void do2() const { f(); }
};

Then a Functor with both a const and a non-const operator() would have its
non-const version used in do1() and its const version used in do2(). It seems
that boost::function should have the same behavior.

The C++ standard mem_fun and const_mem_fun avoid this issue of passing
constness by using two separate classes, but I don't believe that
boost::function should dodge the issue again.

        Doug Gregor


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk