A bunch of code just got handed over to me and I got baffled by macros in the header. I could not understand what they are for:
#define WRAPPER_MACRO(symbol) symbol
#define ANOTHER_SYMBOL WRAPPER_MACRO(ANOTHER_SYMBOL)
#define PREFIXED_ANOTHER_SYMBOL WRAPPER_MACRO(PFX_ANOTHER_SYMBOL)
Why do this? What is the benefit?
Edit: This is not the actual verbatim code from my codebase but it has the same template. I just replaced macro names.
As #Michael said, we'll need to see the real macros to know for sure. But without them, I'm willing to take a few guesses that might help you out.
The macro nesting is probably a stringification thing. This bit of code is from a codebase I maintain:
// As per http://gcc.gnu.org/onlinedocs/cpp/Stringification.html:
// "If you want to stringify the result of expansion of a macro argument, you
// have to use two levels of macros."
#ifndef STRINGIFY
#define STRINGIFY(s) TOSTRING(s)
#define TOSTRING(s) #s
#endif
I'm also guessing your PREFIXED_ANOTHER_SYMBOL macro is doing something similar to this, using the # or ## preprocessor directives to prepend a certain symbol to whatever you feed the macro.
Related
Could I implement this in C?
#define X abc
then X_menu(); will be preprocessed as abc_menu();
In another build
if I define X def
then X_menu(); will be def_menu();
I'm sure there should be a method, but I could not figure out.
No, you wouldn't want this behavior as it would be very unsafe and difficult to deal with replacing every X in every name. However, you could use a macro function to do something similar
#define X(F) abc##F
X(_menu();)
## is macro concatenation, so X(_menu();) will expand to abc_menu();
As Roger points out, the macro will also work with the syntax
X(_menu)();
which you may find easier to read
I am traversing through linux kernel code. I found a macro defined as #define __async_inline __always_inline. I searched for __always_inline,I found the following statement #define __always_inline inline. My question is why they need to do like this? They can directly use inline instead of this macro's?
The code says this:
#ifdef CONFIG_HAS_DMA
#define __async_inline
#else
#define __async_inline __always_inline
#endif
It is self-explained. __async_inline will be replaced by inline if CONFIG_HAS_DMA is not defined.
This is a common way to parameterize code, to move a decision of some sort (in this case, the use of inline) to a single place, so that should that decision change (for whatever reason: different compilers, different configuration options, different architectures), there is only one single place to change.
Currently, I am using:
#define p printf(
In order to reduce the amount of characters I use within printf's throughout the program, e.g, instead of:
printf("Hello, World.");
I can do:
p"Hello, World.");
My question is, is it possible to further shorten this? E.g, adding the ending brace into the define? Something like (pseudo-code) :
#define p printf()
Or some such? Or even a shorter way of doing the #define?
Edit: I'd better clarify before I get downvoted into oblivion. The point of this is not to save keystrokes because I am lazy, or because I want to make it unreadable. I have already written the program in question (which is quite readable and hopefully won't get me put in programmers hell), and I am curious as to how low I can get the char count. This question would assist in doing so.
You can use macros with variadic arguments:
#define p(...) printf(__VA_ARGS__)
Even though a name such as p is not a good idea, this syntax can very well be used with conditional logging. For example:
#ifndef NDEBUG
# define log(...) fprintf(stderr, __VA_ARGS__)
#else
# define log(...) ((void)0)
#endif
Sometimes, you may want to do something specific with the format specifier. For that, you can take advantage of a gcc extension (and possibly other compilers) for example such as the following:
#define log(fmt, ...) fprintf(stderr, "Log: "fmt"\n", ##__VA_ARGS__)
Note that ##__VA_ARGS__ is not standard. See this answer also.
Yes your macro can take an argument
http://gcc.gnu.org/onlinedocs/cpp/Macro-Arguments.html
That is evil. Stop trying to save keystrokes and improve your typing skill instead. It is not an appropriate use of macros to "simplify" code in this manner, because you will simply make your code harder to read for ordinary C programmers. Always keep readability in mind.
Be happy you don't have to write System.out.println instead.
Based on your demonstrated need, consider puts
This would be safer/better to macro-ize, since it doesn't take a variable number of arguments. You've taken printf and limited it use. Also, a user will type p("%d") and the program will blow up.
I am using both the JUCE Library and a number of Boost headers in my code. Juce defines "T" as a macro (groan), and Boost often uses "T" in it's template definitions. The result is that if you somehow include the JUCE headers before the Boost headers the preprocessor expands the JUCE macro in the Boost code, and then the compiler gets hopelessly lost.
Keeping my includes in the right order isn't hard most of the time, but it can get tricky when you have a JUCE class that includes some other classes and somewhere up the chain one file includes Boost, and if any of the files before it needed a JUCE include you're in trouble.
My initial hope at fixing this was to
#undef T
before any includes for Boost. But the problem is, if I don't re-define it, then other code gets confused that "T" is not declared.
I then thought that maybe I could do some circular #define trickery like so:
// some includes up here
#define ___T___ T
#undef T
// include boost headers here
#define T ___T___
#undef ___T___
Ugly, but I thought it may work.
Sadly no. I get errors in places using "T" as a macro that
'___T___' was not declared in this scope.
Is there a way to make these two libraries work reliably together?
As greyfade pointed out, your ___T___ trick doesn't work because the preprocessor is a pretty simple creature. An alternative approach is to use pragma directives:
// juice includes here
#pragma push_macro("T")
#undef T
// include boost headers here
#pragma pop_macro("T")
That should work in MSVC++ and GCC has added support for pop_macro and push_macro for compatibility with it. Technically it is implementation-dependent though, but I don't think there's a standard way of temporarily suppressing the definition.
Can you wrap the offending library in another include and trap the #define T inside?
eg:
JUICE_wrapper.h:
#include "juice.h"
#undef T
main.cpp:
#include "JUICE_wrapper.h"
#include "boost.h"
rest of code....
I then thought that maybe I could do some circular #define trickery like so:
The C Preprocessor doesn't work this way. Preprocessor symbols aren't defined in the same sense that a symbol is given meaning when, e.g., you define a function.
It might help to think of the preprocessor as a text-replace engine. When a symbol is defined, it's treated as a straight-up text-replace until the end of the file or until it's undefined. Its value is not stored anywhere, and so, can't be copied. Therefore, the only way to restore the definition of T after you've #undefed it is to completely reproduce its value in a new #define later in your code.
The best you can do is to simply not use Boost or petition the developers of JUCE to not use T as a macro. (Or, worst case, fix it yourself by changing the name of the macro.)
What I'm trying to figure out is if something such as this (written in C):
#define FOO 15
#define BAR 23
#define MEH (FOO / BAR)
is allowed? I would want the preprocessor to replace every instance of
MEH
with
(15 / 23)
but I'm not so sure that will work. Certainly if the preprocessor only goes through the code once then I don't think it'd work out the way I'd like.
I found several similar examples but all were really too complicated for me to understand. If someone could help me out with this simple one I'd be eternally grateful!
Short answer yes. You can nest defines and macros like that - as many levels as you want as long as it isn't recursive.
The answer is "yes", and two other people have correctly said so.
As for why the answer is yes, the gory details are in the C standard, section 6.10.3.4, "Rescanning and further replacement". The OP might not benefit from this, but others might be interested.
6.10.3.4 Rescanning and further replacement
After all parameters in the replacement list have been substituted and
# and ## processing has taken place, all placemarker preprocessing tokens are removed.
Then, the resulting preprocessing token sequence
is rescanned, along with all subsequent preprocessing tokens of the
source file, for more macro names to replace.
If the name of the macro being replaced is found during this scan of
the replacement list (not including the rest of the source file's
preprocessing tokens), it is not replaced. Furthermore, if any nested
replacements encounter the name of the macro being replaced, it is not
replaced. These nonreplaced macro name preprocessing tokens are no
longer available for further replacement even if they are later
(re)examined in contexts in which that macro name preprocessing token
would otherwise have been replaced.
The resulting completely macro-replaced preprocessing token sequence
is not processed as a preprocessing directive even if it resembles
one, but all pragma unary operator expressions within it are then
processed as specified in 6.10.9 below.
Yes, it's going to work.
But for your personal information, here are some simplified rules about macros that might help you (it's out of scope, but will probably help you in the future). I'll try to keep it as simple as possible.
The defines are "defined" in the order they are included/read. That means that you cannot use a define that wasn't defined previously.
Usefull pre-processor keyword: #define, #undef, #else, #elif, #ifdef, #ifndef, #if
You can use any other previously #define in your macro. They will be expanded. (like in your question)
Function macro definitions accept two special operators (# and ##)
operator # stringize the argument:
#define str(x) #x
str(test); // would translate to "test"
operator ## concatenates two arguments
#define concat(a,b) a ## b
concat(hello, world); // would translate to "helloworld"
There are some predefined macros (from the language) as well that you can use:
__LINE__, __FILE__, __cplusplus, etc
See your compiler section on that to have an extensive list since it's not "cross platform"
Pay attention to the macro expansion
You'll see that people uses a log of round brackets "()" when defining macros. The reason is that when you call a macro, it's expanded "as is"
#define mult(a, b) a * b
mult(1+2, 3+4); // will be expanded like: 1 + 2 * 3 + 4 = 11 instead of 21.
mult_fix(a, b) ((a) * (b))
Yes, and there is one more advantage of this feature. You can leave some macro undefined and set its value as a name of another macro in the compilation command.
#define STR "string"
void main() { printf("value=%s\n", VALUE); }
In the command line you can say that the macro "VALUE" takes value from another macro "STR":
$ gcc -o test_macro -DVALUE=STR main.c
$ ./test_macro
Output:
value=string
This approach works as well for MSC compiler on Windows. I find it very flexible.
I'd like to add a gotcha that tripped me up.
Function-style macros cannot do this.
Example that doesn't compile when used:
#define FOO 1
#define FSMACRO(x) FOO + x
Yes, that is supported. And used quite a lot!
One important thing to note though is to make sure you paranthesize the expression otherwise you might run into nasty issues!
#define MEH FOO/BAR
// vs
#define MEH (FOO / BAR)
// the first could be expanded in an expression like 5 * MEH to mean something
// completely different than the second