Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk