Re: [boost] [TTI] Review

Subject: Re: [boost] [TTI] Review
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-07-11 21:32:42

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.

Thanks,
--Lorenzo