编译器开关还是预处理器开关？

Question

Switching code using the preprocessor is pretty common:

#define MY_SWITCH (1)
#if MY_SWITCH
   cout << "on" << Test(1);
#else
   cout << "off" << Test(2);
#endif

However if the code outside this snippet changes (eg if the Test() function is renamed) it could happen that the disabled line would remain outdated since it is not compiled.

I would like to do this using a different kind of switch to let the code being compiled on every build so I can find outdated lines immediately. Eg like this:

static const bool mySwitch = true;
if (mySwitch)
{
   cout << "on" << Test(1);
}
else
{
   cout << "off" << Test(2);
}

However I need to prevent this method to consumes additional ressources. Is there any guaranty (or a reliable assumption) that modern C++ compilers will remove the inactive branch (eg using optimization)?

Answer 1

I had this exact problem just a few weeks ago — disabling a problematic diagnostic feature in my codebase revealed that the alternative code had some newish bugs in it that prevented compilation. However, I wouldn't go down the route you propose.

You're sacrificing the benefit of using macros in the first place and not necessarily gaining anything. I expect my compiler to optimise the dead branch away but you can't rely on it and I feel that the macro approach makes it a lot more obvious that there are two distinct "configurations" of your program and only one can ever be used from within a particular build.

I would let your continuous integration system (or whatever is driving automated build tests) cycle through the various combinations of build configuration (provide macros using -D on the commandline, possibly from within your Makefile or other build script, rather than hardcoding them in the source) and test them all .

Answer 2

You don't have guarantee about compiler optimization. (If you want proven optimizations for C, look into compcert ).

However, most compilers would optimize in that case, and some might even warn about dead code. Try with recent GCC or Clang/LLVM with optimizations enabled (eg g++ -Wall -Wextra -O2 ).

Also, I believe that most compilers won't consume resources at execution time of the generated optimized code, but they will consume resources at compilation time.

Perhaps using constexpr might help some compilers to optimize better.

Also, look at the produced assembly code (eg with g++ -O2 -fverbose-asm -S ) or at the intermediate dumps of the compiler (eg g++ -O2 -fdump-tree-all which gives hundreds of dump files). If using GCC, you might customize it with MELT to eg add additional compile-time checks.