Boost logo

Boost :

Subject: Re: [boost] Review Request: Variadic Macro Data library
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-02-21 12:57:05

On 2/21/2011 3:57 AM, Paul Mensonides wrote:
> On Sun, 20 Feb 2011 13:55:47 -0500, Edward Diener wrote:
>> On 2/20/2011 12:19 PM, Paul Mensonides wrote:
>>> 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.
> What I'm getting is actually what you mention before, mimicking function
> calls. That even being a goal (or considered a good thing by accident)
> rather than being benign (at best) is where things go wrong. Macros are
> code generators (or, I suppose, code "removers"). They are not even
> remotely tied to the syntax of the underlying language. When a macro
> (that isn't a general purpose pp-lib macro) is defined, all too often the
> author designs the macro such that its invocation appears to fit into the
> syntax of the underlying language. For example, hacks such as using do/
> while loops in order to require a semicolon outside the macro.
> #define REGISTER(...) \
> do { \
> /* whatever */ \
> } while (false) \
> /**/
> int main() {
> REGISTER(a, b, c); //<--
> }
> That point of view is evil.
> Demanding that competent C++ programmers have a proper view of macros is
> not demanding that they know all of the tricks that I or others know to
> manipulate the preprocessor. However, it does require them to know that
> macros are a fundamentally different thing with fundamentally different
> mechanics (even if they don't understand those mechanics to the level of
> detail that I or others do).
>>> 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 interface is (potentially) silently broken when some other argument
> needs to be passed. I.e. MACRO(a, b, c) => MACRO(id, a, b, c) is
> potentially a silent break. MACRO((a, b, c)) => MACRO(id, (a, b, c)) is
> not.
>> 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 ).
> Another way to provide comfort is via education. Hardcore pp-
> metaprogramming knowledge is not required for this.

Providing function-like syntax for invoking a macro with a variable
number of parameters, as an alternative to pp-lib data syntax, is
important to end-users and library developers if just for the sake of
familiarity and regularity. A programmer using a "call" syntax which may
be a macro or a function is not going to stop and say: this is a
function so I can call it as 'somefunction(a,b,c)', this is a macro and
therefore I must call it as 'somemacro((a,b,c))'. Instead he will ask
that the same syntax be applied to both. You seem to feel this is wrong
and that someone invoking a macro should realize that it is a macro (
and normally does because it is capital letters ) and therefore be
prepared to use a different syntax, but I think that regularity in this
respect is to be valued.

