Is there a way to get VS2008 to stop warning me about unreachable code?

Question

I have a few config options in my application along the lines of

const bool ExecuteThis=true;
const bool ExecuteThat=false;

and then code that

Answer 1

First of all, I agree with you, you need to get rid of all warnings. Every little warning you get, get rid of it, by fixing the problem.

Before I go on with what, on re-read, amounts to what looks like a rant, let me emphasis that there doesn't appear to be any performance penalty to using code like this. Having used Reflector to examine code, it appears code that is "flagged" as unreachable isn't actually placed into the output assembly.

It is, however, checked by the compiler. This alone might be a good enough reason to disregard my rant.

In other words, the net effect of getting rid of that warning is just that, you get rid of the warning.

Also note that this answer is an opinion. You might not agree with my opinion, and want to use #pragma to mask out the warning message, but at least have an informed opinion about what that does. If you do, who cares what I think.

Having said that, why are you writing code that won't be reached?

Are you using consts instead of "defines"?

A warning is not an error. It's a note, for you, to go analyze that piece of code and figure out if you did the right thing. Usually, you haven't. In the case of your particular example, you're purposely compiling code that will, for your particular configuration, never execute.

Why is the code even there? It will never execute.

Are you confused about what the word "constant" actually means? A constant means "this will never change, ever, and if you think it will, it's not a constant". That's what a constant is. It won't, and can't, and shouldn't, change. Ever.

The compiler knows this, and will tell you that you have code, that due to a constant, will never, ever, be executed. This is usually an error.

Is that constant going to change? If it is, it's obviously not a constant, but something that depends on the output type (Debug, Release), and it's a "#define" type of thing, so remove it, and use that mechanism instead. This makes it clearer, to people reading your code, what this particular code depends on. Visual Studio will also helpfully gray out the code if you've selected an output mode that doesn't set the define, so the code will not compile. This is what the compiler definitions was made to handle.

On the other hand, if the constant isn't going to change, ever, for any reason, remove the code, you're not going to need it.

In any case, don't fall prey to the easy fix to just disable that warning for that piece of code, that's like taking aspirin to "fix" your back ache problems. It's a short-term fix, but it masks the problem. Fix the underlying problem instead.

To finish this answer, I'm wondering if there isn't an altogether different solution to your problem.

Often, when I see code that has the warning "unreachable code detected", they fall into one of the following categories:

1. Wrong (in my opinion) usage of const versus a compiler #define, where you basically say to the compiler: "This code, please compile it, even when I know it will not be used.".
2. Wrong, as in, just plain wrong, like a switch-case which has a case-block that contains both a throw + a break.
3. Leftover code from previous iterations, where you've just short-circuited a method by adding a return at some point, not deleting (or even commenting out) the code that follows.
4. Code that depends on some configuration setting (ie. only valid during Debug-builds).

If the code you have doesn't fall under any of the above settings, what is the specific case where your constant will change? Knowing that might give us better ways to answer your question on how to handle it.