On Tue, Jul 20, 2010 at 5:23 PM, Daniel Walker <daniel.j.walker@gmail.com> wrote:
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. :)
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