Re: [boost] [TTI] Review

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

On 7/11/2011 11:07 PM, Lorenzo Caminiti wrote:
> On Mon, Jul 11, 2011 at 10:53 PM, Edward Diener<eldiener_at_[hidden]>  wrote:
>> On 7/11/2011 9:32 PM, Lorenzo Caminiti wrote:
>>> 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.
>>
>> I do not like your syntax. I much prefer the syntax I already have, with a
>> separate macro parameter merely being the template parameters if the
>> end-user is looking for a match, ie.
>>
>> TTI_TEMPLATE(mytpl,BOOST_PP_NIL)
>> TTI_TEMPLATE(mytpl,(class)(int)(template<typename class>  struct))
>>
>> or for variadic macros
>>
>> TTI_TEMPLATE(mytpl)
>> TTI_TEMPLATE(mytpl,class,int,template<typename class>  struct)
>
> OK but don't you need something in between the inner template typename
> and class? (Because they can be any arbitrary type name for non-type
> template parameters.) For example (again, leaving variadics a side for
> a moment):
>
>   TTI_TEMPLATE(mytpl,BOOST_PP_NIL)
>   TTI_TEMPLATE(mytpl,(class)(int)(template<typename)(class>  struct)) // [1]
>
> If so, is that better than the following?
>
>   TTI_TEMPLATE(mytpl,BOOST_PP_NIL)
>   TTI_TEMPLATE(mytpl,(class)(int)(template( (typename)(class) ) struct)) // [2]
>
> (You know I (somewhat strongly this time) prefer [2] to [1], see my
> comment #4. But that's just my opinion.)

There is no reason to prefer replacing '<' and '>' in the syntax for the 
template parameters with '(' and ')' other than to complicate matters 
unnecessarily.

After thinking about this last night I have decided to use a pp-array 
instead of a pp-seq as the extended syntax for the non-variadic version 
and as an alternate syntax for the variadic version. So the syntaxes for 
TTI_TEMPLATE,

using 'template<class,class,class> struct xxx' and
using 'template<class,int,template<class,class> > struct yyy' are:

TTI_TEMPLATE(xxx,BOOST_PP_NIL) // (1) non-variadic only
TTI_TEMPLATE(xxx) // (2) variadic only
TTI_TEMPLATE(yyy,(3,(class,int,template<class,class>))) // (3) both
TTI_TEMPLATE(yyy,class,int,template<class,class>) // (4) variadic only

Using a pp-array allows for the same syntax for specifying the template 
parameters, without the nonsense of changing the angle brackets to 
parentheses.

I want this to be straightforward for an end-user to use. For the check 
params case, (3) and (4), they just copy the template parameters from 
the template for which they are searching and use them.

While your idea of putting the entire template for which their are 
specifically searching in front of the name is externally attractive it 
has two negatives:

1) The end-user has to create a complicated syntax for the template 
parameters which does not correspond to how they actually look in the 
template.

2) It is impossible to parse using non-variadic macros and nearly 
impossible to parse using variadic macros.

While I welcome your arguments, I do not want to keep debating this 
endlessly. I believe I have come up with a syntax, as illustrated above, 
which is easy and understandable for the end-user, provides the maximum 
flexibility for the end-user, is fairly easily programmmable by me, and 
uses a single macro name for both the variadic and non-variadic versions 
of the macro.