c-preprocessor

Wrapping #includes in #ifndef's - adds any value?

不问归期 提交于 2019-12-01 19:29:02
I have inherited C /C++ code base, and in a number of .cpp files the #include directives are wrapped in #ifndef's with the headers internal single include #define . for example #ifndef _INC_WINDOWS #include <windows.h> #endif and windows.h looks like #ifndef _INC_WINDOWS #define _INC_WINDOWS ...header file stuff.... #endif // _INC_WINDOWS I assume this was done to speed up the compile/preprocess of the code. I think it's ugly and a premature optimisation, but as the project has a 5 minute build time from clean, I don't want to makes things worse. So does the practice add any value or speed

A group of variadic macros

萝らか妹 提交于 2019-12-01 19:05:40
I would like to have a group of variable number of arguments passed into a macro. I have following macros which is incorrect: #define M_NARGS(...) M_NARGS_(__VA_ARGS__, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0) #define M_NARGS_(_10, _9, _8, _7, _6, _5, _4, _3, _2, _1, N, ...) N #define M_CONC(A, B) M_CONC_(A, B) #define M_CONC_(A, B) A##B #define M_ID(...) __VA_ARGS__ #define M_LEFT(L, R) L #define M_RIGHT(L, R) R #define M_FOR_EACH(ACTN, ...) M_CONC(M_FOR_EACH_, M_NARGS(__VA_ARGS__)) (ACTN, __VA_ARGS__) #define M_FOR_EACH_0(ACTN, E) E #define M_FOR_EACH_1(ACTN, E) ACTN(E) #define M_FOR_EACH_2(ACTN, E

How can I replace my c++ exception macro with an inline function with __LINE__ and __FILE__ support?

旧巷老猫 提交于 2019-12-01 19:02:45
I currently read the book Effective C++ from Scott Meyers. It says I should prefer inline functions over #define for function-like macros. Now I try to code an inline function to replace my exception macro. My old macro looks like this: #define __EXCEPTION(aMessage) \ { \ std::ostringstream stream; \ stream << "EXCEPTION: " << aMessage << ", file " <<__FILE__ << " line " << __LINE__; \ throw ExceptionImpl(stream.str()); \ } My new inline function is this: inline void __EXCEPTION(const std::string aMessage) { std::ostringstream stream; stream << "EXCEPTION: " << aMessage << ", file " <<__FILE__

Is __COUNTER__ macro portable?

生来就可爱ヽ(ⅴ<●) 提交于 2019-12-01 18:25:11
I have a piece of code which uses __COUNTER__ macro to generate unique names for variables. Is this code portable ? I know that GCC and MSVS support it. What's about other compilers ? Is the macro defined by standard (as far as I know before C++14 it wasn't). It's definitely not standard. It's a compiler extension ( GNU C extensions ) The common predefined macros are GNU C extensions. and a Microsoft-specific one , Microsoft-Specific Predefined Macros: __ COUNTER __ also supported by clang as language extension. The standard doesn't mention it anywhere . GCC manual, section Common Predefined

How can I reliably detect the version of clang at preprocessing time?

冷暖自知 提交于 2019-12-01 17:58:29
Apparently, the clang bundled with Xcode doesn't respect the upstream __clang_major__ and __clang_minor__ values, and instead reports an Xcode user-facing version of some sort. Here are, for reference, the values for the various MacPorts installs of clang. They seem to respect the upstream release identifiers. I get similar values when testing on Linux. ➜ prohibit-clang-3.2 /opt/local/bin/clang++-mp-3.2 -dM -E -x c /dev/null | grep __clang_m #define __clang_major__ 3 #define __clang_minor__ 2 ➜ prohibit-clang-3.2 /opt/local/bin/clang++-mp-3.3 -dM -E -x c /dev/null | grep __clang_m #define _

C++ macro expansion, debugging

删除回忆录丶 提交于 2019-12-01 17:58:13
I have a bunch of MACROS in C++ code that expand into some functions. And I am debugging something. Just want to see what the code ends up looking like” Any ideas? You can view the preprocessor output to see what the code looks like after it is preprocessed. gcc and Visual C++ will both preprocess to stdout if you pass the -E flag on the command line to the compiler. /P, see it under C++ - Preprocessor - Process to a File in the Visual Studio's Property Pages, the output file has the .i extension 来源: https://stackoverflow.com/questions/2701533/c-macro-expansion-debugging

How can I replace my c++ exception macro with an inline function with __LINE__ and __FILE__ support?

吃可爱长大的小学妹 提交于 2019-12-01 17:54:38
问题 I currently read the book Effective C++ from Scott Meyers. It says I should prefer inline functions over #define for function-like macros. Now I try to code an inline function to replace my exception macro. My old macro looks like this: #define __EXCEPTION(aMessage) \ { \ std::ostringstream stream; \ stream << "EXCEPTION: " << aMessage << ", file " <<__FILE__ << " line " << __LINE__; \ throw ExceptionImpl(stream.str()); \ } My new inline function is this: inline void __EXCEPTION(const std:

Reuse define statement from .h file in C# code

限于喜欢 提交于 2019-12-01 17:54:05
I have C++ project (VS2005) which includes header file with version number in #define directive. Now I need to include exactly the same number in twin C# project. What is the best way to do it? I'm thinking about including this file as a resource, then parse it at a runtime with regex to recover version number, but maybe there's a better way, what do you think? I cannot move version outside .h file, also build system depends on it and the C# project is one which should be adapted. You can achieve what you want in just a few steps: Create a MSBuild Task - http://msdn.microsoft.com/en-us/library

C/C++ #define Macro inside macro?

本小妞迷上赌 提交于 2019-12-01 17:37:40
I would like something like: #define C_OR_CPP(C__, CPP__) #ifdef __cplusplus\ CPP__\ #else\ C__\ #endif Is it possible? Maybe some dirty hack with #include ? Reason: I make a header where a struct uses a member variable of type vector<stuff>* , but in C i want it to simply be void* , you know. TIA What's the problem with #ifdef __cplusplus #define C_OR_CPP(C, CPP) CPP #else #define C_OR_CPP(C, CPP) C #endif (Leaving names with double underscore to the implementation per phresnel remark) Not in C++. But you can #ifdef __cplusplus # define CPP #else # define C #endif I assume this is just a

How can I reliably detect the version of clang at preprocessing time?

廉价感情. 提交于 2019-12-01 17:27:31
问题 Apparently, the clang bundled with Xcode doesn't respect the upstream __clang_major__ and __clang_minor__ values, and instead reports an Xcode user-facing version of some sort. Here are, for reference, the values for the various MacPorts installs of clang. They seem to respect the upstream release identifiers. I get similar values when testing on Linux. ➜ prohibit-clang-3.2 /opt/local/bin/clang++-mp-3.2 -dM -E -x c /dev/null | grep __clang_m #define __clang_major__ 3 #define __clang_minor__ 2