On 3/30/2016 7:16 PM, Peter Dimov wrote:

Edward Diener wrote:

...

There are quite a few failures in this clang emulation of the VC++ preprocessor when tested against the preprocessor test code. In fact testing clang emulation of VC++ preprocessor when I don't treat clang as VC++ in Boost PP, but as its normal C++ standard conforming preprocessor, still fails a few cases but far less than when clang is treated as VC++ in Boost PP.

I suppose that the right thing to do here from user point of view (if that's not too much of a hassle, of course) would be to use the conforming mode for the parts that work under it, and the VC++ mode for those that work under it, and if something doesn't work with either, tough luck. :-)

Boost PP is not set up to switch modes. Figuring this out is not a possibility AFAICS, and it is not something I want to spend any time in doing. The problem is clearly that of clang. They have made this mess and it is not up to Boost to fix it IMO. Of course anybody else that wants to tackle this, including yourself, can do it if they like. I suggested to the clang developers, based also on some other people's comments, that it should be possible of them to setup their VC++ targeting so that the emulated VC++ preprocessor is used to expand macros when it is needed for certain header files ( Windows API, VC++ compiler distributed header files ) but that their C++ standard processor should be used otherwise. But they evidently did not want to do that. Even such a simple scheme as having a #pragma to specify one or the other preprocessor behavior they did not want to consider. Asking programmers to support another broken C++ preprocessor at this stage of C++'s development history is a travesty. And all simply because Microsoft has refused for a quarter of a century to fix their C++ preprocessor implementation, which they well know has always been non-standard.

On 3/30/2016 5:22 PM, Gavin Lambert wrote:

On 31/03/2016 12:56, Edward Diener wrote:

...

Asking programmers to support another broken C++ preprocessor at this stage of C++'s development history is a travesty. And all simply because Microsoft has refused for a quarter of a century to fix their C++ preprocessor implementation, which they well know has always been non-standard.

Yes.

Presumably they both have the same motivations: trillions (or likely much higher) of lines of existing code, some unknown fraction of which might depend on the quirks of the existing behaviour.

The current state of C++ is a many-to-many-to-many scenario: compilers x platforms x codebases x { standard } An ideal state would be many-to-one scenario: (compilers U platforms U code) x { standard } With the size of these sets growing, the latter is a scalable model; the former is not. While an ideal state may only be achievable in the limit, we should be moving in that direction--not intentionally away from it. If we do continue to move in that direction (which we must or C++ will die), the aforementioned code must break at some point. With the sets growing, the sooner it breaks the better because it just gets worse as time goes on.

Bear in mind that one of clang's goals is not just to compile new portable programs but also existing previously-MSVC-only codebases, with minimal (or no) changes to the code.

Yes, a misguided goal and deplorable mentality. Valuing popularity more highly that doing what is right results in trading future productivity for short-term expediency. This is an ethical rather than technical failure and a disservice to most of the current generation of C++ developers and all of their successors. Shame on them. Regards, Paul Mensonides

On 3/31/2016 7:44 PM, degski wrote:

...

On 31/03/2016 12:56, Edward Diener wrote:

It is not accurate to blaim M$ for this. Supported (by M$) operating systems are W7SP1, W8.1 and W10 (and their server counterparts) and no others. They all come with their own compiler, and are therefore the the compilers [VS2010-VS2015] that need support (in PP or otherwise) and no more. These compilers all have C++11 support, to some extent, but progressively more of it.

Why do they need support? Compiler != platform. VC++ being the "de facto" compiler on the platform is a huge part of the problem. Even when they do it wrong, the others just follow along because "de facto". Perhaps clang should try to build something new rather than just wallow in the mud with the other pigs. Moreover, no C++ code should have to support any compiler whatsoever. Code should target the standard. Compilers should target the standard. Any temporary workarounds for bugs or missing features should be exactly that: temporary. -Paul

On 4/1/2016 12:25 AM, degski wrote:

On 1 April 2016 at 06:47, Paul Mensonides wrote:

Why do they need support? Compiler != platform.

...

You're right, approaching it this way. vs2015 Update 2 is the only compiler that "needs" support, as it will compile code that runs on W7SP1, W8.1 and W10 (as they are the M$ supported OSes). In a world of open source and free (as in beer) compilers/OSes, this is not an issue, just upgrade to the latest and greatest.

C++ code should target the C++ Standard. Compilers should target the C++ Standard. C++ code should not have to target any compiler at all.

VC++ being the "de facto" compiler on the platform is a huge part of the

...

problem.

I don't really see what you intend to say here. Their platform, their compiler.

