On 7/11/2011 9:17 PM, Lorenzo Caminiti wrote:
On Mon, Jul 11, 2011 at 7:03 PM, Edward Diener<eldiener@tropicsoft.com> 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/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?)
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.
You have fallen in love with this sort of thing, perhaps because you have had to do something similar your 'local' library, but I will opt for a simpler and clearer way, even if it means a few extra macro names.
Fair enough. My comment #5 was just a NOTE so I actually really don't feel strongly about it (and "love" would instead be a strong feeling ;) ). If I'm the only one suggesting this syntax, you should probably ignore it.
However, as you suggested, I can do:
TTI_TEMPLATE(name,pp-seq-or-variadic-template-parameters)
Sure, my comment #6 (removing VM macros) is independent from my comment #5 (removing CHECK_PARAMS macros).
with variadic parameters support, and will look to implement a single macro on that side rather than both TTI_TEMPLATE and TTI_TEMPLATE_CHECK_PARAMS.
I'm not sure about this... wouldn't you expect the macros to be symmetric with and without variadics? In other words, if there is a CHECK_PARAMS without variadics, I would expect it to be a CHECK_PARAMS also with variadics. That is because CHECK_PARAMS does not semantically have anything to do with variadics, it is just "the macro you use when you specify the template parameters" (variadics or not).
As my second reply explains I might be able to do a single nonvariadic macro of either: TTI_TEMPLATE(name,BOOST_PP_NIL) and TTI_TEMPLATE(name,(pp-seq)) to distinguish between the two. I will look into it. Eddie