On 4/27/07, Peter Dimov <pdimov@mmltd.net> wrote:
Eric Niebler wrote:
Peter Dimov wrote:
Eric Niebler wrote:
Although I don't know all the details of bind and lambda, I had hoped that _1 and _2 would be abstract proto entities, such that
_1 == _2
creates an expression template like:
equal< terminal< arg<1> >, terminal< arg<2> > >
which is a generic, abstract representation of an equals expression with two placeholders. Can't bind and lambda both be implemented to recognize such a type and do the appropriate thing with it?
Possibly, if they are made to honor is_bind_expression specializations and result_of, if is_bind_expression reports true for the above type, if the above is a function object that actually returns x == y, and if result_of works for it.
Yes, that can all be made to work without much difficulty.
The part about boost::bind using is_bind_expression and result_of cannot, not without major surgery and possibly compromising portability.
Sometimes I get excited about the new C++0x features and tell myself, why not rewrite boost::bind to take advantage of them? Then it occurs to me that C++0x has a std::bind built-in. :-) (Happened twice so far.)
Actually, I think that's a great idea down the road. Boost.Bind can still be useful even after everyone gets std::bind at no additional cost with their compiler (though that might not happen 'til 2010 or so). If the current TR1 bind implementation were moved to Boost.TR1 then Boost.Bind could improve on the standard. One area where it could do better is in adaptability for call wrappers. In TR1 3.3/3 call wrappers with weak result types (the wrappers that bind must generate when the Result template parameter is not explicitly used) are required be un-adaptable (no result_type member) if the bound function object has no result_type member. It could do better if it provided a result<> member that used result_of. To go one step further, if Boost provided a result_of implementation using decltype in addition to a TR1 compliant result_of, Boost.Bind could support perfect, generic, non-intrusive return type deduction. Daniel