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

Subject: Re: [boost] [clang] Using clang in Windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-07-15 11:08:30

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.

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.