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

Subject: Re: [boost] [clang] Using clang in Windows
From: Lars Viklund (zao_at_[hidden])
Date: 2014-07-15 11:28:19

On Tue, Jul 15, 2014 at 11:08:30AM -0400, Edward Diener wrote:
> On 7/15/2014 5:46 AM, Lars Viklund wrote:
> >On Tue, Jul 15, 2014 at 10:01:26AM +0100, Paul A. Bristow wrote:
> >>Perhaps we have to wait for Microsoft to produce an (presumably) optional
> >>'correct' pre-processor?
> >>
> >>This wait will not be what *you* want, of course!
> >
> >I thought that the problem with writing a correct preprocessor is that
> >then they would not be able to consume their own headers and probably a
> >lot of customer headers. That would mean restricting it to only new code
> >against a new SDK, and you're going to have a hard time getting _that_
> >over the "every feature starts at -100 points" barrier.
> >
> 
> While I agree that consuming their own headers might be a problem I have my
> own doubts about anything but a very small percent of customer headers being
> affected negatively by a change to a C++ standard conforming preprocessor.
> Most of the strange VC++ preprocessing behavior only really shows when one
> is creating the sort of large scale preprocessing constructs that are found
> in Boost PP. I do not think many customers will do macro programming at
> anywhere near that level.

I'm not overly concerned about someone intentionally writing complicated
preprocessing, as those kinds of people are capable of implementing
their PP magic in conformant terms. I'm concerned about people that
without much knowledge write ill-formed macros that the VC++ PP ends up
interpreting in the way the user intends, but which a proper PP would
either reject or translate differently.

This is the same reason as why there's so much code out there that only
builds with VC++. A lot of people throw tokens at the compiler until
they stick and call it a day.

It may be that most occurences of actual PP programming are not affected
by the differences, but it seems that there's a _lot_ of diverging
behaviour in the VC++ PP that existing macros are accidentally using.

> But in either case what can be done is the creation of a set of pragmas to
> switch between current VC++ preprocessor and a C++ standard conforming
> preprocessor when it comes to macro expansion ( where essentially all the
> VC++ preprocessor bugs manifest themselves ). In this way one could control
> which macros ( VC++ header files etc. ) are subject to the current VC++
> preprocessor macro expansion buggy implementation and which macros ( Boost
> PP et al ) are subject to a correct C++ standard preprocessor macro
> expansion implementation. I made this same argument on the clang developers
> mailing list for clang's VC++ implementation but without getting any
> replies. Of course if people do not understand how badly the VC++
> preprocessor behaves regarding macro expansion when one does preprocessor
> programming beyond the simple level most people employ, then it does not
> matter to them how badly the VC++ preprocessor actually works because its
> problems do not manifest themselves in what they normally do.

A system headers, a pragma or some other way of indicating
non-conformant headers would be nice. I'd attribute this to the very
slim set of people that work on the clang-cl part as well, not to
mention the rather fundamental dislike for clang-cl, MS and VC++ that
runs throughout the cfe-dev list, at least to my impression. Just ask
about 32-bit SEH some day :)

-- 
Lars Viklund | zao_at_[hidden]