MSVC std::_Pad no virtual destructor - c++

I'm using
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50727.1 for x64
and when I do
#include <mutex>
#include <condition_variable>
I get
c:\program files (x86)\microsoft visual studio 11.0\vc\include\thr\xthread(172) : error C4265: 'std::_Pad' : class has virtual functions, but destructor is not virtual
instances of this class may not be destructed correctly
do I need to upgrade to a newer version of MSVC?

You don't need to update.
It is a warning that could be important when using virtual functions. If you allocate memory in a derived class you need a virtual destructor and freeing the memory on object destruction. Using std::mutex you are safe (huge disclaimer here).
You get rid of this warning by using #pragma warning. If you treat warnings as errors you have to get rid of it but never lower the compiler warnings level:
#pragma warning(push)
#pragma warning(disable:4265)
#include <mutex>
#pragma warning(pop)
Surround the warning with care, you don't want to disable warnings for the whole file, you might miss some essential warning.

Related

#pragma warning(disable: 4577) doesn't work in VS2017

I'm disabling the warning C4577 at the top of my C++ file, outsides of any scope:
#pragma warning(disable: 4577)
But I'm still getting a lots of warnings like:
warning C4577: 'noexcept' used with no exception handling mode specified; termination on exception is not guaranteed.
How can I disable the warning only for my file?
Regards,
Christian

'Microsoft::WRL::FtmBase' class has virtual functions, but destructor is not virtual

I'm getting this compile error
C:\Program Files (x86)\Windows
Kits\10\include\10.0.17134.0\winrt\wrl\implements.h(1453): warning
C4265: 'Microsoft::WRL::FtmBase': class has virtual functions, but
destructor is not virtual
after adding "#include < wrl.h>" to my program. I'm using /W4 flag. Is there something that I'm missing here? some kind of macro that needs to be defined? Curious if there's a way to fix that warning without suppressing it.
Also, I'm using latest VS 2017 with c++17 if that helps.

Avoid weak-vtable warnings for classes only defined in a source file

I understand that a class class needs at least one virtual function defined in a source file (out of line), otherwise the vtable will need to be inserted into every object file.
I have the following situation:
//foo.cpp
struct Foo {
virtual int Bar() { return 1; }
virtual ~Foo() = default;
};
The clang code model in Qt Creator (4.5.2) emits a -Wweak-table warning for Foo.
Strictly speaking the warning is correct, as the vtable will be included in every translation unit. Practically, it's worthless because either way the vtable is only emitted in foo.o anyway.
How can I disable -Wweak-vtables only for classes defined in a source file?
It turns out that standalone clang does the right thing by default, only the clang code model in Qt creator shows the useless warning. It's already reported as QTCREATORBUG-19741, so there's nothing more to do than wait for an updated Qt creator version.
Not really sure, but where I work, we have some practices for disabling warnings in localized sources.
Under windows:
#pragma warning(push)
#pragma warning(disable : 4820)
//Rest of your includes (cstdio, vector...)
#pragma warning(pop) //For /Wall
Under gcc like:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-local-typedefs"
//Rest of your includes (cstdio, vector...)
#pragma GCC diagnostic pop

Boost "destructor is not virtual" error in MSVC 11

I am trying to compile a program with boost 1.57.0 using MSVC 11.0 and I get the following error:
z:\d\dev\boost_1_57_0\boost\exception\exception.hpp(171) : error C4265: 'boost::exception_detail::error_info_container' but destructor is not virtual instances of this class may not be destructed correctly
Is there anything I can do about it?
These posts didn't seem to offer a solution
http://boost.2283326.n4.nabble.com/boost-exception-detail-error-info-base-does-not-have-virtual-destructor-td3384903.html
http://boost.2283326.n4.nabble.com/Re-exception-warning-about-non-virtual-destructor-resolution-td4554753.html
I should've thought about this before. The error is a warning promoted to an error through /W4. I managed to fix it by wrapping a warning disable around the include.
#pragma warning(push)
#pragma warning(disable : 4265)
#include <boost/...>
#pragma warning(pop)

Is there an alternative to suppressing warnings for unreachable code in the xtree?

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.