Boost logo

Boost :

Subject: Re: [boost] [clang] Using clang in Windows
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2014-07-18 07:50:05

On 07/18/2014 03:58 AM, Richard wrote:
> "Paul A. Bristow" <pbristow_at_[hidden]> 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


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