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

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

--
Bjørn