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 17:23:38

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. :)

Daniel Walker