>> 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.
> Actually, it is more likely just for the sake of compatibility with C. I
> originally proposed adding them at a committee meeting in Redmond. That
> proposal got rolled into a general "compatibility with C preprocessor"
> proposal.
>>> 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>.
> Shocking, but true!
>>> 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 ?
> As I said before, I don't have a problem with these particular macros.
> I.e. DATA_TO_SEQ(__VA_ARGS__). I only have a problem with ALGORITHM_B
> (...) => ALGORITHM_A(DATA_TO_SEQ(__VA_ARGS__)). There are lots of other
> uses of DATA_TO_SEQ (et al) and element extraction (ala TUPLE_ELEM)
> besides this. As long as the pp-lib doesn't provide definitions like
> ALGORITHM_B, I don't have a problem with it. If users provide that
> themselves, in spite of a lack of endorsement for the library, the
> ramifications are on their own heads.
> The following are the chaos-pp analogs of the macros that you have in the
> sandbox right now. If they were added to the pp-lib (where they belong
> if they are worthwhile) these are the names that I would use (not because
> I'm wedded to the names, but for symmetry with existing practice).
> ----
> Chaos has no direct analog of this ATM. Normally the functionality is
> produced via CHAOS_PP_TUPLE_SIZE((...)). However, if it existed it would
> be called CHAOS_PP_VARIADIC_SIZE(...). If I (or you) added it to the pp-
> lib, I would prefer it be called BOOST_PP_VARIADIC_SIZE(...) for symmetry
> with existing practice.
> ----
> The direct analog of this in Chaos is CHAOS_PP_VARIADIC_ELEM(n, ...). If
> I (or you) added it to the pp-lib, I would prefer it be called

Did you mean BOOST_PP_VARIADIC_ELEM(n,...) ?

> ----
> Chaos has no direct analog of this because (as you know), it's pointless
> (unless you're doing something internally to for compiler workarounds).

I do not think it is pointless. I am going variadics -> tuple. The
end-user wants regularity, even if its a no-brainer to write '(
__VA_ARGS__ )'.

I think this is where we may differ, not technically, but in our view of
what should be presented to an end-user. I really value regularity ( and
orthogonality ) even when something is trivial. My view is generally
that if it costs the library developer little and makes the end-user see
a design as "regular", it is worth implementing as long as it is part of
the design even if it is utterly trivial. You may feel I am cosseting an
end-user, and perhaps you are right. But as an end-user myself I
generally want things as regular as possible even if it causes some very
small extra compile time.

> -----
> Chaos has no direct analog for any of these because it doesn't consider
> variadic data to be a sequential data structure. Chaos does have
> conversion macros to one data structure to another. However, the basic
> functionality to do that is implemented by one generic algorithm:
> => (a)(b)(c)
> => (a, (b, (c, ...)))
> The library normally only supplies direct non-generic versions when there
> is a reasonable efficiency gain over the generic version or when there is
> an interesting implementation mechanic that I want to preserve. There
> are a lot of these direct conversions for CHAOS_PP_SEQ and
> CHAOS_PP_TUPLE. The current set is:
> The primary reason that there is no direct conversion (other than
> (__VA_ARGS__)) to the other data types is that with variadic data there
> is no such thing as an empty sequence and there is no safe way to define
> a rogue value for it without artificially limiting what the data can
> contain.

I understand this.

My point of view is that although it's theoretically a user error to use
an empty sequence for a variadic macro even if a corresponding pp-lib
data type can be empty, in reality it should be allowed since there is
no way to detect it. I understand your point of view that you want to do
everything possible to eliminate user error, and I agree with it, but
sometimes nothing one can do in a language is going to work ( as you
have pointed out with variadics and an empty parameter ). In that case I
do not see why functionality should not be provided anyway and if the
user then uses it accidentally it becomes his problem. To not provide
functionality because a user error, which can not be detected, might
occur is not the way I usually view software design ( sorry to sound
dogmatic, because I am normally very practical as a programmer ).

In the case of converting from variadics to pp data types, if the
end-user passes an empty sequence, and the pp=lib data type supports an
empty sequence, then it is fine with me.

Going the other way from a pp data type to variadics, I admit I did not
consider the case in my current library where the pp data type is empty.
Since this can be detected on the pp data type side, I think I can put
out a BOOST_PP_ASSERT_MSG(cond, msg) in that case, or I can choose to
ignore it if that is what I decide to do. But in either case it is a
detectable problem.

> ----
> The direct analog of this in Chaos is CHAOS_PP_TUPLE_SIZE(tuple). If I
> (or you) added this to the pp-lib, it should be just BOOST_PP_TUPLE_SIZE
> (tuple).
> ----
> The direct analog of this in Chaos is CHAOS_PP_TUPLE_ELEM(n, tuple) where
> it ignores the 'n' if variadics are enabled.

The 'n' tells which tuple element to return. How can it be ignored ?

> CHAOS_PP_TUPLE_ELEM(?, 0, (a, b, c)) => a

OK, I see. the '?' is just a marker for the size of the tuple when there
are variadics and must be specified when there are not.

> If this was added to the pp-lib, I would prefer that it did so the same
> way. However, another way would be "overload" the macro (which as no
> direct analog in the pp-lib or your library). Basically, that ends up
> being something like:
> #if (variadics enabled)

That is an interesting technique below. Bravo ! As long as it is
documented, since it confused me until I took a few more looks and
realized what you are doing.

> #define BOOST_PP_TUPLE_ELEM(...) \
> )(__VA_ARGS__) \
> /**/
> #define BOOST_PP_TUPLE_ELEM_2(n, tuple) // ...
> #define BOOST_PP_TUPLE_ELEM_3(size, n, tuple) \
> BOOST_PP_TUPLE_ELEM_2(n, tuple) \
> /**/
> #else
> #define BOOST_PP_TUPLE_ELEM(size, n, tuple) // old way
> #endif
> -----
> The direct analog of this in Chaos is CHAOS_PP_TUPLE_REM_CTOR (which,
> BTW, stands for "constructed parentheses removal"). The "constructed"
> refers to when the tuple is the direction result of a macro expansion.
> CHAOS_PP_REM_CTOR(?, MACRO()). Otherwise, if you already have a tuple
> 't', just use CHAOS_PP_REM t. ATM, Chaos has CHAOS_PP_TUPLE_REM,
> CHAOS_PP_TUPLE_REM_CTOR, and CHAOS_PP_REM. It does not have a
> ----
> If added to the pp-lib, should be the same as BOOST_PP_TUPLE_ELEM above.
> Either ignored size argument or overload.
> ----
> Isn't this just REM_CTOR?

