On 9/29/2013 5:43 PM, Beman Dawes wrote:
On Sun, Sep 29, 2013 at 4:06 PM, Edward Diener
wrote: 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++.
If they don't intend to "mimic bugs not required for that purpose" then the fix I put in Boost PP config.h is absolutely necessary. Please try "bjam toolset=clang" in the Boost PP test directory under Windows after building or installing clang under Windows. You will soon understand why I made the change I did. After the slew of failures that you see because clang, a highly comformant C++ preprocessor pretends to be VC++ for the purposes of the Boost PP code because it defines _MSC_VER, you can make the change I originally did and try "bjam toolset=clang" again in the Boost PP test directory. Then you will see the difference. I do understand and applaud clang's purpose to compile code properly under Windows, even using the Windows header files. But I do not see the purpose of emulating VC++ when it is broken in regards to the C++ standard if it is not necessary. My Boost PP change made emulation of the broken VC++ preprocessor unnecessary for Boost PP. Please remember that very little other, if any at all, preprocessor code written for Windows is going to require clang to emulate the broken VC++ preprocessor in order to compile Windows code. Boost PP pushes the boundary of what can be done with the C++ preprocessor in a cross-platform way. Can it really be that clang in Windows wants to go from a C++ standard compliant preprocessor to the rather horrible VC++ preprocessor just to accomplish its goal of compiling C++ under Windows ? Each case is distinct and there may be some other cases where clang will attempt to emulate VC++ but trying to duplicate the VC++ preprocessor should not be one of them. I cannot emphasize this more. There's no point in producing a first-rate product and then crippling it in some large respect because of emulation on a particular OS. I don't particularly care what else it brings to the table. I know it is a fine line to decide what compromises might have to be made in pure C++ standard code to emulate VC++ and therefore compile Windows code. There may be other cases where clang will emulate VC++ even if it does not strictly follow the C++ standard. But the preprocessor is not one of them if you know anything at all about how badly VC++'s preprocessor is broken for all but the most basic macro expansions.
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.