Subject: Re: [boost] Review Request: Variadic Macro Data library
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2011-02-20 12:19:05
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