Sure. But again I value regularity even when something is trivial.

> ----
> These I don't see the point of these--particularly with the pp-lib
> because of compiler issues. These already exist as BOOST_PP_LIST_ENUM
> and SEQ_ENUM. There isn't an ARRAY_ENUM currently, but it's easy to
> implement. The distinction between these names and the *_TO_DATA variety
> is that these are primary output macros.

That's just a name. Names can always be changed. My macros are the same
as yours in that they are output macros which convert the pp-lib data
types to variadic data.

> If an attempt is made by a user
> to use the result as macro arguments, all of the issues with compilers
> (e.g. VC++) will be pulled into the user's domain.

The returned variadic data is no different from what the user will enter
himself when invoking a variadic data macro. The only compiler issue I
see is the empty variadic data one.

I do see the point of these macros again as a simple matter of regularity.

> ----
> To summarize what I would prefer:
> -> (nothing, unless workarounds are necessary)

I know its trivial but I still think it should exist.

> or BOOST_PP_TUPLE_TO_ARRAY(size, (...))
> or BOOST_PP_TUPLE_TO_LIST(size, (...))
> or BOOST_PP_TUPLE_TO_SEQ(size, (...))

For the previous three, see above discussion about using
SOME_MACRO(a,b,c) vs. SOME_MACRO((a,b,c)). I do understand your reason
for this as a means of getting around the empty-variadics user error.
But I still feel that treating variadic data here as tuples is wrong
from the end-user point of view even though it elegantly solves the
empty variadic data problem. In my internal code I am solving the
problem in the exact same way, but I am keeping the syntax as
SOME_MACRO(a,b,c) as opposed to SOME_MACRO((a,b,c)).

So I would say, please consider using the SOME_MACRO(a,b,c) instead as I
am doing.

I would even say to change my names to:


in order to match the ENUM names you already have in pp-lib for
converting the other way and which you have below.

But keep the SOME_MACRO(a,b,c) like syntax.

> or BOOST_PP_TUPLE_SIZE(size, tuple)
> -> BOOST_PP_TUPLE_ELEM(n, tuple)
> or BOOST_PP_TUPLE_ELEM(size, n, tuple)
> or BOOST_PP_TUPLE_REM_CTOR(size, tuple)
> or BOOST_PP_TUPLE_REVERSE(size, tuple)
> or BOOST_PP_TUPLE_TO_LIST(size, tuple)
> or BOOST_PP_TUPLE_TO_SEQ(size, tuple)
> or BOOST_PP_TUPLE_REM_CTOR(size, tuple)

Again I value the orthogonality of the pp-data to variadic data idea in
common names. BOOST_PP_TUPLE_REM_CTOR does not suggest that to the
end-user. How about:

#define BOOST_PP_TUPLE_ENUM(tuple) \

in order to mimic your three following names.

> also add:


> The basic gist is to add the low-level variadic stuff and adapt the
> existing tuple stuff to not require the size.

I think our only real disagreements can be summed up as:

I want the end-user to view variadic data as such from a perceptual
point of view, even with the
empty-variadics-is-an-error-which-can-not-be-caught problem. That is why
I supply the various conversions from variadic sequences to pp-lib types
and back explicitly, and I want some regularity in names reflecting that
although I do not insist on my own names.

You feel that variadics as input for conversion should in general be
treated as a pp-lib tuple since creating a tuple from variadic macro
data is trivial.

Boost list run by bdawes at, gregod at, cpdaniel at, john at