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

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

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: http://www.boost.org/development/tests/develop/teeks99-09-p-win2012R2-64on64... Also, if I recall, the build was also having trouble for support of VS2017, which ate up some resources. OTOH, * 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 developments: * 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? Thanks, Raffi

On Thu, Aug 10, 2017 at 12:41 AM, Andrey Semashev via Boost wrote:

Having C++17-capable clang and MSVC around the corner doesn't necessarily mean that people will go right ahead and use it. There'll

That's false. People (some) *will* use them. Not supporting them basically means you're blocking those people from upgrading. Note that existing compilers already have C++17 stuff and people *are* using it. -- Olaf

On Thu, Aug 10, 2017 at 9:36 AM, Andrey Semashev via Boost wrote:

...

That's false. People (some) *will* use them. Not supporting them basically means you're blocking those people from upgrading. Note that existing compilers already have C++17 stuff and people *are* using it.

Of course, there are enthusiasts but most people will start using C++17 much later, e.g. when they upgrade the production system and it ships the new compiler.

And? Are you proposing to delay fixes until those people start complaining? Note that both VS 2015 and 2017 have shipped and both are hitting those issues already. -- Olaf

On Thu, Aug 10, 2017 at 3:47 AM, Olaf van der Spek wrote:

On Thu, Aug 10, 2017 at 9:36 AM, Andrey Semashev wrote:

...

...

That's false. People (some) *will* use them. Not supporting them basically means you're blocking those people from upgrading. Note that existing compilers already have C++17 stuff and people *are* using it.

Of course, there are enthusiasts but most people will start using C++17 much later, e.g. when they upgrade the production system and it ships the new compiler.

And? Are you proposing to delay fixes until those people start complaining?

That's not what he's proposing at all, is it? Boost has a release schedule. People are waiting for Boost 1.65 - either for fixes, or sometimes new features. Andrey is simply suggesting that releasing 1.65 is more important right now, to keep to that release schedule.There are people and groups who take dependencies on Boost libraries not just because of the quality, but because Boost releases frequently. If we're balancing getting a Boost 1.65 release on time instead of delaying it by a few weeks, versus releasing 1.65 with C++17 support now instead of three months from now, Andrey's suggestion is not unreasonable. C++17 will hopefully even be a published ISO standard by the time 1.66 releases. (December is when users would be able to hopefully expect 1.66, ceteris paribus - assuming no more delays for 1.65, based on the release schedule) Glen

