On Sun, Jul 8, 2018 at 12:54 PM Peter Dimov via Boost
John Maddock wrote:
I preprocessed the source and it's picking up the latest headers for me:
m:\\compilers\\vc2017\\vc\\tools\\msvc\\14.13.26128\\include\\system_error
and I still see:
class error_category { // categorize an error public: /* constexpr */ error_category() _NOEXCEPT // TRANSITION
I have 14.14.26428 and I see the same. :-/
Well this sure simplifies version checking for this particular issue if nothing else.
Defines wise we have: ... _CPPLIB_VER =650
After looking at the config_info output from the test matrix, the values are, for reference:
_CPPLIB_VER=405: msvc-8.0 _CPPLIB_VER=505: msvc-9.0 _CPPLIB_VER=520: msvc-10.0 _CPPLIB_VER=540: msvc-11.0 _CPPLIB_VER=610: msvc-12.0 _CPPLIB_VER=650: msvc-14.0 and above
The new macros are:
"The STL now identifies itself with two macros, defined by including any STL header (e.g. <ciso646>). _MSVC_STL_VERSION is defined as 141 and will remain that way for the VS 2017 v141 toolset series. _MSVC_STL_UPDATE is defined as 201709 in VS 2017 15.5, and will be increased as features are added in future updates. (The year-month typically won’t correspond to an update’s release date. Our process for updating this macro is “we’re checking in std::meow() and it’s now October, so we need to change the value”, and depending on branch/merge timing, it might take a month or more to ship.) The value for VS 2017 15.6 is not yet set in stone, but it will be 201711 or greater."
https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-1...
and I was going to suggest we add them, but someone already did:
https://github.com/boostorg/config/commit/d5986d697ca534e18d192bd28b8c1177fe...
Incidentally... while looking into this, I encountered
https://github.com/boostorg/config/commit/15a0c119a13938bd00b99273e6fb876ff0...
which uses the compiler version to decide on a library feature. It will define BOOST_NO_CXX17_STD_APPLY under Clang.
It might be a good idea to codify the above knowledge somehow into a BOOST_MSSTL_VERSION macro and then check that instead of _MSC_VER or BOOST_MSVC which generally doesn't work with Clang.
It sounds like Boost.Predef could help here, since it can detect Dinkumware? - Jim