Their platform, yes, but only VC++ is their compiler. A compiler is just software running on some platform that produces executables compatible with another (possibly the same) platform. IOW, Windows is their platform, but the notion of "C++ compiler that runs on Windows or produces Windows executables" is not owned by Microsoft, nor should they be involved in it in any way (including not being "owner" of "the" C++ ABI on Windows) except maybe that of defining the executable file format (and even that is tenuous and could also be irrelevant with better QoL design in the Windows system). What all of the compilers that run on any platform (e.g. Windows: VC++, mingw, clang) should be doing is attempting to target the Standard, not copying each other's crap.

Boost doesn't have to support VC++ either, correct, but it does it's best to do so.

Unfortunately. Boost used to be a bastion of ingenuity and cutting edge practice. It is now mired in its own legacy of bending over backward (and forward) to support garbage.

Code should target the standard. Compilers should target the standard.

...

Any temporary workarounds for bugs or missing features should be exactly that: temporary.

AFAIK that's what M$ is working at. Windows pre-dates Linux by over 5 years, i.e. no gcc/clang whatever. Windows predates "The Standard", you are referring to, by 13 years. The bugs and missing features ARE temporary, their time-frame differs from yours, though.

Sure. What does that have to do with any other compiler? Microsoft owns Windows and owns VC++. It doesn't own clang, mingw, or any other C++ compiler that runs on Windows. Nor does it own C++. Microsoft does not get to decide what C++ is. The C++ standard committee decides that. Where VC++ is good or bad with respect to the conformance should be irrelevant to all other compilers. The standard each of them is measured against is not each other but, well, the Standard. That breeds competition rather than lock-in, and it is that competition that provides the motivation that ultimately yields improved time frames.

M$ suffers from legacy code like any other company. Being commmercial and supporting a huge user base, I can see that they don't re-write the OS in one go, i.e. they depend on the bad choices of the past.

So, "untouchable" code written in the past was compiled by a compiler in the past. Where did that compiler go? It is not like every software project depends on all of the trillions of lines of code previously written in every other project ever. -Paul

On 4/2/2016 2:04 AM, degski wrote:

On 1 April 2016 at 23:52, Paul Mensonides wrote:

Don't keep going on that it's all crap.

I am not referring to VC++. I am referring to clang intentionally conforming to VC++ rather than conforming to the Standard. That decision is crap and the mentality that produced it is also crap. The same is true for any other intentional nonconformance. What it says to me is either that clang's popularity is more important to the clang project than clang doing the right thing (i.e. decisions based on benefitting clang (popularity/adoption/etc.) not on benefitting the C++ community) or that the clang project's technical decision-making is extremely shortsighted--or both.

Microsoft does not get to decide what C++ is. The C++ standard committee

...

decides that.

I'm sure Herb Sutter keeps them in the loop on this one.

This is about what clang is doing, not Microsoft. Microsoft has intentionally disregarded the Standard repeatedly over a long period of time. They are getting better, slowly. That's old news. Clang, however, has now made a decision to intentionally disregard the Standard as well in order to attempt conform to Microsoft's definition of C++. Microsoft lost my respect a long time ago and has yet to regain it. Clang has now lost it as well.

...

Where VC++ is good or bad with respect to the conformance should be irrelevant to all other compilers.

And it could be, but where's libc++ for windows, f.e.?

Indeed (w/conforming C library). But not relevant when vendors are intentionally non-conforming (e.g. clang).

...

The standard each of them is measured against is not each other but, well, the Standard. That breeds competition rather than lock-in, and it is that competition that provides the motivation that ultimately yields improved time frames.

...

From the links above, the message I get is that M$ has taken op that challenge. It seems the mountain is coming to Mohammad. Give W10 and vs2015U2 a try, and be honest when giving your feedback.

Microsoft has "taken up the challenge" more times now than I can count. I will believe it when I see it. That is not to say that VC++ isn't improving (because it is), but the pace is slow, and I have yet to see anything that leads me to believe it comes from any sense of ethics (i.e. that Microsoft's trajectory is trustworthy because the forces that drive that trajectory are ethical). WRT W8+: That is a whole other issue. Attempting to artificially turn a product into a service is not only unethical but also exploitative. It is the software equivalent of a payday loan. Microsoft is hardly alone is doing this, but W8 is where it started WRT to Windows itself. I don't care how technically good it may or may not be at that point. Regards, Paul Mensonides

On 4/5/2016 3:53 AM, Niall Douglas wrote:

On 4 Apr 2016 at 16:21, Paul Mensonides wrote:

...

