Re: [boost] Where we are 1.65.0

Subject: Re: [boost] Where we are 1.65.0
From: John Maddock (jz.maddock_at_[hidden])
Date: 2017-08-09 18:59:15

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