Re: [boost] Where we are 1.65.0

Subject: Re: [boost] Where we are 1.65.0
From: Stephan T. Lavavej (stl_at_[hidden])
Date: 2017-08-09 18:20:24

[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 <meow.h>
> 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