Deleting forward declared pointers leads to undefined behavior.
Examples:
https://gist.github.com/jatinganhotra/4144778
https://stackoverflow.com/a/14382111/399908
However, my Visual Studio (VS2012) compiler doesn't warn me about it.
Is this an unfixed VS2012 compiler bug?
Did I disable (or never enable) the corresponding warning?
Is this specific to some project setting?
Visual Leak Detector hinted me to the problem, but is there some method (pragma, code, macro, ...) to detect this at compile time?
The respective warning is C4150.
It should be active by default and it is categorized in warning level 2 (which should be active too, since default warning level is W3 afaik).
Note: Instead of lowering the warning level, try to pragma warnings in specific cases.
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]
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)
I am trying to eliminate the warnings in my project so I can turn on the flag that treats warnings as errors. The project uses the boost library, specifically the Concept_check.hpp and cuthill_mckee_ordering.hpp files. The warnings 4510 and 4610 are shown in the concept_check.hpp file and I have tried to disable them using #pragma warning push and pop. The warnings are caused by the boost library trying to instantiate a class using the template found in concept_check.cpp when there is no constructor written for it.
My Question is this: Is there a more sure fire way that I can disable these warnings without modifying the boost code? I am using Visual studio 2010.
Perhaps you are looking in the wrong direction. As Alan Stokes pointed out, the warning is there for a reason. I have three hints that are perhaps not the answers you expect, but may bring an acceptable solution:
Instead of silencing the warning, just fix the error. I don't know your code, but there are other people that had a similar problem which was possible to fix by just declaring a variable.
Another question is: why do you want to turn all your warnings into errors? Is it really neccessary? I agree that normal code should always compile without warnings. But these warnings are not originating from your own code. Consider a static code-checker that warns you about issues where your compiler is blind about.
If you have to use -WX, move the offending code into a static object/library/module so you will be bothered about the warning only when you need to recompile this module. You could use specific compile options for this module, to get the warnings completely out of your way.
There is another possibility, but I'm not able to check whether it really works. According the Microsoft Documentation it is possible to set the warning level of specific warnings. (there are similar options for GCC). First, switch all warnings to error:
/WX
Then, set the warning level of the two offending warnings to zero:
/W04510 /W04610
A complete commandline would look like this:
cl source.cpp /WX /W04510 /W04610
The best solution would be to combine this with hint 3 above. This way, the specific compiler options are only used for the files that cause the warnings.
Maybe these solutions work.
You can disable specific warning from a .h file (#pragma warning( disable: ... ).
When using the std::map with types that use trivial, non-throwing, copy constructors, a compiler warning/error is thrown (warning level 4, release mode) for unreachable code in xtree. This is because the std::map has a try-catch in it that helps maintain the state of the tree in the case of an exception, but the compiler figures out that the catch statement will never be called if the stored elements don't throw. These warnings can be easily suppressed with the following lines at the top of the .cpp file:
#pragma warning(push)
#pragma warning(disable:4702)
#include <xtree>
#pragma warning(pop)
Is there a way to bypass this warning/error without changing the warning level, building in debug, suppressing the warning, or using a different type in the map? Is there plans to change this in the standard library?
Update:
Maybe it is compiler specific. I am using vc7.
The error is below:
c:\program files\microsoft visual studio .net 2003\vc7\include\xtree(1116) : error C2220: warning treated as error - no 'object' file generated
c:\program files\microsoft visual studio .net 2003\vc7\include\xtree(1116) : warning C4702: unreachable code
Apparently the xtree is used by the std::map.
Unfortunately it looks like xtree is part of the underlying implementation of map in VC7, and as such there isn't much that can be done to mitigate it. It looks like it's a bug in the standard library.
Is it a possibility to use a newer compiler? I'm fairly sure there are free downloads of more recent versions of the compiler you could use, and perhaps they've fixed this issue.
If that's not an option, probably the best solution is to wrap the include of map into your own private header, complete with a comment and the #pragma+include <xtree> lines you already discovered (in addition to an include of map. This way you hide the workaround from normal use.
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 )