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.