Boost logo

Boost :

Subject: Re: [boost] Where we are 1.65.0
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2017-08-09 20:56:50

Le 09.08.17 à 20:20, Stephan T. Lavavej via Boost a écrit :
> [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.

Thanks for the feedback! and thanks again for the boost.test fixes!

>> 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,

You're right!

We definitely need runners for this, and the plethora of
architectures/compilers is well covered for established compilers, not
so well maybe for new compilers.

I do not know about the state of VS2017 /std:c++17, I believe teeks99-09
is doing it:

Also, if I recall, the build was also having trouble for support of
VS2017, which ate up some resources.


* as a developer, I would say: bad luck, give me runners, and I will fix
the problems as I see them coming
* as a user, I would say: boost is so-so ahead of its time for C++ (and
many more bad things of course)

that makes me feel like:
* having support for "cutting edge" sounds to me better than "release
often", especially when the price is so low (most of the problems seems
to be fixed, we need to cycle the runners)
* fixing things in RCs, like now, is exactly the right time
* and fixing means also having runners for those compilers, so that the
development can go smoothly for next release. Having to wait half a
release cycle is too short for developments to my opinion.

I am all in favor of postponing the release and getting those fixed.

I am also wondering about several topics that are orthogonal to
* would a different branching policy help here? it has been mentioned
that some PRs are on the pipe, but those need to stage to develop and
then merged to master, which ultimately will pull some unwanted changes
that are not addressing the issues specific to the release
* would it make sense to share the know-how on how to set up a new
compiler? I am not referring to how to run the regression script, but
rather on how to install a test machine with a cutting edge compiler.
This is more an IT perspective, but maybe gathering that knowledge would
help us having more test machines?


Boost list run by bdawes at, gregod at, cpdaniel at, john at