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.
Related
In Visual Studio, warning C4996 (using a deprecated function) is treated as an error, and code that uses deprecated functions doesn't compile at all.
There are various ways to disable C4996 entirely, either suppressing it for a single line, for a translation unit, or for an entire project. But what if I want it to still raise a warning, but allow compilation while not treating it as an error?
#include <iostream>
[[deprecated]]
void deprecated_function()
{
std::cout << "I function, but have been deprecated.\n";
}
int main() {
deprecated_function();
}
This doesn't compile at all.
#include <iostream>
[[deprecated]]
void deprecated_function()
{
std::cout << "I function, but have been deprecated.\n";
}
int main() {
#pragma warning(suppress: 4996)
deprecated_function();
}
This compiles, but doesn't issue a warning at all.
Is it possible to tell Visual Studio to emit a warning, but still allow compilation, for a deprecated function? I'm thinking of refactoring purposes, where I'd like to mark a function as deprecated, identify all the places it's used, but the code still compiles at each intermediate stage where some but not all uses of the deprecated function have been replaced.
I'm compiling using Visual Studio 2019 Community 16.8.4, warning level set to /W3, "Treat Warnings as Errors" set to "No". This particular warning seems to be treated as an error if it gets emitted at all.
Found a working solution. It turns out the relevant flag is actually "SDL checks", not "Treat Warnings as Errors". Flipping it from /sdl to /sdl- causes compilation to emit a warning while still compiling.
EDIT: If I want to keep all the SDL checks on except treating Warning C4996 as an error, I can use the flag /sdl in combination with the flag /w34996, which specifies that 4996 is treated as a level 3 warning instead of an error.
According to cppreference [[deprecated("message string")]] we should be able to use the symbol but in VS results in error instead.
For example I wan't to issue a warning for ANSI methods in UNICODE builds and vice versa:
#ifdef UNICODE
[[deprecated("This method does not work well in UNICODE builds")]]
#endif // UNICODE
void f() {}
compiler doesn't let me compile, but standard says the attribute should allow usage but issue a warning message.
How to resolve this?, btw. my project is set to maximum conformance with the standard.
What ever the reason for VS going against the standard, is there a better way to issue a warning for above case?
Very much late to the party, but this cost me a couple of hours this morning.
By default, Visual Studio and the sdl (Security Development Lifecycle) compile flag treat
[[deprecated]] as an error. Whether or not you agree with this or not, that's how they do it.
To fix this go to Configuration Properties -> C/C++ -> Command Line and add /sdl /w34996
The /wX part represents the severity of the warning, and the rest is the error you want to report as a warning.
I hope this saves people some time.
I was able to get the compiler to treat [[deprecated]] as a warning by adding
/w34996
to the compiler options, as suggested in the responses in following link
https://developercommunity.visualstudio.com/content/problem/786502/cant-treat-deprecated-warning-as-warning-with-wx.html
is there a better way to issue a warning for above case?
There's no other way of warning about usage of a function than deprecation attribute in standard C++ at least that I know of.
Msvc has other alternatives such as #pragma deprecated(f), but those are not better.
How to resolve this?
Assuming you haven't configured your compiler to treat warnings as errors, you could proceed with writing a bug report to the maintainers.
I haven't tested it with Visual Studio, but in my case the following helped and probably is more generic:
On that error usually warnings are treated as errors with the compiler flag -Werror, that is automatically set in Visual Studio. That is the reason way a class or function marked with [[deprecated]] results in an error. To avoid explicitly that error and output it just as a warning, the compiler flag -Werror -Wno-error=deprecated-declarations can be set. In CMake it would look like:
add_compile_options(-Werror -Wno-error=deprecated-declarations)
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.
Is there any way to turn off asserts instead of switching to Release mode. I need to debug a code which make assertions really often and it slows down my work.
These asserts are not related to the issue i am trying to solve, so for now they only slow down my progress, because they are called very often in one of my base classes.
Now I don't have the time to improve their design, so can someone tell me if there is a way to turn off asserts while being in debug mode and using it's capabilities.
User _CrtSetReportMode
int iPrev = _CrtSetReportMode(_CRT_ASSERT,0);
// Start Operation with no ASSERTs
...
// Restore previous mode with ASSERTs
_CrtSetReportMode(_CRT_ASSERT,iPrev);
Instead of using 0, you can use _CRTDBG_MODE_DEBUG only.
You can use _set_error_mode or _CrtSetReportMode (see xMRi's answer) to alter failure reporting method and avoid modal dialog box. See code snippet there:
int main()
{
_set_error_mode(_OUT_TO_STDERR);
assert(2+2==5);
}
Also note that assert failures are typically for a reason, and you want to fix code, not just suppress the report. By removing them from debug builds completely you are simply breaking good things built for you.
#define NDEBUG before #include <assert.h> to disable assert macro.
You may so add this to pre-processor definition in project settings.
I don't have Visual Studio 2013, but the following works for me in Visual Studio 2015, so maybe the same or something similar works for VS 2013, too.
In your main() function, call
_set_abort_behavior(0, _WRITE_ABORT_MSG | _CALL_REPORTFAULT);
In Visual Studio, go to Debug / Windows / Exception Settings. In the Exception Settings, go to Win32 Exceptions / 0xc0000420 Assertion Failed. Uncheck the box in front of that entry.
I need both of the above to suppress assertion pop-ups in Debug mode.
You can add an compiler flag /DNDEBUG to turn off asserts. I feel this is cleaner since you don't have to change anything in your code.
Fromm the MSVC documentations:
You can turn off the assert macro without modifying your source files by using a /DNDEBUG command-line option.
I can inhibit many warnings in Visual Studio 2005 SP1 in the C/C++ Advanced property page, which causes the IDE to use the /wd switch on the command line which invokes the compiler. However, when I try to inhibit warning 4200 (nonstandard extension used : zero-sized array in struct/union), it still appears when I compile. (Of course it's justified; I'm just not in a position to fix the code, nor would it be worth bothering, because it's generated, and the warning is entirely benign under the circumstances.) Does anybody happen to know if this is a bug in the compiler? Or might there be something I can do about it?
To completely disable the warning in the file you can add the following to the top of the file
#pragma warning(disable:2400)
If you want some more flexibility other than a blanket disable for the file, the following page lists several other more fine grained options.
http://msdn.microsoft.com/en-us/library/2c8f766e(VS.80).aspx
It's unclear based on your information as to whether or not it's a bug in the compiler or a configuration issue. I would lean towards a configuration issue, specifically conflicting compiler options that is making it difficult to suppress the warning.
EDIT
OP mentioned they can't control the generated code so they can't directly include the pragma. If that's the case then try this trick. Say the file name is Generated.cpp. No longer include Generated.cpp as one of the files to compile. Instead create a new file called Example.cpp with the following contents
#pragma warning(disable:2400)
#include "Generated.cpp"
Now you'll get the text of Generated.cpp with the disabled warning by only compiling Example.cpp.
You mean like with pragma?
#pragma warning( disable : 2400 )