Re: [boost] [TTI] Review for The Type Traits Introspection library by Edward Diener **extended**

Subject: Re: [boost] [TTI] Review for The Type Traits Introspection library by Edward Diener **extended**
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-07-17 20:06:53

On 7/17/2011 7:02 PM, Jeffrey Lee Hellrung, Jr. wrote:
> On Sun, Jul 17, 2011 at 3:18 PM, Edward Diener<eldiener_at_[hidden]>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_at_[hidden]
>>>> 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