On Tue, Jul 20, 2010 at 1:09 PM, Steven Watanabe <watanabesj@gmail.com> 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