... broken with clang
On Sat, Dec 17, 2011 at 6:42 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
... All in all, I consider clang to be at a too early stage of development to support it in the libraries.
While I believe clang has a bright future, I'm afraid I agree with you. Clang's lack of support on Windows, including lack of installer, makes it hard for Windows developers to work with clang. Looking forward to the day when clang "just works" on Windows, --Beman
On 12/17/2011 04:48 PM, Beman Dawes wrote:
On Sat, Dec 17, 2011 at 6:42 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
... All in all, I consider clang to be at a too early stage of development to support it in the libraries.
While I believe clang has a bright future, I'm afraid I agree with you.
Clang's lack of support on Windows, including lack of installer, makes it hard for Windows developers to work with clang.
Looking forward to the day when clang "just works" on Windows,
It's trivial to install on Mac OS X (comes with XCode). It's also relatively easy to get it to work on Linux. Why would it be required to use Windows to support clang? Surely you can get ssh access to some linux or mac boxes.
... All in all, I consider clang to be at a too early stage of development to support it in the libraries.
While I believe clang has a bright future, I'm afraid I agree with you.
Clang's lack of support on Windows, including lack of installer, makes it hard for Windows developers to work with clang.
Looking forward to the day when clang "just works" on Windows,
It's trivial to install on Mac OS X (comes with XCode). It's also relatively easy to get it to work on Linux.
last time i checked, linux users had to install a patched version of libstdc++ to enable c++11 support ... tim
On 12/17/2011 06:07 PM, Tim Blechmann wrote:
... All in all, I consider clang to be at a too early stage of development to support it in the libraries.
While I believe clang has a bright future, I'm afraid I agree with you.
Clang's lack of support on Windows, including lack of installer, makes it hard for Windows developers to work with clang.
Looking forward to the day when clang "just works" on Windows,
It's trivial to install on Mac OS X (comes with XCode). It's also relatively easy to get it to work on Linux.
last time i checked, linux users had to install a patched version of libstdc++ to enable c++11 support ...
Then don't enable C++11 support. Like GCC, it's not enabled by default.
On Sat, Dec 17, 2011 at 10:57 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 12/17/2011 04:48 PM, Beman Dawes wrote:
On Sat, Dec 17, 2011 at 6:42 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
... All in all, I consider clang to be at a too early stage of development to support it in the libraries.
While I believe clang has a bright future, I'm afraid I agree with you.
Clang's lack of support on Windows, including lack of installer, makes it hard for Windows developers to work with clang.
Looking forward to the day when clang "just works" on Windows,
It's trivial to install on Mac OS X (comes with XCode). It's also relatively easy to get it to work on Linux.
Why would it be required to use Windows to support clang? Surely you can get ssh access to some linux or mac boxes.
+1 to that. Plus, as development on embedded devices seriously picking up, and Clang happening to be the only compiler available to iOS developpers starting with iOS 5.0, it would be sad to have Boost to be so Windows-centric and only support compilers that only install/run well on Windows. I understand we need to run tests and all, but at least, Clang is not an iOS-only compiler, so it can be tested on Linux or Windows. -- François Duranleau
On 19 Dec 2011, at 15:10, Francois Duranleau wrote:
On Sat, Dec 17, 2011 at 10:57 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 12/17/2011 04:48 PM, Beman Dawes wrote:
On Sat, Dec 17, 2011 at 6:42 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
... All in all, I consider clang to be at a too early stage of development to support it in the libraries.
While I believe clang has a bright future, I'm afraid I agree with you.
Clang's lack of support on Windows, including lack of installer, makes it hard for Windows developers to work with clang.
Looking forward to the day when clang "just works" on Windows,
It's trivial to install on Mac OS X (comes with XCode). It's also relatively easy to get it to work on Linux.
Why would it be required to use Windows to support clang? Surely you can get ssh access to some linux or mac boxes.
+1 to that. Plus, as development on embedded devices seriously picking up, and Clang happening to be the only compiler available to iOS developpers starting with iOS 5.0, it would be sad to have Boost to be so Windows-centric and only support compilers that only install/run well on Windows. I understand we need to run tests and all, but at least, Clang is not an iOS-only compiler, so it can be tested on Linux or Windows.
The most important thing is probably for people to run the boost regression tester with the compiler of their preference, and file bugs when things break. It's not hard to do, but it is a fairly high time investment unfortunately. http://www.boost.org/development/running_regression_tests.html Chris
On Mon, Dec 19, 2011 at 10:58 AM, Christopher Jefferson <chris@bubblescope.net> wrote:
On 19 Dec 2011, at 15:10, Francois Duranleau wrote:
+1 to that. Plus, as development on embedded devices seriously picking up, and Clang happening to be the only compiler available to iOS developpers starting with iOS 5.0, it would be sad to have Boost to be so Windows-centric and only support compilers that only install/run well on Windows. I understand we need to run tests and all, but at least, Clang is not an iOS-only compiler, so it can be tested on Linux or Windows.
The most important thing is probably for people to run the boost regression tester with the compiler of their preference, and file bugs when things break. It's not hard to do, but it is a fairly high time investment unfortunately.
http://www.boost.org/development/running_regression_tests.html
Granted. However, what decides what compilers are supported by Boost libraries? I was mostly commenting on Beman Dawes's sad (IMHO) comment roughly saying "CLang is currently poorly supported on Windows, so why bother now?" as if Boost should only care about developpers on Windows. Plus, CLang has more than a bright future, as I believed I have showed with the iOS example (and I forgot to add MacOSX as well; actually, Apple has embraced CLang as its base compiler), CLang is now! Anyway, just my two cents and a bit (a lot?) of laziness about having to run and report regression tests results for what I deem as a non exotic compiler :P. -- François Duranleau
On Dec 20, 2011, at 8:41 AM, Francois Duranleau wrote:
On Mon, Dec 19, 2011 at 10:58 AM, Christopher Jefferson <chris@bubblescope.net> wrote:
On 19 Dec 2011, at 15:10, Francois Duranleau wrote:
+1 to that. Plus, as development on embedded devices seriously picking up, and Clang happening to be the only compiler available to iOS developpers starting with iOS 5.0, it would be sad to have Boost to be so Windows-centric and only support compilers that only install/run well on Windows. I understand we need to run tests and all, but at least, Clang is not an iOS-only compiler, so it can be tested on Linux or Windows.
The most important thing is probably for people to run the boost regression tester with the compiler of their preference, and file bugs when things break. It's not hard to do, but it is a fairly high time investment unfortunately.
http://www.boost.org/development/running_regression_tests.html
Granted. However, what decides what compilers are supported by Boost libraries?
Availability of testing resources. If someone is willing to run the Boost Tests using Clang on Windows (every day, and report the results), then that will go a long way to making it a supported configuration. See http://www.boost.org/development/running_regression_tests.html for a description of how to do this. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Tue, Dec 20, 2011 at 11:48 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Dec 20, 2011, at 8:41 AM, Francois Duranleau wrote:
On Mon, Dec 19, 2011 at 10:58 AM, Christopher Jefferson <chris@bubblescope.net> wrote:
The most important thing is probably for people to run the boost regression tester with the compiler of their preference, and file bugs when things break. It's not hard to do, but it is a fairly high time investment unfortunately.
http://www.boost.org/development/running_regression_tests.html
Granted. However, what decides what compilers are supported by Boost libraries?
Availability of testing resources.
If someone is willing to run the Boost Tests using Clang on Windows (every day, and report the results), then that will go a long way to making it a supported configuration.
See http://www.boost.org/development/running_regression_tests.html for a description of how to do this.
Why on Windows specifically? Nowhere in the link above does it mandate having to run the tests on Windows. -- François Duranleau
On Dec 20, 2011, at 9:25 AM, Francois Duranleau wrote:
On Tue, Dec 20, 2011 at 11:48 AM, Marshall Clow <mclow.lists@gmail.com> wrote:
On Dec 20, 2011, at 8:41 AM, Francois Duranleau wrote:
On Mon, Dec 19, 2011 at 10:58 AM, Christopher Jefferson <chris@bubblescope.net> wrote:
The most important thing is probably for people to run the boost regression tester with the compiler of their preference, and file bugs when things break. It's not hard to do, but it is a fairly high time investment unfortunately.
http://www.boost.org/development/running_regression_tests.html
Granted. However, what decides what compilers are supported by Boost libraries?
Availability of testing resources.
If someone is willing to run the Boost Tests using Clang on Windows (every day, and report the results), then that will go a long way to making it a supported configuration.
See http://www.boost.org/development/running_regression_tests.html for a description of how to do this.
Why on Windows specifically? Nowhere in the link above does it mandate having to run the tests on Windows.
Maybe I misunderstood your question. I thought that you were asking about Boost supporting clang on Windows. To do that, we should really be testing that configuration. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Tue, Dec 20, 2011 at 12:31 PM, Marshall Clow <mclow.lists@gmail.com> wrote:
Maybe I misunderstood your question. I thought that you were asking about Boost supporting clang on Windows. To do that, we should really be testing that configuration.
Of course. But my question was not really a question but rather a part of a general comment on "CLang is not currently well supported on Windows, so don't bother about supporting CLang in Boost libraries for now". I was arguing that CLang is actually used (and in some cases we have no other choices now) on other platforms than Windows, and because CLang is readily available on platforms like Linux and MacOSX, seems to me CLang should be supported by libraries. I do not mind if CLang is said to be (at least officially) supported only on those tested platforms, because, like you (and others) pointed out, we need support from somewhere/someone to test CLang on Windows to be able to officially support it there. -- François Duranleau
On Dec 20, 2011, at 9:48 AM, Marshall Clow wrote:
On Dec 20, 2011, at 8:41 AM, Francois Duranleau wrote:
On Mon, Dec 19, 2011 at 10:58 AM, Christopher Jefferson <chris@bubblescope.net> wrote:
On 19 Dec 2011, at 15:10, Francois Duranleau wrote:
+1 to that. Plus, as development on embedded devices seriously picking up, and Clang happening to be the only compiler available to iOS developpers starting with iOS 5.0, it would be sad to have Boost to be so Windows-centric and only support compilers that only install/run well on Windows. I understand we need to run tests and all, but at least, Clang is not an iOS-only compiler, so it can be tested on Linux or Windows.
The most important thing is probably for people to run the boost regression tester with the compiler of their preference, and file bugs when things break. It's not hard to do, but it is a fairly high time investment unfortunately.
http://www.boost.org/development/running_regression_tests.html
Granted. However, what decides what compilers are supported by Boost libraries?
Availability of testing resources.
If someone is willing to run the Boost Tests using Clang on Windows (every day, and report the results), then that will go a long way to making it a supported configuration.
I could run a few Clang testers, Linux and Darwin for Boost if that would help. I'm afraid I wouldn't have time to report bugs back to Clang but perhaps someone else could help out with that. -- Noel
Hi Noel, On Tuesday, 20. December 2011 20:32:38 Belcourt, Kenneth wrote:
If someone is willing to run the Boost Tests using Clang on Windows (every day, and report the results), then that will go a long way to making it a supported configuration. I could run a few Clang testers, Linux and Darwin for Boost if that would help. I'm afraid I wouldn't have time to report bugs back to Clang but perhaps someone else could help out with that.
Well, that would be great. A working regression tester helps a lot. And as clang seems to become the only compiler in the Apple World, this would help getting Boost to newer OS X and iOS systems. Filing bug reports is a different matter. But it helps a lot if I can point to the regression results ;-) One step at a time. Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold@ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke
On Dec 20, 2011, at 1:19 PM, Jürgen Hunold wrote:
On Tuesday, 20. December 2011 20:32:38 Belcourt, Kenneth wrote:
If someone is willing to run the Boost Tests using Clang on Windows (every day, and report the results), then that will go a long way to making it a supported configuration. I could run a few Clang testers, Linux and Darwin for Boost if that would help. I'm afraid I wouldn't have time to report bugs back to Clang but perhaps someone else could help out with that.
Well, that would be great. A working regression tester helps a lot.
And as clang seems to become the only compiler in the Apple World, this would help getting Boost to newer OS X and iOS systems.
Filing bug reports is a different matter. But it helps a lot if I can point to the regression results ;-) One step at a time.
Hi Jurgen, Will do. Just tried to fire up a run and found this error using trunk clang on Boost trunk with the nightly testing process on Redhat Linux (gcc-4.1.2). -- Noel compile.c++.without-pth /scratch/boost/results/boost/bin.v2/libs/uuid/test/compile_random_generator.test/clang-linux-trunk/debug/compile_random_generator.o "/home/kbelco/llvm/build/Debug+Asserts/bin/clang" -c -x c++ -O0 -g -fno-inline -Wall -g -fPIC -DBOOST_ALL_NO_LIB=1 -I".." -o "/scratch/boost/results/boost/bin.v2/libs/uuid/test/compile_random_generator.test/clang-linux-trunk/debug/compile_random_generator.o" "../libs/uuid/test/compile_random_generator.cpp" In file included from ../libs/uuid/test/compile_random_generator.cpp:13: In file included from ../boost/uuid/random_generator.hpp:11: In file included from ../boost/uuid/uuid.hpp:38: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/algorithm:64: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_algobase.h:69: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iosfwd:45: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/c++io.h:38: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/gthr.h:132: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/gthr-default.h:100:1: error: weakref declaration must have internal linkage __gthrw(pthread_once) ^ /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/gthr-default.h:81:23: note: expanded from macro '__gthrw' #define __gthrw(name) __gthrw2(__gthrw_ ## name,name,name) ^ /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/gthr-default.h:72:46: note: expanded from macro '__gthrw2' extern __typeof(type) name __attribute__ ((__weakref__(#name2))); \
On 12/20/2011 10:22 PM, Belcourt, Kenneth wrote:
Will do. Just tried to fire up a run and found this error using trunk clang on Boost trunk with the nightly testing process on Redhat Linux (gcc-4.1.2).
-- Noel
compile.c++.without-pth /scratch/boost/results/boost/bin.v2/libs/uuid/test/compile_random_generator.test/clang-linux-trunk/debug/compile_random_generator.o
"/home/kbelco/llvm/build/Debug+Asserts/bin/clang" -c -x c++ -O0 -g -fno-inline -Wall -g -fPIC -DBOOST_ALL_NO_LIB=1 -I".." -o "/scratch/boost/results/boost/bin.v2/libs/uuid/test/compile_random_generator.test/clang-linux-trunk/debug/compile_random_generator.o" "../libs/uuid/test/compile_random_generator.cpp"
In file included from ../libs/uuid/test/compile_random_generator.cpp:13: In file included from ../boost/uuid/random_generator.hpp:11: In file included from ../boost/uuid/uuid.hpp:38: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/algorithm:64: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_algobase.h:69: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iosfwd:45: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/c++io.h:38: In file included from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/gthr.h:132: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/gthr-default.h:100:1: error: weakref declaration must have internal linkage __gthrw(pthread_once) ^ /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/gthr-default.h:81:23: note: expanded from macro '__gthrw' #define __gthrw(name) __gthrw2(__gthrw_ ## name,name,name) ^ /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/x86_64-redhat-linux/bits/gthr-default.h:72:46: note: expanded from macro '__gthrw2' extern __typeof(type) name __attribute__ ((__weakref__(#name2))); \
That's clearly not a Boost problem, it's clang being incompatible with those GCC files.
On Dec 20, 2011, at 11:32 AM, Belcourt, Kenneth wrote:
On Dec 20, 2011, at 9:48 AM, Marshall Clow wrote:
Availability of testing resources.
If someone is willing to run the Boost Tests using Clang on Windows (every day, and report the results), then that will go a long way to making it a supported configuration.
I could run a few Clang testers, Linux and Darwin for Boost if that would help. I'm afraid I wouldn't have time to report bugs back to Clang but perhaps someone else could help out with that.
I will be happy to help characterize bugs and report them to the clang folks. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
On Dec 20, 2011, at 2:29 PM, Marshall Clow wrote:
On Dec 20, 2011, at 11:32 AM, Belcourt, Kenneth wrote:
On Dec 20, 2011, at 9:48 AM, Marshall Clow wrote:
Availability of testing resources.
If someone is willing to run the Boost Tests using Clang on Windows (every day, and report the results), then that will go a long way to making it a supported configuration.
I could run a few Clang testers, Linux and Darwin for Boost if that would help. I'm afraid I wouldn't have time to report bugs back to Clang but perhaps someone else could help out with that.
I will be happy to help characterize bugs and report them to the clang folks.
Awesome, thanks Marshall. I should have a trunk clang build of Boost starting tonight with results tomorrow. -- Noel
On 17 December 2011 15:48, Beman Dawes <bdawes@acm.org> wrote:
On Sat, Dec 17, 2011 at 6:42 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
... All in all, I consider clang to be at a too early stage of development to support it in the libraries.
While I believe clang has a bright future, I'm afraid I agree with you.
Clang's lack of support on Windows, including lack of installer, makes it hard for Windows developers to work with clang.
Looking forward to the day when clang "just works" on Windows,
I haven't noticed any problems with building Clang for Windows. It's pretty straightforward process. What is missing for Boost users/developers is Boost.Build support for Clang on Windows: https://svn.boost.org/trac/boost/ticket/5943 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 12/17/2011 8:37 AM, Mateusz Łoskot wrote:
On 17 December 2011 15:48, Beman Dawes <bdawes@acm.org> wrote:
On Sat, Dec 17, 2011 at 6:42 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
... All in all, I consider clang to be at a too early stage of development to support it in the libraries.
While I believe clang has a bright future, I'm afraid I agree with you.
Clang's lack of support on Windows, including lack of installer, makes it hard for Windows developers to work with clang.
Looking forward to the day when clang "just works" on Windows,
I haven't noticed any problems with building Clang for Windows. It's pretty straightforward process. <snip>
Ah, but have you successfully *used* clang on Windows? What std library did you link with? If you've managed this, please post a how-to here or somewhere accessible. Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 17 December 2011 18:00, Eric Niebler <eric@boostpro.com> wrote:
On 12/17/2011 8:37 AM, Mateusz Łoskot wrote:
On 17 December 2011 15:48, Beman Dawes <bdawes@acm.org> wrote:
On Sat, Dec 17, 2011 at 6:42 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
... All in all, I consider clang to be at a too early stage of development to support it in the libraries.
While I believe clang has a bright future, I'm afraid I agree with you.
Clang's lack of support on Windows, including lack of installer, makes it hard for Windows developers to work with clang.
Looking forward to the day when clang "just works" on Windows,
I haven't noticed any problems with building Clang for Windows. It's pretty straightforward process. <snip>
Ah, but have you successfully *used* clang on Windows? What std library did you link with? If you've managed this, please post a how-to here or somewhere accessible. Thanks,
Eric, your assumption hits the spot. When I was running a quick test of Clang with Boost under Windows, I built Clang without problems. Next, I tried to compile Boost and I had got the errors as reported in ticket #5943. So, I assumed it is Boost.Build issue and abandoned any further testing. At that time, I hadn't monitored Clang development closely, so I had no idea about the now well-known problems with ABI (RTTI, streams) between Clang and Visual C++ C/C++ Run-Time libraries. Later, I have seen some random notes about possible use of Apache STDCXX or even LLVM/libc++ with Clang on Windows, though nothing officially confirmed, so I decided to wait a bit. Also, I may be thoroughly wrong, but according to what I have seen on libc++ mailing list it seems to be targeting Windows through MinGW, MinGW is not my cup of tea, so not even tried it. It feels to me we have number of C++ std libraries being developed, but none included Clang on Windows support in near roadmap. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 12/17/2011 07:48 AM, Beman Dawes wrote:
On Sat, Dec 17, 2011 at 6:42 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
... All in all, I consider clang to be at a too early stage of development to support it in the libraries. While I believe clang has a bright future, I'm afraid I agree with you.
Clang's lack of support on Windows, including lack of installer, makes it hard for Windows developers to work with clang.
Looking forward to the day when clang "just works" on Windows,
--Beman
While I have no intent to ship product from clang anytime soon, I do find that its less verbose and more targeted error messages can provide a quick way to sort through the gcc/msvc cruft from template errors. If one were to look back through the ML archives when Doug was getting boost to build with clang you will find that many a non-compliant construct was found via clang. I generally have no problems with clang and boost. I reported an issue with Log a few days back because IIRC the reviewed version of Log worked fine. I'll need to re-verify that is true. I'm certain you are not implying that lack of window's support somehow makes clang a non-relevant compiler. Imagine what those of us using Unix do when presented with the myriad of wacky errors produced by VC++. After my initial groan and sigh I reboot into windows or fire up a VM and figure it out. It would be a shame if authors didn't take advantage of compiling with clang. I generally find that it uncovers real issues that other compilers miss. I've yet to discover that the compiler was actually wrong with recent releases. Michael -- Michael Caisse Object Modeling Designs www.consultomd.com
On 12/18/2011 01:12 AM, Michael Caisse wrote:
While I have no intent to ship product from clang anytime soon, I do find that its less verbose and more targeted error messages can provide a quick way to sort through the gcc/msvc cruft from template errors.
Have you really tried it? Because I have the exact opposite experience. When templates are involved, it generates much more verbose output with a huge amount of cruft (especially when both macros and templates are involved, as is often the case in Boost). While with GCC the error message is in the middle of the screen, with Clang you have to scroll two or three pages. It's also much harder to make it display types or other compile-time values in error messages or warnings.
If one were to look back through the ML archives when Doug was getting boost to build with clang you will find that many a non-compliant construct was found via clang.
Clang is indeed a good way to find invalid code. Its standard conformance is very good while still being very GCC-compatible.
On 12/17/2011 04:25 PM, Mathias Gaunard wrote:
On 12/18/2011 01:12 AM, Michael Caisse wrote:
While I have no intent to ship product from clang anytime soon, I do find that its less verbose and more targeted error messages can provide a quick way to sort through the gcc/msvc cruft from template errors.
Have you really tried it?
Yes. It is actually how I develop these days. I compile with both gcc and clang. Very often I find clang produces less cruft. Sometimes it produces completely useless information. However, just like you, I'm well versed in reading gcc output.
It's also much harder to make it display types or other compile-time values in error messages or warnings.
This is part of why I like it. I usually know what my_thing_t is and I really don't need the compiler to expand the templates for pages and pages. Less often I need to understand exactly why the compiler doesn't like the type and seeing the gcc fully resolved output is just fine. I guess this is why I compile with both during development. michael -- Michael Caisse Object Modeling Designs www.consultomd.com
participants (11)
-
Belcourt, Kenneth -
Beman Dawes -
Christopher Jefferson -
Eric Niebler -
Francois Duranleau -
Jürgen Hunold -
Marshall Clow -
Mateusz Łoskot -
Mathias Gaunard -
Michael Caisse -
Tim Blechmann