The problem with Visual Studio and warnings when the variables are uninitialized
I have tried another compiler like Clang. The Clang was able to generate warnings.
//clang 3.8.0
//MSVS 2017
#include<iostream>
using namespace std;
class dummy
{
public:
void dummyFunction()
{
static_cast<int>(m_DummyVariable);
}
private:
double m_DummyVariable;
};
int main()
{
dummy obj;
double outside;
static_cast<int>(outside);
obj.dummyFunction();
return 0;
}
I expected to get three warnings as the online clang was able to do so. However, in Visual Studio regardless of the warning level(1,2,3,4 or all warnings options) which I have set in project's properties, I have not been able to get any warnings. Do I have to change any property of my project?
If you right click on you project and hit properties, go to the bottom and click on Code Analysis. Changing rule set to Microsoft All Rules as well as ticking the box to run code analysis on build makes warnings appear for me.
Worth noting that as soon as I send the outside variable to standard output Visual Studio throws a warning and an error.
Related
Using the compiler option /Wall with VS 2019 16.8.6, I'm getting a C4596;
error C4596: 'i': illegal qualified name in member declaration
for the following test program:
struct S {
int S::i;
};
int main() {}
Here's a godbolt.
The error shows up for all VS 2019 version available there with /Wall.
VS 2017 15.9.33 shows the same behavior.
VS 2015 doesn't show it.
VS 2017 and 2019 even show it when all warnings are disabled with /w, however specifically disabling 4596 really disables it.
Is this a bug or am I doing/reading something wrong?`
Is there a way to treat some, especially this, error as warning (not the other way round)?
There is a (somewhat weird) way to 'reset' this warning to 'normal' mode (i.e. to not treat it as an error); this involves using the #pragma warning(n:xxxx) directive, as shown below:
#pragma warning(4:4596)
struct S {
int S::i; // With that #pragma, this now generates 'just' a warning
};
warning C4596: 'i': illegal qualified name in member declaration
Not being party to the design of the MSVC compiler, I can't really say any more about why this happens. However, more information on adjusting its warnings using #pragma directives can be found here.
Also, possibly of interest, is that the clang-cl compiler (used from within Visual Studio) generates just a warning, with or without that pragma:
warning : extra qualification on member 'i'
[-Wmicrosoft-extra-qualification]
It seems to me that VS2017 fails to catch some fairly obvious compiler warnings which older versions do not. This seems so fundamental to me that I'm guessing the problem has to be something I'm missing (e.g. some new default compiler setting, perhaps?). Has anyone else seen this?
To test this, I create a simple console application in both 2013 and 2017. The only change I made the to the project settings was to set the compiler warning level to 4 and to report warnings as errors. Below is the entirety of the source
In VS2013 this fails. In 2017, it builds just fine...
// TestWarning4127.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <iostream>
int main()
{
if (true) // *** SHOULD generate warning 4127
std::cout << "Warning";
return 0;
}
Am I missing something obvious here...?
When used inside an if or while conditions the trivial constants such as 1 or true do not generate warnings in VS 2017 as described in the Compiler Warning (level4) official documentation. Excerpt from the official documentation:
The controlling expression of an if statement or while loop evaluates
to a constant. Because of their common idiomatic usage, trivial
constants such as 1 or true do not trigger the warning, unless they
are the result of an operation in an expression.
That being said it's not a warning in VS 2013 with the default warning levels of W3 either. Only with the elevated W4 settings does the VS 2013 report a warning. It was removed in VS 2017 altogether.
For comparison, the GCC does not generate the warning either:
Live example on Coliru.
I ran into this while compiling some portable code in gcc. Basically this strange code compiles in Visual studio which really just blows my mind:
class Zebra {int x;};
Zebra goo() {Zebra z; return z;}
void foo(Zebra &x)
{
Zebra y;
x = y;
foo(goo());
}
Visual studio lets this one fly. gcc will catch this as a compile error. Interestingly, If you typedef Zebra to int, VC++ will complain. Quite contradictory behavior. Thoughts?
This is old extension to Visual Studio, the only reference I could find on the Microsoft site was this bug report: Temporary Objects Can be Bound to Non-Const References, which has the following example code:
struct A {};
A f1();
void f2(A&);
int main()
{
f2(f1()); // This line SHALL trigger an error, but it can be compiled without any errors or warnings.
}
One of the responses notes:
There is a level 4 warning (level 4 warning are enabled if you pass /W4 to the compiler) for it
This blog post: Visual C++ is so Liberal which covers this extension notes that:
Using Disable Language Extensions (/Za) makes it an error:
As others said, this is due to Microsoft C++ extension. Though /Za flag is not recommended as it can break things.
Instead use the /permissive- switch for better standards compliancy and you will get healthy errors for these cases. Note that this flag is available since VS 2017.
The switch /Za does not support certain key Microsoft SDK header files. By contrast /permissive- offers a useful conformance mode where input C++ code is interpreted according to ISO C++ rules but also allows conforming extensions necessary to compile C++ on targets supported by Visual C++.
More info is on Visual C++ Team Blog.
I ran into this while compiling some portable code in gcc. Basically this strange code compiles in Visual studio which really just blows my mind:
class Zebra {int x;};
Zebra goo() {Zebra z; return z;}
void foo(Zebra &x)
{
Zebra y;
x = y;
foo(goo());
}
Visual studio lets this one fly. gcc will catch this as a compile error. Interestingly, If you typedef Zebra to int, VC++ will complain. Quite contradictory behavior. Thoughts?
This is old extension to Visual Studio, the only reference I could find on the Microsoft site was this bug report: Temporary Objects Can be Bound to Non-Const References, which has the following example code:
struct A {};
A f1();
void f2(A&);
int main()
{
f2(f1()); // This line SHALL trigger an error, but it can be compiled without any errors or warnings.
}
One of the responses notes:
There is a level 4 warning (level 4 warning are enabled if you pass /W4 to the compiler) for it
This blog post: Visual C++ is so Liberal which covers this extension notes that:
Using Disable Language Extensions (/Za) makes it an error:
As others said, this is due to Microsoft C++ extension. Though /Za flag is not recommended as it can break things.
Instead use the /permissive- switch for better standards compliancy and you will get healthy errors for these cases. Note that this flag is available since VS 2017.
The switch /Za does not support certain key Microsoft SDK header files. By contrast /permissive- offers a useful conformance mode where input C++ code is interpreted according to ISO C++ rules but also allows conforming extensions necessary to compile C++ on targets supported by Visual C++.
More info is on Visual C++ Team Blog.
I ran into this while compiling some portable code in gcc. Basically this strange code compiles in Visual studio which really just blows my mind:
class Zebra {int x;};
Zebra goo() {Zebra z; return z;}
void foo(Zebra &x)
{
Zebra y;
x = y;
foo(goo());
}
Visual studio lets this one fly. gcc will catch this as a compile error. Interestingly, If you typedef Zebra to int, VC++ will complain. Quite contradictory behavior. Thoughts?
This is old extension to Visual Studio, the only reference I could find on the Microsoft site was this bug report: Temporary Objects Can be Bound to Non-Const References, which has the following example code:
struct A {};
A f1();
void f2(A&);
int main()
{
f2(f1()); // This line SHALL trigger an error, but it can be compiled without any errors or warnings.
}
One of the responses notes:
There is a level 4 warning (level 4 warning are enabled if you pass /W4 to the compiler) for it
This blog post: Visual C++ is so Liberal which covers this extension notes that:
Using Disable Language Extensions (/Za) makes it an error:
As others said, this is due to Microsoft C++ extension. Though /Za flag is not recommended as it can break things.
Instead use the /permissive- switch for better standards compliancy and you will get healthy errors for these cases. Note that this flag is available since VS 2017.
The switch /Za does not support certain key Microsoft SDK header files. By contrast /permissive- offers a useful conformance mode where input C++ code is interpreted according to ISO C++ rules but also allows conforming extensions necessary to compile C++ on targets supported by Visual C++.
More info is on Visual C++ Team Blog.