Microsoft Visual Studio doesn't set `__cplusplus` correctly by default

[bitweeder]

Currently, there is a global C++ dialect check performed during feature testing to ensure the client is running at least the baseline requirement. Ironically, this test is broken, providing a pointed reminder of why simple global checks are a bad idea. MSVS 2019 always reports that it's C++98, regardless of how /std is set, unless /Zc:__cplusplus is also set. This raises the following questions:

• Does this issue affect other MSVS versions besides 16.3?

A few potential solutions suggest themselves:

• Set the /Zc:__cplusplus flag in our build files and propagate it to clients. This is a heavy-handed option unless we provide an opt-out, e.g., cmake command-line switch. Also, if this behavior is specific to the 2019 series (or equivalent SDK-provided compilers), we'll need to add a guard of some kind.
• Document this issue and require the client to address it themselves. This seems a bit unfriendly, and may arguably increase the friction of using the library, at least with MSVS, but it does have a light touch to it. A bit of build system magic would even allow us to throw up a warning if the flag is not set and we suspect it should be.
• Kill the global test and rely on other methods. The global test was chosen specifically so that we wouldn't have to make guesses about compilers we haven't tested with. Without it, we can't rely on the usual feature-detection suspects since most of them didn't start showing up until the C++11 era; we'd be restricted to hard-version checks against known compilers.

This will remain open for the time being.

[bitweeder]

Some further research has shown that there is a proprietary macro, _MSVC_LANG, which fulfills the usual role of __cplusplus, tracking how /std is set. Unlike __cplusplus, it defaults to 201402L rather than 199711L, reflecting the default (and minimum) standard available through /std. The value returned when /std:c++latest is set is “a higher, unspecified value” than that of the latest supported Standard (currently 201703L). The downside is that it’s only available in MSVS 2015 Update 3 and later—admittedly, not much of a downside. One of the upsides is that it avoids the complicated situation of determining whether the currently-used C++ dialect doesn’t support a given feature even if the compiler version indicates that it can, in the absence of SD_6 macros and reliable __cplusplus checks. Pending some testing, this will probably be sufficient to close the bug.

[bitweeder]

This has been fixed as part of the post-Cologne SD-6 update.