Re: [boost] [TTI] Review

Subject: Re: [boost] [TTI] Review
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-07-13 08:49:27

On 7/12/2011 4:57 PM, Jeffrey Lee Hellrung, Jr. wrote:
> On Tue, Jul 12, 2011 at 10:23 AM, Edward Diener<eldiener_at_[hidden]>wrote:
>
>> On 7/11/2011 11:55 PM, Jeffrey Lee Hellrung, Jr. wrote:
>>
>>> [I have not looked in detail at the TTI library and only *just* caught up
>>> on
>>> this email exchange...whew!]
>>>
>>> On Mon, Jul 11, 2011 at 8:07 PM, Lorenzo Caminiti<lorcaminiti_at_[hidden]**
>>>> wrote:
>>>
>>>   On Mon, Jul 11, 2011 at 10:53 PM, Edward Diener<eldiener_at_[hidden]*
>>>> *>
>>>> wrote:
>>>>
>>>>   [...]
>>>
>>>   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))
>>>>>
>>>>
>>>>
>>> This is acceptable.
>>>
>>>
>>>   or for variadic macros
>>>>>
>>>>> TTI_TEMPLATE(mytpl)
>>>>> TTI_TEMPLATE(mytpl,class,int,**template<typename class>   struct)
>>>>>
>>>>
>>>>
>>> Didn't Paul Mensonides (sp? sorry Paul!) rail against such constructs just
>>> a
>>> week or two ago? :)  I.e., shouldn't the template signature be packaged
>>> into
>>> a single parameter?
>>>
>>
>> I do not know what you are referring to regarding Paul Mensonides' opinion
>> but a large part of variadic macros value, IMO, is that they provide a
>> better syntax for the end-user while the pp-lib data types provide much
>> richer functionality internally. So I see no reason why the variadic macro
>> syntax should not be provided for end-user use.
>>
>
> Perhaps I'm misinterpreting and/or reading too much into
>
> http://article.gmane.org/gmane.comp.lib.boost.devel/221076
>
> e.g.,
>
> ">  BOOST_LOCAL_PARAMS(int x, int&  y) // (1) BOOST_LOCAL_PARAMS( (int x)
> [...]
> Regardless, I actually believe that the (1) case above is actually a
> large step *backwards*.  It's worse, not better, because it's trying (and
> failing) to be the underlying language and introducing a bunch of gotchas
> in the attempt."
>
> and subsequent follow-ups, e.g.,
>
> http://article.gmane.org/gmane.comp.lib.boost.devel/221104
>
> and, if so, let me know, but I read this and think (among other things),
> wouldn't it be better to package the template signature up into a single
> parameter?

I wanted to clarify my reaction to Paul's remarks in the URLs you 
quoted. I agree with him in general that it is better to pass 
preprocessing tokens as data in pp-lib data structures, since the data 
normally has a corresponding notion of equivalence to 'data' in C++ or 
other languages. This is because the pp-lib data structures mimic 
containers which computer languages use to pass data. But I do not see 
this as a hard and fast rule, especially when the preprocessing tokens 
being passed are being treated basically as 'strings' to be concatenated 
to form a C++ language construct. In that case I see nothing wrong with 
passing data as just variadic data tokens and accessing the concatenated 
'strings' as __VA_ARGS__.

This is the case with my design for TTI_HAS_TEMPLATE, where the actual 
template parameters on which the introspection is occuring are just 
strings of tokens being passed by the end-user to internally form the 
template construct which I will be checking in my code.