Removing all support for Visual C++ 7.0, GCC 3.2 and other old compilers
Hello all, There has been some discussion on the development list about dropping all support for old C++ compilers. This will allow us to remove a lot of workarounds and simplify the code but before doing so it's a good idea to find out if anyone is still using them. Using boost with these compilers will cause a compile error in the config library (you can work round that using a custom configuration, but it's unlikely you'll be able to get much to work). The currently proposed versions for removing support are: Digital Mars 8.40 and earlier Visual C++ 7.0 and earlier GCC 3.2 and earlier Intel C++ 5.0 and earlier Which is, I think, a very cautious list. There's also a good chance that we might want to remove support for Borland C++ 5.x. Is there anyone still using those compilers? Just to be clear, this doesn't mean we'll be fully supporting all compilers later than these. Old compilers such as Visual C++ 7.1 and gcc 3.4 won't have a config error and we won't deliberately remove support, but support will be patchy. Many libraries (especially new ones) don't support those compilers, and we also don't have any formal testing for them, so if a new change breaks something, it might not be noticed. If you are still using compilers which are a little more recent than the ones listed above, it might still be worth mentioning in case we consider removing support for them in the future. Thanks in advance for any response, Daniel James
Daniel James wrote:
Hello all,
There has been some discussion on the development list about dropping all support for old C++ compilers. This will allow us to remove a lot of workarounds and simplify the code but before doing so it's a good idea to find out if anyone is still using them. Using boost with these compilers will cause a compile error in the config library (you can work round that using a custom configuration, but it's unlikely you'll be able to get much to work). The currently proposed versions for removing support are:
Digital Mars 8.40 and earlier Visual C++ 7.0 and earlier GCC 3.2 and earlier Intel C++ 5.0 and earlier
Which is, I think, a very cautious list. There's also a good chance that we might want to remove support for Borland C++ 5.x. Is there anyone still using those compilers?
Just to be clear, this doesn't mean we'll be fully supporting all compilers later than these. Old compilers such as Visual C++ 7.1 and gcc 3.4 won't have a config error and we won't deliberately remove support, but support will be patchy. Many libraries (especially new ones) don't support those compilers, and we also don't have any formal testing for them, so if a new change breaks something, it might not be noticed.
If you are still using compilers which are a little more recent than the ones listed above, it might still be worth mentioning in case we consider removing support for them in the future.
Thanks in advance for any response,
Hmmm - take for example the serialization library. Little by little over time, tweaks base on boost.config have been accumulated so they are all over the place. These tweaks depend on macros defined in boost config with something like "if compiler < borland 5.0" or something like that. Would all these "old macros" be eliminated? This of course would totally break compilation of the library on any platform. Is this the case? Who would fix all this? What advantage would it bring to anyone. Of course newer libraries don't support this - but boost has never required support of anything other the standard C++. Sorry, I don't think I'm understanding this. Robert Ramey
Daniel James
On Mon, 5 Aug 2013, at 11:56 PM, Robert Ramey wrote:
Hmmm - take for example the serialization library.
Little by little over time, tweaks base on boost.config have been accumulated so they are all over the place. These tweaks depend on macros defined in boost config with something like "if compiler < borland 5.0" or something like that. Would all these "old macros" be eliminated? This of course would totally break compilation of the library on any platform.
No, of course not. But that's off topic here, the development list thread would be the place to discuss implementation details. Which is why I didn't say anything about them.
On 05/08/2013 21:58, Daniel James wrote:
Hello all,
There has been some discussion on the development list about dropping all support for old C++ compilers. This will allow us to remove a lot of workarounds and simplify the code but before doing so it's a good idea to find out if anyone is still using them. Using boost with these compilers will cause a compile error in the config library (you can work round that using a custom configuration, but it's unlikely you'll be able to get much to work).
Good :)
The currently proposed versions for removing support are:
Digital Mars 8.40 and earlier Visual C++ 7.0 and earlier GCC 3.2 and earlier Intel C++ 5.0 and earlier
Intel is now 12 and gcc is 4.x, coudln't we reach a bit further on those ? ICC before 8 is rather obnoxious to work with and so is gcc pre 4.x
Whatever is to be done I would say it is important that it is documented which version is the last to support any particular compiler. I'm still dependant on Visual Studio 6 and I recall not finding it clearly stated which was the last version of Boost to support it. Appreciatively, Richard. -----Original Message-----
Hello all,
There has been some discussion on the development list about dropping all support for old C++ compilers. This will allow us to remove a lot of workarounds and simplify the code but before doing so it's a good idea to find out if anyone is still using them. Using boost with these compilers will cause a compile error in the config library (you can work round that using a custom configuration, but it's unlikely you'll be able to get much to work).
The currently proposed versions for removing support are:
Digital Mars 8.40 and earlier Visual C++ 7.0 and earlier GCC 3.2 and earlier Intel C++ 5.0 and earlier
On Tue, 6 Aug 2013, at 01:33 PM, Kerry, Richard wrote:
Whatever is to be done I would say it is important that it is documented which version is the last to support any particular compiler. I'm still dependant on Visual Studio 6 and I recall not finding it clearly stated which was the last version of Boost to support it.
That's a very good point. Visual Studio 6 was quite badly handled. I believe at some point config introduced some incompatible code. No one noticed for a couple of versions, so it isn't exactly clear when it happened. It would have been better if we'd had a better cut off point - and maybe even backported fixes to that version for people who use the compiler.
on Tue Aug 06 2013, Daniel James <daniel-AT-calamity.org.uk> wrote:
On Tue, 6 Aug 2013, at 01:33 PM, Kerry, Richard wrote:
Whatever is to be done I would say it is important that it is documented which version is the last to support any particular compiler. I'm still dependant on Visual Studio 6 and I recall not finding it clearly stated which was the last version of Boost to support it.
That's a very good point. Visual Studio 6 was quite badly handled. I believe at some point config introduced some incompatible code. No one noticed for a couple of versions, so it isn't exactly clear when it happened. It would have been better if we'd had a better cut off point - and maybe even backported fixes to that version for people who use the compiler.
There never was an official version of Boost-as-a-whole that supported VC6 (or any other compiler). Some libraries never supported that compiler. Others did. Eventually, volunteer testers for that platform disappeared and we stopped testing Boost with it altogether. -- Dave Abrahams
On Tue, 6 Aug 2013, at 01:14 PM, Joel Falcou wrote:
Intel is now 12 and gcc is 4.x, coudln't we reach a bit further on those ? ICC before 8 is rather obnoxious to work with and so is gcc pre 4.x
Possibly, that's why I mentioned that we might remove support from some later versions as well. I don't really know anything about old versions of Intel, but I would be surprised if anyone is using a version earlier than 8. I think there might still be a few Visual C++ 7.1 users and gcc 3.4 users (using mingw?). At least there was last year, maybe they'll have managed to upgrade by now. Rather than removing support for those compilers immediately, it might be better to go through some kind of deprecation process (e.g. warnings when compiling, mentions in release notes). Daniel
On 06/08/2013 13:35, Daniel James wrote:
On Tue, 6 Aug 2013, at 01:14 PM, Joel Falcou wrote:
Intel is now 12 and gcc is 4.x, coudln't we reach a bit further on those ? ICC before 8 is rather obnoxious to work with and so is gcc pre 4.x
Possibly, that's why I mentioned that we might remove support from some later versions as well. I don't really know anything about old versions of Intel, but I would be surprised if anyone is using a version earlier than 8. I think there might still be a few Visual C++ 7.1 users and gcc 3.4 users (using mingw?).
Visual 7 and gcc 3.4 soudns reasonable. Isn't Mingw now uptodate to 4.6 or 7 ?
At least there was last year, maybe they'll have managed to upgrade by now. Rather than removing support for those compilers immediately, it might be better to go through some kind of deprecation process (e.g. warnings when compiling, mentions in release notes).
Definitively.
On Tue, 6 Aug 2013, at 01:45 PM, Joel Falcou wrote:
On 06/08/2013 13:35, Daniel James wrote:
On Tue, 6 Aug 2013, at 01:14 PM, Joel Falcou wrote:
Intel is now 12 and gcc is 4.x, coudln't we reach a bit further on those ? ICC before 8 is rather obnoxious to work with and so is gcc pre 4.x
Possibly, that's why I mentioned that we might remove support from some later versions as well. I don't really know anything about old versions of Intel, but I would be surprised if anyone is using a version earlier than 8. I think there might still be a few Visual C++ 7.1 users and gcc 3.4 users (using mingw?).
Visual 7 and gcc 3.4 soudns reasonable. Isn't Mingw now uptodate to 4.6 or 7 ?
My mistake, I thought there was a mingw 3.4 tester last year, but checking the release notes it was actually for linux. FWIW I did have a 3.4 bug report about a year ago.
Intel is now 12 and gcc is 4.x, coudln't we reach a bit further on those ? ICC before 8 is rather obnoxious to work with and so is gcc pre 4.x
Even 13 for Intel! We stopped using Intel 9.1 a long time ago (4 years now), perhaps everything below 10 could be dropped. Cheers, Matthieu -- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher Music band: http://liliejay.com/
On 06/08/2013 13:42, Matthieu Brucher wrote:
Intel is now 12 and gcc is 4.x, coudln't we reach a bit further on those ? ICC before 8 is rather obnoxious to work with and so is gcc pre 4.x
Even 13 for Intel!
Oops of course !
We stopped using Intel 9.1 a long time ago (4 years now), perhaps everything below 10 could be dropped.
10 is maybe a bit optimistic. I remember people using the 9 inside MSVC6 in repalcement of cl.exe itself. Well, it's actually maybe a sign it should go also.
Daniel James wrote:
Hello all,
There has been some discussion on the development list about dropping all support for old C++ compilers. This will allow us to remove a lot of workarounds and simplify the code but before doing so it's a good idea to find out if anyone is still using them. Using boost with these compilers will cause a compile error in the config library (you can work round that using a custom configuration, but it's unlikely you'll be able to get much to work). The currently proposed versions for removing support are:
Digital Mars 8.40 and earlier Visual C++ 7.0 and earlier GCC 3.2 and earlier Intel C++ 5.0 and earlier
Which is, I think, a very cautious list. There's also a good chance that we might want to remove support for Borland C++ 5.x. Is there anyone still using those compilers?
Just to be clear, this doesn't mean we'll be fully supporting all compilers later than these. Old compilers such as Visual C++ 7.1 and gcc 3.4 won't have a config error and we won't deliberately remove support, but support will be patchy. Many libraries (especially new ones) don't support those compilers, and we also don't have any formal testing for them, so if a new change breaks something, it might not be noticed.
If you are still using compilers which are a little more recent than the ones listed above, it might still be worth mentioning in case we consider removing support for them in the future.
I am totally missing what this thread is about. a) boost config has macros which can be used to make library code conditional on which compiler is being used. b) some of those compilers are out of date and not widely used anymore. So what? Why is this a problem? New libraries don't support old compilers - the don't even check for these macros - so some macros are getting defined which aren't being referrerd to - so what? What is being proposed exactly? Just eliminating all these old macros from boost config would break any library which happens to check for them. So I presume that's not the plan. Drop Boost support for compiling with compiler X? What does that mean exactly. It has never been a requirement that any boost library support an particular compiler - Only that it be conformant with standard C++. If some library in addition to works with some old compiler X - so what? How can we "Drop Support" which we never had in the first place. As I said, I'm totally not getting what this is about. Robert Ramey
I am totally missing what this thread is about.
a) boost config has macros which can be used to make library code conditional on which compiler is being used. b) some of those compilers are out of date and not widely used anymore.
So what? Why is this a problem?
It's a maintenance effort, plus if we have a consensus to drop support for older compilers there are a lot of workarounds which are currently untested frankly, and which can be ripped out and code simplified.
New libraries don't support old compilers - the don't even check for these macros - so some macros are getting defined which aren't being referrerd to - so what?
What is being proposed exactly?
Just eliminating all these old macros from boost config would break any library which happens to check for them. So I presume that's not the plan.
Nothing will break by removing the macros from Boost.Config, they're only defined when the compiler is broken anyway, modern compilers don't define them. There are one or two helper macros such as BOOST_EXPLICIT_TEMPLATE_TYPE which will continue to be defined, but will be undocumented and will always be defined to the "conforming compiler" version.
Drop Boost support for compiling with compiler X?
What does that mean exactly. It has never been a requirement that any boost library support an particular compiler - Only that it be conformant with standard C++. If some library in addition to works with some old compiler X - so what? How can we "Drop Support" which we never had in the first place.
Well if Boost.Config drops support for compiler X, then in effect so does all of Boost. Not sure if that helps, John.
On 13-08-06 09:49 AM, Robert Ramey wrote:
Daniel James wrote:
Hello all,
There has been some discussion on the development list about dropping all support for old C++ compilers. This will allow us to remove a lot of workarounds and simplify the code but before doing so it's a good idea to find out if anyone is still using them. <snip> I am totally missing what this thread is about.
a) boost config has macros which can be used to make library code conditional on which compiler is being used. b) some of those compilers are out of date and not widely used anymore.
So what? Why is this a problem?
Because some libraries, to preserve the impression of being portable to these ancient compilers, pull in dependencies on other libraries that would be otherwise unnecessary. On the dev list, there is a specific example being discussed. Shuffle over there if you want to understand the issue in detail. -- Eric Niebler Boost.org
participants (8)
-
Daniel James -
Dave Abrahams -
Eric Niebler -
Joel Falcou -
John Maddock -
Kerry, Richard -
Matthieu Brucher -
Robert Ramey