From: Geurt Vos (G.Vos_at_[hidden])
Date: 2001-05-08 07:52:56
> > ---
> > "The header <boost/function.hpp> provides several classes that are
> > generalized function pointers"
> > ---
> >
> > Generalized function pointers? And still you say one shouldn't think
> > of it as a pointer? So my advice to this all: either give it full
>
> I knew you'd notice that :). I've been planning on reworking the
> documentation to stress that boost::function works on function
> objects, and that function pointers are merely a singleton function
> object that happens to have a more optimal representation inside
> boost::function.
>
I'm just wondering, how hard will it be to convince the masses that
a free function is a special kind of functor? If they try to hang
on to the C world... :p
> > pointer semantics (don't!) or make it a functor only thing, with only
> > a high level interface and lose the ability to assign function pointers.
> > I wouldn't want to go for the first option, because there will be great
> > many problems and all. For one the 0 assignment won't work correctly
> > in the following case (because it's construction, not assignment):
> >
> > void SomeFunc(const boost::function<void> &);
> >
> >
>
> I'm not sure I understand what you mean by this. It's a construction
> if you pass in something other than a boost::function<void>, but so
> what? I'm obviously missing something :)
>
The idea I presented allowed 'assignment to 0', not 'construction
to 0'. So the following code is not valid:
boost::function<void> f(0);
This simply can't be done because we still have the templated
constructor, which will be called (as 'const int &') when 0
is used as construction argument.
The 'nil' thing could of course solve this...
> > Even though there's some optimization for function pointers, I strongly
> > urge this support is removed. For one free functions won't be used that
> > often, and also, explain to the user that function assignment -something
> > they'll barely use - is optimized, whereas member function assignment is
> > not.
>
> I disagree that we should remove the optimization. I think this is
> solvable through documentation (as mentioned above).
>
I'm not sure if you have to say there's optimization involved.
I mean, since a function is a special kind of functor, it is
quite natural boost::function supports them. The fact that
free function pointers can be optimized is simply something
the user gets for free...
Geurt