Which compilers are not supported for 1.48 ?
Are really old and broken compilers still supported? Do we need them? For example VC++6. It gives thousands of warnings on type_traits and boost PP headers. Tests for VC++6 do not compile. Nobody tested boost libraries on that compiler for years. May be we shall get rid of compilers, that do not support template partitial specialization, ADL or SFINAE? If not, shall we try to make the tests pass (or at least compile) for them? Best regards, Antony Polukhin
On Sat, Jul 16, 2011 at 01:00:37AM +0400, Antony Polukhin wrote:
Are really old and broken compilers still supported? Do we need them?
For example VC++6. It gives thousands of warnings on type_traits and boost PP headers. Tests for VC++6 do not compile. Nobody tested boost libraries on that compiler for years.
May be we shall get rid of compilers, that do not support template partitial specialization, ADL or SFINAE? If not, shall we try to make the tests pass (or at least compile) for them?
These kinds of threads pop up every now and then. The last time I believe the violent consensus was that it was a bit counter-productive to touch code uncessarily, especially such code that isn't clearly delimited by feature test or workaround macros. Sure, it might not be worth keeping code targeting inferior compilers around if rewriting or otherwise doing heavy work in the code, but intentionally destroying functionality for the people that, probably due to a lack of choice, _do_ use such compilers, sounds a bit evil. Note that not all compilers are as clearly broken as VC6, which is properly pre-standard and works mostly out of coincidence. VisualAge for example is under active development and is generally competent, tracking several 0x features, on the level of other competing compilers. It however has some quirks regarding some of the things you mention. Should it be destroyed as well? What about SunStudio? It's really broken in some ways, but perfectly sane in others. Should code that currently is broken be excised, even if a compiler is improving? The world needs more compilers, and it saddens me when new libraries are developed and deployed claiming to be portable but only really builds on recent GCC and maybe MSVC. rantingly yours, -- Lars Viklund | zao@acc.umu.se
On 7/15/2011 5:36 PM, Lars Viklund wrote:
On Sat, Jul 16, 2011 at 01:00:37AM +0400, Antony Polukhin wrote:
Are really old and broken compilers still supported? Do we need them?
For example VC++6. It gives thousands of warnings on type_traits and boost PP headers. Tests for VC++6 do not compile. Nobody tested boost libraries on that compiler for years.
May be we shall get rid of compilers, that do not support template partitial specialization, ADL or SFINAE? If not, shall we try to make the tests pass (or at least compile) for them?
These kinds of threads pop up every now and then. The last time I believe the violent consensus was that it was a bit counter-productive to touch code uncessarily, especially such code that isn't clearly delimited by feature test or workaround macros.
snipped...
The world needs more compilers, and it saddens me when new libraries are developed and deployed claiming to be portable but only really builds on recent GCC and maybe MSVC.
The problem I have found is that it is difficult to test on many other compilers because they are not popular enough, C++ standard enough, or they are not free to use. While I certainly do not think there is anything wrong with charging for software, C++ compiler creators might realize that Boost developers are doing them a service testing their compilers and they should have some deal by which one is not charged for using their compiler in such a scenario. For TTI I wanted to test Intel C++ but it is not free even though there is a 30-day trial period. Some other compilers are free but deficient in areas where finding a workaround becomes onerous. Some compilers do not really work well, or if at all, on some OSs. So what happens is that many developers may want to test on compilers other than gcc and MSVC ( on Windows ), but find it easiest to test on those compilers simply because there is not much else around that can be used to test one's C++ code fairly easily. I certainly feel that it is the Boost library developer's prerogative whether to try to support some older compiler. I would not even think of testing with VC6, and even VC7 or VC7.1 has enough quirks and headaches so that I now avoid them. With gcc anything below 3.4.2 is more trouble than its worth and I am sure that plenty of developers are targeting only gcc 4+ and up. I agree it is great to have as many compilers as possible, and I applaud efforts like clang. But when compilers cause more headaches than one's own code/design it is just easier seeking correct code and forgot about compilers which can not handle the C++ standard ( 1998/2003 at the least ) fairly readily.
2011/7/16 Lars Viklund <zao@acc.umu.se>:
The world needs more compilers, and it saddens me when new libraries are developed and deployed claiming to be portable but only really builds on recent GCC and maybe MSVC.
Let me simplify the question: VC++6 and other old compiler builds are totally broken in multiple wide used libraries. 1) Shall I fix and commit bugfixes for those errors (hundreds of them)? I have no time to fix them all. 2) Shall I do nothing? 2.1) Do we need code, old/deprecated headers that does not work at all? 2.2) Why don`t post a warning/error for a user, that this compiler is not supported and '21 error(s), 1674 warning(s)' are not the user fault? 3) Shall I post bug reports for library maintainers? 3.1) They have opened bugs even for new compilers... When will be the fixes ready? Will be there any fixes? Best regards, Antony Polukhin
Antony Polukhin wrote:
2011/7/16 Lars Viklund <zao@acc.umu.se>:
The world needs more compilers, and it saddens me when new libraries are developed and deployed claiming to be portable but only really builds on recent GCC and maybe MSVC.
Let me simplify the question: VC++6 and other old compiler builds are totally broken in multiple wide used libraries.
1) Shall I fix and commit bugfixes for those errors (hundreds of them)? I have no time to fix them all. 2) Shall I do nothing? 2.1) Do we need code, old/deprecated headers that does not work at all? 2.2) Why don`t post a warning/error for a user, that this compiler is not supported and '21 error(s), 1674 warning(s)' are not the user fault? 3) Shall I post bug reports for library maintainers? 3.1) They have opened bugs even for new compilers... When will be the fixes ready? Will be there any fixes?
I find it a bit odd that Boost should work hard to support compiler versions that are themselves unsupported since many years. Why do we think this is a productive idea? Bo Persson
on Sat Jul 16 2011, "Bo Persson" <bop-AT-gmb.dk> wrote:
Antony Polukhin wrote:
2011/7/16 Lars Viklund <zao@acc.umu.se>:
The world needs more compilers, and it saddens me when new libraries are developed and deployed claiming to be portable but only really builds on recent GCC and maybe MSVC.
Let me simplify the question: VC++6 and other old compiler builds are totally broken in multiple wide used libraries.
1) Shall I fix and commit bugfixes for those errors (hundreds of them)? I have no time to fix them all. 2) Shall I do nothing? 2.1) Do we need code, old/deprecated headers that does not work at all? 2.2) Why don`t post a warning/error for a user, that this compiler is not supported and '21 error(s), 1674 warning(s)' are not the user fault? 3) Shall I post bug reports for library maintainers? 3.1) They have opened bugs even for new compilers... When will be the fixes ready? Will be there any fixes?
I find it a bit odd that Boost should work hard to support compiler versions that are themselves unsupported since many years.
Why do we think this is a productive idea?
Let me be clear: Boost doesn't have an official policy about what compilers are supported. Library maintainers are free to support whichever toolchains they like. Now, maybe we should change all or part of that, but that's how it stands today. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 16 Jul 2011, at 05:51, Antony Polukhin wrote:
2011/7/16 Lars Viklund <zao@acc.umu.se>:
The world needs more compilers, and it saddens me when new libraries are developed and deployed claiming to be portable but only really builds on recent GCC and maybe MSVC.
Let me simplify the question: VC++6 and other old compiler builds are totally broken in multiple wide used libraries.
Shall we at least officially list the compilers boost supports, in which libraries, so users know what is supported, rather than having to just compile and hope? Chris
On 07/16/2011 01:18 PM, Christopher Jefferson wrote:
Shall we at least officially list the compilers boost supports, in which libraries, so users know what is supported, rather than having to just compile and hope?
Each library should already document on which compilers it is known to work.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Mathias Gaunard Sent: Saturday, July 16, 2011 5:52 PM To: boost@lists.boost.org Subject: Re: [boost] Which compilers are not supported for 1.48 ?
On 07/16/2011 01:18 PM, Christopher Jefferson wrote:
Shall we at least officially list the compilers boost supports, in which libraries, so users know what is supported, rather than having to just compile and hope?
Each library should already document on which compilers it is known to work.
I fear it is more complicated than that. For example, the Boost.Math library has some parts that work as far back as the Jurassic VC6, but some that only work with the shiniest new compiler versions. It's just too difficult and much too tedious to try to even discover everything that works/doesn't work, let alone list it, so I'm afraid that 'Suck it and See' must remain the answer for older, and less popular platforms, compilers. We try hard to get *everything* to work for the newest GCC and MSVC, as the detailed regression results will reveal. (Should we refer the general user to these test results?) But the general message should be - upgrade to the latest compiler and the latest Boost if humanly possible. Too many problem reported could be avoided by doing this. Sorry. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 15 July 2011 18:34, Edward Diener <eldiener@tropicsoft.com> wrote:
While I certainly do not think there is anything wrong with charging for software, C++ compiler creators might realize that Boost developers are doing them a service testing their compilers and they should have some deal by which one is not charged for using their compiler in such a scenario.
While I haven't done it specifically for C++ compilers, I've found that you can get access to commercial software for legitimate testing purposes by asking the right people for it. The disconnect comes when the people responsible for selling the software aren't closely affiliated with the people developing the software, which tends to happen at larger companies.
For TTI I wanted to test Intel C++ but it is not free even though there is a 30-day trial period.
I believe the Intel compiler is free for non-commercial use. Check out < http://software.intel.com/en-us/articles/non-commercial-software-development/> for more details. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
2011/7/15 Lars Viklund <zao@acc.umu.se>:
On Sat, Jul 16, 2011 at 01:00:37AM +0400, Antony Polukhin wrote:
Are really old and broken compilers still supported? Do we need them?
For example VC++6. It gives thousands of warnings on type_traits and boost PP headers. Tests for VC++6 do not compile. Nobody tested boost libraries on that compiler for years.
May be we shall get rid of compilers, that do not support template partitial specialization, ADL or SFINAE? If not, shall we try to make the tests pass (or at least compile) for them?
These kinds of threads pop up every now and then. The last time I believe the violent consensus was that it was a bit counter-productive to touch code uncessarily, especially such code that isn't clearly delimited by feature test or workaround macros.
Sure, it might not be worth keeping code targeting inferior compilers around if rewriting or otherwise doing heavy work in the code, but intentionally destroying functionality for the people that, probably due to a lack of choice, _do_ use such compilers, sounds a bit evil.
Note that not all compilers are as clearly broken as VC6, which is properly pre-standard and works mostly out of coincidence.
VisualAge for example is under active development and is generally competent, tracking several 0x features, on the level of other competing compilers. It however has some quirks regarding some of the things you mention. Should it be destroyed as well?
What about SunStudio? It's really broken in some ways, but perfectly sane in others. Should code that currently is broken be excised, even if a compiler is improving?
The world needs more compilers, and it saddens me when new libraries are developed and deployed claiming to be portable but only really builds on recent GCC and maybe MSVC.
I think it's counter productive to tailor code around vendor specific work arounds, instead the vendors should fix their issues. It's better if the vendors were to work closer with for example boost to make sure that they follow the standard. Otherwise we'll end up with what we have in the web development world, where instead of the vendors getting their act together we have every single web develop in the world spending obscene amounts of time just getting consistency across browsers. I do however agree that there's nothing gained from deliberately undoing current work arounds, especially for compilers which aren't in development. Kind regards, Sebastian Karlsson
On Mon, 18 Jul 2011 12:16:36 +0100, Sebastian Karlsson <sairony@gmail.com> wrote:
I think it's counter productive to tailor code around vendor specific work arounds, instead the vendors should fix their issues. It's better
This is an appalling attitude - not towards vendors, but towards users. The only way to get bug fixes in Boost is to rev forward to new releases, and you appear to have the attitude that if that requires compiler upgrades its just tough. Life, in reality, is not like that on any non-trivial production system: Boost is just one component: the compiler builds all the components. Its a non-trivial upgrade, and likely not an agile one. James
2011/7/19 James Mansion <james@mansionfamily.plus.com>:
On Mon, 18 Jul 2011 12:16:36 +0100, Sebastian Karlsson <sairony@gmail.com> wrote:
I think it's counter productive to tailor code around vendor specific work arounds, instead the vendors should fix their issues. It's better
This is an appalling attitude - not towards vendors, but towards users. The only way to get bug fixes in Boost is to rev forward to new releases, and you appear to have the attitude that if that requires compiler upgrades its just tough. Life, in reality, is not like that on any non-trivial production system: Boost is just one component: the compiler builds all the components. Its a non-trivial upgrade, and likely not an agile one.
James
To support all versions of all vendors is a maintenance nightmare, negatively affects readability and overall is just a whole lot of trouble. This is IMO already an issue when reading the boost source, where there's often multiple code branches for compilers with different quirks. Making sure that the most widely used compilers are supported is reasonable, but making sure that for example VS6 works for new features is more trouble than it's worth. Besides, projects still on VS6 are mostly just maintenance and likely won't upgrade boost anyway. 99% of all other 3rd party libs does not support as wide range of compilers as boost, so boost won't really be the first problem. Same goes for compilers with very low user count, it's better to contact the vendor in that case and pressure for a fix. It's a huge disservice to the user in the long term to have libraries tailor themselves to compiler specific workarounds, that's why we have a standard. Kind regards, Sebastian Karlsson
16.07.2011 1:00, Antony Polukhin пишет:
Are really old and broken compilers still supported? Do we need them?
For example VC++6. In the 1.47 release notes, I see the following: Boost's primary test compilers are: Visual C++ 7.1, 9.0, 10.0 ... Boost's additional test compilers include: Visual C++ 7.1, 9.0, 10.0 ...
I see no MSVC 6.0 in this list. For me, it means that MSVC 6.0 is not supported. -- Sergey Cheban
Personally I think it should be more explicit. I quite like Qt's page on platform support, in that it's broken down into 'tiers' with an explanation of what each tier means in terms of support. Furthermore, it explicitly states that whilst compilers not listed may work, they should not be considered officially supported. http://doc.qt.nokia.com/4.8-snapshot/supported-platforms.html On Sun, Jul 17, 2011 at 5:36 AM, Sergey Cheban <s.cheban@drweb.com> wrote:
16.07.2011 1:00, Antony Polukhin пишет:
Are really old and broken compilers still supported? Do we need them?
For example VC++6.
In the 1.47 release notes, I see the following: Boost's primary test compilers are: Visual C++ 7.1, 9.0, 10.0 ... Boost's additional test compilers include: Visual C++ 7.1, 9.0, 10.0 ...
I see no MSVC 6.0 in this list. For me, it means that MSVC 6.0 is not supported.
-- Sergey Cheban
______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
On 16/07/2011 21:28, Joshua Boyce wrote:
Personally I think it should be more explicit. I quite like Qt's page on platform support, in that it's broken down into 'tiers' with an explanation of what each tier means in terms of support. Furthermore, it explicitly states that whilst compilers not listed may work, they should not be considered officially supported.
http://doc.qt.nokia.com/4.8-snapshot/supported-platforms.html
On Sun, Jul 17, 2011 at 5:36 AM, Sergey Cheban<s.cheban@drweb.com> wrote:
16.07.2011 1:00, Antony Polukhin пишет:
Are really old and broken compilers still supported? Do we need them?
For example VC++6.
In the 1.47 release notes, I see the following: Boost's primary test compilers are: Visual C++ 7.1, 9.0, 10.0 ... Boost's additional test compilers include: Visual C++ 7.1, 9.0, 10.0 ...
I see no MSVC 6.0 in this list. For me, it means that MSVC 6.0 is not supported.
Well, the problem is there can't be an one size fit all list as different libraries within boost work to different extent for different compilers. Also, the list of compilers on the release note merely reflect the different compilers used running the regression tests, and not that they will necessarily work without issues. KTC
On Jul 15, 2011, at 2:00 PM, Antony Polukhin wrote:
Are really old and broken compilers still supported? Do we need them?
Some targets are only supported by really old compilers, like Metrowerks C++ circa 2000 for 68K Mac OS. PowerPC gets only one upgrade further if you insist on self-hosting (i.e. building on the targeted platform) outside of the IDE (in a scriptable command shell). (Whether anyone should be targeting these platforms in the first place is an advocacy conversation I won't entertain here.)
May be we shall get rid of compilers, that do not support template partitial specialization, ADL or SFINAE?
There's no need to "get rid of" anything. I simply refrain from using Boost libraries requiring SFINAE in programs targeting these platforms. Frequently I'm better off using something less header- heavy anyway, due to the slow I/O during preprocessing and poor inlining of function templates. As for already-written libraries like shared_ptr, I expect that some breakage may occur between releases. All I ask is that my patches be considered, and either accepted or appropriately critiqued. In fact, this has already happened and I was more than satisfied with the process -- although I'd prefer to use Git next time. :-)
If not, shall we try to make the tests pass (or at least compile) for them?
I certainly don't expect anyone other than myself to test Boost with Metrowerks C++ 2.4.1. Josh
participants (15)
-
Antony Polukhin -
Bo Persson -
Christopher Jefferson -
Dave Abrahams -
Edward Diener -
James Mansion -
Joshua Boyce -
Joshua Juran -
KTC -
Lars Viklund -
Mathias Gaunard -
Nevin Liber -
Paul A. Bristow -
Sebastian Karlsson -
Sergey Cheban