I am not referring to VC++. I am referring to clang intentionally conforming to VC++ rather than conforming to the Standard. That decision is crap and the mentality that produced it is also crap. The same is true for any other intentional nonconformance.

Until very recently - VS2015 Update 2 - clang needed to behave like MSVC in order to grok Windows system headers.

Now Windows system headers are (apparently) standards conforming, clang no longer needs to behave this way. Hence me submitting feature request https://llvm.org/bugs/show_bug.cgi?id=27169 to have winclang no longer implement a broken preprocessor except in msvc compatibility mode.

(Note as of Update 2, -fms-compatibility is no longer needed to use clang with a MSVC target. An enormous improvement).

...

What it says to me is either that clang's popularity is more important to the clang project than clang doing the right thing (i.e. decisions based on benefitting clang (popularity/adoption/etc.) not on benefitting the C++ community) or that the clang project's technical decision-making is extremely shortsighted--or both.

I think their decision making here is far more driven by lack of resources than anything else, only a tiny - if very productive - segment of clang's dev team work on MSVC ABI support. They needed to sell to management the need for a MSVC ABI target. That means telling a very simple compelling use case story. As Microsoft have now picked up clang for Visual Studio and have finally repaired their headers, I'd call that simple story a resounding success.

...

This is about what clang is doing, not Microsoft. Microsoft has intentionally disregarded the Standard repeatedly over a long period of time.

The Microsoft compiler team had strong business reasons to do so. Their biggest customer is Microsoft itself, and parts of that org want a broken preprocessor and other deviations from the spec. Everyone I know in the compiler team would *just love* to conform to the standard more closely, but in the end your biggest customers drive the product.

...

They are getting better, slowly. That's old news. Clang, however, has now made a decision to intentionally disregard the Standard as well in order to attempt conform to Microsoft's definition of C++. Microsoft lost my respect a long time ago and has yet to regain it. Clang has now lost it as well.

Microsoft decided to resource a clang port to Visual Studio some years ago. Gaby dos Reis indeed did much of the original prototyping of clang married to C2 codegen to see if it was viable. That's now a shipping product. Microsoft are tidying and fixing up the rest of the tool ecosystem to become as standards conforming as any other ecosystem, indeed some would argue that STL has been a bit *too* standards conforming in the MSVC STL in that he has exchanged performance in a number of places for a very strict interpretation.

Whatever respect you have for whom is your business, but no one can argue that very significant resources have been directed at this over many years, and it is having big effects. There is every reason to expect that the MSVC ABI target will be 98% C++ *17* standards conforming by end of 2017. Most of the missing 2% are due to legacy ABI problems e.g. the MSVC mangling system can't easily express lambda types in template args etc. That's as good as is achievable on an ABI approaching thirty years old and long preceding ISO standardisation.

Microsoft are also the only vendor shipping finished editions of many of the 17 era Library Fundamentals. VS2015 ships a very high quality implementation of the Filesystem TS for example, indeed it has fewer quirks than Beman's edition in Boost. I understand that is only going to improve in the next two years as Modules, Concepts and Coroutines all land, and by 2018 it is highly likely Microsoft's C++ dev environment will meet or exceed that of any other major vendor bar none.

Like you, I'll believe that when I see it, but the trends are looking excellent. Microsoft is back to being competitive in C++ after a gap of over twenty years.

And when does Microsoft actually ship a version of VC++ with a C++ standard conforming preprocessor ? Nobody is holding their breath for this just as nobody has held their breath for this over the last 25 years, during which Microsoft has repeatedly made noises that they will fix their non-standard conforming preprocessor and never have done so. All this talk of yours about how conformant to the C++ standard Microsoft is becoming means nothing unless they can fix the preprocessor. The rest of your touting of how serious Microsoft is in conforming to the C++ standard is just "show business" to me. Whatever Microsoft ships as their backend compiler, whatever noises they make about being serious about conforming as closely as possible to the C++11 or C++14 or C++17 standards, if they can't ship a C++ standards preprocessor they will never be conformant to the C++ standard.

On Tue, Apr 5, 2016 at 2:02 PM, degski wrote:

...

All this talk of yours about how conformant to the C++ standard Microsoft is becoming means nothing unless they can fix the preprocessor. The rest of your touting of how serious Microsoft is in conforming to the C++ standard is just "show business" to me. Whatever Microsoft ships as their backend compiler, whatever noises they make about being serious about conforming as closely as possible to the C++11 or C++14 or C++17 standards, if they can't ship a C++ standards preprocessor they will never be conformant to the C++ standard.

It seems google is happy https://randomascii.wordpress.com/2016/03/24/compiler-bugs-found-when-portin..., maybe boost should tell them that you're unhappy with the preprocessor and where it's buggy?

I don't think Google is an adequate example. From what I've seen, their coding policy is rather primitive and until recent attempts to cautiously use select C++11 features it was mostly C with classes. Boost, on the other hand, has always used C++ to its full power. No wonder that many weaker compilers choke at Boost.

On Tue, Apr 5, 2016 at 4:59 PM, degski wrote:

Hi Andrey,

...

I don't think Google is an adequate example. From what I've seen, their coding policy is rather primitive and until recent attempts to cautiously use select C++11 features it was mostly C with classes. Boost, on the other hand, has always used C++ to its full power. No wonder that many weaker compilers choke at Boost.

The point I was trying to make was not whether or not google writes good code (it seems they have 50k commits a day, you seem to dismiss that readily),

The commit rate has nothing to do with code quality or C++ use. And I wasn't talking about code quality at all.

but rather that it apparently is possible to have a fruitfull dialog with M$ about bugs in their latest compiler, herewith suggesting that boost enter into a dialog with M$. I would think that boost carries certainly more weight than the google chrome project.

There is no "Boost" that could enter into dialog. The guy from Google you referenced to was paid for doing his job on reporting compiler bugs. I would guess that work took considerable amount of time, too. That is not something that could happen in a volunteer driven community. At best you could hope that particular developers interested in MSVC and Windows would be eager enough to report bugs to MS, but that is unlikely to be the case for every Boost developer. That is especially unlikely given the poor quality of MSVC over the years.

On Tue, Apr 5, 2016 at 6:01 PM, degski wrote:

What do YOU see as a way forward in achieving the objective of being able to use Clang/LLVM with boost on Windows? I'm not talking about compiling boost with Clang/LLVM (that's of minor importance I would say), I'm happy compiling with VC, but I would like to be able to use those VC-binaries with Clang/LLVM, i.e. the headers need to be able to deal with the platform/compiler combo.

I would like to ask you to respond in terms of solutions rather than arguing points of dis-agreement.

The answer to that has always been the same. Someone interested in clang on Windows has to get his hands dirty and make that happen. That means at least setting up regular testing and probably filing pull requests against libraries.

On 2016-04-05 18:38, degski wrote:

Hi Andrey,

...

That means at least setting up regular testing and probably filing pull requests against libraries.

Is it hard to set it up?

I never did this myself but there is this page: http://www.boost.org/development/running_regression_tests.html

Could one (I) get help of some who are already doing this (on VC)?

I would recommend starting a new thread with an appropriate title to catch attention of the respective persons. I'm sure someone will be able to answer your questions.

What about taking action on the pull requests, TypeOf seems to be stuck in 2014, is this the only one?

I have no idea. I'm not using clang on Windows and I don't know which libraries have problems with it.

Andrey Semashev wrote:

At best you could hope that particular developers interested in MSVC and Windows would be eager enough to report bugs to MS, but that is unlikely to be the case for every Boost developer.

That's exactly what happened when Microsoft decided to make their compiler conform to the standard, starting with version 7.1. They gave us a direct channel to report bugs in the prerelease 7.1 compiler, which we did. We also introduced BOOST_WORKAROUND to make it easier for compiler vendors to test their new compilers on Boost without workarounds. The preprocessor quirks however are a bit different story, as fixing them will probably break an ungodly amount of code.

Paul Mensonides wrote:

Microsoft should not get to unilaterally decide what C++ is on Windows--including the ABI (which by its nature can limit what parts of C++ even can be implemented).

This is not a reasonable demand. The platform ABI is traditionally defined by the platform vendor.

On 4/7/2016 1:11 PM, Peter Dimov wrote:

Paul Mensonides wrote:

...

Microsoft should not get to unilaterally decide what C++ is on Windows--including the ABI (which by its nature can limit what parts of C++ even can be implemented).

This is not a reasonable demand. The platform ABI is traditionally defined by the platform vendor.

Platform ABI is not the same thing as C++ ABI. The platform ABI is a lower layer. Link compatibility of C++ binaries produced by different C++ implementations may require compatible (or the same) C++ ABIs, but link compatibility can break for independently built binaries for all sorts of reasons. Regards, Paul Mensonides

Hi, Is there a (simple) git command-line that gives me a complete "develop" boost source distribution clone, so I could give it a try? Thanks in advance, degski On 31 March 2016 at 14:28, Edward Diener wrote:

On 3/30/2016 5:05 PM, Edward Diener wrote:

...

