c-preprocessor

问题 Is there a way to (ab)use the C preprocessor to emulate namespaces in C ? I'm thinking something along these lines: #define NAMESPACE name_of_ns some_function() { some_other_function(); } This would get translated to: name_of_ns_some_function() { name_of_ns_some_other_function(); } 回答1: When using namespace prefixes, I normally add macros for the shortened names which can be activated via #define NAMESPACE_SHORT_NAMES before inclusion of the header. A header foobar.h might look like this: //

问题 I have a C program below: #define f(g,g2) g##g2 main() { int var12=100; printf("%d",f(var,12)); } when I run just the preprocessor it expands this as { int var12=100; printf("%d",var12); } which is the reason why the output is 100. Can anybody tell me how/why the preprocessor expands var##12 to var12 ? 回答1: nothing too fancy: ## tells the preprocessor to concatenate the left and right sides see http://en.wikipedia.org/wiki/C_preprocessor#Token_concatenation 回答2: because ## is a token

问题 I would like to be able to do something like #print "C Preprocessor got here!" for debugging purposes. What's the best / most portable way to do this? 回答1: The warning directive is probably the closest you'll get, but it's not entirely platform-independent: #warning "C Preprocessor got here!" AFAIK this works on most compilers except MSVC, on which you'll have to use a pragma directive: #pragma message ( "C Preprocessor got here!" ) 回答2: The following are supported by MSVC, and GCC. #pragma

问题 My preprocessor appears to assume that undefined constants are 0 for the purpose of evaluating #if conditions. Can this be relied upon, or do undefined constants give undefined behaviour? 回答1: Yes, it can be relied upon. The C99 standard specifies at §6.10.1 ¶3: After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers are replaced with the pp-number 0 Edit Sorry, I thought it was a C question; still, no big deal, the

问题 I have to do something like this in C. It works only if I use a char, but I need a string. How can I do this? #define USER "jack" // jack or queen #if USER == "jack" #define USER_VS "queen" #elif USER == "queen" #define USER_VS "jack" #endif 回答1: I don't think there is a way to do variable length string comparisons completely in preprocessor directives. You could perhaps do the following though: #define USER_JACK 1 #define USER_QUEEN 2 #define USER USER_JACK #if USER == USER_JACK #define USER

问题 I'm looking for a way to convert a preprocessor token to a string. Specifically, I've somewhere got: #define MAX_LEN 16 and I want to use it to prevent buffer overrun: char val[MAX_LEN+1]; // room for \0 sscanf(buf, "%"MAX_LEN"s", val); I'm open to other ways to accomplish the same thing, but standard library only. 回答1: see http://www.decompile.com/cpp/faq/file_and_line_error_string.htm specifically: #define STRINGIFY(x) #x #define TOSTRING(x) STRINGIFY(x) #define AT __FILE__ ":" TOSTRING(_

问题 I have an external c++ dll to import using DLLImport. If my application is compiling in x64 I need to import the x64 version of this dll, if it is an x86 build, I need the x86 dll. What is the best way to achieve this? Ideally, I'd like some preprocessor directive, but I understand this doesn't work in c#? More info: the DLL is being imported by a project which is set to AnyCPU. A parent project is the one which determines whether the application compiles as x64 or x86. We compile both

问题 At least some C preprocessors let you stringize the value of a macro, rather than its name, by passing it through one function-like macro to another that stringizes it: #define STR1(x) #x #define STR2(x) STR1(x) #define THE_ANSWER 42 #define THE_ANSWER_STR STR2(THE_ANSWER) /* "42" */ Example use cases here. This does work, at least in GCC and Clang (both with -std=c99 ), but I'm not sure how it works in C-standard terms. Is this behavior guaranteed by C99? If so, how does C99 guarantee it? If

问题 Presuming that your C++ compiler supports them, is there any particular reason not to use __FILE__ , __LINE__ and __FUNCTION__ for logging and debugging purposes? I'm primarily concerned with giving the user misleading data—for example, reporting the incorrect line number or function as a result of optimization—or taking a performance hit as a result. Basically, can I trust __FILE__ , __LINE__ and __FUNCTION__ to always do the right thing? 回答1: __FUNCTION__ is non standard, __func__ exists in

问题 Say we have a macro like this #define FOO(type,name) type name Which we could use like FOO(int, int_var); But not always as simply as that: FOO(std::map<int, int>, map_var); // error: macro "FOO" passed 3 arguments, but takes just 2 Of course we could do: typedef std::map<int, int> map_int_int_t; FOO(map_int_int_t, map_var); // OK which is not very ergonomic. Plus type incompatibilities have to be dealt with. Any idea how to resolve this with macro ? 回答1: Because angle brackets can also