Re: [boost] [TTI] Review

Subject: Re: [boost] [TTI] Review
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-07-11 18:12:59

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:

1) All compilers for which TTI will compile correctly support variadic 
macros so don't worry about it and do nothing.

2) If the compiler does not support variadic macros, then the particular 
BOOS_TTI_TEMPLATE macro and functionality can not be used, and this 
needs to be documented.

3) Along with the the variadic version of BOOST_TTI_TEMPLATE which you 
suggested, and which in agreeing with you I can indeed implement and 
have decided to so do ( thanks for the good suggestion ), I will still 
need separate versions of BOOST_TTI_TEMPLATE and 
BOOST_TTI_TEMPLATE_CHECK_PARAMS for compilers which do not support 
variadic macros, possibly with slightly different names.

Now you may feel that 1) or 2) are the right ways to look at things, but 
I am obliged to do 3) even if it adds another macro name ( or two ) for 
compilers which do not support variadic macros. This still means that I 
will do as you have suggested for compilers which do support variadic 
macros. So I hope my choice of 3) satisfies you while still supporting 
the rare compiler user when variadic macros are not supported.

Also please remember that while most compilers support variadic macros, 
some of them need a compiler switch to be turned on to do so properly, 
and there are programmers who may not want to use that compiler switch.

> The pp skeleton code will go something
> like:
>
> #if VARIADICS
>
> #define TTI_TEMPLATE_VA_(...) \
>      TTI_TEMPLATE_SEQ_(VA_TUPLE_TO_SEQ(__VA_ARGS__))
>
> #define TTI_TEMPLATE(...) \
>      BOOST_PP_IIF(IS_VARIADIC(__VA_ARGS__), \
>          TTI_TEMPLATE_VA_ \
>      , \
>          TTI_TEMPLATE_SEQ_ \
>      )(__VA_ARGS__)
>
> #else // variadics
>
> #define TTI_TEMPLATE(seq) TTI_TEMPLATE_SEQ_(seq)
>
> #endif // variadics
>
> Take a look at BOOST_LOCAL_FUNCTION_PARAMS at:
> http://svn.boost.org/svn/boost/sandbox/local/boost/local/function.hpp
>
> This macro could be expanded to also detect a single token and accept the
> trait parameters in front. The full grammar will then read something like:
>
> TTI_TEMPLATE(trait, [tpl_signature_ {class | struct }] name)
>
> If the compiler supports variadics:
>
> tpl_signature_:
>      tpl_signature_va_ | tpl_signature_seq_ // you can use either variadics
> or sequences :)
>
> If not:
>
> tpl_signature_:
>      tpl_signature_seq_ // you must use sequences (because variadiacs are not
> supported)
>
> Where:
>
> tpl_signature_seq_:
>      template( (class | typename | type_identifier | tpl_signature_seq_) ...
> ) // the pp-seq
>
> tpl_signature_va_:
>      template<  {class | typename | type_identifier | tpl_signature_seq_} ...
>> // the pp-variadic tuple
>
> Where lexical conventions are:
>      [token] := token is optional
>      token1 | token 2 := either token1 or token2
>      {expr} := the token(s) resulting from the inner expression epxr
>      (tokens) ... := repeat tokens within parenthesis one or more times
> (tokens) (tokens) etc
>      tokens ... := repeat tokens separated by commas one or more times
> tokens, tokens etc
>
> I think this should be possible but usually the devil is in the details...
> so I don't know unless someone tries to implement it :)
>
> The real question still stands: Would this be a better interface for
> TTI_TEMPLATE? (You know my opinion is yes, but that's just my opinion.)
>
> Please ask questions and let me know if I am not able to explain myself.

I appreciate the code, and logic, but I can work it out for myself. My 
experience working with Paul Mensonides on variadic macro support for 
pp-lib has made me a much better macro coder using pp-lib, and I have 
learned nearly all the good 'tricks'.

Eddie