[Marshall Clow]
* Some libraries didn't build with ToT clang/libc++ (Locale, Wave and Test) This is because in C++17, some deprecated library features have been removed. [bind1st, mem_fun, auto_ptr, random_shuffle, etc ] Boost.Config has support for these removals, but this was ... incomplete. [ This is on me; I did the partial job of adding these to Config's libc++ support a while back ] Normally, I would be tempted to say "Well, clang 5 is not shipping yet, and so we can put this off until 1.66.0". But both clang 5 and C++17 are imminent (they will both happen well before the 1.66 release, and so I think we should fix this now.
Also, a future version of MSVC will have the same library issues.
This was actually implemented in MSVC 2015 RTM, as opt-in behavior. In MSVC 2015.3 when /std:c++latest was added, we made C++17 mode remove auto_ptr/etc. by default (with the same macro being used for opt-out). I would like to gently point out that I gave Boost a heads-up when all of this happened, in classic emails like "Removing auto_ptr/etc. from Boost" on March 18, 2015 and "Boost and auto_ptr (was Boost 1.60.0 beta 1...)" on November 11, 2015. We're treating the other C++17 removals identically. The old iostreams members are hopefully totally irrelevant, the std::function allocator support probably is too (I would expect boost::function to be used), but std::unexpected() removal may be relevant. That one's going to be enabled by /std:c++17 and /std:c++latest in 2017's second toolset update. As a reminder, "std::auto_ptr in public interfaces" on May 20, 2017 is repeating this cycle, with early notification of deprecation warnings: [STL]
Additionally, in VC 2017's second toolset update (not the first one that's being released soon), I am planning to aggressively warn about C++17's deprecated features in C++17 mode (/std:c++17 or /std:c++latest). All of the library stuff in Annex D will emit warnings, except for the
C headers (it's silly that they're deprecated). [snipped outdated sentence] This is going to be pretty noisy, but it'll ultimately make migrating code to C++20 and beyond easier.
I plan to have a system of fine-grained escape hatch macros, and a big "silence all C++17 deprecation warnings" macro, but libraries like Boost will need to avoid the deprecated components (or locally suppress C4996) since they don't really control the user's preferences.
Auditing Boost right now for unnecessary use of the Annex D stuff would be a good idea. Stuff like std::iterator, the old allocator members, and std::result_of are probably commonly used.
Thanks, STL