On Sun, 20 Feb 2011 11:52:20 -0500, Edward Diener wrote:
I could not agree more that it does not scale well for general use, and I understand that it is not the way you would want to extend the pp-lib to use variadic macros internally.
But consider just the case where an end-user is doing some pp programming for their own use, and the use of other end-user programmers using their library, which may have nothing to do with pp programming itself.
All uses of macros are metaprogramming. The more programmers understand that, the less "macro problems" there will be.
They want to present a macro interface which uses variadic macros rather than, let's say, Boost PP sequences. They are doing this just to make their interface look easier to use, ie. SOME_MACRO(a,b,c,d,etc.) rather than SOME_MACRO((a),(b),(c),(d),etc.).
So, what's the problem with SOME_MACRO((a, b, c)) instead? I.e. a tuple rather just variadic content? The real scalability problem is with higher-order macros, not something like MACRO(a, b, c) vs. MACRO((a)(b) (c)) vs MACRO((a, b, c)). When higher-order macros are involved, there is a much higher price in providing this syntactic convenience. That price ultimately leads to lack of re-use and replication in library code. Believe it or not, I actually use preprocessor metaprogramming (as well as template metaprogramming) quite heavily in my own code. The only time that I would provide a macro that uses the variadic data as an element sequence (that's not a general-purpose pp-library macro) as an interface is if it is absolutely certain that it will never become higher-order and that the number of arguments before the variadic data will never change. Regards, Paul Mensonides