$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [clang] Using clang in Windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-07-15 10:47:49
On 7/15/2014 5:01 AM, Paul A. Bristow wrote:
>
>
>> -----Original Message-----
>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Edward Diener
>> Sent: 14 July 2014 22:08
>> To: boost_at_[hidden]
>> Subject: Re: [boost] [clang] Using clang in Windows
>>
>> On 7/14/2014 1:35 PM, Paul A. Bristow wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of
>>>> Edward Diener
>>>> Sent: 14 July 2014 08:06
>>>> To: boost_at_[hidden]
>>>> Subject: [boost] [clang] Using clang in Windows
>>>>
>>>> Just a note to everybody about using clang in Windows
>
> <snip>
>>
>> 2) The greater of the two problems is that in order to compile with the
>> VC++ header files clang in Windows, targeting VC++, has had to emulate a
>> certain amount of VC++ "bugs" just to digest the header files without compile
> errors.
>> The most serious negative form of this emulation IMO is that clang has
> emulated
>> some of the "bugs" in the very non-standard VC++ preprocessor. However the
> extent
>> of the "bugs" in the VC++ preprocessor, even if the VC++ preprocessor "works"
> fine
>> for the majority of fairly simple macro processing, is large when it comes to
> the sort
>> of preprocessor metaprogramming done in Boost PP and my own VMD library.
>> These bugs all center around the fact that the VC++ preprocessor does not do
> macro
>> expansion correctly, often seemingly not fully expanding macro input before
> the
>> tokens are substituted in the invoking macros output. But there are a number
> of
>> other things which the VC++ preprocessor gets wrong, which can only be
> illustrated
>> by very complicated examples and rarely by easy cases. It is highly doubtful
> that
>> clang targeting VC++ duplicates all the "bugs" and preprocessing weirdness of
> VC++
>> macro expansion, but just duplicating some of them creates another compiler
> with
>> weird VC++ like problems which a library like Boost PP is asked to deal with.
> I know
>> Paul Mensonides has no enthusiasm for such work and neither do I, dealing with
>> VC++ itself has been hard enough. I made the suggestion in the clang
> developer's
>> mailing list that clang targeting VC++ should act like the buggy VC++
> preprocessor
>> for macros in VC++'s header files but should be a C++ standard conforming
>> preprocessor otherwise, possibly controlled by some pragmas, but it seems like
>> nobody cares about this. There are just too many programmers who just want
> clang
>> targeting VC++ to behave like VC++ so they can use it theirt VS IDE compiler
> and they
>> don't care if doing so means that it cannot compile other C++ standard code
>> correctly, in this particular case C++ macros.
>
> Thanks for your efforts on this can of worms too.
>
> 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.
>
> This wait will not be what *you* want, of course!
What I do not want is to have to try to hack Boost PP in order to make
clang targeting VC++ work. To clang's credit when I ran the Boost PP
tests, which I have largely expanded, in the 'develop' branch against
the clang VC++ implementation, only a single test failed due to clang
emulating VC++ preprocessor bugs.
I have argued vehemently in the clang developer mailing list that,
although I do now understand that clang targeting VC++ has to emulate
some of VC++'s preprocessor bugs in order to compile the VC++ header
files, clang targeting VC++ should otherwise be a C++ standard
conforming preprocessor for all other code. This could be done pretty
nicely via a pragma. But it does not seem to have made much of an
impression on others there. Many clang developers/users are so happy
that they can use clang in place of VC++ in the VS IDE that they cannot
understand what a poor C++ preprocessor VC++ is when one goes beyond
fairly simple macro expansion techniques, as of course Boost PP does.