Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk