Re: [boost] [clang] Using clang in Windows

On 07/18/2014 03:58 AM, Richard wrote:

"Paul A. Bristow" spake the secret code

...

From: Edward Diener Sent: 15 July 2014 15:48

...

On 7/15/2014 5:01 AM, Paul A. Bristow wrote:

...

...

...

Perhaps we have to wait for Microsoft to produce an (presumably) optional 'correct' pre-processor?

I recall some post about this related to one of the Boost developers talking to Herb Sutter about the non-standard VC++ preprocessor and getting a verbal promise that Microsoft would finally produce a standard conforming C++ preprocessor for VC++. But I believe that Microsoft has made similar "noises" in that direction over the years and nothing has ever happened so I am not sanguine about it happening anytime soon.

Can we produce any collective Boost wish to help this to happen?

My suggestion has been to identify (or create) the issues on connect that call out the non-conformant behavior and have the entire community vote them up and comment on them. Most open issues against the compiler or the IDE have one or two votes. It's easy to disregard these as having minimal impact on the user base. Even if it was only *library authors* that upvoted these issues on connect, they would stand out significantly. If lots of boost/C++ users upvoted them, then it would stand out in a huge way.

Not a bad idea, but how do you engage boost users in this if boost libraries and clang features are so nice about hiding it for them. I am thinking it may be time to be less gentle on new none compliant compiler versions. Why don't Boost attempt to remind Boost users and their compiler vendors that there are underlying non compliant compiler and standard library issues, in this case with the MS header files and preprocessor, that is complicating the availability, maintenance and improvement of the Boost libraries. One slightly radical but perhaps effective method would be to provide custom diagnostics, e.g. compiler warning and errors as appropriate. triggered by work around macros in Boost. The diagnostics should have a direct link to a page on Boost Wiki (or similar) that states the purpose of the diagnostics. Then state the status related to the goals of the Wiki page and suggested actions to take by users to help. The Wiki page should state how it is possible to silence the compiler warnings, but encourage users to take suggested actions before silencing the diagnostics. For Clang on Windows using MS headers this could be done. I am also thinking it should be done for new MS compilers. The alternative to be less gentle now about these issues is to accept that MS and others may continue having compliance issues that Boost have to work around. So when using MSVC 2025 compiler or libraries, Boost will still need to maintain and create new tweaks for this sort of issues. It would be bad if their C++11, and C++14 "feature complete" compilers does not have this fixed. It would be scary if users of their C++17 compilers still suffer. -- Bjørn