I have made local changes in the Boost preprocessor config.hpp on the 'develop' branch to have clang's emulation of the non-standard VC++ preprocessor act like the VC++ preprocessor as far as Boost PP is concerned. Boost PP has a large number of workarounds for VC++ without which Boost PP preprocessor code would not work when compiling using any version of VC++.

I have tested the usual compilers extensively to make sure they are unaffected by these changes as well as the normal clang-linux implementation. Everything remains the same for these compilers with my changes so I am assured the changes will not affect any other compiler implementation.

I was able to test both clang-3.8 and the latest build of clang, which is clang-3.9, by invoking clang-cl. My user-config.jam file for these entries looks like:

using clang-win : 3.8 : SomePath/clang-cl : <compatibility>vc12 using clang-win : 3.9 : SomePath/clang-cl : <compatibility>vc14

By passing toolset=clang-win-3.8 or toolset=clang-win-3.9 I was able to successfully test these implementations against the Boost PP test code.

There are quite a few failures in this clang emulation of the VC++ preprocessor when tested against the preprocessor test code. In fact testing clang emulation of VC++ preprocessor when I don't treat clang as VC++ in Boost PP, but as its normal C++ standard conforming preprocessor, still fails a few cases but far less than when clang is treated as VC++ in Boost PP. Needless to say when invoking clang-linux, which tests the normal clang implementation whether on Windows or Linux, there are no failures in the Boost PP tests.

I am perfectly willing to push my changes to 'develop' for the preprocessor. The changes are essentially just in the Boost PP config.hpp file, which sets macros which control the compiler workarounds in Boost PP. As I have previously stated I am not personally willing to try to figure out or report to clang why their VC++ preprocessor emulation in Boost PP is failing, but others who are interested can do so if they wish. My personal reasons for this is that I think it is a very bad thing to attempt to replicate an already flawed C++ preprocessor in another compiler in general code. I also have spent enough time working with the VC++ preprocessor trying to find workarounds for its non-standard behavior that I do not want to do so for another preprocessor which attempts to be non-standard.

I posted this to alert others to my plans to update Boost PP on 'develop' with this change, in case anybody is greatly opposed to it or wants to discuss it further. The change will not affect any other compiler but clang in VC++ preprocessor emulation mode. Unless I hear objections etc. I plan to push my update within the next day although I will wait awhile for any replies to this post.

I pushed my update to Boost PP on 'develop' so anybody using clang targeting VC++ for Windows can try it out. It is possible that the clang emulating the non-standard VC++ preprocessor errors I see when running the preprocessor tests with clang-win toolset are few but are being propagated in many different cases. However I don't even think there is a way to see, for anybody interested, how clang is expanding macros in its VC++ emulation as opposed to normal clang-linux where macro expansion is shown when clang preprocessor erros are detected.

Note on clang targeting on Windows:

The LLVM 3.8 binary distribution of clang for Windows defaults to clang/clang++ targeting VC++, while all previous LLVM binary distributions of clang for Windows defaulted to clang/clang++ targeting mingw(-64)/gcc.

The clang-cl executable always targets VC++ AFAIK. When you build from source using VC++ on Windows then clang/clang++ targets VC++ by default and when you build from source using mingw(-64)/gcc on Windows then clang/clang++ targets mingw(-64)/gcc by default.

You can always change the targeting of clang through the use of the clang/clang++ '-target' option. It's details are poorly documented at http://clang.llvm.org/docs/CrossCompilation.html#target-triple. I chided clang developers about this incomplete documentation but without effect.

I was given the targets '-target i686-pc-windows-gnu' and '-target x86_64-pc-windows-gnu' as a way of targeting mingw(-64)/gcc for 32-bit and 64-bit clang/clang++ versions respectively, both of which I have tested and do work. I believe the equivalent targets for 32-bit and 64-bit versions of clang/clang++ targeting VC++ are '-target=i686-pc-windows-msvc' and '-target=x86_64-pc-windows-msvc' respectively but I have not tried these out.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- (\___/) (+'.'+) (")_(") This is Bunny. Copy and paste Bunny into your signature to help him gain world domination!

Easiest way is to go to https://github.com/boostorg/preprocessor, and hit the "download" button ;-)

I actually did that after I posted and before you answered. I also installed VS2015 Update 2, which was released on 30.03.2016. As testing is concerned, I have the impression, that more things are broken ow than before. It would be nice, if those things that propagate get fixed (typeof/type_traits), before attempting any other changes. These problems (typeof/type_traits) appeared with Geometry, but were quite easy to work around. Yesterday I tried Spirit, which also failes too compile (as a user of it), but to me it was unfixable, no easy work around. degski