Re: [boost] [TTI] Review

Subject: Re: [boost] [TTI] Review
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-07-11 22:53:34

On 7/11/2011 9:32 PM, Lorenzo Caminiti wrote:
> On Mon, Jul 11, 2011 at 9:11 PM, Edward Diener<eldiener_at_[hidden]>  wrote:
>> On 7/11/2011 7:03 PM, Edward Diener wrote:
>>>
>>> On 7/11/2011 6:25 PM, lcaminiti wrote:
>>>>
>>>> Edward Diener-3 wrote:
>>>>>
>>>>> On 7/11/2011 5:02 PM, lcaminiti wrote:
>>>>>>
>>>>>> Edward Diener-3 wrote:
>>>>>>>
>>>>>>> On 7/11/2011 2:45 PM, Joel falcou wrote:
>>>>>>>>
>>>>>>>> See :
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/MetaScale/nt2/blob/master/modules/sdk/include/nt2/sdk/details/preprocessor.hpp
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> for the file, line 85 and after.
>>>>>>>>
>>>>>>>> The point is it works without variadics
>>>>>>>
>>>>>>> Line 87: #define NT2_PP_DETAILS_STRIP_PARENS_I(...) 1,1
>>>>>>> Line 91: #define NT2_PP_DETAILS_TEST_ARITY_I(a,b,c,...) c
>>>>>>> Line 96: #define NT2_PP_DETAILS_MAYBE_STRIP_PARENS_2_I(...)
>>>>>>> __VA_ARGS__
>>>>>>>
>>>>>>> Clearly it needs variadic macro support.
>>>>>>>
>>>>>>> I have already added a REMOVE_PARENS ( the equivalent to
>>>>>>> NT2_PP_STRIP(X)
>>>>>>> in your URL above ) to a proposed addition to pp-lib which I am
>>>>>>> discussing with Paul Mensonides, based on the updated variadic macro
>>>>>>> support on which both of us worked and which is now in the Boost
>>>>>>> trunk.
>>>>>>>
>>>>>>> My point is also that I may well be able to simplify the
>>>>>>> BOOST_TTI_TEMPLATE macros in TTI using variadic macro support
>>>>>>> techniques, as Lorenzo suggested, but I do not feel correct in
>>>>>>> dropping
>>>>>>> macro support support for compilers which do not support variadic
>>>>>>> macros
>>>>>>> although I understand there are few of them left.
>>>>>>>
>>>>>>
>>>>>> I will later reply to all your comments on my review but let me quickly
>>>>>> clarify a couple of things.
>>>>>>
>>>>>> My suggestion was to have the *same* macro TTI_TEMPLATE handle *both*
>>>>>> variadics tupletes and sequences.
>>>>>
>>>>> I did understand it, and I am willing to do that, but of course it needs
>>>>> variadic macro support in the compiler. But what do you think I should
>>>>> do if the compiler does not support variadic macros ? The possibilities
>>>>> are:
>>>>>
>>>>
>>>> I was trying to say for compilers without variaidics (detected by
>>>> BOOST_NO_VARIADIC_MACROS) you can do:
>>>>
>>>> TTI_TEMPLATE(trait, [tpl_signature_seq_ {class | struct}] name)
>>>>
>>>> And for compilers with variadics you can do:
>>>>
>>>> TTI_TEMPLATE(trait, [{tpl_signature_seq_ | tpl_signature_va_} {class |
>>>> struct}] name)
>>>>
>>>> Can't you? (Am I missing something?)
>>>
>>> I do not want to stick the tpl-signature as a prefix sequence to the
>>> name. It is ugly and confusing. For some reason you like this sort of
>>> thing but I find it poor. Furthermore having to extract the template
>>> parameters from the 'name' itself may be undoable even with varaiadic
>>> macros much less with only non-variadic macros.
>>
>> After thinking about this, and calming down a bit ( my apologies for getting
>> emotional above ), it may be possible, even without variadic macros, to
>> distinguish between:
>
> OK, it looks like we're exchanging messages in real-time here-- I sent
> you a reply and .5 sec after I got this other message :)
>
>> TTI_TEMPLATE(name)
>>
>> and
>>
>> TTI_TEMPLATE((pp-seq) name)
>>
>> as well as extracting both the pp-seq and the name separately from the
>> second form. Still I will probably opt for:
>>
>> TTI_TEMPLATE(name,BOOST_PP_NIL)
>>
>> or
>>
>> TTI_TEMPLATE(name,(pp-seq))
>>
>> to distinguish between the two for non-variadic macros. I really do not like
>> the idea of prepending the name being looked for with the template
>> parameters in a single macro argument.
>
> I don't think for 1 single macro argument the template prefix is
> needed (see [1] below).
>
> Let's write down some examples for what I meant with comment #5
> leaving variadics (comment #6) and implementation issues a side for a
> moment. Let's just try to see if (1) we understand each other and (2)
> we list options that users will find to be a better interface for the
> library. I will not list the trait parameter (even if I suggested to
> always add it).
>
> Here's some examples of what I was proposing with my comment #5:
>
> // check if mytpl exist
> TTI_TEMPLATE( mytpl ) // [1]
>
> // check if template<class>  struct mytpl exist
> TTI_TEMPLATE( template( (class) ) struct mytpl )
>
> // check if template<class, int>  class mytpl exist
> TTI_TEMPLATE( template( (class) (int) ) class mytpl )
>
> // check if template<class, int, template<typename, class>  struct>
> class mytpl exist
> TTI_TEMPLATE( template( (class) (int) (template( (typename) (class) )
> struct) class mytpl )
>
> The real question still is: For the TTI library user, is the interface
> above better than TTI_TEMPLATE_CHECK_PARAMS? (Again, you know my
> answer is yes but that's just my opinion.) I think we should all focus
> the discussion in try to answer this question first.

I do not like your syntax. I much prefer the syntax I already have, with 
a separate macro parameter merely being the template parameters if the 
end-user is looking for a match, ie.

TTI_TEMPLATE(mytpl,BOOST_PP_NIL)
TTI_TEMPLATE(mytpl,(class)(int)(template<typename class> struct))

or for variadic macros

TTI_TEMPLATE(mytpl)
TTI_TEMPLATE(mytpl,class,int,template<typename class> struct)

Eddie