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

Subject: Re: [boost] Review Request: Variadic Macro Data library
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-02-20 13:55:47

On 2/20/2011 12:19 PM, Paul Mensonides wrote:
> 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.

A library presents an interface where one uses a macro to do 
"something". The programmer using that macro to accomplish some task in 
that library. The use of that macro is not "metaprogramming" as I 
understand it, although I think this is just an argument about a word 
meaning than any real disagreement. Imagine a relative newbie in C++ 
using a macro and then being told he is "metaprogramming". No doubt he 
would feel a little proud of that fact <g>, but I doubt if that would 
prove much about his real "metaprogramming" knowledge or skills, not 
that I think "metaprogramming" is that abstruse.

Undoubtedly a C++ programmer should understand macros. But whether he 
understands it at his own level and whether he understands it as you do 
are different things.

>
>> 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?

By the same token what is wrong with SOME_MACRO(a,b,c) ? The point is 
not that their is something wrong with SOME_MACRO((a,b,c)) or even with 
SOME_MACRO((a)(b)(c)) but that programmers using macros which a library 
provides seem more comfortable with SOME_MACRO(a,b,c). The reason for 
this is most probably because the latter mimics function call syntax and 
a library implementer is looking syntactically for as much sameness as 
possible in order to promote ease of use ( or memorability ).

One may just as well ask why C++ adapted variadic macros as part of the 
next proposed standard ? I believe it was solely for syntactic ease of 
use with a variable amount of macro tokens. It sure wasn't because C++ 
provided much functionality to deal with the variadic data per se.

>  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.

Nah ! I don't believe it <g>.

>  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.

Fair enough. But I believe some other proposed Boost libraries, besides 
my own TTI library, are using variadic macro syntax in their public 
interface. Why should they not do that and take advantage of pp-lib at 
the same time ?