Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>My initial reaction was <em><code>#ifdef</code>, of course</em>, but I think <code>#if</code> actually has some significant advantages for this - here's why:</p> <p>First, you can use <code>DEBUG_ENABLED</code> in preprocessor <em>and</em> compiled tests. Example - Often, I want longer timeouts when debug is enabled, so using <code>#if</code>, I can write this</p> <pre><code> DoSomethingSlowWithTimeout(DEBUG_ENABLED? 5000 : 1000); </code></pre> <p>... instead of ...</p> <pre><code>#ifdef DEBUG_MODE DoSomethingSlowWithTimeout(5000); #else DoSomethingSlowWithTimeout(1000); #endif </code></pre> <p>Second, you're in a better position if you want to migrate from a <code>#define</code> to a global constant. <code>#define</code>s are usually frowned on by most C++ programmers.</p> <p>And, Third, you say you've a divide in your team. My guess is this means different members have already adopted different approaches, and you need to standardise. Ruling that <code>#if</code> is the preferred choice means that code using <code>#ifdef</code> will compile -and run- even when <code>DEBUG_ENABLED</code> is false. And it's <em>much</em> easier to track down and remove debug output that is produced when it shouldn't be than vice-versa.</p> <p>Oh, and a minor readability point. You should be able to use true/false rather than 0/1 in your <code>#define</code>, and because the value is a single lexical token, it's the one time you don't need parentheses around it. </p> <pre><code>#define DEBUG_ENABLED true </code></pre> <p>instead of </p> <pre><code>#define DEBUG_ENABLED (1) </code></pre>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload