I would like to expand a variadic macro to another macro that takes a single argument, which is formed by joining the variadic arguments with a delimiter/separator (e.g. "_"). Something like this:
#define FOO(...)
FOO(a, b, c, d);
which expands into
#define BAR(X)
BAR(a_b_c_d);
I know there is __VA_ARGS__ for working with the variadic parameters, and ## for concatenation. How do I use them together to achieve what I want (preferably using C++17 and older language features, without libraries such as Boost)?
First, there are no language feature that directly tackles the question you are trying to solve. (there might be complier specific ones, but I don't know).
However, if you know the upper limit of the amount of argument that macro can take(preferably not too many), you can use this answer as a guide to iterate through the __VA_ARGS__: Is it possible to iterate over arguments in variadic macros?
On the other hand, Boost.Preprocessor is a header only library. While it is a pretty heavy macro-only library that could bring a lot of ugliness behind the scene, it does offer simple ways to handle macros that take up to thousands of parameter.
Here's a quick one that should work for you:
#define CAT_OP(index, state, elem) BOOST_PP_CAT(state, BOOST_PP_CAT(_, elem))
#define CAT_SEQ(seq) BOOST_PP_SEQ_FOLD_LEFT(CAT_OP, BOOST_PP_SEQ_HEAD(seq), BOOST_PP_SEQ_TAIL(seq))
#define CAT_VA_ARGS(...) CAT_SEQ(BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__))
Demo.
It treats the variadic as a Sequence, then performs a left fold over the sequence with concat operation.
Related
In C, it is quite common to capture argument as string literl via macro as mentioned in this answer:
#define CALL_DO_SOMETHING(VAR) do_something(#VAR, VAR);
But on the other hand, there are many projects with policies against the usage of macro and recommend always using templates instead.
I am wondering if it is possible to express the similar syntax in a modern C++ way or it is yet another corner case where macro has to be used?
Stringification can only be done by MACRO.
I know that in expanding a function-like preprocessor macro, the # and ## tokens in the top-level substitution list essentially act "before" any macro expansions on the argument. For example, given
#define CONCAT_NO_EXPAND(x,y,z) x ## y ## z
#define EXPAND_AND_CONCAT(x,y,z) CONCAT_NO_EXPAND(x,y,z)
#define A X
#define B Y
#define C Z
then CONCAT_NO_EXPAND(A,B,C) is the pp-token ABC, and EXPAND_AND_CONCAT(A,B,C) is the pp-token XYZ.
But what if I want to define a macro that expands just some of its arguments before pasting? For example, I would like a macro that allows only the middle of three arguments to expand, then pastes it together with an exact unexpanded prefix and an exact unexpanded suffix, even if the prefix or suffix is the identifier of an object-like macro. That is, if again we have
#define MAGIC(x,y,z) /* What here? */
#define A X
#define B Y
#define C Z
then MAGIC(A,B,C) is AYC.
A simple attempt like
#define EXPAND(x) x
#define MAGIC(x,y,z) x ## EXPAND(y) ## z
results in an error 'pasting ")" and "C" does not give a valid preprocessing token". This makes sense (and I assume it's also producing the unwanted token AEXPAND).
Is there any way to get that sort of result using just standard, portable preprocessor rules? (No extra code-generating or -modifying tools.)
If not, maybe a way that works on most common implementations? Here Boost.PP would be fair game, even if it involves some compiler-specific tricks or workarounds under the hood.
If it makes any difference, I'm most interested in the preprocessor steps as defined in C++11 and C++17.
Here's a solution:
#define A X
#define B Y
#define C Z
#define PASTE3(q,r,s) q##r##s
#define MAGIC(x,y,z,...) PASTE3(x##__VA_ARGS__,y,__VA_ARGS__##z)
MACRO(A,B,C,)
Note that the invocation "requires" another argument (see below for why); but:
MACRO(A,B,C) here is compliant for C++20
MACRO(A,B,C) will "work" in many C++11/C++17 preprocessors (e.g., gnu/clang), but that is an extension not a C++11/C++17 compliant behavior
I know that in expanding a function-like preprocessor macro, the # and ## tokens in the top-level substitution list essentially act "before" any macro expansions on the argument.
To be more precise, there are four steps to macro expansion:
argument identification
argument substitution
stringification and pasting (in an unspecified order)
rescan and further replacement
Argument identification associates parameters in the macro definition with arguments in an invocation. In this case, x associates with A, y with B, z with C, and ... with a "placemarker" (abstract empty value associated with a parameter whose argument has no tokens). For C++ preprocessors up to C++20, use of a ... requires at least one parameter; since C++20's addition of the __VA_OPT__ feature, use of the ... in an invocation is optional.
Argument substitution is the step where arguments are expanded. Specifically, what happens here is that for each parameter in the macro's replacement list (here, PASTE3(x##__VA_ARGS__,y,__VA_ARGS__##z)), where said parameter does not participate in a paste or stringification, the associated argument is fully expanded as if it appeared outside of an invocation; then, all mentions of that parameter in the replacement list that do not participate in stringification and paste are replaced with the expanded result. For example, at this step for the MAGIC(A,B,C,) invocation, y is the only mentioned qualifying parameter, so B is expanded producing Y; at that point we get PASTE3(x##__VA_ARGS__,Y,__VA_ARGS__##z).
The next step applies pastes and stringification operators in no particular order. Placemarker's are needed here specifically because you want to expand the middle and not the end, and you don't want extra stuff; i.e., to get A to not expand to X, and to stay A (as opposed to changing to "A"), you need to avoid argument substitution specifically. a.s. is avoided in only two ways; pasting or stringifying, so if stringification doesn't work we have to paste. And since you want that token to stay the same as what you had, you need to paste to a placemarker (which means you need one to paste to, which is why there's another parameter).
Once this macro applies the pastes to the "placemarkers", you wind up with PASTE3(A,Y,C); then there is the rescan and further replacement step, during which PASTE3 is identified as a macro invocation. Fast forwarding, since PASTE3 pastes its arguments, a.s. doesn't apply to any of them, we do the pastes in "some order" and we wind up with AYC.
As a final note, in this solution I'm using a varying argument to produce the placemarker token precisely because it allows invocations of the form MACRO(A,B,C) in at least C++20. I'm left-pasting that to z because that makes the addition at least potentially useful for something else (MAGIC(A,B,C,_) would use _ as a "delimiter" to produce A_Y_C).
I have always asked this but I have never received a really good answer; I think that almost any programmer before even writing the first "Hello World" had encountered a phrase like "macro should never be used", "macro are evil" and so on, my question is: why? With the new C++11 is there a real alternative after so many years?
The easy part is about macros like #pragma, that are platform specific and compiler specific, and most of the time they have serious flaws like #pragma once that is error prone in at least 2 important situation: same name in different paths and with some network setups and filesystems.
But in general, what about macros and alternatives to their usage?
Macros are just like any other tool - a hammer used in a murder is not evil because it's a hammer. It is evil in the way the person uses it in that way. If you want to hammer in nails, a hammer is a perfect tool.
There are a few aspects to macros that make them "bad" (I'll expand on each later, and suggest alternatives):
You can not debug macros.
Macro expansion can lead to strange side effects.
Macros have no "namespace", so if you have a macro that clashes with a name used elsewhere, you get macro replacements where you didn't want it, and this usually leads to strange error messages.
Macros may affect things you don't realize.
So let's expand a little here:
1) Macros can't be debugged.
When you have a macro that translates to a number or a string, the source code will have the macro name, and many debuggers can't "see" what the macro translates to. So you don't actually know what is going on.
Replacement: Use enum or const T
For "function-like" macros, because the debugger works on a "per source line where you are" level, your macro will act like a single statement, no matter if it's one statement or a hundred. Makes it hard to figure out what is going on.
Replacement: Use functions - inline if it needs to be "fast" (but beware that too much inline is not a good thing)
2) Macro expansions can have strange side effects.
The famous one is #define SQUARE(x) ((x) * (x)) and the use x2 = SQUARE(x++). That leads to x2 = (x++) * (x++);, which, even if it was valid code [1], would almost certainly not be what the programmer wanted. If it was a function, it would be fine to do x++, and x would only increment once.
Another example is "if else" in macros, say we have this:
#define safe_divide(res, x, y) if (y != 0) res = x/y;
and then
if (something) safe_divide(b, a, x);
else printf("Something is not set...");
It actually becomes completely the wrong thing....
Replacement: real functions.
3) Macros have no namespace
If we have a macro:
#define begin() x = 0
and we have some code in C++ that uses begin:
std::vector<int> v;
... stuff is loaded into v ...
for (std::vector<int>::iterator it = myvector.begin() ; it != myvector.end(); ++it)
std::cout << ' ' << *it;
Now, what error message do you think you get, and where do you look for an error [assuming you have completely forgotten - or didn't even know about - the begin macro that lives in some header file that someone else wrote? [and even more fun if you included that macro before the include - you'd be drowning in strange errors that makes absolutely no sense when you look at the code itself.
Replacement: Well there isn't so much as a replacement as a "rule" - only use uppercase names for macros, and never use all uppercase names for other things.
4) Macros have effects you don't realize
Take this function:
#define begin() x = 0
#define end() x = 17
... a few thousand lines of stuff here ...
void dostuff()
{
int x = 7;
begin();
... more code using x ...
printf("x=%d\n", x);
end();
}
Now, without looking at the macro, you would think that begin is a function, which shouldn't affect x.
This sort of thing, and I've seen much more complex examples, can REALLY mess up your day!
Replacement: Either don't use a macro to set x, or pass x in as an argument.
There are times when using macros is definitely beneficial. One example is to wrap a function with macros to pass on file/line information:
#define malloc(x) my_debug_malloc(x, __FILE__, __LINE__)
#define free(x) my_debug_free(x, __FILE__, __LINE__)
Now we can use my_debug_malloc as the regular malloc in the code, but it has extra arguments, so when it comes to the end and we scan the "which memory elements hasn't been freed", we can print where the allocation was made so the programmer can track down the leak.
[1] It is undefined behaviour to update one variable more than once "in a sequence point". A sequence point is not exactly the same as a statement, but for most intents and purposes, that's what we should consider it as. So doing x++ * x++ will update x twice, which is undefined and will probably lead to different values on different systems, and different outcome value in x as well.
The saying "macros are evil" usually refers to the use of #define, not #pragma.
Specifically, the expression refers to these two cases:
defining magic numbers as macros
using macros to replace expressions
with the new C++ 11 there is a real alternative after so many years ?
Yes, for the items in the list above (magic numbers should be defined with const/constexpr and expressions should be defined with [normal/inline/template/inline template] functions.
Here are some of the problems introduced by defining magic numbers as macros and replacind expressions with macros (instead of defining functions for evaluating those expressions):
when defining macros for magic numbers, the compiler retains no type information for the defined values. This can cause compilation warnings (and errors) and confuse people debugging the code.
when defining macros instead of functions, programmers using that code expect them to work like functions and they do not.
Consider this code:
#define max(a, b) ( ((a) > (b)) ? (a) : (b) )
int a = 5;
int b = 4;
int c = max(++a, b);
You would expect a and c to be 6 after the assignment to c (as it would, with using std::max instead of the macro). Instead, the code performs:
int c = ( ((++a) ? (b)) ? (++a) : (b) ); // after this, c = a = 7
On top of this, macros do not support namespaces, which means that defining macros in your code will limit the client code in what names they can use.
This means that if you define the macro above (for max), you will no longer be able to #include <algorithm> in any of the code below, unless you explicitly write:
#ifdef max
#undef max
#endif
#include <algorithm>
Having macros instead of variables / functions also means that you cannot take their address:
if a macro-as-constant evaluates to a magic number, you cannot pass it by address
for a macro-as-function, you cannot use it as a predicate or take the function's address or treat it as a functor.
Edit: As an example, the correct alternative to the #define max above:
template<typename T>
inline T max(const T& a, const T& b)
{
return a > b ? a : b;
}
This does everything the macro does, with one limitation: if the types of the arguments are different, the template version forces you to be explicit (which actually leads to safer, more explicit code):
int a = 0;
double b = 1.;
max(a, b);
If this max is defined as a macro, the code will compile (with a warning).
If this max is defined as a template function, the compiler will point out the ambiguity, and you have to say either max<int>(a, b) or max<double>(a, b) (and thus explicitly state your intent).
A common trouble is this :
#define DIV(a,b) a / b
printf("25 / (3+2) = %d", DIV(25,3+2));
It will print 10, not 5, because the preprocessor will expand it this way:
printf("25 / (3+2) = %d", 25 / 3 + 2);
This version is safer:
#define DIV(a,b) (a) / (b)
Macros are valuable especially for creating generic code (macro's parameters can be anything), sometimes with parameters.
More, this code is placed (ie. inserted) at the point of the macro is used.
OTOH, similar results may be achived with:
overloaded functions (different parameter types)
templates, in C++ (generic parameter types and values)
inline functions (place code where they are called, instead of jumping to a single-point definition -- however, this is rather a recommandation for the compiler).
edit: as for why the macro are bad:
1) no type-checking of the arguments (they have no type), so can be easily misused
2) sometimes expand into very complex code, that can be difficult to identify and understand in the preprocessed file
3) it is easy to make error-prone code in macros, such like:
#define MULTIPLY(a,b) a*b
and then call
MULTIPLY(2+3,4+5)
that expands in
2+3*4+5 (and not into: (2+3)*(4+5)).
To have the latter, you should define:
#define MULTIPLY(a,b) ((a)*(b))
I don't think that there is anything wrong with using preprocessor definitions or macros as you call them.
They are a (meta) language concept found in c/c++ and like any other tool they can make your life easier if you know what you're doing. The trouble with macros is that they are processed before your c/c++ code and generate new code that can be faulty and cause compiler errors which are all but obvious. On the bright side they can help you keep your code clean and save you a lot of typing if used properly, so it comes down to personal preference.
Macros in C/C++ can serve as an important tool for version control. Same code can be delivered to two clients with a minor configuration of Macros. I use things like
#define IBM_AS_CLIENT
#ifdef IBM_AS_CLIENT
#define SOME_VALUE1 X
#define SOME_VALUE2 Y
#else
#define SOME_VALUE1 P
#define SOME_VALUE2 Q
#endif
This kind of functionality is not so easily possible without macros. Macros are actually a great Software Configuration Management Tool and not just a way to
create shortcuts for reuse of code. Defining functions for the purpose of
reusability in macros can definitely create problems.
Preprocessor macros are not evil when they are used for intended purposes like:
Creating different releases of the same software using #ifdef type of constructs, for example the release of windows for different regions.
For defining code testing related values.
Alternatives-
One can use some sort of configuration files in ini,xml,json format for similar purposes. But using them will have run time effects on code which a preprocessor macro can avoid.
In my experience macros are not ideal for program size and can be difficult to debug. But if used carefully they are fine.
Often a good alternatives are generic functions and/or inline functions.
I would like to write a C++ macro taking arbitrary argument like:
#define MANIP(...) \
//Implementation
Such that writing
MANIP(m_a, m_b, m_c);
expands to
f(a, b, c);
g("a", "b", "c");
Is this possible?
Thank you in advance for helping me with this seemingly extravagant question :)
I don't believe there will be an easy way to go from m_a to a. However, the stringize operator # is part of standard C and C++.
for example, given
#define STRING(x) #x
then STRING(m_a) will be transformed to "m_a".
The preprocessor cannot split tokens. This means it is impossible to produce foo from m_foo or (as has recently been asked) foo from "foo".
If you can use variadic macros (as Matthieu M. points out, this means C99 or C++0x) Jens Gustedt’s P99 library would be helpful here. There are macros to make this even easier, but let’s make this readable to people who aren’t familiar with the library, OK?
Simplified case: there are either two or three arguments passed.
#define MANIP2(a, b) \
f(a, b) \
g(#a, #b)
#define MANIP3(a, b, c) \
f(a, b, c) \
g(#a, #b, #c)
#define MANIP(...) \
MANIP_( \
P99_PASTE2(MANIP, P99_NARG(__VA_ARGS__)), \
__VA_ARGS__) \
#define MANIP_(MANIPMAC, ...) MANIPMAC(__VA_ARGS__)
This illustrates the basic principle. In practice, there are foreach-style macros (analogous to Boost’s) to make this easier to code (though, as I mentioned, harder to read for the uninitiated). See the P99 library documentation for details.
It's not really possible to have the pre-processor (which is what handles #define statements, not the C++ compiler itself) break arguments into parts. So if you're trying to extract the a from m_a you can't do it. Instead it'd be better to define your macro like:
#define MANIP(m, a, b, c)
And require the 'm' to be a separate input.
Secondly, you can't easily convert from non-string inputs to string inputs. IE, converting from a to "a" isn't easily doable. I'm phrasing it that way since I know some CPPs (C-Pre-processor) can do it. But I don't think it's portable.
Generally when you're trying to do complex things, you should be working with the programming language rather than the CPP.
Specifically, in C++ you have templates which will let you get a lot farther with work like that than #define statements for the CPP.
Consider this macro:
#define MAKE_TEMPLATE(...) template <typename T, __VA_ARGS__ >
When used with zero arguments it produces bad code since the compiler expects an identifier after the comma. Actually, VC's preprocessor is smart enough to remove the comma, but GCC's isn't.
Since macros can't be overloaded, it seems like it takes a separate macro for this special case to get it right, as in:
#define MAKE_TEMPLATE_Z() template <typename T>
Is there any way to make it work without introducing the second macro?
No, because the macro invocation MAKE_TEMPLATE() does not have zero arguments at all; it has one argument comprising zero tokens.
Older preprocessors, apparently including GCC at the time this answer was originally written, sometimes interpreted an empty argument list as you'd hope, but the consensus has moved toward a stricter, narrower extension which more closely conforms to the standard.
To get the answer below to work, define an additional macro parameter before the ellipsis:
#define MAKE_TEMPLATE(UNUSED, ...) template <typename T, ## __VA_ARGS__ >
and then always put a comma before the first argument when the list is not empty:
MAKE_TEMPLATE(, foo )
Old answer
According to http://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.html, GCC does support this, just not transparently.
Syntax is:
#define MAKE_TEMPLATE(...) template <typename T, ## __VA_ARGS__ >
Anyway, both also support variadic templates in C++0x mode, which is far preferable.
In case of GCC you need to write it like this:
#define MAKE_TEMPLATE(...) template <typename T, ##__VA_ARGS__ >
If __VA_ARGS__ is empty, GCC's preprocessor removes preceding comma.
First of all beware that variadic macros are not part of the current C++. It seems that they will be in the next version. At the moment they are only conforming if you program in C99.
As of variadic macros with zero arguments, there are tricks à la boost to detect this and to macro-program around it. Googel for empty macro arguments.