On Sun, Jul 17, 2011 at 3:18 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
On 7/17/2011 4:15 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Sun, Jul 17, 2011 at 12:35 PM, Edward Diener<eldiener@tropicsoft.com
wrote:
On 7/17/2011 2:22 PM, Jeffrey Lee Hellrung, Jr. wrote:
Looks like it would be a simple matter of dispatching on
is_member_function_pointer, is_function, and is_member_object_pointer from Boost.TypeTraits.
It is little more complicated than that. The second parameter ( the first is the enclosing type ) in the non-composite form is the return type. A return type could be a member function pointer itself etc., right ?
I think you can dispatch based on (a) the first template parameter is a member function pointer (or member data pointer for MEMBER_DATA)
This means switching the first two parameters when specifying the composite syntax. I am not comfortable with that only because the library regularizes on the notion that the first template parameter is the enclosing type. Otherwise your idea below will work.
Whoops, I had understood the composite syntax to allow you to do has_member_function_xxx< Result (T::*)( Arg0, Arg1 ) > but I see from the documentation of HAS_COMP_MEMBER_FUNCTION that it isn't the case. So why not support the above syntax instead? I don't see the point in specifying the enclosing class type twice. To reiterate what I had above, I propose the following to all be equivalent: has_member_function_xxx< Result (T::*)( Arg0, Arg1 ) > has_member_function_xxx< T, Result ( Arg0, Arg1 ) > // my personal preference, probably has_member_function_xxx< T, Result, boost::mpl::vector2< Arg0, Arg1 > > By the way, how do you check for const member functions? I don't remember seeing anything about this in the documentation. I would assume something like has_member_function_xxx< Result (T::*)( Arg0, Arg1 ) const > has_member_function_xxx< T const, Result ( Arg0, Arg1 ) > has_member_function_xxx< T const, Result, boost::mpl::vector2< Arg0, Arg1 >
would be most natural...??? - Jeff