2

Will the compiler remove this if statement?

 #define DEBUG 0
 int main(int argc, char ** argv)
 {
    if(DEBUG)
    {
       ...
    }
    return 0;
 }

I tried to google this, and search stackoverflow but I think my search terms were bad because I couldn't find the information.

If this is optimized what would I want to read about to learn about the optimization?

Constantin

Constantin
  • 16,812
  • 9
  • 34
  • 52
  • 10
    You can always find out yourself by asking your compiler to generate an assembly listing of its output. – Greg Hewgill Feb 17 '12 at 22:26
  • 1
    Depends on your compiler and its options, but yes it will probably remove the whole block. If its really adding and removing of code that you require though I'd used conditional compilation using #ifdef's instead of using if. – Dampsquid Feb 17 '12 at 22:28
  • Whenever a compiler is allowed by the standard to do x or y, you will always find one compiler that does x, and another that does y. So asking this kind of question is always only answered by: "try it and see" – PlasmaHH Feb 17 '12 at 22:33
  • Yes, I'm noticing differing responses. A great thing about stack overflow (kind of embarrassing) is that when I ask a question it pops up "Related" next to it, which are usually exactly what I'm looking for. That response seems to to be the usual one. – Constantin Feb 17 '12 at 22:34
  • Here's an SO question on viewing assembly: http://stackoverflow.com/questions/1354899 – Brian Maltzan Feb 17 '12 at 22:34
  • Here's [gcc's](http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) options. – Brian Maltzan Feb 17 '12 at 22:31
  • I would say yes because I've been bitten a few times trying to benchmark code only to discover that it had been optimized away because it had no side effects. Optimizers have gotten very clever. – Ferruccio Feb 17 '12 at 23:23

5 Answers5

4

Yes, any decent C/C++ compiler will remove such if block.

Mārtiņš Možeiko
  • 12,733
  • 2
  • 45
  • 45
3

You don't need to guess. Compile and step with debugger watching assembly instructions. You don't even need to be well familiar with assembly to see if there is actual code generated for lines in question or not.

Roman R.
  • 68,205
  • 6
  • 94
  • 158
3

I'm not sure if a compiler can optimize it away. I guess yes since in this situation you couldn't have any side effect, so it can be safely removed without changing semantics of the code.

In any case guessing is not nice and relying on an optimization is not nice too.

Why don't you use a #ifdef .. #endif block instead that a code block?

#define DEBUG

#ifdef DEBUG
  ...
#endif

In this way you will have a sure outcome.

Jack
  • 131,802
  • 30
  • 241
  • 343
  • I was thinking about this approach as well, I just didn't want to bloat my source files with #ifdef. (For human reading). Thanks Jack. – Constantin Feb 17 '12 at 22:35
  • 1
    I just usually indent them together with code, to not have a bad visual approach.. but it's just a matter of personal taste – Jack Feb 17 '12 at 22:36
2

You cannot make the universal statement that every compiler will optimize the same things the same way. Likewise any compiler that might happen to do it today might not in some future version.

Yes, a number of compilers today can and will do that but that doesnt mean you should plan for it or expect it. If you dont want that code there, comment it out, ifdef it out or remove it.

As mentioned by others, try it and find out for yourself. If you are debugging something and suspect that this has or has not happened, simply look and find out...

old_timer
  • 69,149
  • 8
  • 89
  • 168
  • 1
    In this case, I would argue it is perfectly safe to assume no industrial-strength compiler will ever fail to optimize this out. On the other hand, however, DEBUG is the kind of thing that someone might carelessly make a variable, configurable on the command line. In that sense, it might be troublesome. – jkerian Feb 17 '12 at 22:52
  • Right I was talking to the more general "Will A Compiler Remove" part of the question being too open and vague. The word debug also leads to folks that use ides for example not really knowing what command line options (including optimization) are used, and when you compile for debug some if not all optimizations are skipped so that you can single step and do memory watches and things like that. – old_timer Feb 17 '12 at 22:57
  • @dwelch, thank you for the insight. Could you explain your second comment further? Is doing a #define DEBUG bad practice? Thank you. – Constantin Feb 17 '12 at 23:55
  • Debug wasnt me, that was jkerian, it made me think of compiling for debug, in order to be able to single step or watch variables you need next to no optimization. – old_timer Feb 18 '12 at 02:51
1

You got good answers to check it in your compiler assembly output. I would like to share similar idiom that is very usefull to me sometimes:

 int main(int argc, char ** argv)
 {
    const bool bDebug = false;
    if(bDebug)
    {
       ...
       LOG(""); /// some heavy loging here
    }
    return 0;
 }

so I leave such if-s in some relevant places in my code, and when I get a bug report that something bad happend I step through code and when I need to ouput some large arrays/data structures, I modify from debugger bDebug variable (actually I name them bVerbose), and then allow code to enter such IF-s. You dont have to recompile code to add heavy logging.

marcinj
  • 48,511
  • 9
  • 79
  • 100