This question already has an answer here:
Macro expansion and stringification: How to get the macro name (not its value) stringified using another macro?
(1 answer)
Closed 8 months ago.
I am wondering if there is anyway to stringify a macro expanision that is another macro before it gets completley expanded. Easier to show in code:
#define A_MACRO 0
#define ANOTHER_MACRO A_MACRO
I want to expand ANOTHER_MACRO into the string "A_MACRO"
Double stringification does not work, it stringifies ANOTHER_MACRO into 0. I have searched and cannot find an answer and played around with macros in a test application, but I have had no luck. Is it possible?
Edit: I do not have the ability to change either macro. A_MACRO has a descriptive name that I would like to use, and we "point" to it with another macro that follows a standard name and I can grab it with a file parser. I was hoping I could just write a stringification macro to get that name, but I think I will have to find a way to latch onto it with my file parser, thanks everyone for your help.
No, there isn't. You can either not expand the macro argument, or you can fully expand it.
There may be a solution to whatever the underlying problem is, but this is a dead end.
Related
This question already has answers here:
What is the benefit of putting #undef before #define?
(2 answers)
Closed last year.
I'm reviewing the open source FANN library. As far as I have examined, the developers contributing to the project are quite experienced in C. But I wonder why they do the following in doublefann.h file:
#undef DOUBLEFANN
#define DOUBLEFANN
What's the purpose of removing an identifier using #undef and then redefining it using #define?
I don't think there's any secret; it's just that the author of that code wanted to override any existing preprocessor-value of DOUBLEFANN (e.g. as set by an earlier line in some header-file, or perhaps as provided by a -DDOUBLEFANN=something argument on the compiler's command-line) and replace it with his own definition of DOUBLEFANN as a defined preprocessor macro with an empty value.
As to why the author felt it was necessary to do that, I have no idea.
This question already has answers here:
How to define a C++ preprocessor macro through the command line with CMake?
(4 answers)
How to pass macro definition from "make" command line arguments (-D) to C source code?
(6 answers)
Closed 1 year ago.
I was searching for some way to change the macro values. I want to use macro values like user-friendly variables. Like we used the scanf function and store the user input to a variable.
If this way is not possible then Can we use the CMake or make to do this? If yes then how?
Example.
header. h
#define LED 8
I want to change this value before compile. Is there any way we can do that?
Please explain in detail. So I can understand perfectly. Possible add some example or link of example.
Thanks.
You need a compilation flag -DLED=8 where you replace the 8 with whatever value you want.
You should also wrap the LED macro with
#ifndef LED
#define LED 8
#endif
This way, the -DLED=X will define the macro as X and, since it's already defined, the header file won't try to redefine it.
Regarding CMake, try adding add_compile_definitions(LED=8). Check this for more info.
This question already has answers here:
What does it mean by "#define X X"?
(2 answers)
Closed 2 years ago.
I am looking into if_link.h in the Linux kernel headers and it contains this enum:
enum {
IFLA_UNSPEC,
IFLA_ADDRESS,
IFLA_BROADCAST,
IFLA_IFNAME,
IFLA_MTU,
IFLA_LINK,
IFLA_QDISC,
IFLA_STATS,
IFLA_COST,
#define IFLA_COST IFLA_COST
IFLA_PRIORITY,
#define IFLA_PRIORITY IFLA_PRIORITY
IFLA_MASTER,
#define IFLA_MASTER IFLA_MASTER
....
}
The defines look useless; what is their purpose? And why do only some of the items have defines?
As Matthew Slattery mentioned in another answer, the GCC manual has a section, namely ยง3.10.5 Self-Referential Macros, which describes the possible uses of such macros.
One possible use is to avoid infinite expansion when a macro expands into a call to itself, but this is a discouraged practice. The other use is to define both preprocessor macros and enums:
You might do this if you want to define numeric constants with an enum, but have `#ifdef' be true for each constant.
So this is basically what M.M said in the above comment.
This seems to be confirmed by this patch:
<rant> Why do the kernel developers behave so inconsistently? I much
prefer interfaces where an enum value is ALSO added as a define to
itself, to make it easy to probe which features are available in the
current set of headers.
The really frustrating part is the some of the enum values in this
set have #defines, and some of them don't.
This macros used in IPv4 protocol for provides the ability to create, remove, or get information about a specific network interface. See man page.
I was reading the Ruby source code when I stumbled upon the following:
#define RSTRING_EMBED_LEN_MAX RSTRING_EMBED_LEN_MAX
context
As far as I can tell RSTRING_EMBED_LEN_MAX is not defined before. (I grepped the Ruby source recursively).
What does that line do exactly?
This define will expand into the literal token RSTRING_EMBED_LEN_MAX, just as you would expect.
By looking at the source, you'll see, that the macro is used to define an enum value with the same name, set to (int)((sizeof(VALUE)*3)/sizeof(char)-1).
The commit, linked by matt, explains they converted all macros into enums, to improve debugging. And the macro was left for compatibility reasons.
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