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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk