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@acc.umu.se