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/det...
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?)
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'.
Sure. BTW, if you end-up taking a look at Boost.Local and see strange things, please let me know (I'm happy to improve/fix my code if needed). Thanks, --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/TTI-Review-tp3658414p3661016.html Sent from the Boost - Dev mailing list archive at Nabble.com.