On 7/12/2011 4:57 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Tue, Jul 12, 2011 at 10:23 AM, Edward Diener<eldiener@tropicsoft.com>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@gmail.com**
wrote:
On Mon, Jul 11, 2011 at 10:53 PM, Edward Diener<eldiener@tropicsoft.com*
*> 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.