The title say it all really, the function object returned from mem_fn is an unspecified type that: "3.5: 2 The simple call wrapper shall be derived from std::unary_function<cv T*, Ret > when pm is a pointer to member function with cv-qualifier cv and taking no arguments, where Ret is pm’s return type. 3 The simple call wrapper shall be derived from std::binary_function<cv T*, T1, Ret > when pm is a pointer to member function with cv-qualifier cv and taking one argument of type T1, where Ret is pm’s return type." However my tests indicate that this inheritance is not taking place, and in any case the nested members result_type and argument_type are not present in the function object returned. Regards, John Maddock.
Can you please attach a simple testcase? Thanks.
Created attachment 10218 [details] Test case (caution complicated) The attached test cases are rather complex - sorry but it's easier to give you all the bad news at once :-) They also depend on Boost, and you'll need to change the include from <functional> to <tr1/functional> to mesh with gcc's current (non-conforming?) include style. As for the original bug report: it's easy to verify by inspecting the source that _Mem_fn has no base class as required. Hope this gives you what you need. John Maddock
(In reply to comment #2) > As for the original bug report: it's easy to verify by inspecting the source > that _Mem_fn has no base class as required. I beg to disagree. Have you really checked the actual versions of it for member function taking no argument and taking one argument? If I do that in the straightforward way, that is looking at the -E output, the expected bases are there. In other terms, functional_iterate.h looks fine to me. > Hope this gives you what you need. Well, to date, not really, to be honest. I would appreciate a decently sized testcase (eventually, what are we going to put in the testsuite, otherwise?!?) or at least reaching a minimum of consensus about the matter by looking at the sources... Thanks in advance for your help.
This is not a bug. TR1 3.5 refers to member function pointers, not member data pointers as in the submitted test case. mem_fn has no result_type for member data pointers because the constness of the result type depends on the constness of the argument type; use result_of to get the appropriate result type given the argument type. See also TR1 DR 10.24 "Mem_fn result_type for pointer to data member".
Thanks for the clarification Doug: having re-read the text, the issues list, and scratched my head for a while I agree with you. I'll update the Boost test case appropriately. Feel free to close this one down as invalid (it appears I don't have permission to do that). Regards, John.
Agreed.