
on Wed Sep 14 2011, "John M. Dlugosz"
On 9/13/2011 11:38 AM, Nevin Liber wrote:
On 13 September 2011 11:13, Dave Abrahams
wrote: I know this isn't the answer you're looking for, but IMO you should just avoid std::binary_function and friends. They don't buy you anything you can't get from embedding the typedefs directly, and they can inhibit the empty base optimization.
And they are deprecated in C++11 (along with mem_fun and mem_fun_ref, for that matter).
Thanks.
So what is the "best practice" for creating something that plays well with older compilers that don't have decltype or all the C++11 features?
What kinds of things are first_argument_type and second_argument_type needed for?
Almost nothing these days. There are some (mostly older) library components like bind2nd that create wrapper function objects with non-templatized call operators, and therefore need first_argument_type and second_argument_type so they can deduce the parameter types to the generated wrapper.
I'm supposing that they would make bind smarter, work better perhaps, or give more sensible error messages.
bind uses templated function call operators, so it doesn't need to know what arguments the underlying function object can accept. It wouldn't use the information if you supplied it. The only interesting information for modern library components is the return type of your function (object). On compilers without decltype you need to do something like embed a result_type typedef or provide an embedded result<> metafunction. -- Dave Abrahams BoostPro Computing http://www.boostpro.com