On Sun, Sep 29, 2013 at 4:06 PM, Edward Diener
With all due respect, Beman, there is no point of doing this at least for Boost headers once I reverted the fix to the Boost PP code that would have allowed clang under Windows to correctly compiler Boost PP code as a strictly conforming C++ standard preprocessor. It fails miserably as the VC++ preprocessor and I am not personally interested particularly in discovering why since the VC++ preprocessor is just badly broken in a number of respects general. To emulate that brokeness cannot be the goal of any C++ compiler.
IIUC, they are aiming to support the aspects of VC++ that are required to compile and run the libraries shipped with Visual Studio and libraries like Boost. I doubt they intend to mimic bugs not required for that purpose, and they have stated up front that they intend to support all C++11/14 features, not just those supported by VC++.
I will wish the clang people best of luck on their Windows implementation but if it means emulating VC++ in every respect I do not see the purpose of it, as I can just as well use VC++.
VC++ is not planning to support all of C++11/14 until roughly the end of 2014. Clang under Visual Studio will support all known C++11/14 features out of the chute. Surely that is a huge win for Visual Studio users, whether boost developers or otherwise. Even once VC++ catches up, there is a great advantage in having two compilers running under the same IDE since errors resulting in hard to diagnose error messages from one compiler often produce easy to understand error messages from a different compiler. It also makes it faster to tell if an error is a compiler error or a user error. --Beman