Boost logo

Boost :

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

On Mon, Jul 11, 2011 at 7:03 PM, Edward Diener <eldiener_at_[hidden]> 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 :
>>>>>> 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
>>     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).


Boost list run by bdawes at, gregod at, cpdaniel at, john at