C++ Standard for Visual Studio 2015 - c++

I am trying to install MongoDB driver and is reading this following section
https://github.com/mongodb/mongo-cxx-driver/wiki/Download-and-Compile-the-Legacy-Driver
SCons Options when Compiling the C++ Driver
Select options as appropriate for your environment. Please note that some flags may not be available on older versions.
Important note about C++11/C++14: The boost libraries do not offer a stable ABI across different versions of the C++ standard. As a result, you must ensure that your application, the C++ driver, and boost are all built with the same language standard. In particular, if you are building the C++ driver with C++11 enabled, you must also build your application with C++11 enabled, and link against a C++11 compiled boost. Note that on most systems, the system or package installed boost distribution is not built with C++11, and is therefore incompatible with a C++11 build of the legacy driver.
Important note about the C++ standard library: Much like the C++11 issues, it is again critical that all three components (your application, boost, and the C++ driver) be built against the same C++ runtime library. You cannot mix components that have linked against libc++ with those that have linked against libstdc++.
Important 26compat Note: If you are using the 26compat branch, the install-mongoclient target is only enabled when the --full flag is provided. Similarly, you must use the --use-system-boost flag when building 26compat.*
My main question, I am trying to find out what standard my visual studio 2015 is running on when I build solution. I have tried to read around but I think I misunderstood the concept of C++11 and C++14. On Microsoft page it mentioned that VS2015 supports C++11,C++14 and C++17. But how do I know what am I using now? I can't find a way to explicitly configure. I am new to C++ and have been coding Java for many years. C++ is confusing to me because there are so many variety such as compilers and standards. Please help me understand and possibly find out what standard I am running.

The text is mostly nonsense.
ABI's are dictated by compilers, not standards. There is no ABI for C++11, there's one for GCC and a different one for MSVC2015.
"C++11 enabled" is a setting on GCC, and it does affect their ABI. The same applies to libc++ versus libstdc++, neither is part of the C++11 standard. Also, the mixing of build environments and the OS ("system Boost version") is mostly a Linux thing.
MSVC++ isn't GCC, and it doesn't use libstdc++, so all this does not affect you. And Boost versions aren't even a MSVC++ setting anymore, for the last few versions library configuration has been a per-project setting instead. (Tip: Create a Boost.vsprops file for that)

Related

How to compile with VS2017 for an older C++ standard?

I am using Visual Studio 2017 and need to create code that is compatible to VS2008 (C++03 or C++98). Is there a switch to restrict MSVC to C++03 features?
I am using CMake and tried to set
set_property(TARGET tgt PROPERTY CXX_STANDARD 98)
But this seems only to make sure, that the compiler supports C++98 or newer.
Any solution, that checks if C++ code uses features that are newer than the features supported by VS2008 will work as well. I just need to make sure, that I do not accidentally use features that are too new.
MSVC only got the standard switch in one of the updates to VS2015 (Update 3 to be exact) which was more or less C++14 compliant, and as such there are only switches for standards starting with C++14 (plus a few later features that were already implemented at the time of the update). All older features are enabled unconditionally for backwards compatibility (and because of all the work required to retrofit already implemented features for previous standards for virtually no gain).
See this blog post for more information: https://devblogs.microsoft.com/cppblog/standards-version-switches-in-the-compiler/
Also, note that there were a lot of conformance improvements in newer versions of MSVC, so even with the std switches you could write code that wouldn't work or would behave differently on older compiler.
A better solution would be just to use VS2008 toolset from VS2017 visual studio, as explained here: https://devblogs.microsoft.com/cppblog/stuck-on-an-older-toolset-version-move-to-visual-studio-2015-without-upgrading-your-toolset/
That way you'll be certain your code compiles on the older toolset, while using up-to-date IDE.

GCC: emit warnings when c++11 is used

Given
Cross-platform C++ project that has to build on some ancient windows mobile platforms. However the development is done with GCC.
Problem
Every time that C++11 feature is used it will build locally but fail on the build server (mobile windows).
Question
Is it possible to configure GCC to somehow warn if C++11 feature is used in our code-base (excluding other source-dependencies).
What have you tried?
I know about using -std=c++98 -pedantic, but:
I would like to use the latest compiler standard on Linux platform
There are some linux-only third-party dependencies (build from the source) that require C++11
Build the code you need to be C++98 compatible using C++98 flags.
Build the code you need to be C++11 compatible using C++11 flags.
Examine the documentation of the compiler and standard library used to ensure ABI compatibility between code built with C++98 and C++11; you may have to (for example) use C++98 strings in your C++11 code in order to have ABI compatibility, assuming you pass std::strings between the C++98 and C++11 code bases.
You cannot both use C++11 and not use C++11 when building the same file, unless you build it twice. Which is also an option; build the C++98 compatible stuff twice, once with C++latest and once with C++98. Throw away the C++98 build after halting on errors and warnings.

how to Enable c++17 Support in code blocks

