Is there an alternative to using the preprocessor concatenation operator ## in a #define as follows
#define EXCLUDE_FROM_INSTANTIATION( Type ) \
#define SUPPRESS_##Type \
DO_CRAZY_STUFF() \
#undef SUPPRESS_##Type \
I don't think it can be done with the C preprocessor. The most obvious solution, but a bad one, is to run the preprocessor twice. That would involve custom build steps that wouldn't be intuitive to anoyone trying to maintain your code down the line. Generally if you need something like that it makes more sense to move to a more powerful macro processor/code generator. One of the most common free ones is m4.
Related
I wanted to see how the arduino function digitalWrite actually worked. But when I looked for the source for the function it was full of macros that were themselves defined in terms of other macros. Why would it be built this way instead of just using a function? Is this just poor coding style or the proper way of doing things in C?
For example, digitalWrite contains the macro digitalPinToPort.
#define digitalPinToPort(P) ( pgm_read_byte( digital_pin_to_port_PGM + (P) ) )
And pgm_read_byte is a macro:
#define pgm_read_byte(address_short) pgm_read_byte_near(address_short)
And pgm_read_byte_near is a macro:
#define pgm_read_byte_near(address_short) __LPM((uint16_t)(address_short))
And __LPM is a macro:
#define __LPM(addr) __LPM_classic__(addr)
And __LPM_classic__ is a macro:
#define __LPM_classic__(addr) \
(__extension__({ \
uint16_t __addr16 = (uint16_t)(addr); \
uint8_t __result; \
__asm__ __volatile__ \
( \
"lpm" "\n\t" \
"mov %0, r0" "\n\t" \
: "=r" (__result) \
: "z" (__addr16) \
: "r0" \
); \
__result; \
}))
Not directly related to this, but I was also under the impression that double underscore should only be used by the compiler. Is having LPM prefixed with __ proper?
If your question is "why one would use multiple layers of macros?", then:
why not? Notably in the pre-C99 era without inline. A canonical example was 1980s era getc which was (IIRC) at that time (SunOS3.2, 1987) documented as being a macro, with a NOTE in the man page telling (I forgot the details) that with some FILE* filearr[]; a getc(filearr[i++]) was wrong (IIRC, the undefined behavior terminology did not exist at that time). When you looked into some system headers (e.g. <stdio.h> or some header included by it) you could find the definition of such macro. And at that time (with computers running only at a few MHz, so thousand times slower than today) getc has to be a macro for efficiency reasons (since inline did not exist, and compilers did no interprocedural optimizations like they are able to do now). Of course, you could use getc in your own macros.
even today, some standards define macros. In particular today's waitpid(2) system call document WIFEXITED & WEXITSTATUS as macros, and it is sensible to #define some of your macros mixing both of them.
the main point is to understand the working of the C preprocessor, and its profoundly textual (so very brittle) nature. This is explained in all textbooks about C. Hence you need to understand what is happening under the hoods.
the rule of thumb with modern era C (that is C99 & C11) is to systematically prefer having some static inline function (defined in some header file) to an equivalent macro. In other words, #define some macro only when you cannot avoid it. And explicitly document that fact.
several layers of macro might (sometimes) increase code readability.
macros can be tested with #ifdef macroname which is sometimes useful.
Of course, when you dare defining several layers of macros (I won't call them "recursive", read about self-referential macros) you need to be very careful and understand what is happening with all of them (combined & separately). Looking into the preprocessed form is helpful.
BTW, to debug complex macros, I sometimes do
gcc -C -E -I/some/directory mysource.c | sed 's:^#://#:' > mysource.i
then I look into the mysource.i and sometimes even have to compile it, perhaps as gcc -c -Wall mysource.i to get warnings which are located in the preprocessed form mysource.i (which I can examine in my emacs editor). The sed command is "commenting" the lines starting with # which are setting source location (à la #line).... Sometimes I even do indent mysource.i
(actually, I have a special rule for that in my Makefile)
Is having LPM prefixed with __ proper?
BTW, names starting with _ are (by the standard, and conventionally) reserved to the implementation. In principle you are not allowed to have your names starting with _ so there cannot be any collision.
Notice that the __LPM_classic__ macro uses the statement-expr extension
(of GCC & Clang)
Look also at other programming languages. Common Lisp has a very different model of macros (and a much more interesting one). Read about hygienic macros. My personal regret is that the C preprocessor has never evolved to be much more powerful (and Scheme-like). Why that did not happen (imagine a C preprocessor able to invoke Guile code to do the macro expansion!) is probably for sociological & economical reasons.
You still should sometimes consider using some other preprocessor (like m4 or GPP) to generate C code. See autoconf.
Why would it be built this way instead of just using a function?
The purpose is likely to optimize functions' calls using pre-C99 compilers, that don't support inline functions (via inline keyword). This way, the whole stack of function-like macros is essentially merged by preprocessor into single block of code.
Every time you call a function in C, there is a tiny overhead, because of jumping around program's code, managing the stack frame and passing arguments. This cost is negligible in most applications, but if the function is called very often, then it may become a performance bottleneck.
Is this just poor coding style or the proper way of doing things in C?
It's hard to give definitive answer, because coding style is subjective topic. I would say, consider using inline functions or even (better) let the compiler inline them by itself. They are type-safe, more readable, more predictable, and with the proper assistance from compiler, the net result is essentially the same.
Related reference (it's for C++, but the idea is generally the same for C):
Why should I use inline functions instead of plain old #define macros?
I would like to have a macro that prints it's own name (among other things), but I can't find a way to expand the macros' name in the macro itself. Basically, I want the equivalent of __FUNCTION__ for a macro name.
For example:
#define F(a, b, c) do { \
printf("%s: %s,%s,%s\n", __MACRO__, #a, #b, #c); \
c = a+b; b=a; \
} while(0)
F(x,y,z);
I would like this to print "F: x,y,z" when called.
This is indeed an XY problem.
Here is really what I'm trying to do: Soft linking symbols from a library using dlopen and dlsyms.
In order to do so the typical way i know of is:
1) Include the headers from the library.
2) Declare a variable of the type of the function you are trying to import
3) Initialize said variable with a call to dlsym
4) The call the actual function through that variable instead of calling the symbol directly.
When you have many such function to soft link, it becomes very repetitive, so macro can help.
For an full fledge example of that, see here: https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/mac/SoftLinking.h
The problem in that example and others is that you still need to manually copy the parameters list for each the functions you want to soft link.
I'm trying to improve on that, and was experimenting with macro tricks, one of which would have been helped by being able to answer my initial question.
--
Beside my soft linking issues, there are other situation where this could be useful. For example for debugging purpose, one might want to print some diagnostic information before or after every call to certain functions. One could do so by overriding functions names with macros:
#define funcA(...) \
printf("Before call to %s:%d - %d\n", #funcA, __LINE__, g_count); \
funcA(__VA_ARGS__) \
printf("After call to %s:%d - %d\n", #funcA, __LINE__, g_count);
This works well enough but if I want to do this for a bunch of function, I have to copy that macro and change funcA to funcB 4 times for each new macro. I'd rather copy it and just change the name of the macros, without having to change what's inside.
I can optimize the above by defining an internal macro p, similar to what Basile suggested:
#define funcA(...) WRAP(funcA, __VA_ARGS__)
But that's still means I need to change funcA to the new function name twice every time I copy the macro for another function.
Read more about the C preprocessor. Read the documentation of GNU cpp. Notice its stringification and concatenation abilities.
Perhaps going thru some extra internal macro might help you, so you might have a public macro like
#define FOO(X,Y,Z) PRIVATE_FOO(FOO,X,Y,Z)
with another PRIVATE_FOO macro doing stringification tricks on its first argument, maybe
#define PRIVATE_FOO(Mac,X,Y,Z) do { \
printf("%s: %s,%s,%s\n", #Mac, #X, #Y, #Z); \
Z = X+Y; Y=X; \
} while(0)
Perhaps the C preprocessor is not adequate for your task. You could generate some C code with some other tool (perhaps the GPP preprocessor, or perhaps a simple awk or python script, or perhaps some real program; you'll need to change your build process, e.g. your Makefile, to handle that). You could customize your GCC compiler with MELT if you need that. Since we don't know your actual motivations, we cannot help more.
I cannot help more, unless you motivate and clarify your question.
Your soft linking issue needs simply to use some weak symbols. It is probably unrelated to C preprocessing.
I have an embedded OS that needs its resources to be defined statically by compile time.
So e.g.
#define NUM_TASKS 200
At the moment, I have one header file where every developer needs to declare the tasks he/she needs, kind of like this:
#define ALL_TASKS ( \
1 + \ /* need one task in module A */
2 \ /* need two tasks in module B */
)
and during compilation of the OS, there is a check:
#if (ALL_TASKS > NUM_TASKS)
#error Please increase NUM_TASKS in CONF.H
#endif
So when I compile and more Tasks are needed the compilation stops and gives explicit notice that the static OS won't have enough tasks for this to work.
So far so good.
Enter the lazy programmer that forgets to add the tasks he added in module A to the global declaration file in directory x/y/z/foo/bar/baz/.
What I would like is the following construct, which I can't seem to achieve with any macro tricks I tried:
Have macros to declare the resources needed in a module like so:
OS_RESERVE_NUMBER_OF_TASKS(2)
in the modules adds 2 to the global number of Tasks.
my first rough idea was something like this:
#define OS_RESERVE_NUMBER_OF_TASKS(max_tasks) #undef RESOURCE_CALC_TEMP_MAX_NUM_TASKS \
#define RESOURCE_CALC_TEMP_MAX_NUM_TASKS RESOURCE_CALC_MAX_NUM_TASKS + max_tasks \
#undef RESOURCE_CALC_MAX_NUM_TASKS \
#define RESOURCE_CALC_MAX_NUM_TASKS RESOURCE_CALC_TEMP_MAX_NUM_TASKS \
#undef RESOURCE_CALC_TEMP_MAX_NUM_TASKS
but that doesn't work because a #define in a #define does not work.
So the question basically is:
Do you have an idea how it would be possible to split the calculation of the number of tasks into multiple files (namely the modules themselves) and have that number comapred to the defined max number of tasks during compile time?
If this isn't solvable with pure C preprocessor, I'll have to wait until we change the make system to scons...
Can you require that tasks have some ID or similar which all task users must use?
tasks.h
enum {
TASK_ID_TASK_A_1,
TASK_ID_TASK_B_1,
TASK_ID_TASK_B_2,
NUM_TASKS
};
void * giveResource(int taskId, int resourceId);
user_module_B.c
#include "tasks.h"
...
resource = giveResource(TASK_ID_TASK_B_1, resource_id_B_needs);
You can update the value of a macro in the course of translating one unit using the Boost Preprocessor library's evaluated slots functionality. It defines several "slots" that can be treated as mutable global variables by preprocessor code, which will let you add to a value as you go along rather than defining it with a single expression.
(It's pure standard C, but the code that implements it is rather complicated)
You can't do it in one line, because it relies on calls to #include, and that means you can't wrap it up into a pretty one-liner macro, but it would look something like this:
#define TASK_SLOT 2 //just pick one
#define ALL_TASKS BOOST_PP_SLOT(TASK_SLOT)
#define BOOST_PP_VALUE 1 + 2
#include BOOST_PP_ASSIGN_SLOT(TASK_SLOT) // ALL_TASKS now evals to 3
#define BOOST_PP_VALUE 3 + ALL_TASKS
#include BOOST_PP_ASSIGN_SLOT(TASK_SLOT) // ALL_TASKS now evals to 6
As Drew comments (I may have misunderstood your req.), this is only valid for one translation unit. Which is fine if you have a central NUM_TASKS and each unit is allowed to add up its own ALL_TASKS figure.
If you need the value to increment across multiple .c files (so that the final ALL_TASKS is the total across all modules, not for one), you'd need to wrap them up into a unity build for this technique to work, which most people reckon is a bad idea. A more advanced build system would then probably be appropriate, because the preprocessor is only designed to work on single units.
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.
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