|
| Re: Using CDT for Macro Expansion in Comments [message #1716559 is a reply to message #1716547] |
Fri, 04 December 2015 19:52  |
David Vavra
Messages: 1426
Registered: October 2012 |
Senior Member |
|
|
CDT doesn't have a preprocessor or at least not one you can access. I think you want the GCC option -E which will stop processing after the preprocessor phase. Output is to stdout.
https://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/Preprocessor-Options.html
https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#Overall-Options
But it's the preprocessor that understands and removes comments so it won't help here.
Here's the preprocessor output from your example (edited to remove extra blank lines):
[dvavra@fred PNL]$ gcc -E Test.c
# 1 "Test.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "Test.c"
void main() {
}
If the source is only seen by the preprocessor and your presumed intermediate processor, you don't need comments. The preprocessor itself doesn't understand the source language. Example:
[dvavra@fred PNL]$ gcc -E Test2.c
# 1 "Test2.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "Test2.c"
void main() {
@ assert 1 == 1;
@ assert 1 +2 ==3 ;
}
This may help in interpreting those "#" lines inserted by the preprocessor.
https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html
You could also use a pre-preprocessor that removes the comment "//" if for some reason you want to be able to compile the original without expansion while retaining the expansion ability.
However, in your specific case, you don't need to do this. You could just call assert directly. I added
assert(A==1)
assert(B(1,2) ==3);;
to your example:
[dvavra@fred PNL]$ gcc -E Test3.c
# 1 "Test3.c"
# 1 "/home/dvavra/proj/HCP7/PNL//"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "Test3.c"
void main() {
@ assert 1 == 1;
@ assert (1 +2) ==3 ;
assert((1)==1);
assert((1 +2) ==3);
}
You should change the definition of B to have parentheses around the a+b part.
#define B(a,b) (a+b)
or you will get assert(a+b==3); which is OK here but may give unintended results in other situations. It's generally a good idea to surround potential expressions with parentheses as a guard. So,
#define A (1)
#define B(a,b) (a+b)
I did this in the above example. Depends on what you want though. YMMV.
EDIT:
After some pondering, I didn't go quite far enough when using parentheses. Macro B should really be:
#define B(a,b) ((a)+(b))
Consider an example: #define SQR(x) (x * x) called with SQR(5+3) yields (5+3*5+3) which is incorrect. In this case, precedence in the resulting expansion is a gotcha. Won't necessarily be one with x+x but something to think about.
Some are against macro use in principle and would recommend instead;
inline int SQR(int x) { return x*x; }
However, this is only available in C starting with C99 and inline is merely a request and not an order. The compiler could implement this as a static function which could cause other problems. For example, if the idea was to avoid having to specify some common part of an expression, say x*x+someCommonExpressionUsingVarsInScope, this is not easily accomplished with an inline function. A trivial example, perhaps, but it illustrates the problem.
Each way has pros and cons.
[Updated on: Sat, 05 December 2015 02:06] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.03291 seconds
] 
Search
Help
Register
Login
Home
