Hello, In my C code, I have: #define message message("Start\n"); When I look at the SRC file, I see: RSEG ?CO?MAIN ?SC_0: DB 'S' ,'t' ,'a' ,'r' ,'t' ,00AH,000H ; message("Start\n"); Why does the C51 version 1.32 keep "Start\n" in the output? Does this also happen to newer version? Thanks, Anh
"Why does the C51 version 1.32 keep "Start\n" in the output?" If you don't want it, why did you put it there?!
What I mean is that I have the code: #define message . . . message("Start\n"); message("Start\n") should expands to nothing so "Start\n" should not be in the output Anh
The macro expands to nothing, but the literal string constant still exists. How about another #define to make the constant vanish: //#define MessageString "Start\n" #define MessageString #define message(a) ... message(MessageString)
Why does the C51 version 1.32 keep "Start\n" in the output? Does this also happen to newer version? It does it because that is what you told the compiler to do. The line
#define message
message("Start\n");
("Start\n");
#define message(x) message("Start\n")
I don't know if this thread might help you: http://www.keil.com/forum/docs/thread3796.asp It shows (among other things) how to define a debug TRACE macro that can dissappear completely when the code is built in non-debug mode. The secret is in the use of an extra set of parenteses.
Thanks guys, Your responses really help me a lot. Looks like the TRACE macro is what I need to remove unnessary code. Is there a way to expand a macro into // to comment out the code? Ex: #define message // so that message("Start\n"); would expand to: //("Start\n"); Anh
How about: #define comment /##/ '##' is the "token pasting' operator that lets you glue bits together into a single token for the compiler.
Sounds like a very bad idea to me. remember, it's the preprocessor that does macro expansion, and it's also the prepropcessor that strips comments... Far better to make your macro expansion explicitly & directly conditional (as described in the TRACE example), than rely on the order of macro "side-effects"...
I'd agree. (My previous post was answering the question asked, rather than recommending a strategy. See the linked thread in which I make other comments.)