Re: [boost] Review Request: Variadic Macro Data library

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