On 7/17/2011 7:02 PM, Jeffrey Lee Hellrung, Jr. wrote:
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 )>
For BOOST_TTI_HAS_COMP_MEMBER_FUNCTION(xxx) it generates a metafunction called has_comp_member_function_xxx ( in the reference I am giving the wrong name, which I will correct, but the macro metafunction table is correct ) and you are right that the template takes a single parameter of the form 'Result (T::*)( Arg0, Arg1 )' I really was asleep when answering you. This is the one case where the first template parameter is not the enclosing type. So your suggestion of checking the first type for a member function pointer does work if I combine BOOST_TTI_HAS_COMP_MEMBER_FUNCTION and BOOST_TTI_HAS_MEMBER_FUNCTION.
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> >
First and third are fine. It is what now exists for BOOST_TTI_HAS_COMP_MEMBER_FUNCTION and BOOST_TTI_HAS_MEMBER_FUNCTION respectively. The second, even if you like it, is unnecessary, and I also use it for BOOST_TTI_HAS_COMP_STATIC_MEMBER_FUNCTION so I do not want to create confusion.
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>
For the first, BOOST_TTI_HAS_COMP_MEMBER_FUNCTION, you have it correct. For the third, BOOST_TTI_HAS_MEMBER_FUNCTION, it would be: has_member_function_xxx< T, Result, boost::mpl::vector2< Arg0, Arg1>, boost::function_types::const_qualified> I could also try to combine BOOST_TTI_HAS_COMP_STATIC_MEMBER_FUNCTION and BOOST_TTI_HAS_STATIC_MEMBER_FUNCTION but that will be a little harder because they both begin with the enclosing type while the former follows the 'Result, boost::mpl::vector2< Arg0, Arg1>' syntax while the latter follows with the 'Result ( Arg0, Arg1 )' syntax.
would be most natural...???
Eddie