A quick survey for C++17 issues in *develop* finds: auto_ptr: ~~~~~~~~~ assign asio (tests do all pass actually with msvc in C++17 mode, but I can't see where/how auto_ptr usage is controlled). ptr_container python (it has a workaround in place, but replies on __cplusplus being set to the correct value, which is not the case for msvc). statechart. typeof (PR submitted) unary/binary_function: ~~~~~~~~~~~~~~~~~~~~ functional (has own workaround that's std lib specific, won't work for everything else?) bimap hash (has own workaround that's std lib specific, won't work for everything else?) Gil ICL MPI bind1st/2nd: ~~~~~~~~~~~~~ GIL Random Spirit Random_shuffle: ~~~~~~~~~~~~~~~ Compute Graph lambda MSM So there's a bit of work to do to fully fix this. John. --- This email has been checked for viruses by AVG. http://www.avg.com

On Thu, Aug 10, 2017 at 4:40 AM, John Maddock via Boost < boost@lists.boost.org> wrote:

FYI The scope_exit issue was being caused by Typeof, I've filed a PR for that: https://github.com/boostorg/typeof/pull/9

I guess the options we have are either:

* Have a big push over the next week to fix any remaining C++17 issues and delay the release accordingly, or * Make the release now, and issue a .1 release in say a month's time with bug fixes only (not only C++17 ones).

I have no real though which is preferable to be honest.

My plan is quite limited * Take a few patches that were already landed on develop and merge to master (wave, fiber, config). Artymom has indicated to me that he's not comfortable with rushing the changes to locale, so we won't be doing that. * Make an RC2 - preferably today I'm not really interested in making large-scale changes post-beta (thanks for the survey, John!). -- Marshall

On Thu, Aug 10, 2017 at 3:37 PM, Marshall Clow via Boost wrote:

My plan is quite limited

* Take a few patches that were already landed on develop and merge to master (wave, fiber, config). Artymom has indicated to me that he's not comfortable with rushing the changes to locale, so we won't be doing that.

* Make an RC2 - preferably today

I'm not really interested in making large-scale changes post-beta (thanks for the survey, John!).

Will there be a .1 with support for C++17 or will that have to wait for 1.66? -- Olaf

On 2017-08-10 08:36, Andrey Semashev via Boost wrote:

On 08/10/17 09:53, Olaf van der Spek wrote:

...

On Thu, Aug 10, 2017 at 12:41 AM, Andrey Semashev via Boost wrote:

...

Having C++17-capable clang and MSVC around the corner doesn't necessarily mean that people will go right ahead and use it. There'll

That's false. People (some) *will* use them. Not supporting them basically means you're blocking those people from upgrading. Note that existing compilers already have C++17 stuff and people *are* using it.

Of course, there are enthusiasts but most people will start using C++17 much later, e.g. when they upgrade the production system and it ships the new compiler.

This is of course what most people will do. But as a library author I need to support new standards in advance of my users starting to use them, so they aren't blocked by my tardiness. Since I depend significantly upon Boost, if Boost doesn't support new standards in a timely manner, this blocks me, which then blocks my users. I'm working on enabling building everything with C++17 *today*, with the expectation of having it fully working and a supported option within the next month or so. I certainly don't expect Boost to make much use of C++17 features, but I consider being able to *compile and link* with "-std=c++17" and its cl equivalent a fairly essential bar to meet for future Boost releases, and IMO would be worth holding up the release for. Otherwise we'll be blocked on this for many months. Regards, Roger

On Thu, Aug 10, 2017 at 10:58 AM, degski via Boost wrote:

On 10 August 2017 at 10:36, Andrey Semashev via Boost < boost@lists.boost.org

...

wrote:

...

Of course, there are enthusiasts but most people will start using C++17 much later, e.g. when they upgrade the production system and it ships the new compiler.

In this particular transition, I'm not so sure, C++17 is really the completion of C++11 and C++14, so those who did go to C++11, might want to upgrade sooner than you think. Also, MSVC (current and eminent release) is now in much better shape than it ever was. So those people are certainly motivated. Additionally, contrary to the past, the upgrade (full monty) is free (Community Edition) for many. Equally so, on Windows, Clang/LLVM is now up to scratch, certainly with the release of 5.0, planned for 23rd of August.

Anecdotically, at CERN-Institute (some of the most advanced scientists) they won't upgrade from what I understood, as they choose to stay on C++03.

​It's true that at CERN they are doing some of the most advanced (and important) science and data processing. But that doesn't mean that, outside of that most important field, that's a good indication of C++ needs for other people. From my past experience as a physicist, I can recall not so many years ago that a lot of work in physics was done in Fortran 77, not because other tools were not available or preferred but mostly because of inertia (of course, that's IMHO). ​I have a fondly remembrance of that, but that is because I was young. In objective terms, it was less than amazing :-) Just my 2 cents. Best regards, Francesco

Le 16/08/2017 à 17:58, Marshall Clow via Boost a écrit :

RC3 came out on Monday, and fixed a crashing bug in Boost.Asio.

We have a report of a new problem in Boost.Thread (timed waits wait way too long), which Vicente is looking into.

If necessary, we'll have an RC4 with a fix for Boost.Thread. Hopefully we'll know the answer to that today.

As signaled in other post it was introduced on this commit: https://github.com/boostorg/thread/commit/d4cff01c724f1355fef0990f3d6d678e52... That is 1.65. boost::detail::timespec_now is wrong an I must use boost::detail::timespec_now_realtime. The fix consist in applying https://github.com/boostorg/thread/pull/127. Can I apply it on master? Best,