Re: [boost] any_function (callback) library

From: Doug Gregor (gregod_at_[hidden])
Date: 2001-04-09 21:44:46

On Monday 09 April 2001 10:06, you wrote:
> From: "Doug Gregor" <gregod_at_[hidden]>
>
> > I would like to solicit input from those interested in any_function,
> > especially regarding the interface & semantics. Barring major
> > omissions/oversights/etc, I'll be requesting a formal review within a few
> > days.
>
> Interface:
>
> * I propose to rename any_function to just 'boost::function'. :-)

Sounds good to me.

> * The numbered variants (function0, function1, etc) are quite handy for
> defining interfaces, since if you maintain a library that defines
>
> void f(boost::function<X, Y> const & g);
>
> and you compile against, say, boost 1.23.0 (where boost::function has 7
> template parameters) but your users compile against boost 1.23.2, where
> boost::function has 10 template parameters, their program won't link. This
> can be solved by defining boost::function0, boost::function1, and so on, so
> the library function would be
>
> void f(boost::function1<X, Y> const & g);
>
> and boost::function<R, A1, ..., AN> would be an alias for
> boost::functionN<...> (no template typedefs, but a public inheritance would
> probably suffice.)

This makes sense... I'd been considering something similar to this, but for 
an entirely different reason. The use of an arbitrary number of parameters 
makes it unwieldy to use a trait/policy class. Either you are stuck with 
filling in extra arguments:

function<int, float, int, unused, unused, unused, my_traits> foo;

or moving the trait class to the front (which doesn't allow for any 
defaults). Instead, a sort of generative interface could be used. For 
instance, the defaults would be the same as it is used now:

function<int, float, int> foo;

Additionally, named parameters would be used to specify policies and/or 
traits, i.e.,

function<int, float, int>::allocator<my_allocator> foo;
function<int, int, std::string>::ref_counted bar;

        Doug