-Wshadow will \"Warn whenever a local variable shadows another local variable.\". Is there an equivalent in Visual C++ (2008)? I tried /W4 but it didn\'t pick up on it. I al
Check out warnings C6244 and C6246
But you will need to enable automatic code analysis to get them, see How to: Enable and Disable Automatic Code Analysis for C/C++
If you cannot do it in your VS edition (Analyzing Managed Code Quality by Using Code Analysis), try to add the /analyze flag to the compilation command line. You will get some warnings that the '/analyze-' flag, which has been added by your IDE, is replaced with the manually added '/analyze' flag, but the analysis will work ;-)
(I would add this as a comment to Dawn's answer, but have insufficient reputation at the moment)
There is an issue open on Microsoft Connect petitioning to have the warning upgraded from Code Analysis to standard compilation. I suggest upvoting it to try to get Microsoft's attention.
Visual Studio 2015 now warns about shadowed variables by default. Excerpt from http://blogs.msdn.com/b/vcblog/archive/2014/11/12/improvements-to-warnings-in-the-c-compiler.aspx follows:
Shadowed variables A variable declaration "shadows" another if the enclosing scope already contains a variable with the same name. For example:
void f(int x)
{
int y;
{
char x; //C4457
char y; //C4456
}
}
The inner declaration of x shadows the parameter of function f, so the compiler will emit: warning C4457: declaration of 'x' hides function parameter The inner declaration of y shadows the declaration of y in the function scope, so the compiler will emit: warning C4456: declaration of 'y' hides previous local declaration Note that, as before, a variable declaration with the same name as a function parameter but not enclosed in an inner scope triggers an error instead:
void f(int x)
{
char x; //C2082
}
The compiler emits: error C2082: redefinition of formal parameter 'x'
There's no warning about this that's disabled by default, so if you're not seeing the warning at the default levels, I'd say it can't be done. (Which is lame.)
I am afraid no.
You could perhaps try compiling your code with Clang:
We use gcc at work, to build our code, but compile with Clang regularly to test the code conformance to the Standard and benefit from its warnings.