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

Subject: Re: [boost] [clang] Using clang in Windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-07-18 09:47:55

On 7/18/2014 7:50 AM, Bjørn Roald wrote:
> 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.

A separate diagnostic library based on macros could work to do this. But 
we should of course allow the end-user to turn on or off such compiler 
diagnostics messages.