in codeblocks There isn't a C++17 option in the Build or Compiler options, only C++14
how can i enable it in codeblocks so that both coding tools and compiler support it?
Code::Blocks is not a compiler (but some glorified source code editor, sometimes calling themselves IDEs, which runs some external compiler).
You need a C++17 compiler (and once you've got one you might configure your IDE or editor to use it with the appropriate options). Try the very latest version of GCC (at least GCC 7, and perhaps wait for GCC 8) or Clang (wait for Clang5) and pass it the -std=c++17 option
Note that C++17 is the C++ standard slated to be published by the end of 2017. You may need to wait a bit (perhaps a year or two) for compilers and the standard library implementations to correctly and completely implement it.
Therefore I don't recommend using C++17 features on a project to be released soon (at end of 2017), since you are then building on β quality foundations. However, if you work on a large project to be released in 2019, you might take the risk of betting that the C++17 features you are using in it will become mature by that time.
Regarding standard libraries functions (such as std::filesystem) you'll easily find approximate equivalent (e.g. in native OS or POSIX APIs, in Boost, in Qt, in POCO, ...) that should be reasonably easy to port once C++17 implementations are common.
(I recommend using your compiler on the command line, or using make, ninja, or some other build automation system running compiler commands; details can be operating system and compiler specific.)

GCC runtime libraries vs Microsoft Visual C++ runtime redistributables

Could anyone shed some light on C++ library versioning and distribution of
GCC library (libgcc, libstdc++,..?)
Microsoft Visual C++ runtime libraries (6.0, 2005, 2008, 2010, 2012, 2013, 2015,....)
With my limited exposure to GCC programming, I have never seen C++ runtime libraries being distributed along with program. That is often the case with MS Windows programs.
Can a relatively old linux system run a newer C++14 program (which is compiled on a newer system and then copied over to old system)?
Do GCC programmers distribute runtime libraries along with programs? If no, Why do Windows programs distribute them? How GCC distributions ensure that a C++ program always works when installed?
What about the frameworks such as Qt, How does Qt handle versioning and distribution on Linux and Windows? Does Qt also distribute runtimes for different versions?
May be it has to do with platform, how Linux is designed vs How Windows is designed.
What is so fundamentally different in approaches GCC & MS Windows take?
GCC's runtime libraries, like GNU's C library, provide a stable binary interface (small footnote: GCC 5.1 kind of blew this up, due to new C++ features that had to be implemented).
Microsoft's libraries don't, and each little version difference may and probably will break the ABI (application binary interface).
Additionally, Microsoft compilers change their ABI with version increments as well, making it a bad idea to combine code built by different versions of their tools. Also here, GCC maintains a strict ABI, which makes object code perfectly compatible (if no ABI breaking codegen options are given of course).
This ABI consists of object size and layout, which a compiler uses when generating code. Therefore running code built against one version but using a different version at runtime may produce unexpected results because the memory layout and use is just different.
GNU/Linux is quite strong in this regard, and is generally able to maintain strong backwards compatibility.
As long as the compiled program was compiled against an older version of the library, it will run perfectly if loaded with a newer version that a user has installed.
The same story goes for Qt, which only breaks ABI between major version numbers (Qt 4 and Qt 5 cannot be loaded at runtime interchangeable).
There are some small exceptions, GCC 5's libstdc++ being a big problem there. I know of no big glibc ABI breakages though.
The new Microsoft Universal CRT attempts to solve this issue, by providing a stable C runtime interface and as the story would have us believe, provide a glibc style library ABI stability. This UCRT is available for Windows Vista and up, but applications need to be compiled specifically against this. The first version of VS that has this capability, is VS2015.

Which C++11 compilers for Windows support new type traits like "is_nothrow_move_constructible"?

Is there any C++11 compiler for Windows that supports the new C++11 type traits, like is_nothrow_move_constructible?
I was trying to write a container that supported it, only to find that none of my compilers (VC++ 2010, TDM MinGW32 GCC 4.6) support it...
For mingw, I would recommend STL's distro here (gcc 4.7.1). It comes with boost 1.50 also.
There also is mingw-w64 (a fork of the original mingw), I recommend rubenvb's personal builds here. Go to Toolchains targetting Win32 if you want the 32-bit versions. He also has personal builds of clang (clang support on windows is still very buggy. The x64 build will report linker errors so can only be used for better diagnostics, etc.)
STL's distro is very nice, however I find the mingw-w64 to have much better support for the win32 api (I have run into countless problems with the original mingw) and c++11 headers, such as <atomic> which is unsupported in the original mingw. mingw-w64 is much more actively developed (can create 32-bit and 64-bit binaries) and includes support for newer functions from windows vista and up.
For more info on the naming conventions of mingw-w64, see here and the faq.
Visual Studio C++ 2012 Beta supports a lot of C++11 type traits according to the reference. Have a look at the Visual Studio C++ 2012 Documentation However, I could not find is_nothrow_move_constructible documented there. It appears to be supported though.
GCC 4.7 does support is_nothrow_move_constructible you can try it on Windows by installing MinGW Distro.
Not an answer, but I just learned something from looking at the source code of GCC 4.7's type_traits header:
You don't even need is_nothrow_xyz in the first place!
The noexcept operator tells you if an exception throws.
So for these specific type traits, you can use that instead.
(Or at least in theory. Whether your compiler implements it is another matter.)