From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-05-11 13:54:53
On Saturday 11 May 2002 12:22 pm, you wrote:
> Wouldn't make_function work for std::unary_function, std::binary_function
> and
> boost::function too? But yes, handling arbitrary function objects would be
> difficult.
Yes, it could be made to work with unary_function, binary_function, and
boost::function.
> Well I guess I'll write make_function myself then. It won't work for any
> function
> object but I can live with that.
That's probably the best option. Sorry :(
> Just one thing though, I'd like it to work for the result of a boost::bind
> as well.
> But the result of a boost::bind is implementation-defined according to the
> documentation. So there is no way to portably create boost::bind overloads
> for
> make_function, right?
It wouldn't work anyway, because boost::bind function objects don't have
exact argument types to deduce. For instance, how would the following work?
template<typename T>
struct add_to {
typedef T result_type;
template<typename U>
T& operator()(T& t, const U& u) const
{
return t += u;
}
};
std::string& foo;
make_function(bind<std::string&>(add_to<std::string>(), ref(foo), _1));
The boost::bind function object takes at least 1 argument (any more would be
ignored), but the type of that first argument isn't specified. Boost.Function
doesn't (and can't) do partial bindings.
> > If we _did_ have a working set of function traits, it would be possible
> > to make Boost.Function objects implicitly constructed only from function
>
> objects
>
> > that are callable by the Boost.Function object.
>
> This seems to me as an awesome addition to Boost.Function! Too bad there
> are compilers out there that don't support the needed functionality. :(
>
> Dirk Gerrits
There are workarounds for most compiler deficiencies, but of course we won't
know until someone tries. I'll work on it sometime.
Doug