On 9/29/2013 6:17 PM, Chandler Carruth wrote:
On Sun, Sep 29, 2013 at 4: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++.
Indeed. Boost.PP I think would likely be a prime candidate for explicitly detecting Clang (even on Windows) and just doing the right thing.
The fix that I had made to Boost PP config.h, which I was asked to remove by Beman Dawes, explicitly detects that when _MSC_VER is defined and __clang__ is defined Boost PP should not treat the compiler as VC++. In the Boost PP config.h file prior to my fix if _MSC_VER is defined then the compiler is treated as VC++. There are other cases in the Boost header files that assume that when _MSC_VER is defined the compiler is VC++ ( see my thread "Boost and clang under Windows" ) without checking if it could be another compiler emulating VC++. I had proposed in the aforementioned thread that I was willing to work on changing such code in other Boost libraries so that it did the correct thing when both _MSC_VER and __clang__ were defined, but the reaction of not only Mr. Dawes and others was that I should not do that so I desisted.