On 11 July 2018 at 17:35, Vinnie Falco via Boost wrote:

Several libraries fail to build with /permissive-, I have generated a log of build output:

https://gist.github.com/vinniefalco/40b2e8e6a283377330258ce1e3281b6c

This thread shows how and why it's important to get boost to build with Clang/LLVM (clang-cl), as VS is (still) a moving target and clang probably already has it right. By reporting those bugs MS (which it possibly is), you'll also be helping VS (and your-selves) forward. Trying to fix a build of Boost with a vaporware like VS 15.6.6 seems a waste of time and is highly irrelevant. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*

On 11 July 2018 at 17:56, Vinnie Falco via Boost wrote:

I couldn't disagree more (although, Boost should also be compiled with clang-cl if it is not discontinued).

You, I surmise, are alluding to the indeed dis-continued (it is), ill-conceived idea of Clang/C2 (C2 is the VC backend)) as opposed to Clang/LLVM. MS, words from the mouth of STL (the man), is testing their STL (the library) with Clang/LLVM, Boost should do the same. MS is, from what I gather also a (one of the) contributors to Clang.

The latest Visual Studio is not vaporware it is a released, shipping product which many people use to accomplish real work.

Yes, it was, but even today I upgraded to 15.7.5, to which I only upgraded 2 weeks ago or so. Today's 15.7.5 is also 'a shipped release'. If one has any sense one pushes the button and get upgraded, particularly non-corporates will do that. And in fact, I suspect that Visual Studio

actually fixed a bug which is what is causing this new compilation error.

It's better to first find out if the code should compile in the first place by referencing it with the (compilation) result of a compiler that might not have that (possible) bug. This, to my eye, should not compile as the code appears in a class

template where difference_type is a nested type of the base class and should not be visible unqualified.

This proves my point, iff clang would say it's shite as well, you're 99.999% sure and you know what to do, using VS will, at this moment, not be conclusive in any way, shape or form (you're stabbing in the dark). degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*

The fixes for this are contained in the develop branch and only need to be merged. And yes it (obviously) was a MSVC bug and it seems to be resolved now. PS: And yes MSVC is a moving target. But concluding that it should not be supported by boost would be short-sighted. There are just to many users of Boost with MSVC and they rely on Boost abstracting all those dirty details relating to compiler bugs away (as well as platform dependencies etc). Am 11.07.2018 um 16:56 schrieb Vinnie Falco via Boost:

On Wed, Jul 11, 2018 at 7:49 AM, degski via Boost wrote:

...

This thread shows how and why it's important to get boost to build with Clang/LLVM (clang-cl), as VS is (still) a moving target and clang probably already has it right. By reporting those bugs MS (which it possibly is), you'll also be helping VS (and your-selves) forward. Trying to fix a build of Boost with a vaporware like VS 15.6.6 seems a waste of time and is highly irrelevant. I couldn't disagree more (although, Boost should also be compiled with clang-cl if it is not discontinued). The latest Visual Studio is not vaporware it is a released, shipping product which many people use to accomplish real work. And in fact, I suspect that Visual Studio actually fixed a bug which is what is causing this new compilation error.

The code in question which fails is:

BOOST_DEDUCED_TYPENAME difference_type n;

This, to my eye, should not compile as the code appears in a class template where difference_type is a nested type of the base class and should not be visible unqualified. The resulting errors appear in the log I linked. Changing that code to the following:

BOOST_DEDUCED_TYPENAME BidirectionalIteratorConcept<Iterator>::difference_type n;

resolves the error for _MSC_VER >= 1912

On Wed, Jul 11, 2018 at 8:16 AM, Alexander Grund via Boost < boost@lists.boost.org> wrote:

The fixes for this are contained in the develop branch and only need to be merged.

And yes it (obviously) was a MSVC bug and it seems to be resolved now.

PS: And yes MSVC is a moving target. But concluding that it should not be supported by boost would be short-sighted. There are just to many users of Boost with MSVC and they rely on Boost abstracting all those dirty details relating to compiler bugs away (as well as platform dependencies etc).

Yes, but at some point we have to ship a boost release. [ We've had this discussion many times in the past - "should we delay Boost 1.XX because VS XX.yy will be released next week", and we've pretty much always said - "Nope - we're shipping" ] Note that this is not a commentary on the current details - just a general observation. -- Marshall

Yes, but at some point we have to ship a boost release.

[ We've had this discussion many times in the past - "should we delay Boost 1.XX because VS XX.yy will be released next week", and we've pretty much always said - "Nope - we're shipping" ]

Note that this is not a commentary on the current details - just a general observation. Completely agreed. But this does also highlight the importance of proper workarounds. The current thing is a great example: A workaround for a MSVC bug was included in the RC. However the code for

that was invalid C++ and guarded by a `_MSVC >= xxxx` version macro. Hence a bug in MSVC was fixed by using another bug in MSVC with the assumption the latter will not be fixed (soon). My point is: Even those workarounds should be expected to work in the future by using proper C++ (as far as possible) which now is the case (thanks for the ones working on that). I see that once a project switched to a Boost version they stay there for quite a while and for those this will be a huge problem (Please don't argue that they could simply update boost. Sometimes newer Boost have breaking changes/new bugs in other libraries that prevent this [Boost.Serialization e.g.]) Alex Grund

On 11 July 2018 at 19:53, Peter Dimov via Boost wrote:

degski wrote:

This thread shows how and why it's important to get boost to build with

...

Clang/LLVM (clang-cl),

FWIW, all my attempts to get Appveyor to build the tests for System with Clang have failed and I'm out of ideas.

I gathered so much, could you, please, post what is, in your opinion, your best effort in this respect. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*