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.
I'm looking at this macro within Microsoft's GSL:
#define GSL_CONTRACT_CHECK(type, cond) \
(GSL_LIKELY(cond) ? static_cast<void>(0) \
: gsl::details::throw_exception(gsl::fail_fast( \
"GSL: " type " failure at " __FILE__ ": " GSL_STRINGIFY(__LINE__))))
Let's simplify it to ignore what I don't care about:
#define CHECK_1(cond) \
(cond ? static_cast<void>(0) : do_something() )
Now, I would intuitively write something like:
#define CHECK_2(cond) \
do { \
if (not (cond)) {do_something();} \
} while(0)
My question: Is there any difference between these wrapping mechanisms? Is there perhaps some corner use case where one causes some unintended compilation gaffe, but not the other?
Note:
This might actually be a C question in disguise, I'm not sure there's any real C++ issue here.
So, my skillz tell me that CHECK_1 and CHECK_2 should be entirely equivalent and only a matter of style. I can't think of why this might not be the case. #NathanOliver seems to agree.
The do while version is a statement while the ternary is an expression. For instance, if assert was defined using a do/while, it couldn't be used in the form
c1 ? x : c2 ? y : (assert(c3), z)
On the other hand, only the do while form allows any multistatements macro definitions in C as a ternary requires expressions as operands.
This distinction makes the choice clear in C: ternary if possible as the macro can be used in more situations ; do while otherwise.
In C++, where macros are still needed in certain situations, at least to short circuit parameter evaluation at compile time when a macro is disabled, the do while form is never the best option (IMHO). I tend to prefer either the ternary form or, even more c++ fashioned: wrapping the macro definition in an anonymous lambda called immediately.
Using a lambda enables multi statements macros just as with do while. It is a single expression as with the ternary. It enables type safety when forwarding the macro arguments to the lambda (you need to trust the compiler to inline that part at runtime, and it will). Passing macro arguments to the lambda prevents name collision between the macro arguments and the macro body. In general it provides scope isolation due to lambda capture being disabled by default. It enables converting varargs to parameter packs for flexibility an type safety starting from c++17. Plus you get a clean stack frame in the debugger when breaking inside the macro.
My problem is this - I tried to make a Heap checker to be used in testing and for this
a) overload standard global new/delete operators so that they let my custom class know about each alloc and delete
b) add custom new operators that have a signature like
void* operator new(size_t size, const char* filename, const char* function, int line)
c) make a macro that replaces standard new calls with my new calls and the given file, func & line
#define new new(__FILE__, __FUNCTION__, __LINE__)
this works well, except for cases where somebody uses a custom new in a class or operator new() directly - that means that I can only define this macro after loading in standard C++ libs (functional, algo, string...), as they are heavy on doing that stuff
d) so we came up with the brilliant idea of using var-arg macro which would solve these problems
#define new(...) new(__VA_ARGS__, __FILE__, __FUNCTION__, __LINE__)
this works well for all the problematic cases in the last point, as any parameters passed to either new (someargs) or operator new(size_t, someargs) gets replaced by the var-arg macro and sent into my custom new operators
But it doesn't work for the most usual case of just calling:
int* ptr = new int;
because the new call doesn't have parentheses, therefore it's not expanded as a function macro
Which brings me to the question mentioned in the title :
Is there any way to do this with macros so that one would be able to replace the same character sequence in original code no matter whether it's called without a parameter list or with one?
The desired result in this case would be:
new without parentheses after it - new -> new(__file__, __func__, __line__)
new with parentheses after it - new(args) -> new(args, __file__, __func__, __line__)
I realize that this is an obvious case of trying to redefine the same macro, so it shouldn't be possible. I'm looking for some preprocessor magic that would let me get around that.
Disclaimer : I know it's ugly and we actually settled on the solution in c) with simply ignoring the standard library news. But as I did spend some time researching the possibility I'd be interested if anyone has a potential way to do this.
Cheerios!
___EDIT___
Please don't concentrate on what I'm trying to accomplish but only on the question in the title. The Heap Checker itself can be implemented in a variety of standard-compliant ways and this is not one of them :) It's more of my curiosity as to how much it's possible to bend the language with the preprocessor.
The question stands - can I use some preprocessor commands to achieve a different behaviour for the same sequence with and without parentheses after it (that is, something that works just as if I had both a function-like and object-like macro of the same name)
Thanks for any and all answers :)
No, you can't. See §16.3p2 [cpp.replace] of the C++ standard (similar wording found in other versions and in the equivalent section of the C standard; nothing has changed) (emphasis mine):
An identifier currently defined as an object-like macro (see below) may be redefined by another #define preprocessing directive provided that the second definition is an object-like macro definition and the two
replacement lists are identical, otherwise the program is ill-formed. Likewise, an identifier currently defined as a function-like macro (see below) may be redefined by another #define preprocessing directive provided that the second definition is a function-like macro definition that has the same number and spelling of parameters, and the two replacement lists are identical, otherwise the program is ill-formed.
In other words, a macro identifier is either object-like or function-like, but the same identifier cannot be used for both.
I know that my question is similar to this one or this one, but I find that it is not really the same and, more, the second one has not an answer accepted, I decided to ask if it is correct to add preprocessor directives when a function-like macro is called?
In my case I have a function-like macro:
#define FUNC_MACRO(a, b) // do something with the variables
and somewhere in the code I call it with specific difference if some other macro is defined:
// ...
FUNC_MACRO(aVal
#ifdef ANOTHER_MACRO
+ offset
#endif // ANOTHER_MACRO
, bVal);
// ...
I tested on my machine (linux, with gcc 4.8) and it worked ok (with and without the preprocessor directives, and with and without ANOTHER_MACRO defined), but is it safe to do so?
I read the 16.3/9 paragraph from the answer of the first similar question, but is it true for my case too?
The C language leaves this as undefined behavior in 6.10.3 Macro replacement, ¶11:
If there are sequences of preprocessing tokens within the list of arguments that would otherwise act as preprocessing directives, the behavior is undefined.
So indeed it's wrong to do it.
GCC and perhaps other popular compiles don't catch it, which is probably why many users of the language are not aware. I encountered this when some of my code failed to compile on PCC (and promptly fixed the bug in my code).
Update: PJTraill asked in the comments for a case where it would be "misleading or meaningless" to have preprocessor directives inside a macro expansion. Here's an obvious one:
foo(a, b,
#ifdef BAR
c);
#else
d);
#endif
I'm not sure whether it would have been plausible for the language to specify that balanced preprocessor conditionals inside the macro expansion are okay, but I think you'd run into problems there too with ambiguities in the order in which they should be processed.
Do the following instead?
#ifdef ANOTHER_MACRO
FUNC_MACRO(aVal + offset, bVal);
#else
FUNC_MACRO(aVal, bVal);
#endif
EDIT: Addressing concern raised by comment; I do not know if the OP's method is specifically wrong (I think other answers cover that). However, succinctness and clarity are two aspects held to be pretty important when coding with C.
As such I would much prefer to find better ways to achieve what the OP seems to be trying, by slightly rethinking the situation such as I have offered above. I guess the OP may have used a triviallised example but I usually find with most C situations that if something is becoming overly complex or attempting to do something it does not seem like the language should allow, then there are better ways to achieve what is needed.
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.