c-preprocessor

问题 In Linux header file epoll.h , I found the following code: enum EPOLL_EVENTS { EPOLLIN = 0x001, #define EPOLLIN EPOLLIN ... } What does it mean by #define EPOLLIN EPOLLIN ? 回答1: This create a macro named EPOLLIN whose replacement text is also EPOLLIN . This is most likely a way for the preprocessor to check which event codes are available and conditionally compile code as necessary. If we go to the git repo for glibc and look at the output of git blame we see the following for enum EPOLL

问题 In Linux header file epoll.h , I found the following code: enum EPOLL_EVENTS { EPOLLIN = 0x001, #define EPOLLIN EPOLLIN ... } What does it mean by #define EPOLLIN EPOLLIN ? 回答1: This create a macro named EPOLLIN whose replacement text is also EPOLLIN . This is most likely a way for the preprocessor to check which event codes are available and conditionally compile code as necessary. If we go to the git repo for glibc and look at the output of git blame we see the following for enum EPOLL

问题 I thought that both cpp foo.c and gcc -E foo.c do preprocess the source file the same way, but I got their output to differ for the same file. $ cat foo.c #define VARIABLE 3 #define PASTER(x,y) x ## _ ## y #define EVALUATOR(x,y) PASTER(x,y) #define NAME(fun) EVALUATOR(fun, VARIABLE) extern void NAME(mine); Result for cpp : $ cpp foo.c # 1 "foo.c" # 1 "<built-in>" 1 # 1 "<built-in>" 3 # 329 "<built-in>" 3 # 1 "<command line>" 1 # 1 "<built-in>" 2 # 1 "foo.c" 2 extern void mine ## _ ## 3; $

问题 I thought that both cpp foo.c and gcc -E foo.c do preprocess the source file the same way, but I got their output to differ for the same file. $ cat foo.c #define VARIABLE 3 #define PASTER(x,y) x ## _ ## y #define EVALUATOR(x,y) PASTER(x,y) #define NAME(fun) EVALUATOR(fun, VARIABLE) extern void NAME(mine); Result for cpp : $ cpp foo.c # 1 "foo.c" # 1 "<built-in>" 1 # 1 "<built-in>" 3 # 329 "<built-in>" 3 # 1 "<command line>" 1 # 1 "<built-in>" 2 # 1 "foo.c" 2 extern void mine ## _ ## 3; $

问题 Are there any guidelines people tend to follow when selecting a name for their include guard? I don't understand why the name for the .h file will slightly differ from the name used in the include guard. For example, I have seen sphere.h and then #ifndef SPHERE_H_ . Could I just as easily have used SPHERE_ or do the names have to match? Are the underscores also necessary? 回答1: To pick a good name for a header guard, consider these points: 1) the name has to be unique, so make it long and

问题 Is it possible to differentiate between operating systems in C# using preprocessor ? like : #if OS_WINDOWS //windows methods #elif OS_MAC //mac methods #elif OS_LINUX //linux methods #endif 回答1: What you are asking for is possible but needs a bit of work. Define a preprocessor variable in your csproj <PropertyGroup Condition=" '$(OS)' == 'Windows_NT' "> <DefineConstants>_WINDOWS</DefineConstants> </PropertyGroup> Use that in your code #if _WINDOWS // your windows stuff #else // your *nix

问题 Why #define assert(expression) ((void)0) , rather than #define assert(expression) is used in release mode?(strictly speaking, when NDEBUG is defined) I heard that there are some reasons, but I've forgot it. 回答1: ((void)0) defines assert(expression) to do nothing. The main reason to use it is that #define assert(expression) would allow assert(expression) to compile without a semicolon but it will not compile if the macro is defined as ((void)0) 回答2: The reason why ((void)0) is used in empty

问题 It seems I often spend way too much time trying to get a #define macro to do exactly what i want. I'll post my current dilemma below and any help is appreciated. But really the bigger question is whether there is any utility someone could recommend, to quickly display what a macro is actually doing? It seems like even the slow trial and error process would go much faster if I could see what is wrong. Currently, I'm dynamically loading a long list of functions from a DLL I made. The way I've

问题 I recently discovered that when using the __FILE__ predefined macro in MSVC (specifically 2013) that by default it will print relative paths for source files and absolute paths for header files. As an example I have a VS project containing the following: Solution Project Headers foo.h Sources main.cpp Both main.cpp and foo.h are in the same directory on disk. main.cpp: #include <iostream> #include <string> #include "foo.h" int main(int, char*[]) { std::cout << __FILE__ << std::endl; foo::bar(

问题 I recently discovered that when using the __FILE__ predefined macro in MSVC (specifically 2013) that by default it will print relative paths for source files and absolute paths for header files. As an example I have a VS project containing the following: Solution Project Headers foo.h Sources main.cpp Both main.cpp and foo.h are in the same directory on disk. main.cpp: #include <iostream> #include <string> #include "foo.h" int main(int, char*[]) { std::cout << __FILE__ << std::endl; foo::bar(