I am getting this warning when I compile my Visual Studio C++ program:
Warning C26495 Variable 'boost::function_base::functor' is uninitialized. Always initialize a member variable (type.6). Project1 C:\boost\function\function_base.hpp 603
And here is the line in function_base.hpp:
public:
detail::function::vtable_base* vtable;
mutable detail::function::function_buffer functor;
Has anyone ran into this with boost and have you solved it? I tried this, but it gave errors:
mutable detail::function::function_buffer functor{};
Minimal reproducible example:
#include <boost\\algorithm\\string\\find.hpp>
int main()
{
}
This 'minimal reproducible example' gives this error:
Warning C26495 Variable 'boost::function_base::functor' is uninitialized. Always initialize a member variable (type.6).
#define BOOST_VERSION 107500
#define BOOST_LIB_VERSION "1_75"
You probably want to disable "external warnings"
Add your Boost directory to the "External Include Directories" so that find.hpp will use the "External Includes" settings. You can then disable code analysis for this specific warning, or drop the warning level to /W3 for similar warnings.
Related
I have just installed a fresh Visual Studio 16.10.3 and added Google Test to my command console app. Right of the bat, I get the following warnings:
Severity
Code
Description
Project
File
Line
Suppression State
Warning
C26812
The enum type 'testing::TestPartResult::Type' is unscoped. Prefer 'enum class' over 'enum' (Enum.3).
Tests
D:\C++\ConsoleTest\packages\Microsoft.googletest.v140.windesktop.msvcstl.static.rt-dyn.1.8.1.4\build\native\include\gtest\gtest-test-part.h
62
Warning
C26495
Variable 'testing::internal::Mutex::critical_section_' is uninitialized. Always initialize a member variable (type.6).
Tests
D:\C++\ConsoleTest\packages\Microsoft.googletest.v140.windesktop.msvcstl.static.rt-dyn.1.8.1.4\build\native\include\gtest\internal\gtest-port.h
1804
Warning
C26495
Variable 'testing::internal::Mutex::critical_section_init_phase_' is uninitialized. Always initialize a member variable (type.6).
Tests
D:\C++\ConsoleTest\packages\Microsoft.googletest.v140.windesktop.msvcstl.static.rt-dyn.1.8.1.4\build\native\include\gtest\internal\gtest-port.h
1804
Warning
C26495
Variable 'testing::internal::Mutex::owner_thread_id_' is uninitialized. Always initialize a member variable (type.6).
Tests
D:\C++\ConsoleTest\packages\Microsoft.googletest.v140.windesktop.msvcstl.static.rt-dyn.1.8.1.4\build\native\include\gtest\internal\gtest-port.h
1804
Warning
C26495
Variable 'testing::internal::Mutex::type_' is uninitialized. Always initialize a member variable (type.6).
Tests
D:\C++\ConsoleTest\packages\Microsoft.googletest.v140.windesktop.msvcstl.static.rt-dyn.1.8.1.4\build\native\include\gtest\internal\gtest-port.h
1804
Warning
C26812
The enum type 'testing::internal::Mutex::StaticConstructorSelector' is unscoped. Prefer 'enum class' over 'enum' (Enum.3).
Tests
D:\C++\ConsoleTest\packages\Microsoft.googletest.v140.windesktop.msvcstl.static.rt-dyn.1.8.1.4\build\native\include\gtest\internal\gtest-port.h
1804
I tried suppressing the warnings by surrounding #include "pch.h" as described here:
#pragma warning(push, 0)
#include "pch.h"
#pragma warning(pop)
However, that didn't work - instead, I only got an additional warning that
#pragma warning(pop): no matching '#pragma warning(push)' (C4193)
I also read the Broken Warnings Theory. Unfortunately, I have to admit that I do not understand it. I think this is the relevant section:
To suppress the warning in external headers, we need to both specify which headers are external and what the warning level in those headers should be:
cl.exe /experimental:external /external:I some_lib_dir /external:W0 /W4 my_prog.cpp
This would effectively get rid of any warning inside some_hdr.hpp while preserving warnings inside my_prog.cpp.
But where would I add these switches and what would be the correct path variable for googletest?
Thank you in advance for your help!
Instead of
suppressing the warnings by surrounding #include "pch.h"
you should use the warning pragma to surround both header files(gtest-port.h and gtest-test-part.h), which can be found in External Dependencies in Solution Explorer of the Visual Studio project. The detailed methods are as below.
Add the following code to the very beginning and end of gtest-port.h
#pragma warning( push )
#pragma warning( disable : 26495 )
#pragma warning( disable : 26812 )
// Original Code
#pragma warning( pop )
Similarly, add the following code to the very beginning and end of gtest-test-part.h
#pragma warning( push )
#pragma warning( disable : 26812 )
// Original Code
#pragma warning( pop )
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]
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.
I am currently compiling a Qt project which integrates OpenMesh and CUDA together. Since I have to use nvcc to compile the project, I found an error from the OpenMesh:
J:\OpenMesh2.4\include\OpenMesh/Core/System/compiler.hh(109) : fatal error C1189:
#error : "You have to define _USE_MATH_DEFINES in the compiler settings!"
Since the compiler is nvcc not vc compiler, even I add the macro in the "preprocessor definitions", the error still appears. I just wonder if there is a way to add this macro for the nvcc?
I also tried to manually add this macro in one of my header which include the open mesh headers. The above error is gone but the compile gives another strange error about the source code of openmesh.
Found the solution: add -D followed by the macro in the nvcc flag...
I'm getting a compile-time error. It complains that I'm initializing a variable, but not referencing it. What's happening is that I initialize it then make a debug print statement that only get's compiled in for a debug build but not a release build. The error in question is warning c4189 (it's treated as an error and won't compile).
Is it possible to suppress this warning? How about warnings in general?
Don't suppress the warning, fix it! Wrap the declaration and initialization of the variable so it only exists in a debug build too.