Boost and clang under Windows
First off I am not of course proposing any changes to the upcoming release build of Boost 1.55 for clang under Windows. It turns out that clang under Windows, possibly to support the ability to use Windows header file, becomes another compiler which defines _MSC_VER. I believe the Intel compiler also does this but there may be some others. However clang is a much more strictly conforming to the C++ standard compiler than VC++ and does not have VC++'s quirks. This presents a problem in Boost. The Boost header files have numerous places where testing the macro _MSC_VER produces slightly different behavior based on the fact that the code is being used by VC++ or a compiler with the same behavior as VC++. But clang does not have the same behavior as VC++ despite defining _MSC_VER. Can I go ahead and change some of these situations as necessary to get clang under Windows to work properly with Boost code ? The usual change will be to test not only _MSC_VER but also that __clang__ is not defined for keeping the current implementation which assumes a VC++ compatible compiler with VC++ behavior. I am willing to make those changes in 'trunk' and keep an eye out for any significant failures in unit tests for our current regression tests. I have already made a slight change to Boost PP config.hpp on 'trunk' so that clang for Windows will pass the preprocessor tests. I am willing to work on other changes but I do not want to go ahead and do so if the maintainers of other libraries see any reasons for me not making the changes on 'trunk'. Of course I will test any changes I make locally to make sure they do not affect any other _MSC_VER defined compilers as well as with VC++. But the changes themselves should be fairly simple, just adding a check that __clang__ is not defined as part of the VC++ type behavior. Obviously something like the many tests for _MSC_VER in order to specify #pragma once will not change but some other situations will to exclude clang from the _MSC_VER functionality.
On Sunday 29 September 2013 12:59:27 Edward Diener wrote:
First off I am not of course proposing any changes to the upcoming release build of Boost 1.55 for clang under Windows.
It turns out that clang under Windows, possibly to support the ability to use Windows header file, becomes another compiler which defines _MSC_VER. I believe the Intel compiler also does this but there may be some others.
However clang is a much more strictly conforming to the C++ standard compiler than VC++ and does not have VC++'s quirks. This presents a problem in Boost.
The Boost header files have numerous places where testing the macro _MSC_VER produces slightly different behavior based on the fact that the code is being used by VC++ or a compiler with the same behavior as VC++. But clang does not have the same behavior as VC++ despite defining _MSC_VER.
Can I go ahead and change some of these situations as necessary to get clang under Windows to work properly with Boost code ?
The usual change will be to test not only _MSC_VER but also that __clang__ is not defined for keeping the current implementation which assumes a VC++ compatible compiler with VC++ behavior. I am willing to make those changes in 'trunk' and keep an eye out for any significant failures in unit tests for our current regression tests.
I have already made a slight change to Boost PP config.hpp on 'trunk' so that clang for Windows will pass the preprocessor tests. I am willing to work on other changes but I do not want to go ahead and do so if the maintainers of other libraries see any reasons for me not making the changes on 'trunk'. Of course I will test any changes I make locally to make sure they do not affect any other _MSC_VER defined compilers as well as with VC++. But the changes themselves should be fairly simple, just adding a check that __clang__ is not defined as part of the VC++ type behavior. Obviously something like the many tests for _MSC_VER in order to specify #pragma once will not change but some other situations will to exclude clang from the _MSC_VER functionality.
Sorry, I haven't been following the discussion about Clang on Windows closely, but as I understand, it is in an early stage of development, isn't it? I think someone said it is not able to compile even the simplest "hello world" code samples? If so, should we add more scaffolding to Boost in order to make it work with a pre-alpha state compiler? My second concern is that Clang advertise itself as an MSVC-compatible compiler while not being one. Intel compiler, for example, also does this, but unlike Clang it is pretty close. If Clang aims to be compatible with MSVC (and I assume it does, since it defines _MSC_VER), it has to make sure it can swallow any MSVC-specific code. For this reason I would prefer Boost code not to be adjusted for Clang, but rather the other way around. If someone is willing to push Clang on Windows forward, I think reporting bugs to Clang team is more appropriate than adjusting software for it.
On 9/29/2013 1:21 PM, Andrey Semashev wrote:
On Sunday 29 September 2013 12:59:27 Edward Diener wrote:
First off I am not of course proposing any changes to the upcoming release build of Boost 1.55 for clang under Windows.
It turns out that clang under Windows, possibly to support the ability to use Windows header file, becomes another compiler which defines _MSC_VER. I believe the Intel compiler also does this but there may be some others.
However clang is a much more strictly conforming to the C++ standard compiler than VC++ and does not have VC++'s quirks. This presents a problem in Boost.
The Boost header files have numerous places where testing the macro _MSC_VER produces slightly different behavior based on the fact that the code is being used by VC++ or a compiler with the same behavior as VC++. But clang does not have the same behavior as VC++ despite defining _MSC_VER.
Can I go ahead and change some of these situations as necessary to get clang under Windows to work properly with Boost code ?
The usual change will be to test not only _MSC_VER but also that __clang__ is not defined for keeping the current implementation which assumes a VC++ compatible compiler with VC++ behavior. I am willing to make those changes in 'trunk' and keep an eye out for any significant failures in unit tests for our current regression tests.
I have already made a slight change to Boost PP config.hpp on 'trunk' so that clang for Windows will pass the preprocessor tests. I am willing to work on other changes but I do not want to go ahead and do so if the maintainers of other libraries see any reasons for me not making the changes on 'trunk'. Of course I will test any changes I make locally to make sure they do not affect any other _MSC_VER defined compilers as well as with VC++. But the changes themselves should be fairly simple, just adding a check that __clang__ is not defined as part of the VC++ type behavior. Obviously something like the many tests for _MSC_VER in order to specify #pragma once will not change but some other situations will to exclude clang from the _MSC_VER functionality.
Sorry, I haven't been following the discussion about Clang on Windows closely, but as I understand, it is in an early stage of development, isn't it? I think someone said it is not able to compile even the simplest "hello world" code samples? If so, should we add more scaffolding to Boost in order to make it work with a pre-alpha state compiler?
My second concern is that Clang advertise itself as an MSVC-compatible compiler while not being one. Intel compiler, for example, also does this, but unlike Clang it is pretty close. If Clang aims to be compatible with MSVC (and I assume it does, since it defines _MSC_VER), it has to make sure it can swallow any MSVC-specific code. For this reason I would prefer Boost code not to be adjusted for Clang, but rather the other way around. If someone is willing to push Clang on Windows forward, I think reporting bugs to Clang team is more appropriate than adjusting software for it.
The problem is that one is asking clang to dumb itself down in order to be compatible with VC++. It may do this just enough regarding Windows header files but it may be too much to ask it to do this in regard to Boost header files. Windows header files may have non-standard C++-isms in them which clang can fairly easily adjust to since the Windows header files hardly implement much of C++. Remember that Boost hopes to create code which is standard C++ compatible in implementations which are on the cutting edge of C++ implementation. The clang implementation is on the cutting edge of the C++ standard. Boost only chooses workarounds for compilers which do not follow the standard in some respects. Asking clang to dumb itself down to accept non-standard implementations in Boost because _MSC_VER is defined is much more radical than asking clang to accept Windows headers files. I would still much prefer that we make the adjustments for clang under Windows in the Boost header files than asking clang to adapt to some VC++-ism ( essentially adding erroneous C++ code to their very conformant C++ implementation ) which is not standard C++, simply because _MSC_VER is defined by them in their Windows build. The changes we would ask them to make for Boost, to support C++ non-conformance under Windows, would almost certainly be far greater than what they may have had to do to compile Windows headers.
On Sun, Sep 29, 2013 at 1:40 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
On 9/29/2013 1:21 PM, Andrey Semashev wrote:
On Sunday 29 September 2013 12:59:27 Edward Diener wrote:
First off I am not of course proposing any changes to the upcoming release build of Boost 1.55 for clang under Windows.
It turns out that clang under Windows, possibly to support the ability to use Windows header file, becomes another compiler which defines _MSC_VER. I believe the Intel compiler also does this but there may be some others.
However clang is a much more strictly conforming to the C++ standard compiler than VC++ and does not have VC++'s quirks. This presents a problem in Boost.
The Boost header files have numerous places where testing the macro _MSC_VER produces slightly different behavior based on the fact that the code is being used by VC++ or a compiler with the same behavior as VC++. But clang does not have the same behavior as VC++ despite defining _MSC_VER.
Can I go ahead and change some of these situations as necessary to get clang under Windows to work properly with Boost code ?
Please do not do that. I had face-to-face meetings this week with Chandler Carruth and others working on Clang for Windows. They are depending on Boost's tests to find bugs in Clang's emulation of Visual C++, and if you work around their bugs it will deprive them of a valuable testing tool.
The usual change will be to test not only _MSC_VER but also that __clang__ is not defined for keeping the current implementation which assumes a VC++ compatible compiler with VC++ behavior. I am willing to make those changes in 'trunk' and keep an eye out for any significant failures in unit tests for our current regression tests.
Please do not do that.
I have already made a slight change to Boost PP config.hpp on 'trunk' so that clang for Windows will pass the preprocessor tests.
Please revert that change. That preprocessor problem was one of the specific examples they cited where they are hoping to achieve VC++ compatibility. They really want boost tests to fail until compatibility is achieved, and then to detect any regressions if compatibility is lost. I don't think it occurred to them or to me during the discussions that anyone would try to workaround failures before the clang folks had a chance to introduce Microsoft compatibility fixes. I'll get back to Chandler with a request for a public statement of their plan. He asked me to post a request for help on the Boost list, but it may take several days. It takes quite a while to work through do lists after a C++ committee meeting. --Beman
On 9/29/2013 2:52 PM, Beman Dawes wrote:
On Sun, Sep 29, 2013 at 1:40 PM, Edward Diener <eldiener@tropicsoft.com>wrote:
On 9/29/2013 1:21 PM, Andrey Semashev wrote:
On Sunday 29 September 2013 12:59:27 Edward Diener wrote:
First off I am not of course proposing any changes to the upcoming release build of Boost 1.55 for clang under Windows.
It turns out that clang under Windows, possibly to support the ability to use Windows header file, becomes another compiler which defines _MSC_VER. I believe the Intel compiler also does this but there may be some others.
However clang is a much more strictly conforming to the C++ standard compiler than VC++ and does not have VC++'s quirks. This presents a problem in Boost.
The Boost header files have numerous places where testing the macro _MSC_VER produces slightly different behavior based on the fact that the code is being used by VC++ or a compiler with the same behavior as VC++. But clang does not have the same behavior as VC++ despite defining _MSC_VER.
Can I go ahead and change some of these situations as necessary to get clang under Windows to work properly with Boost code ?
Please do not do that. I had face-to-face meetings this week with Chandler Carruth and others working on Clang for Windows. They are depending on Boost's tests to find bugs in Clang's emulation of Visual C++, and if you work around their bugs it will deprive them of a valuable testing tool.
OK.
The usual change will be to test not only _MSC_VER but also that __clang__ is not defined for keeping the current implementation which assumes a VC++ compatible compiler with VC++ behavior. I am willing to make those changes in 'trunk' and keep an eye out for any significant failures in unit tests for our current regression tests.
Please do not do that.
OK.
I have already made a slight change to Boost PP config.hpp on 'trunk' so that clang for Windows will pass the preprocessor tests.
Please revert that change. That preprocessor problem was one of the specific examples they cited where they are hoping to achieve VC++ compatibility. They really want boost tests to fail until compatibility is achieved, and then to detect any regressions if compatibility is lost.
OK. I have reverted the change. But... does clang really want to emulate VC++'s highly broken preprocessor when building under Windows ? I have a really hard time believing that. Essentially the change I made in Boost PP config.hpp ( you can check it ) makes clang under Windows behave as a strictly conforming C++ preprocessor on the order of gcc and Wave rather than as the VC++ preprocessor. You have to know how bad the VC++ preprocessor is, as Paul Mensonides knows in full, and as I know somewhat, to realize what that means. I also doubt whether clang can even emulate the brokeness of the VC++ preprocessor in every respect, but I certainly cannot believe it would even want to. I just want to make the point that while I understand that clang under Windows wants to emulate VC++ in some respects in order to compile Windows header code, I don't see the point of emulating VC++ completely. In that latter case there would be no reason even to use it as a highly conformant C++ compiler on Windows since it would essentially be "the same as VC++". There is no sour grapes involved but I will not be the one to report preprocessor problems with clang under Windows if clang really wants to emulate the broken VC++ preprocessor. And since nearly every library to some greater or lesser extent depends on Boost PP for some macro preprocessing they will exhibit preprocessing errors using current clang under Windows and failed to pass their tests.
I don't think it occurred to them or to me during the discussions that anyone would try to workaround failures before the clang folks had a chance to introduce Microsoft compatibility fixes. I'll get back to Chandler with a request for a public statement of their plan.
He asked me to post a request for help on the Boost list, but it may take several days. It takes quite a while to work through do lists after a C++ committee meeting.
On 29 September 2013 19:52, Beman Dawes <bdawes@acm.org> wrote:
Please do not do that. I had face-to-face meetings this week with Chandler Carruth and others working on Clang for Windows. They are depending on Boost's tests to find bugs in Clang's emulation of Visual C++, and if you work around their bugs it will deprive them of a valuable testing tool.
They should be testing with BOOST_COMPILER_CONFIG set to "boost/config/compiler/visualc.hpp". That way BOOST_MSVC and the appropriate compatibility macros will be set for them, but we can still use BOOST_MSVC to treat Visual C++ differently to clang.
On Sunday 29 September 2013 20:57:56 Daniel James wrote:
On 29 September 2013 19:52, Beman Dawes <bdawes@acm.org> wrote:
Please do not do that. I had face-to-face meetings this week with Chandler Carruth and others working on Clang for Windows. They are depending on Boost's tests to find bugs in Clang's emulation of Visual C++, and if you work around their bugs it will deprive them of a valuable testing tool.
They should be testing with BOOST_COMPILER_CONFIG set to "boost/config/compiler/visualc.hpp". That way BOOST_MSVC and the appropriate compatibility macros will be set for them, but we can still use BOOST_MSVC to treat Visual C++ differently to clang.
BOOST_MSVC should only be defined for genuine MSVC, not for any pretenders. That's the whole point of this macro.
On 29 September 2013 21:12, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Sunday 29 September 2013 20:57:56 Daniel James wrote:
On 29 September 2013 19:52, Beman Dawes <bdawes@acm.org> wrote:
Please do not do that. I had face-to-face meetings this week with Chandler Carruth and others working on Clang for Windows. They are depending on Boost's tests to find bugs in Clang's emulation of Visual C++, and if you work around their bugs it will deprive them of a valuable testing tool.
They should be testing with BOOST_COMPILER_CONFIG set to "boost/config/compiler/visualc.hpp". That way BOOST_MSVC and the appropriate compatibility macros will be set for them, but we can still use BOOST_MSVC to treat Visual C++ differently to clang.
BOOST_MSVC should only be defined for genuine MSVC, not for any pretenders. That's the whole point of this macro.
Errr, that's what I said. I was suggesting that they could test with BOOST_COMPILER_CONFIG set to the Visual C++ header so it will be set in *their* tests. For our use BOOST_MSVC wouldn't be set.
On Sunday 29 September 2013 21:19:24 Daniel James wrote:
On 29 September 2013 21:12, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Sunday 29 September 2013 20:57:56 Daniel James wrote:
On 29 September 2013 19:52, Beman Dawes <bdawes@acm.org> wrote:
Please do not do that. I had face-to-face meetings this week with Chandler Carruth and others working on Clang for Windows. They are depending on Boost's tests to find bugs in Clang's emulation of Visual C++, and if you work around their bugs it will deprive them of a valuable testing tool.
They should be testing with BOOST_COMPILER_CONFIG set to "boost/config/compiler/visualc.hpp". That way BOOST_MSVC and the appropriate compatibility macros will be set for them, but we can still use BOOST_MSVC to treat Visual C++ differently to clang.
BOOST_MSVC should only be defined for genuine MSVC, not for any pretenders. That's the whole point of this macro.
Errr, that's what I said. I was suggesting that they could test with BOOST_COMPILER_CONFIG set to the Visual C++ header so it will be set in *their* tests. For our use BOOST_MSVC wouldn't be set.
I don't understand. Why would they test a known to be incorrect configuration?
On 29 September 2013 21:23, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Sunday 29 September 2013 21:19:24 Daniel James wrote:
On 29 September 2013 21:12, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Sunday 29 September 2013 20:57:56 Daniel James wrote:
On 29 September 2013 19:52, Beman Dawes <bdawes@acm.org> wrote:
Please do not do that. I had face-to-face meetings this week with Chandler Carruth and others working on Clang for Windows. They are depending on Boost's tests to find bugs in Clang's emulation of Visual C++, and if you work around their bugs it will deprive them of a valuable testing tool.
They should be testing with BOOST_COMPILER_CONFIG set to "boost/config/compiler/visualc.hpp". That way BOOST_MSVC and the appropriate compatibility macros will be set for them, but we can still use BOOST_MSVC to treat Visual C++ differently to clang.
BOOST_MSVC should only be defined for genuine MSVC, not for any pretenders. That's the whole point of this macro.
Errr, that's what I said. I was suggesting that they could test with BOOST_COMPILER_CONFIG set to the Visual C++ header so it will be set in *their* tests. For our use BOOST_MSVC wouldn't be set.
I don't understand. Why would they test a known to be incorrect configuration?
If they want to test their emulation of Visual C++, they should be testing using the same code as Visual C++, which means testing with the Visual C++ configuration.
On 29 Sep 2013 at 14:52, Beman Dawes wrote:
I don't think it occurred to them or to me during the discussions that anyone would try to workaround failures before the clang folks had a chance to introduce Microsoft compatibility fixes. I'll get back to Chandler with a request for a public statement of their plan.
I think there are multiple issues at work here, and the list is conflating them all as one. It might be worth disambiguating them: 1. There is getting clang to compile Mingw-path Boost on Windows. This is fairly easy, simply configure clang to pretend to be Mingw and apart from some minor gotchas this works and spits out Mingw type PE binaries. 2. There is getting clang to compile MSVC-path Boost on Windows with all its quirks workarounds and special cases and code paths for legacy MSVCs which modern MSVCs sometimes emulate if they spot a legacy pattern. This is very similar to IE10 spotting IE6 patterns and forcing legacy behaviour to prevent legacy code breakage. 3. There is getting clang to compile Boost as if it were MSVC18 (VS2013). Here the new, much less customised Dinkumware STL and much more conformant compiler ought to let Boost disable custom MSVC code paths in many cases, and adopt the GCC/clang code paths instead. Someone just needs to go through and try flipping code path selection switches to see what happens with the latest MSVC [1]. Item 1 is an easy add to Boost Build, though I struggle to see the value add for Boost apart from clang AST parsing on Windows. Item 2 is valuable to clang developers for debugging clang, and not really anyone else. Item 3 is value adding to Boost. Item 3 is the one Boost ought to encourage. Note that Item 2 and Item 3 are not mutually incompatible. Item 3 can be implemented with no damage done to Item 2 with the right design. If clang's developers want Item 2, they can supply the appropriate preprocessor macros to have Boost output the quirkest, most MSVC-specific possible code. Meanwhile, Boost can move ahead by removing MSVC quirk code paths for newer MSVCs, something I think everyone will agree would be a huge win in maintenance and bugs. [1]: It took a bit of creativity and effort, but I now have a single C++ path for VS2013 and GCC and clang in Boost.AFIO. Exact same C++ for all three compilers. I'm very pleased with VS2013, it's a huge improvement. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On Sun, Sep 29, 2013 at 4:16 PM, Niall Douglas <s_sourceforge@nedprod.com>wrote:
On 29 Sep 2013 at 14:52, Beman Dawes wrote:
I don't think it occurred to them or to me during the discussions that anyone would try to workaround failures before the clang folks had a chance to introduce Microsoft compatibility fixes. I'll get back to Chandler with a request for a public statement of their plan.
I think there are multiple issues at work here, and the list is conflating them all as one. It might be worth disambiguating them:
I was going to write just such an email....
1. There is getting clang to compile Mingw-path Boost on Windows. This is fairly easy, simply configure clang to pretend to be Mingw and apart from some minor gotchas this works and spits out Mingw type PE binaries.
FWIW, while there are some folks in the Clang community interested in MinGW compatibility, it has significantly fewer resources devoted to it, and isn't my personal priority.
2. There is getting clang to compile MSVC-path Boost on Windows with all its quirks workarounds and special cases and code paths for legacy MSVCs which modern MSVCs sometimes emulate if they spot a legacy pattern. This is very similar to IE10 spotting IE6 patterns and forcing legacy behaviour to prevent legacy code breakage.
FWIW, we have a very strong interest in getting this to work with at least VS2012 and VS2010. I don't think anyone is looking at compatibility on the Clang side further back.
3. There is getting clang to compile Boost as if it were MSVC18 (VS2013). Here the new, much less customised Dinkumware STL and much more conformant compiler ought to let Boost disable custom MSVC code paths in many cases, and adopt the GCC/clang code paths instead. Someone just needs to go through and try flipping code path selection switches to see what happens with the latest MSVC [1].
We also care about and will work to support VS2013 as it sees updates, but we're still getting started here. Some things may work better with Clang, and some things may not work at all. For example, I don't think we have any of the Visual Studio or MSBuild integration.
Item 2 is valuable to clang developers for debugging clang, and not really anyone else.
I'm hopeful that Clang's Windows support is valuable to Boost developers and other developers using C++ on Windows.
Item 3 is value adding to Boost. Item 3 is the one Boost ought to encourage.
Clang developers will also benefit from bugs here as we've yet to really get a handle on VS2013.
On Mon, Sep 30, 2013 at 8:15 AM, Chandler Carruth <chandlerc@google.com>wrote:
On Sun, Sep 29, 2013 at 4:16 PM, Niall Douglas <s_sourceforge@nedprod.com
wrote: [SNIPPED]
Item 2 is valuable to clang developers for debugging clang, and not really anyone else.
I'm hopeful that Clang's Windows support is valuable to Boost developers and other developers using C++ on Windows.
[SNIPPED]
As someone who develops exclusively for Windows (and currently jumps through major hoops to get code working under Clang just for the improved diagnostics -- obviously can't use its codegen just yet) I just wanted to say yes yes yes yes yes a million times yes. :)
On 30.09.2013 2:15, Chandler Carruth wrote:
We also care about and will work to support VS2013 as it sees updates, but we're still getting started here. Some things may work better with Clang, and some things may not work at all. For example, I don't think we have any of the Visual Studio or MSBuild integration. Currently, the CLang compiler can be used as a _toolset_ for the Visual Studio and MSBuild. Out of box, without any 3rd party plugins.
-- Sergey Cheban
On 29 Sep 2013 at 17:15, Chandler Carruth wrote:
I think there are multiple issues at work here, and the list is conflating them all as one. It might be worth disambiguating them:
I was going to write just such an email....
Occasionally great minds can think alike ... :)
We also care about and will work to support VS2013 as it sees updates, but we're still getting started here. Some things may work better with Clang, and some things may not work at all. For example, I don't think we have any of the Visual Studio or MSBuild integration.
I don't know if VS2013's preprocessor has fixed __VA_ARGS__ handling yet, which is severely broken. The bug report at http://connect.microsoft.com/VisualStudio/feedback/details/380090/ suggests no. I really wish Microsoft would add a new compiler switch to turn on EDG's preprocessor, or some standards conforming preprocessor implementation, and deprecate the current one.
Item 2 is valuable to clang developers for debugging clang, and not really anyone else.
I'm hopeful that Clang's Windows support is valuable to Boost developers and other developers using C++ on Windows.
Ok, replace "not really anyone else" with "not really anyone else using Boost", which is what I didn't make clear. As you know, I would just love - if my next employer allows me - to implement a standard component object layer for C++, as one the biggest scalability constraints facing all users of C++ is change ripple propagation, and the only technology to have done something useful on that is Microsoft's COM which, partially through its age and partially through deliberate restraints during its design, hugely limits exposing much of anything modern C++ through its ABI. A huge part of any such standardised component object layer must be clang's AST, particularly if C++ Modules ever starts looking production ready. And therefore, if clang could gain the ability to cope well with MSVC-only code, that chops a huge chunk of work off what I have in mind. In other words, I too have a huge vested interest in clang as a direct substitute for MSVC so I can use your AST to package up MSVC binaries. Basically I wish you all god's speed. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On Sunday 29 September 2013 13:40:04 Edward Diener wrote:
On 9/29/2013 1:21 PM, Andrey Semashev wrote:
Sorry, I haven't been following the discussion about Clang on Windows closely, but as I understand, it is in an early stage of development, isn't it? I think someone said it is not able to compile even the simplest "hello world" code samples? If so, should we add more scaffolding to Boost in order to make it work with a pre-alpha state compiler?
My second concern is that Clang advertise itself as an MSVC-compatible compiler while not being one. Intel compiler, for example, also does this, but unlike Clang it is pretty close. If Clang aims to be compatible with MSVC (and I assume it does, since it defines _MSC_VER), it has to make sure it can swallow any MSVC-specific code. For this reason I would prefer Boost code not to be adjusted for Clang, but rather the other way around. If someone is willing to push Clang on Windows forward, I think reporting bugs to Clang team is more appropriate than adjusting software for it.
The problem is that one is asking clang to dumb itself down in order to be compatible with VC++. It may do this just enough regarding Windows header files but it may be too much to ask it to do this in regard to Boost header files. Windows header files may have non-standard C++-isms in them which clang can fairly easily adjust to since the Windows header files hardly implement much of C++.
Remember that Boost hopes to create code which is standard C++ compatible in implementations which are on the cutting edge of C++ implementation. The clang implementation is on the cutting edge of the C++ standard. Boost only chooses workarounds for compilers which do not follow the standard in some respects. Asking clang to dumb itself down to accept non-standard implementations in Boost because _MSC_VER is defined is much more radical than asking clang to accept Windows headers files.
I would still much prefer that we make the adjustments for clang under Windows in the Boost header files than asking clang to adapt to some VC++-ism ( essentially adding erroneous C++ code to their very conformant C++ implementation ) which is not standard C++, simply because _MSC_VER is defined by them in their Windows build. The changes we would ask them to make for Boost, to support C++ non-conformance under Windows, would almost certainly be far greater than what they may have had to do to compile Windows headers.
This has nothing to do with Boost being the cutting edge of C++. It still is, whether or not it supports a particular (non-mainstream) compiler on a particular platform. If Clang aims to implement C++ and not MS extensions/bugs then it shouldn't pretend to be MSVC. As simple as that. GCC went that route, even though it still implements some MS extensions (but notably not bugs). IMHO, that would be the simplest and probably the right way. As for now, Clang pretends to be MSVC, so it should pretend better. This includes implementing extensions (__declspec, intrinsics, __intXX, pragmas and what not) and probably some fundamental shortcomings. It might also require various compatibility modes with different MSVC versions. They provide a Visual Studio plugin, so the user is able to use Clang as a drop-in replacement for MSVC. And this means the user is "allowed" to feed his MFC/COM/DCOM/ATL/DirectX or whatever other Windows-specific code to it, not just windows.h. I'm not requiring things like managed C++ or AMP, since these things are more dialects of C++ than C++, but nevertheless, if Clang supports them as well, this will be an additional plus. I admit, the latter approach is surely less pleasant for Clang team, but if they define _MSC_VER for nothing they will simply make things much much harder for developers. Intel took this approach and please note that Intel compiler does implement more of C++ than MSVC does, but these features are disabled by default.
On 9/29/2013 3:00 PM, Andrey Semashev wrote:
On Sunday 29 September 2013 13:40:04 Edward Diener wrote:
On 9/29/2013 1:21 PM, Andrey Semashev wrote:
Sorry, I haven't been following the discussion about Clang on Windows closely, but as I understand, it is in an early stage of development, isn't it? I think someone said it is not able to compile even the simplest "hello world" code samples? If so, should we add more scaffolding to Boost in order to make it work with a pre-alpha state compiler?
My second concern is that Clang advertise itself as an MSVC-compatible compiler while not being one. Intel compiler, for example, also does this, but unlike Clang it is pretty close. If Clang aims to be compatible with MSVC (and I assume it does, since it defines _MSC_VER), it has to make sure it can swallow any MSVC-specific code. For this reason I would prefer Boost code not to be adjusted for Clang, but rather the other way around. If someone is willing to push Clang on Windows forward, I think reporting bugs to Clang team is more appropriate than adjusting software for it.
The problem is that one is asking clang to dumb itself down in order to be compatible with VC++. It may do this just enough regarding Windows header files but it may be too much to ask it to do this in regard to Boost header files. Windows header files may have non-standard C++-isms in them which clang can fairly easily adjust to since the Windows header files hardly implement much of C++.
Remember that Boost hopes to create code which is standard C++ compatible in implementations which are on the cutting edge of C++ implementation. The clang implementation is on the cutting edge of the C++ standard. Boost only chooses workarounds for compilers which do not follow the standard in some respects. Asking clang to dumb itself down to accept non-standard implementations in Boost because _MSC_VER is defined is much more radical than asking clang to accept Windows headers files.
I would still much prefer that we make the adjustments for clang under Windows in the Boost header files than asking clang to adapt to some VC++-ism ( essentially adding erroneous C++ code to their very conformant C++ implementation ) which is not standard C++, simply because _MSC_VER is defined by them in their Windows build. The changes we would ask them to make for Boost, to support C++ non-conformance under Windows, would almost certainly be far greater than what they may have had to do to compile Windows headers.
This has nothing to do with Boost being the cutting edge of C++. It still is, whether or not it supports a particular (non-mainstream) compiler on a particular platform.
If Clang aims to implement C++ and not MS extensions/bugs then it shouldn't pretend to be MSVC. As simple as that. GCC went that route, even though it still implements some MS extensions (but notably not bugs). IMHO, that would be the simplest and probably the right way.
As for now, Clang pretends to be MSVC, so it should pretend better. This includes implementing extensions (__declspec, intrinsics, __intXX, pragmas and what not) and probably some fundamental shortcomings. It might also require various compatibility modes with different MSVC versions. They provide a Visual Studio plugin, so the user is able to use Clang as a drop-in replacement for MSVC. And this means the user is "allowed" to feed his MFC/COM/DCOM/ATL/DirectX or whatever other Windows-specific code to it, not just windows.h. I'm not requiring things like managed C++ or AMP, since these things are more dialects of C++ than C++, but nevertheless, if Clang supports them as well, this will be an additional plus.
I admit, the latter approach is surely less pleasant for Clang team, but if they define _MSC_VER for nothing they will simply make things much much harder for developers. Intel took this approach and please note that Intel compiler does implement more of C++ than MSVC does, but these features are disabled by default.
I totally understand your viewpoint. But if we assume that _MSC_VER with clang is strictly VC++ in Boost, and it is turned on in the default usage of clang when using Boost Build under Windows, then it is nothing but VC++ as far as Boost code is concerned and therefore offers none of the standard conformance as a compiler which clang as a compiler is noted for. Therefore, as far as using it with current Boost headers under Windows to test/compile Boost code, it is totally useless AFAICS since using it is using VC++.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sunday 29 September 2013 15:32:45 Edward Diener wrote:
On 9/29/2013 3:00 PM, Andrey Semashev wrote:
On Sunday 29 September 2013 13:40:04 Edward Diener wrote:
On 9/29/2013 1:21 PM, Andrey Semashev wrote:
Sorry, I haven't been following the discussion about Clang on Windows closely, but as I understand, it is in an early stage of development, isn't it? I think someone said it is not able to compile even the simplest "hello world" code samples? If so, should we add more scaffolding to Boost in order to make it work with a pre-alpha state compiler?
My second concern is that Clang advertise itself as an MSVC-compatible compiler while not being one. Intel compiler, for example, also does this, but unlike Clang it is pretty close. If Clang aims to be compatible with MSVC (and I assume it does, since it defines _MSC_VER), it has to make sure it can swallow any MSVC-specific code. For this reason I would prefer Boost code not to be adjusted for Clang, but rather the other way around. If someone is willing to push Clang on Windows forward, I think reporting bugs to Clang team is more appropriate than adjusting software for it.
The problem is that one is asking clang to dumb itself down in order to be compatible with VC++. It may do this just enough regarding Windows header files but it may be too much to ask it to do this in regard to Boost header files. Windows header files may have non-standard C++-isms in them which clang can fairly easily adjust to since the Windows header files hardly implement much of C++.
Remember that Boost hopes to create code which is standard C++ compatible in implementations which are on the cutting edge of C++ implementation. The clang implementation is on the cutting edge of the C++ standard. Boost only chooses workarounds for compilers which do not follow the standard in some respects. Asking clang to dumb itself down to accept non-standard implementations in Boost because _MSC_VER is defined is much more radical than asking clang to accept Windows headers files.
I would still much prefer that we make the adjustments for clang under Windows in the Boost header files than asking clang to adapt to some VC++-ism ( essentially adding erroneous C++ code to their very conformant C++ implementation ) which is not standard C++, simply because _MSC_VER is defined by them in their Windows build. The changes we would ask them to make for Boost, to support C++ non-conformance under Windows, would almost certainly be far greater than what they may have had to do to compile Windows headers.
This has nothing to do with Boost being the cutting edge of C++. It still is, whether or not it supports a particular (non-mainstream) compiler on a particular platform.
If Clang aims to implement C++ and not MS extensions/bugs then it shouldn't pretend to be MSVC. As simple as that. GCC went that route, even though it still implements some MS extensions (but notably not bugs). IMHO, that would be the simplest and probably the right way.
As for now, Clang pretends to be MSVC, so it should pretend better. This includes implementing extensions (__declspec, intrinsics, __intXX, pragmas and what not) and probably some fundamental shortcomings. It might also require various compatibility modes with different MSVC versions. They provide a Visual Studio plugin, so the user is able to use Clang as a drop-in replacement for MSVC. And this means the user is "allowed" to feed his MFC/COM/DCOM/ATL/DirectX or whatever other Windows-specific code to it, not just windows.h. I'm not requiring things like managed C++ or AMP, since these things are more dialects of C++ than C++, but nevertheless, if Clang supports them as well, this will be an additional plus.
I admit, the latter approach is surely less pleasant for Clang team, but if they define _MSC_VER for nothing they will simply make things much much harder for developers. Intel took this approach and please note that Intel compiler does implement more of C++ than MSVC does, but these features are disabled by default.
I totally understand your viewpoint. But if we assume that _MSC_VER with clang is strictly VC++ in Boost, and it is turned on in the default usage of clang when using Boost Build under Windows, then it is nothing but VC++ as far as Boost code is concerned and therefore offers none of the standard conformance as a compiler which clang as a compiler is noted for. Therefore, as far as using it with current Boost headers under Windows to test/compile Boost code, it is totally useless AFAICS since using it is using VC++.
Not totally useless, but less useful than a fully conforming implementation, alternative to MSVC. That's why I would prefer Clang not try to pretend MSVC in the first place.
The Boost header files have numerous places where testing the macro _MSC_VER produces slightly different behavior based on the fact that the code is being used by VC++ or a compiler with the same behavior as VC++. But clang does not have the same behavior as VC++ despite defining _MSC_VER.
That shouldn't really be happening - the code should check for BOOST_MSVC if it really want's "real" msvc and _MSC_VER just for things like #pragma once where some simple form of msvc emulation is required. John.
On Sunday 29 September 2013 19:03:32 John Maddock wrote:
The Boost header files have numerous places where testing the macro _MSC_VER produces slightly different behavior based on the fact that the code is being used by VC++ or a compiler with the same behavior as VC++. But clang does not have the same behavior as VC++ despite defining _MSC_VER.
That shouldn't really be happening - the code should check for BOOST_MSVC if it really want's "real" msvc and _MSC_VER just for things like #pragma once where some simple form of msvc emulation is required.
FWIW, there is BOOST_HAS_PRAGMA_ONCE for that purpose. _MSC_VER can be used to detect availability of other compiler extensions, such as _Interlocked* intrinsics or assembler dialect, for example.
On 9/29/2013 2:03 PM, John Maddock wrote:
The Boost header files have numerous places where testing the macro _MSC_VER produces slightly different behavior based on the fact that the code is being used by VC++ or a compiler with the same behavior as VC++. But clang does not have the same behavior as VC++ despite defining _MSC_VER.
That shouldn't really be happening - the code should check for BOOST_MSVC if it really want's "real" msvc and _MSC_VER just for things like #pragma once where some simple form of msvc emulation is required.
My OP was because it is indeed happening. And even in type traits <g>.
participants (9)
-
Andrey Semashev -
Beman Dawes -
Chandler Carruth -
Daniel James -
Edward Diener -
John Maddock -
Joshua Boyce -
Niall Douglas -
Sergey Cheban