Boost logo

Boost :

Subject: Re: [boost] [TTI] Review
From: lcaminiti (lorcaminiti_at_[hidden])
Date: 2011-07-12 13:27:32


Edward Diener-3 wrote:
>
> 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&lt;class, int&gt; class mytpl exist
>>>> TTI_TEMPLATE( template( (class) (int) ) class mytpl )
>>>>
>>>> // check if template&lt;class, int, template&lt;typename, class&gt;
>>>> 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&lt;typename)(class&gt;
>> 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&lt;class,class,class&gt; struct xxx' and
> using 'template&lt;class,int,template&lt;class,class&gt; > 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&lt;class,class&gt;))) // (3) both
> TTI_TEMPLATE(yyy,class,int,template&lt;class,class&gt;) // (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
>

What is the issue that makes it impossible? Can you show me an example?

> 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.
>

Yep, these were only WANT/NOTE comments. I think we discussed them well
enough and at the end I will use whatever syntax you provide because the
functionality of your library is useful to me. So no problem :)

(BTW, for my usage of your library it's essential that Boost.TTI does not
became a "variadics" only library especially if that is just to make the
syntax look better.)

--Lorenzo

--
View this message in context: http://boost.2283326.n4.nabble.com/TTI-Review-tp3658414p3662959.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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