On 11/4/2012 12:33 PM, Matt Calabrese wrote:
On Sun, Nov 4, 2012 at 3:01 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
I doubt if Microsoft considers full support for C++(11) to be also producing a compliant preprocessor. I am not defending them for that viewpoint but it does seem as if they view the preprocessor has a separate part of the C++ language which they do not have to implement according to the latest C/C++ standards.
I think the problem is that so few people care about a compliant preprocessor, and those who do care are often library developers who consistently bend over backwards with workarounds to support VC++ anyway. That coupled with the fact that fixing their preprocessor means potentially breaking people's code (even though it was noncompliant to begin with), means that it is an extremely low priority for them. IMO, they should just include something like Boost.Wave or Clang's preprocessor and have a compiler option to enable it (even if it defaults to not being enabled, falling back to their noncompliant preprocessor) and make sure that windows headers compile correctly with it on. I can't imagine that this would be too difficult for them to do, and at least then library developers have some way to support VC++ without tons of workarounds -- just tell users of the library to pass in the appropriate compiler option.
There are certainly features of the language which are more important than the preprocessor. However, the preprocessor has been broken for decades. More than that, in comparison to many other language facilities, implementing it correctly is easy. The problem is not that it is a low priority among language features. The problem is that other things such as extensions and integrated libraries are prioritized ahead of language features/bugs--and new instances of those keep occurring so the end of the priority list never gets reached. In the specific case of the preprocessor and some others, the problem is that it is continuously classed as "won't fix" and therefore has no priority at all. I would be much happier with a priority list that was something like: 1. C++ feature A 2. C++ feature B 3. C++ bug 1 ... 100. C/C++ preprocessor 101. language extensions for AMP 102. language extensions for C++/CLI/CX I would be actually happy with a priority list that was something like: 1. C++ feature A 2. C++ feature B 3. C++ bug 1 ... 100. C/C++ preprocessor with language extensions for AMP, C++/CLI, and C++/CX not existing at all and instead implemented entirely as libraries. In that case, the compiler would not be dependent on the development of these things and therefore these things could be developed concurrently by separate teams and have their own priority lists. However, both of the above priority lists are *far* away from what actually appears to occur. Instead, it is more like 1. C++ bindings to WinRT (marketing driven) 2. C++ bindings to C++/CLI (marketing driven) 3. C++ subsetting/extensions for AMP (marketing driven ultimately for cloud services) 4. new C++11 features (actually also marketing driven) 5. feature-breaking bugs Almost everything else is classified as "won't fix." Worse than the above, (1), (2), and (3) get implemented and taken off the list only to be replaced by new marketing-driven, extra-linguistic concerns. The result is excessively slow adoption of C++11 features and almost no adoption of missing C++98 features or fixing of mis-implemented C++98 features. Virtually every action taken by MS WRT VC++ is contrary to what Herb repeatedly says in his various talks and interviews. MS is free to do whatever they want. However, stop lying to us and stop playing politics. Regards, Paul Mensonides