Visual Studio 2012 __cplusplus 和 C++ 11

Question

Anyone know why __cplusplus is defined as 199711L (which is the "old" C++) in my Visual Studio 2012 c++ project? Should it not say 201103L since VS 2012 now has C++ 11 support? Even if I include C++ 11 headers it still is wrongly defined. Any clues?

Answer 1

This has already been submitted to Microsoft for review:

A value of predefined macro __cplusplus is still 199711L

Answer 2

It really depends on what you expect that macro to actually mean. Should 201103L mean "This compiler fully supports all of C++11 in both the compiler and the library?" Should it mean "This compiler supports some reasonable subset of C++11?" Should it mean "This compiler supports at least one C++11 feature in some way, shape, or form?"

It's really up to each implementation to decide when to bump the version number. Visual Studio is different from Clang and GCC, as it has no separate C++03 compilation mode; it provides a specific set of features, and that's what it provides.

In general, a single macro is not a useful tool to decide when to use some feature. Boost.Config is a far more reliable mechanism. The standards committee is investigating ways of dealing with this problem in future versions of the standard.

Answer 3

I am with Nicol on this one. The only reason to test for __cplusplus >= 201103L is to check whether you can use the new features. If a compiler implements only half of the new features but uses the new value of __cplusplus , it will fail to compile a lot of valid C++11 code protected by __cplusplus >= 201103L (I have some that uses thread_local and *this references). If on the other hand it keeps 199711L , it will use the safe C++98 code, which is still fine. It may miss a few optimizations that way, but you can still use other ways to detect if a specific feature is available (compiler version, compiler specific macros like __GXX_EXPERIMENTAL_CXX0X__ , boost macros that check compiler macros for you, etc). What matters is a safe default.

There are 2 possible reasons to switch to the new value of __cplusplus:

• your compiler has full support for C++11 (or close enough, there will always be bugs)
• this is an experimental mode of your compiler that shouldn't be used in production, and what would normally be missing features count as bugs.

As far as I know, all compilers that have switched are in the second category.

I believe some compiler vendors have been way too enthusiastic about changing the value of __cplusplus (easiest C++11 feature to implement, good publicity), and it is good that some are more conservative.

Answer 4

As of April 2018 MSVC 2017 now correctlys reports the macro, but only if a specific switch is used ( /Zc:__cplusplus ). This is because a lot of old code relies on detecting the old value of the macro for MSVC compilers. Source

Hopefully in future, once people worldwide have updated their code, MS will report the macro correctly by default.

Answer 5

As pointed out in another answer, /Zc:__cplusplus is pretty much the answer. Suppose you have a bunch of .vcxproj files underneath a folder hierarchy, simply place a file named Directory.Build.props into the common parent folder and populate it as follows:

<?xml version="1.0" encoding="utf-8"?>
<Project>
  <ItemDefinitionGroup>
    <ClCompile>
      <AdditionalOptions>/Zc:__cplusplus %(AdditionalOptions)</AdditionalOptions>
    </ClCompile>
  </ItemDefinitionGroup>
</Project>

You could also use your very own user property sheets to set this there. Ie in %LOCALAPPDATA%\Local\Microsoft\MSBuild\v4.0 inside all of the Microsoft.Cpp.*.user.props files (where * is the placeholder for the target platforms).

Furthermore it is probably sensible to be defensive about this in code, which means resorting to checking for both _MSVC_LANG and __cplusplus like so (or similar):

#if defined(__cplusplus) && defined(_MSVC_LANG) && (__cplusplus == 199711L)
// Check against _MSVC_LANG with the value you expect for __cplusplus
#else
// Check against __cplusplus as usual
#endif

I would recommend using something like this whenever you can't be certain that your code (eg a header, because you are a library author) is used while /Zc:__cplusplus was specified on the command line.

I'm still a bit puzzled why this is still the case as of VS2022, because if you look at C++ compiler support , Visual C++ isn't half bad compared to all the others.

All the above said, you may want to use feature test macros instead of testing for the C++ standard version.