Re: [boost] boost::bind result type

Subject: Re: [boost] boost::bind result type
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-07-20 19:43:39

On Tue, Jul 20, 2010 at 5:23 PM, Daniel Walker
<daniel.j.walker_at_[hidden]> wrote:
> On Tue, Jul 20, 2010 at 1:09 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
>> AMDG
>>
>> Daniel Walker wrote:
>>>
>>> Here's another idea that we might be able to pursue in the future. The
>>> original complaint is not that there isn't a general way to return a
>>> bind object; you can use boost::function. The complaint is that
>>> boost::function isn't optimal, since it precludes inlining. So,
>>> another approach would be to provide an optimized specialization of
>>> boost::function for bind objects; i.e. boost::function could leverage
>>> implementation specific details of boost::bind to store bind objects
>>> optimally. It makes sense that Boost libraries would be optimized when
>>> used with other Boost libraries, and presumably, stdlib venders will
>>> look for similar opportunities for internal optimization in order to
>>> differentiate themselves. I'm not sure if this is possible, but it
>>> might be something worth looking into.
>>>
>>
>> This isn't possible without knowing the static type of
>> the bind object.
>
> True, but the type of the bind object is not specified in the API. So,
> if we were to optimize boost::function and boost::bind to play well
> together, we could refactor the bind object type to suit our needs.
> I'm not saying it would be easy...
>
>> Boost.Function can't possibly avoid
>> type erasure, so I don't think this leads anywhere.
>
> You can't avoid type erasure when storing arbitrary types, but again,
> the return type of bind is implementation specific. Implementers of
> std::function and std::bind have have some flexibility in choosing the
> return type. There could be opportunities for Boost here too. Under
> certain assumptions, the return type of bind could even be an instance
> of boost::function. I'm more concerned about preserving the current
> semantics of boost::function, but perhaps they could be extended in an
> acceptable way.
>
> Sorry for being so imprecise. Just trying to think outside the box a little. :)
>

Actually, I just looked into it, and this wasn't as hard as I thought.
So, I can be a little more specific about the needed changes. As a
proof of concept, I have attached a patch that allows the following
where the bind object is stored directly by boost::function without
type erasure.

#include <functional>
#include <boost/function.hpp>
#include <boost/bind.hpp>

int main()
{
    using namespace boost;
    function<
         bind_signature(std::plus<int>,boost::arg<1>,int)
    > f = bind(std::plus<int>(), _1, 1);
}

The tag "bind_signature" is used to specify that the signature has
alternative semantics and should be interpreted to construct a
boost::function instance optimized for storing a bind object. One
could think of other conventions for specifying alternate
boost::function semantics; e.g.

function<bind_signature<std::plus<int>(boost::arg<1>,int)> >

The point is to have some convention for the user to tell
boost::function to interpret the signature differently, and then
provide optimized specialization of the boost::function class
template.

The patch is far from complete and only works for two argument binds,
but you get the idea. I basically just adapted David's return type
solution and made it a member type of boost::function. Thanks David!

I'm sure there are a number of nuances to be considered but basically
to complete the feature:
1) decide on a signature convention
2) add support for multiple arities
3) define call operators for stored boost::bind objects
4) test and document everything

Daniel Walker