c-preprocessor

I found this regarding how the C preprocessor should handle string literal concatenation (phase 6). However, I can not find anything regarding how this is handled in C++ (does C++ use the C preprocessor?). The reason I ask is that I have the following: const char * Foo::encoding = "\0" "1234567890\0abcdefg"; where encoding is a static member of class Foo . Without the availability of concatenation I wouldnt be able to write that sequence of characters like that. const char * Foo::encoding = "\01234567890\0abcdefg"; Is something entirely different due to the way \012 is interpreted. I dont have

I have encountered the #define pre-processor directive before while learning C, and then also encountered it in some code I read. But apart from using it to definite substitutions for constants and to define macros, I've not really understook the special case where it is used without a "body" or token-string. Take for example this line: #define OCSTR(X) Just like that! What could be the use of this or better, when is this use of #define necessary? This is used in two cases. The first and most frequent involves conditional compilation: #ifndef XYZ #define XYZ // ... #endif You've surely used

Using VS2005 with BLAH_BLAH defined the following preprocessor conditional is false: #elif defined BLAH_BLAH but if I change it to #elif defined(BLAH_BLAH) it is true. Why do the parentheses make a difference here? It shouldn't make any difference, unless BLAH_BLAH is defined as something funny. The header file was created with a linux editor and added to the project with "Add Existing", after creating the file in the VS editor it evaluates to true. Must be a LF/CR issue? 来源： https://stackoverflow.com/questions/5223789/elif-defined-without-parentheses

Can I use the following in C++ ?: #define $ cout int main(){ $<<"Hello World!\n"; return 0; } I'm wondering whether it will cause any conflicts. It's not definitively legal , but your implementation is allowed to accept it. Consider: [C++11: 2.5/1]: Each preprocessing token that is converted to a token (2.7) shall have the lexical form of a keyword, an identifier, a literal, an operator, or a punctuator. Here, your $ is obviously not a keyword, operator or punctuator (as these are enumerated in the standard), and it doesn't look like a literal, so it could only be an identifier; now,

I have this code which works: #include <stdio.h> #define A(x) x B #define B(x) C(x, #define C(x,y) y x) int main( void ) { printf( A("1") ("2") "3" ); } It prints 132 (the point of the A macro is to swap the thing which follows its parameters in brackets with everything after that until another closing bracket) But if I use that within another macro: #define Z(x) x printf( Z( A("1") ("2") "3" ) ); I get the compile error "Unterminated function-like macro invocation". I realise that this happens because the compiler is trying to process the arguments of Z independently, but I need to use its

Is there a way to partially pre-process a C or C++ source file? By "partially preprocess" I mean expanding some but not all of the #include directives. For example, I would like to expand #includes pointing to my project headers, but not #includes pointing to other libraries' headers. I tried to do this by running gcc -E with only the -I flags for my project headers and not the -I flags for the libraries, but that doesn't work because gcc gives an error when it encounters an #include it cannot expand. EDIT : I do not really care about the preprocessor's behaviour with respect to macro

I am reading on CPP macro expansion and wanted to understand expansion when the (optional) token-string is not provided. I found gcc v4.8.4 does this: $ cat zz.c #define B (B) |B| $ gcc -E zz.c # 1 "zz.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "zz.c" () | | Can anyone explain why the expansion is zero spaces in one instance and one in the other? The C preprocessor operates on "tokens" and whenever there's a possibility of changing the meaning or ambiguity, it always adds whitespace in order to preserve the meaning. Consider your example, (B) there's no ambiguity or meaning altering whether

If I have a piece of code written in C# wrapped in an #if directive, what (if any) precedence is applied to any boolean operators that might be used in that directive? In other words: #if DEBUG || MYTEST && PLATFORM_WINDOWS // ... Some code here #endif Will that be simply evaluated left to right as #if (DEBUG || MYTEST) && PLATFORM_WINDOWS And similarly, would #if PLATFORM_WINDOWS && DEBUG || MYTEST Be evaluated as #if (PLATFORM_WINDOWS && DEBUG) || MYTEST Or is there some precedence order for && vs ||? Edit: To be clear, I am well aware that I can run the code myself to test it, and I have. I

This question already has an answer here: Why these consecutive macro replacements do not result in an error? 3 answers Why is the output from the following code the value 5? #include<stdio.h> #define A -B #define B -C #define C 5 int main() { printf("The value of A is %d\n", A); return 0; } chqrlie This is a tricky question because it is a stress test for the compiler preprocessor. Depending if the preprocessor is an integrated phase of the compiler or a separate program passing its output to the compiler via a file or a pipe and in this case whether it is careful enough to not perform

Is it legal to invoke a variadic macro M with no arguments for its variadic parameter? The relevant standard quote is [cpp.replace]/4 : If the identifier-list in the macro definition does not end with an ellipsis, the number of arguments (including those arguments consisting of no preprocessing tokens) in an invocation of a function-like macro shall equal the number of parameters in the macro definition. Otherwise, there shall be more arguments in the invocation than there are parameters in the macro definition (excluding the ... ). There shall exist a ) preprocessing token that terminates the