How can I disable all MSVC warnings that come from the boost library?
I know I can disable specific warnings where they occur etc... but it clutters my code and if I use boost macros then they don't seem to work. I would like to have a simple way to tell my compiler to not give me warnings about boost. Is this possible?
On a secondary note, I'm a bit surprised that the boost library doesn't disable all these warnings internally so that we users can use it "out of the box".
They try extremely hard to avoid warnings, but some compilers warn for code that is formally correct, just a bit "suspicious". If you change the code to silence the warning, another compiler might warn for that code!
There is a warning policy for Boost code and various compilers
https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines
They are also particularly careful not to disable warnings, because you might have some parts of your code where the warning is actually correct. If Boost disables the warning, you might not find the errors in your code!
You can disable the warnings for all projects by changing the default property pages:
Open any project.
Click on
view->property manager.
In the
property manager (probably along the
left bar), expand the project, then
expand one of the profiles, then
double-click on one of the categories
that all your projects will be using:
Microsoft.Cpp.Win32.user,
Application, or perhaps Core Windows
Libraries.
This brings up the
Properties page, but for all code that you write or will write. Set the
appropriate pre-processor definitions
and disable /wp64 or whatever you
need to do for an individual project.
Since it's probably not desirable to disable those warnings for all projects, it seems like you could disable warnings in visual_c.hpp as described here: Boost warnings with VC++ 9 . But then you'll have to make the change every time you update your libraries.
The first thing that comes to mind is to create special header-file in which to put all Boost #includes. These #includes should be surrounded with blocks of #pragma
#pragma warning(push, 0)
#include <boost/bimap.hpp>
#include <boost/function.hpp>
#pragma warning(pop)
Disadvantage of this way: some compile-time inefficiency
Related
I'm working on a C++ project that uses OpenCV and Boost. Unfortunately when compiling, my compiler gives me hundreds of warnings from the include files of those libraries. Even with an empty main function and no other code I still get these warnings from the include statements. I've heard this is a problem with other 3rd party libraries like Qt. All great libraries. How can I suppress all 3rd party warnings in MSVC.
I know about these solutions:
In GCC:
#pragma GCC system_header
#include "real_3rd_party_header.h"
And also the GCC -isystem option which lets you specify directories
to suppress
How to eliminate external lib/third party warnings in GCC
I wish MSVC had something like this.
And the #pragma push pop macros in MSVC but that only works on your
own code.
https://learn.microsoft.com/en-us/cpp/preprocessor/warning?view=vs-2019
And also the new VS2017 solution
https://devblogs.microsoft.com/cppblog/broken-warnings-theory/
I've spend hours on these last 2 solutions but without any success. The "broken warnings theory" blog doesn't explain how to apply its solution very well anyway.
I'm using:
Visual Studio 2015 and 2019.
Boost 1.72
OpenCV4
I really appreciate anyone willing to help resolve this issue with me. It would be nice to know who has even solved this issue. So many companies use these libraries, some probably with MSVC. There's no way they just keep with the warnings there and forget about them. I'm at the point where I will pay money to get this resolved. Getting this to work may be the deciding factor between reusing 3rd party libraries and rewriting code myself.
All this is from this blog post: https://devblogs.microsoft.com/cppblog/broken-warnings-theory/.
The general tone of the introduction of the article speaks volumes about why this option wasn't there to begin with (and none of it makes much sense to me).
Basically this says you can use /external:I as a synonym to -isystem.
You will probably need /external:templates- as well, due to the way MSVC handles warnings from templates.
Unfortunately, I cannot find any reference to any of this in the MSVC commandline documentation, nor the release notes related to the mentioned VS2017 15.6, so your mileage may vary.
There is though, a CMake issue requesting support for this feature behind their SYSTEM modifier.
This blog page mentions that Visual Studio removes some std features:
https://blogs.msdn.microsoft.com/vcblog/2017/12/08/c17-feature-removals-and-deprecations/
I have a project that consumes some C++ libraries that now use C++17 features. The project also consumes a third party library websocketpp (https://github.com/zaphoyd/websocketpp) that still uses some now removed features. eg auto_ptr and binary_function. I'm getting compiler errors that they are not a member of 'std'.
The blog above mentions that removed features can be restored using a fine grain control. I'm thinking I could use that to get this project to compile for now. Longer term I will see about upgrading websocketpp to C++17 or replacing it with something else.
But, what is the magic to restore features? Is there something I need to #define? If so, what?
In VS2017 v15.5 it is conditionally excluded, based on the project's /std:c++17 setting. You can force it to be included by forcing the underlying macro value. Two basic ways to do this:
Project > Properties > C/C++ > Preprocessor > Preprocessor Definitions and add _HAS_AUTO_PTR_ETC=1. Do so for all configurations and platforms.
If you use a precompiled header then you probably favor defining the macro there. Before any #includes, insert #define _HAS_AUTO_PTR_ETC 1.
Beware of the "ETC", you'll also slurp the deprecated random_shuffle() and unary_function<>. Predicting the future is difficult, but this is probably going to work for a while to come.
I'm using Visual Studio Code for c++ with MinGW and g++. My code uses a couple of g++ predefined macros. These work in the compiler without any problem, but Intellisense doesn't know about the macros and that causes some misdiagnosed errors (and other Intellisense problems) in the editor.
I can get all the predefined macros for my particular configuration of g++ with this command:
g++ -dM -E foo.cpp > defines.h
And this allows me insert them into the "defines" property of the c_cpp_properties.json file. This solution is a hack though, and if I'm not careful it could completely undermine the purpose of these macros. I want the compiler and Intellisense to cooperate across multiple development platforms, and that's looking like a pretty complicated setup.
Is there a better way to let Intellisense know about the g++ predefined macros?
From what I can tell, Intellisense's ability to properly handle preprocessor macros is still limited. If you are using CMake for Makefiles, it appears that you can tell Intellisense what macros you have, as seen here: auto-defined macros. I have not played with this personally, but it would be worth investigating.
If you can't get this to work, I found a feature to just turn off the macro-based highlighting. In settings, set"C_Cpp.dimInactiveRegions" to false. This isn't ideal, because it stops all graying out, including debug blocks like if(0) {...}, but it could be a temporary fix and you might find it less irritating.
Apart from that, look closely for added features in future updates. I'll try to update this post when I find any new discoveries on the matter.
The property in c_cpp_properties.json called compilerPath allows IntelliSense to query the compiler for default include paths and defines. It may be necessary to set intelliSenseMode to gcc-x64 for this to work, as that is not the default on Windows. (I currently do not have a Windows setup so I can't test this for the time being)
But I want to use it with "Warnings treated as errors" = Yes
There seems to be a lot of useful check in the compiler flag but it isn't compatible with the standard headers. I want to use this compiler flag to check my code, but not the std headers. Is there a way to do this?
Or just disable warnings for any code I didn't write?
Edit:
Added pictures of the settings in visual studio and an example of what happens when I try to build. With just including iostream!
Example when trying to compile a basic C++ program with these settings
You can disable the warnings in the headers (or change warning level for them) by changing the warning level before each inclusion, see here: How to suppress warnings in external headers in Visual C++. However that is not so handy because it needs to be done for every inclusion.
However if you'd use precompiled headers (which might be actually good for compilation speed), you can put all the system/STL headers you care about into the precompiled header file, and disable them via pragmas just there. Or you would need to create wrappers for the standard headers where you'll disable the warnings and include the wrapper headers instead.
And as discussed, the "/Wall" sometimes goes too far (e.g. the padding is quite usual thing you sometimes even can't do anything about), and even with the "/W4" the documentation mentions that it might be too detailed (however at the same time recommends it for new projects, so I generally use "/W4 /WX" for new projects). However some of the "/Wall" warnings still might find subtle bugs (like missing case in switch etc.). You might as well enable just some of the extra warnings selectively.
I have recently switched a project to making use of precompiled headers due to compilation becoming slow. Before doing so, it built without any significant warnings.
However, after adding all the QT headers I use in my project (of which I use 40-50) to the stdafx.h file, during building of the solution, when the stdafx.h file gets built I receive a huge number (1000's) of warning relating to QT functions. In particular, I get a lot of "Warning C4251" e.g.
1>c:\Qt\5.9\msvc2015_64\include\QtGui/qrawfont.h(154): warning C4251: 'QRawFont::d': class 'QExplicitlySharedDataPointer' needs to have dll-interface to be used by clients of class 'QRawFont' (compiling source file TitleBar.cpp)
The other two common warning types (albeit far less) are c4800 and c4244.
I am using QT 5.9 64-bit, on a Windows 10 box running VS2015,.
I can obviously just disable them, but I don't really like to do such a thing without understanding why this is happening.
A lot of cross-platform code creates warnings. It's not always possible to disable them, for example if a parameter is unused, one compiler might warn, if it is artificially used to shut up that warning, another might warn about unreachable code. Then MS warns about things like the C standard string library, which it's often impractical to avoid. You have to remember that MS and Apple have very mixed feeling about something like QT. The last thing they want is to sell undifferentiated platforms for running QT applications on. So there's not much motivation to provide appropriate warnings.