On 09/08/2017 19:20, Stephan T. Lavavej via Boost wrote:
[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:
I don't believe anyone is blaming you for this, I think it's just that this is the first time we've had to deal with removals from the std lib and have been slow off the mark. I wonder if we should have a blanket check for C++17 in suffix.hpp which would then set these macros regardless of compiler if it claims to be in C++17 mode? That won't help with VC++ which hasn't updated __cplusplus in a while, but would have avoided the clang issue... Best, John. --- This email has been checked for viruses by AVG. http://www.avg.com