Xcode offers strange solution for explicitly dead code in c++?

Question

I'm writing a program that is supposed to solve a sudoko-like puzzle, Hashiwokakero. I have some code that looks like this:

if (bridgesLeft[row][col] == 1)
{
   doSomething();
}
else if (bridgesLeft[row][col] == 2)
{
   doSomethingElse();
}
else if (bridgesLeft[row][col] == 3)
{
   doAnotherThing();
}
...

I realized that I put a bug in the doSomethingElse() function, so rather than deleting that block, I added else if (bridgesLeft[row][col] == 2 && false) to guarantee that the buggy function wouldn't run, just to make sure that was where my bug was coming from. Xcode gave me a warning, saying my doSomethingElse() code would never run. It also gave me this option:

fix-it: Silence by adding parentheses to mark code as explicitly dead.

Clicking on this button changes

else if (bridgesLeft[row][col] == 2 && false)

to

else if (bridgesLeft[row][col] == /* DISABLES CODE */ (2) && false)

How do parentheses around the '2' mark this code as explicitly dead? What does this mean? If I leave the parentheses in, but take the && false part out, the code block is still executed, so it's not actually making the code dead.

Glassful

The compiler knows that whatever && false is false and will probably get rid of the whatever part. I guess this is more relevant if a function call is this whatever part. Putting that function call into parentheses might indicate that something odds happening. – Benedictus

Not a solution, but maybe comment out the method call instead of fiddling with your logic. You might go back in a few weeks, months and not know why you did that. It is good practice to change it to // doSomethingElse() temp remove because of bug in doSomethingElse. – Kakemono

I personally would disable/ignore that particular warning (at least in debug builds), as it is PROBABLY not useful most of the time. In "release" builds, where you are supposedly producing "production" code, it may be useful to know this. Although I'm a great fan of enabling warnings, some are pretty useless when you are in middle of developing something (one I have turned off is "unused member variable", because I often build classes by adding the member variables first, and stub out the actual functions until I get round to actually implement those) – Nonstop

Answer 1

This does not fix the problem as much as silence the warning by telling clang that the code is meant to be dead, we can see this by reading Improve -Wunreachable-code to provide a means to indicate code is intentionally marked dead via if((0)) which says:

Log: Improve -Wunreachable-code to provide a means to indicate code is intentionally marked dead via if((0)).

Taking a hint from -Wparentheses, use an extra '()' as a sigil that a dead condition is intentionally dead. For example:

if ((0)) { dead }

When this sigil is found, do not emit a dead code warning. When the analysis sees:

if (0)

it suggests inserting '()' as a Fix-It.

From what I can tell it is just looking for an integer literal in (), which in your case the (2) fits this case and silences the warning.

Tourbillion

Hmmm, wouldn't it recommend if (bridgesLeft[row][col] == 2 && (false))? Wouldn't it put the parentheses around the part that actually makes it dead? – Glassful

@DJMcMayhem: I'd expect if ((bridgesLeft[row][col] == 2) && false) but you could be right as well. – Benedictus

Thanks for the update. I'd consider it a bug in Xcode and file a bug report. – Benedictus