Re: [boost] about function.hpp

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-05-03 22:59:19

On Thursday 03 May 2001 07:52 pm, you wrote:
> >Requiring operator== of all function objects used with boost::function
> > would be way too strict, I think. We have to be very careful when adding
> > requirements for functors in boost::function because they are
> > requirements even if not used.
>
> Well you can make it work when the boost::function is pointing to a
> free function, a member function pointer, or a functor that supports
> operator==. If you got a compile time error when you tried to compare
> boost::function's when this didn't hold that would be fine with me.

But making it work at all requires _every_ functor to implement operator==, 
which is too strong a requirement (especially considering that the standard 
library function objects don't have operator==). See my response to Beman 
regarding the impossibility of passing compile-time information through a 
type-erasing barrier (i.e., virtual functions or taking the address of 
functions). I'd love for someone to find a hole in the argument and supply an 
implementation that can do it ;).

> >I'd argue that you should have one Timer object per callback, and then use
> > a static class member to keep track of all of the existing Timer objects
> > to call them; no equality test required.
>
> I can see this working, but it would be a bit more complex
> (aggravated a bit because I'm using a COM like object model). However
> the fact remains that comparing boost::function's is useful and is
> exactly the sort of thing you would do with an ordinary function
> pointer. This seems like a strong argument for making it part of the
> API...

Perhaps a separate concept is required that would include operator==. Maybe 
this is the fundamental difference between boost::function and a 
not-yet-implemented boost::callback?

> >Why not just:
> >-------------------
> >// About
> >handle->RegisterCommand(kAboutCmd, bind(this, &CApp::DoAbout),
> >kDisabledIfDialog);
> >
> >// Delete Formula
> >handler->RegisterCommand(kDeleteFormulaCmd,
> >	bind(this, &CApp::DoDeleteFormula),
> >	bind(this, &CAppMenuHandler::DoEnableDeleteFormula));
> >
> >// Delete palette
> >handler->RegisterCommand(kDeletePaletteCmd,
> >	bind(this, &CApp::DoDeletePalette),
> >	bind(this, &CApp::DoEnableDeletePalette));
> >-------------------
> >
> >Implicit conversion from any function object/function pointer to a
> >boost::function is supported to make all of this easier.
>
> Hmm, I think I could live with that. It's important to make this as
> easy to use and as clean as possible though because it'll be used a
> lot. I looked at the bind.hpp that Peter pointed me to and it had a
> different (and to my eyes uglier) API.
>
>    -- Jesse

I believe Peter's bind() is a lot more general than what I was considering, 
In any case, I don't think that adding support for member functions directly 
into to boost::function is the best choice - it seems wrong to add 
functionality that we know will be bested by the binders/lambda library, 
because then boost::function ends up carrying dead weight. I'd be happy to 
supply a function (probably not named bind) that builds the simple function 
object with a simpler interface.

        Doug