Removing support for old compilers
Hi Stephen As part of your initiative of removing support for old compilers, are you building somewhere a change log in the form of either a list of compiler deficiencies or compiler versions no longer supported? I understand this should be inserted in a prominent place on the Boost 1.56 release notes and can serve as a reference for lib maintainers reviewing your patches (tracking changesets is harder and commit messages are not always completely illuminating). Thank you, Joaquín M López Muñoz Telefónica Digital
On 10/12/2013 10:13 PM, Joaquin M Lopez Munoz wrote:
Hi Stephen
As part of your initiative of removing support for old compilers, are you building somewhere a change log in the form of either a list of compiler deficiencies or compiler versions no longer supported?
I have not built such a thing, but it's easy to create by reading the recent log of boost/config. Where should it be and what should it say?
I understand this should be inserted in a prominent place on the Boost 1.56 release notes and can serve as a reference for lib maintainers reviewing your patches (tracking changesets is harder and commit messages are not always completely illuminating).
Is there anything in particular I can shed light on? Thanks, Steve.
Stephen Kelly <steveire <at> gmail.com> writes:
On 10/12/2013 10:13 PM, Joaquin M Lopez Munoz wrote:
Hi Stephen
As part of your initiative of removing support for old compilers, are you building somewhere a change log in the form of either a list of compiler deficiencies or compiler versions no longer supported?
I have not built such a thing, but it's easy to create by reading the recent log of boost/config.
Not obvious to me: the message log for your changes at boost/config reads * Remove remaining occurances of BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION These evaded scripting. * Require compiler support for partial template specialization. Remove support for the mac programmers workshop entirely. Bump the sunpro requirement to version 5.4. Version 5.3 seems to have had some bugs with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, so bump above that in the abundance of caution. This allows the removal of lots of workaround code: src/boost-trunk{master}$ ../kf5/remove_def.py BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION src/boost-trunk{master}$ git diff --shortstat 192 files changed, 4798 deletions(-) * Remove obsolete MSVC check from pragma guard git grep -h -B1 "^#\s*pragma once" | grep -v pragma | sort | uniq is now clean. * Config: Remove obsolete MSVC version check Frankly, it is hard to know what's going on by looking at this log alone. In particular, nowhere's stated which versions of MSVC have been dropped (I understand 6.0 and 7.0, but the log does not say it), and one has to investigate in order to find out what other compilers are effecively dropped as a consequence of TPS being required (the log mentions MPW and SunPro 5.3, but I guess Digital Mars and GCC 2.x are also affected, don't know about Borland, and maybe there are others as well). I have also the suspicion that along the way you have removed macros and workarounds not directly related to TPS or MSVC 6.0/7.0.
Where should it be and what should it say?
As for the form of the doc, something like this would be IMHO fine: * New minimal requirements on compilers/environments suported by Boost 1.56 - Template partial specialization support · Deleted BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION and [etc] from Boost.Config - [Additional new requirements, SFINAE for instance] · [Resulting changes in Boost.Config (macros removed and so on)] * Compilers dropped starting in Boost 1.56 - MSVC 7.0 and prior · [Boost.Config facilities removed as a consequencce] - GCC 2.x · [Boost.Config facilities removed as a consequencce] - [etc] * List of Boost libs directly modified [useful as a heads up for maintainers wishing to review your changes] As for where to put it, the final destination would be https://svn.boost.org/svn/boost/website/public_html/live/feed/history/ file boost_1_56_0.qbk although this file has not been created yet. You can either ask for the file to be created or, in the meantime, publish your log somewhere for easy reference and public access. Some other things that'd help: * Consider adding some [xxx] subject tag in your communications to the mailing list so that users and maintainers can easily track them (for instance, [compiler support]) * Allow for some time for people to express support/dissent on proposed removals before going ahead, and notify the list when a change is effective. It is important that a proposed change comes with a list of compilers affected (users don't necessarily know whether some compiler X they care about does support, say, TPS, so we need to make sure this is clear to everybody potentially affected.) * With all due respect, I think you are being a little too aggresive at executing this. Removal of compiler support is a sensitive issue and sure enough we won't get unanimous consensus, but some form of general agreement should be reached, and time be given for awareness and discussion. That said, some assertiveness will be needed at the end of the day: it's a matter of finding the right balance and not going overboard with changes that could potentially harm existing Boost users. Joaquín M López Muñoz Telefónica Digital
On 10/13/2013 12:11 PM, Joaquin M Lopez Munoz wrote:
Stephen Kelly <steveire <at> gmail.com> writes:
On 10/12/2013 10:13 PM, Joaquin M Lopez Munoz wrote:
Hi Stephen
As part of your initiative of removing support for old compilers, are you building somewhere a change log in the form of either a list of compiler deficiencies or compiler versions no longer supported? I have not built such a thing, but it's easy to create by reading the recent log of boost/config. Not obvious to me: the message log for your changes at boost/config reads
* Remove remaining occurances of BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION These evaded scripting. * Require compiler support for partial template specialization. Remove support for the mac programmers workshop entirely. Bump the sunpro requirement to version 5.4. Version 5.3 seems to have had some bugs with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, so bump above that in the abundance of caution. This allows the removal of lots of workaround code:
src/boost-trunk{master}$ ../kf5/remove_def.py BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION src/boost-trunk{master}$ git diff --shortstat 192 files changed, 4798 deletions(-) * Remove obsolete MSVC check from pragma guard git grep -h -B1 "^#\s*pragma once" | grep -v pragma | sort | uniq is now clean. * Config: Remove obsolete MSVC version check
Frankly, it is hard to know what's going on by looking at this log alone. In particular, nowhere's stated which versions of MSVC have been dropped (I understand 6.0 and 7.0, but the log does not say it),
That was done in this commit actually: https://svn.boost.org/trac/boost/changeset/85272 That commit message doesn't specify the compiler versions affected either though, indeed.
and one has to investigate in order to find out what other compilers are effecively dropped as a consequence of TPS being required (the log mentions MPW and SunPro 5.3, but I guess Digital Mars and GCC 2.x are also affected,
Only the config/compiler files for MPW and SunPro are affected by this commit. The DigitalMars one didn't define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, nor did it do so before revision 85272, so if it needed the macro, it was already broken. GCC 2.x is already no-longer-supported since revision 85272.
don't know about Borland,
It didn't define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, nor did it do so before revision 85272, so if it needed the macro, it was already broken.
and maybe there are others as well).
If they didn't define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, they were already broken.
I have also the suspicion that along the way you have removed macros and workarounds not directly related to TPS or MSVC 6.0/7.0.
Can you be more specific?
Where should it be and what should it say? As for the form of the doc, something like this would be IMHO fine:
* New minimal requirements on compilers/environments suported by Boost 1.56 - Template partial specialization support · Deleted BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION and [etc] from Boost.Config - [Additional new requirements, SFINAE for instance] · [Resulting changes in Boost.Config (macros removed and so on)] * Compilers dropped starting in Boost 1.56 - MSVC 7.0 and prior · [Boost.Config facilities removed as a consequencce] - GCC 2.x · [Boost.Config facilities removed as a consequencce] - [etc] * List of Boost libs directly modified [useful as a heads up for maintainers wishing to review your changes]
Looks good to me. I'll look into creating it.
Some other things that'd help:
* Consider adding some [xxx] subject tag in your communications to the mailing list so that users and maintainers can easily track them (for instance, [compiler support])
I'll never understand why people want '[compiler support]' prefixing a message titled 'Removing support for old compilers' (both keywords are there) or 'Bumping borland, SunPro, mwerks and MPW compiler requirements' (MPW is more-specific than 'compiler support', so if someone cares about MPW, that's what they'll notice). Anyway, noted. I can't guarantee I'll remember or be able to force myself to do it though.
* Allow for some time for people to express support/dissent on proposed removals before going ahead, and notify the list when a change is effective. It is important that a proposed change comes with a list of compilers affected (users don't necessarily know whether some compiler X they care about does support, say, TPS, so we need to make sure this is clear to everybody potentially affected.) * With all due respect, I think you are being a little too aggresive at executing this. Removal of compiler support is a sensitive issue and sure enough we won't get unanimous consensus, but some form of general agreement should be reached, and time be given for awareness and discussion. That said, some assertiveness will be needed at the end of the day: it's a matter of finding the right balance and not going overboard with changes that could potentially harm existing Boost users.
Ok, noted. Thanks for the feedback. Steve.
Stephen Kelly <steveire <at> gmail.com> writes:
On 10/13/2013 12:11 PM, Joaquin M Lopez Munoz wrote:
Stephen Kelly <steveire <at> gmail.com> writes:
On 10/12/2013 10:13 PM, Joaquin M Lopez Munoz wrote:
Hi Stephen
As part of your initiative of removing support for old compilers, are you building somewhere a change log in the form of either a list of compiler deficiencies or compiler versions no longer supported? I have not built such a thing, but it's easy to create by reading the recent log of boost/config. [...] Frankly, it is hard to know what's going on by looking at this log alone. In particular, nowhere's stated which versions of MSVC have been dropped (I understand 6.0 and 7.0, but the log does not say it),
That was done in this commit actually:
https://svn.boost.org/trac/boost/changeset/85272
That commit message doesn't specify the compiler versions affected either though, indeed.
You want this info to be spoken out oud and easily accessible; now it is hidden deep into one of your many recent commits (worse yet, 85275 was commited on your behalf by Daniel, so looking for skelly is not guaranteed to catch every relevant commit.) Considering that authors and, particularly, users do not customarily scan Boost commits at svn.boost.org, chances are the majority of affected people won't notice until Boost 1.56.
and one has to investigate in order to find out what other compilers are effecively dropped as a consequence of TPS being required (the log mentions MPW and SunPro 5.3, but I guess Digital Mars and GCC 2.x are also affected,
Only the config/compiler files for MPW and SunPro are affected by this commit.
Which are not listed in changeset 85272. Are there other compilers affected?
The DigitalMars one didn't define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, nor did it do so before revision 85272, so if it needed the macro, it was already broken.
But at least one of your commits is related to Digital Mars: https://svn.boost.org/trac/boost/changeset/86043
I have also the suspicion that along the way you have removed macros and workarounds not directly related to TPS or MSVC 6.0/7.0.
Can you be more specific?
Changeset 86043 was the one smelly commit I spotted.
* Consider adding some [xxx] subject tag in your communications to the mailing list so that users and maintainers can easily track them (for instance, [compiler support])
I'll never understand why people want '[compiler support]' prefixing a message titled 'Removing support for old compilers' (both keywords are there) or 'Bumping borland, SunPro, mwerks and MPW compiler requirements' (MPW is more-specific than 'compiler support', so if someone cares about MPW, that's what they'll notice).
Prefixing, which is regularly used in Boost mailing lists, allows people interested in a particular initiative to easily filter and track related messages. Now, if I want to consult the prior discussions on your efforts I have to look for your name and filter out not related stuff. Thank you, Joaquín M López Muñoz Telefónica Digital
On 13 October 2013 13:30, Joaquin M Lopez Munoz <joaquin@tid.es> wrote:
You want this info to be spoken out oud and easily accessible; now it is hidden deep into one of your many recent commits (worse yet, 85275 was commited on your behalf by Daniel, so looking for skelly is not guaranteed to catch every relevant commit.)
Oh sorry. Although I wrote up the changes in the new release notes: http://www.boost.org/users/history/version_1_55_0.html
Daniel James <daniel <at> calamity.org.uk> writes:
On 13 October 2013 13:30, Joaquin M Lopez Munoz <joaquin <at> tid.es> wrote:
You want this info to be spoken out oud and easily accessible; now it is hidden deep into one of your many recent commits (worse yet, 85275 was commited on your behalf by Daniel, so looking for skelly is not guaranteed to catch every relevant commit.)
Oh sorry. Although I wrote up the changes in the new release notes:
Oh, then I'm missing the context. Does this mean that compiler drop is effective with Boost 1.55 and Stpehen is just leveraging this in Boost 1.56 to clean up code? Joaquín M López Muñoz Telefónica Digital
On 13 October 2013 13:49, Joaquin M Lopez Munoz <joaquin@tid.es> wrote:
Daniel James <daniel <at> calamity.org.uk> writes:
On 13 October 2013 13:30, Joaquin M Lopez Munoz <joaquin <at> tid.es> wrote:
You want this info to be spoken out oud and easily accessible; now it is hidden deep into one of your many recent commits (worse yet, 85275 was commited on your behalf by Daniel, so looking for skelly is not guaranteed to catch every relevant commit.)
Oh sorry. Although I wrote up the changes in the new release notes:
Oh, then I'm missing the context. Does this mean that compiler drop is effective with Boost 1.55 and Stpehen is just leveraging this in Boost 1.56 to clean up code?
Only the changes that that I committed to config will be included in boost 1.55. They're the ones I listed on the release notes ("new minimum compiler requirements"). The "candidates for removal" are the changes Stephen is making now, which I'd rather waited until after the release. If the release notes aren't clear, please suggest how they could be changed.
Daniel James <daniel <at> calamity.org.uk> writes:
On 13 October 2013 13:49, Joaquin M Lopez Munoz <joaquin <at> tid.es> wrote:
Daniel James <daniel <at> calamity.org.uk> writes:
Oh sorry. Although I wrote up the changes in the new release notes:
Oh, then I'm missing the context. Does this mean that compiler drop is effective with Boost 1.55 and Stpehen is just leveraging this in Boost 1.56 to clean up code?
Only the changes that that I committed to config will be included in boost 1.55. They're the ones I listed on the release notes ("new minimum compiler requirements"). The "candidates for removal" are the changes Stephen is making now, which I'd rather waited until after the release. If the release notes aren't clear, please suggest how they could be changed.
OK, the situation wrt to Boost 1.55 is perfectly clear then, thank you. As for the changes made by Stephen, I *think* he's following two different tracks: * Cleaning up lib code taking into account the new minimum requirements on compilers supported (for instance, removing workarounds for lack of TPS, etc.) * Proposing additional compilers for removal or going about removing those announced for removal consideration for in the Boost 1.55 release notes. Joaquín M López Muñoz Telefónica Digital
On 10/13/2013 02:30 PM, Joaquin M Lopez Munoz wrote:
Stephen Kelly <steveire <at> gmail.com> writes:
That was done in this commit actually:
https://svn.boost.org/trac/boost/changeset/85272
That commit message doesn't specify the compiler versions affected either though, indeed.
You want this info to be spoken out oud and easily accessible; now it is hidden deep into one of your many recent commits (worse yet, 85275 was commited on your behalf by Daniel, so looking for skelly is not guaranteed to catch every relevant commit.)
My changes amount to removal of definitions of some macros in boost/config, followed by removal of newly-dead code. The log in boost/config is most relevant to what you seem to be looking for. There are very few changes there recently. I recommend using git-svn and `gitk boost/config`. I must confess I'm surprised at how few people on this list use git-svn. No one I know who has reached a certain familiarity with git would always use it over raw svn. Have you ever used git? I wonder will the git migration be beneficial/painful for this community. Or are you speaking for users, and not for yourself (I'm reading below)? I suppose you must be speaking for yourself as you talk about inadequate commit messages... My best advice to you is to use git-svn and gitk.
Considering that authors and, particularly, users do not customarily scan Boost commits at svn.boost.org, chances are the majority of affected people won't notice until Boost 1.56.
Ideas for improving that are welcome. Do you have any ideas? What about keeping http://www.boost.org/users/news/old_compilers.html up to date with the changes/bumps?
and one has to investigate in order to find out what other compilers are effecively dropped as a consequence of TPS being required (the log mentions MPW and SunPro 5.3, but I guess Digital Mars and GCC 2.x are also affected, Only the config/compiler files for MPW and SunPro are affected by this commit. Which are not listed in changeset 85272.
You don't understand. Maybe I was not clear enough. Let me try again: Only the config/compiler files for MPW and SunPro are affected by revision 86241. In that context, your comment about revision 85272 makes no sense. Do you understand now?
Are there other compilers affected?
This also makes no sense with the (hopefully?) clarity above. I answered this in the grandparent mail.
The DigitalMars one didn't define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, nor did it do so before revision 85272, so if it needed the macro, it was already broken. But at least one of your commits is related to Digital Mars:
What does one of my commits being related to Digital Mars have to do with revision 85272 or BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION? Please don't change the point of what we're discussing mid-thread. It's not fair to move the goalposts like that. Revision 86043 is not different to the commits which affected MSVC or GCC. I simplified a preprocessor condition for a compiler which has been marked as obsolete.
I have also the suspicion that along the way you have removed macros and workarounds not directly related to TPS or MSVC 6.0/7.0. Can you be more specific? Changeset 86043 was the one smelly commit I spotted.
It is not smelly. __DMC__ >= 0x810 is always true as of revision 85272.
* Consider adding some [xxx] subject tag in your communications to the mailing list so that users and maintainers can easily track them (for instance, [compiler support]) I'll never understand why people want '[compiler support]' prefixing a message titled 'Removing support for old compilers' (both keywords are there) or 'Bumping borland, SunPro, mwerks and MPW compiler requirements' (MPW is more-specific than 'compiler support', so if someone cares about MPW, that's what they'll notice). Prefixing, which is regularly used in Boost mailing lists, allows people interested in a particular initiative to easily filter and track related messages. Now, if I want to consult the prior discussions on your efforts I have to look for your name and filter out not related stuff.
Filtering for my name is enough. You can consider the [compiler support]/[modularization] implied on all messages from me. Thanks, Steve.
Stephen Kelly wrote:
My changes amount to removal of definitions of some macros in boost/config, followed by removal of newly-dead code.
That's not quite true, Stephen. Here are a few examples of changes that do not remove any dead code: -#if defined(BOOST_NO_TEMPLATED_IOSTREAMS) || ( defined(__GNUC__) && (__GNUC__ < 3) ) +#if ( defined(__GNUC__) && (__GNUC__ < 3) ) -- -#elif defined( _MSC_VER ) && _MSC_VER >= 1310 +#elif defined( _MSC_VER ) -- -#if defined(_MSC_VER) && _MSC_VER >= 1310 && ( defined(_M_IX86) || defined(_M_X64) ) +#if defined(_MSC_VER) && ( defined(_M_IX86) || defined(_M_X64) ) -- -#if !defined( BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION ) ... -#endif -- -#if !defined( BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION ) && !defined( BOOST_NO_SFINAE ) +#if !defined( BOOST_NO_SFINAE ) Now, you'd say that in some of these cases, this is just the first step of a process that will eventually result in the removal of dead code. Maybe so. But in the meantime, we're left with an #ifdef that makes much less sense than the original, which was generally self-documenting. When I see #if defined(BOOST_NO_TEMPLATED_IOSTREAMS) || ( defined(__GNUC__) && (__GNUC__ < 3) ) I know that the following is a workaround for the lack of templated iostreams, and that for some (admittedly lost in time) reason, g++ 2.x lacks templated iostreams but does not define the config macro. Without the first portion, this information is no longer present. Few people would object to actual removal of dead code sections such as #if defined(THIS) || defined(THAT) ... #endif when we know that neither THIS nor THAT will ever be defined (there are some rare exceptions to that). Fiddling with the ifdef conditions is another story.
On 10/13/2013 09:52 PM, Peter Dimov wrote:
Stephen Kelly wrote:
My changes amount to removal of definitions of some macros in boost/config, followed by removal of newly-dead code.
That's not quite true, Stephen.
Here are a few examples of changes that do not remove any dead code:
-#if defined(BOOST_NO_TEMPLATED_IOSTREAMS) || ( defined(__GNUC__) && (__GNUC__ < 3) ) +#if ( defined(__GNUC__) && (__GNUC__ < 3) )
--
-#elif defined( _MSC_VER ) && _MSC_VER >= 1310 +#elif defined( _MSC_VER )
--
-#if defined(_MSC_VER) && _MSC_VER >= 1310 && ( defined(_M_IX86) || defined(_M_X64) ) +#if defined(_MSC_VER) && ( defined(_M_IX86) || defined(_M_X64) )
--
-#if !defined( BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION ) ... -#endif
--
-#if !defined( BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION ) && !defined( BOOST_NO_SFINAE ) +#if !defined( BOOST_NO_SFINAE )
I consider all of the above to be dead code removal. It's ok that you don't see it the same way.
Now, you'd say that in some of these cases, this is just the first step of a process that will eventually result in the removal of dead code. Maybe so. But in the meantime, we're left with an #ifdef that makes much less sense than the original, which was generally self-documenting.
We also have a revision control system.
When I see
#if defined(BOOST_NO_TEMPLATED_IOSTREAMS) || ( defined(__GNUC__) && (__GNUC__ < 3) )
I know that the following is a workaround for the lack of templated iostreams, and that for some (admittedly lost in time) reason, g++ 2.x lacks templated iostreams but does not define the config macro. Without the first portion, this information is no longer present.
... in the source code. It is still in the revision control system, which has logs which are file-specific and a 'blame' feature which is line-specific.
Few people would object to actual removal of dead code sections such as
#if defined(THIS) || defined(THAT)
...
#endif
when we know that neither THIS nor THAT will ever be defined (there are some rare exceptions to that). Fiddling with the ifdef conditions is another story.
I just don't agree with your mail. Thanks, Steve.
Le 13/10/13 22:06, Stephen Kelly a écrit :
On 10/13/2013 09:52 PM, Peter Dimov wrote:
Stephen Kelly wrote:
My changes amount to removal of definitions of some macros in boost/config, followed by removal of newly-dead code. That's not quite true, Stephen.
Here are a few examples of changes that do not remove any dead code:
-#if defined(BOOST_NO_TEMPLATED_IOSTREAMS) || ( defined(__GNUC__) && (__GNUC__ < 3) ) +#if ( defined(__GNUC__) && (__GNUC__ < 3) )
--
-#elif defined( _MSC_VER ) && _MSC_VER >= 1310 +#elif defined( _MSC_VER )
--
-#if defined(_MSC_VER) && _MSC_VER >= 1310 && ( defined(_M_IX86) || defined(_M_X64) ) +#if defined(_MSC_VER) && ( defined(_M_IX86) || defined(_M_X64) )
--
-#if !defined( BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION ) ... -#endif
--
-#if !defined( BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION ) && !defined( BOOST_NO_SFINAE ) +#if !defined( BOOST_NO_SFINAE )
I consider all of the above to be dead code removal. It's ok that you don't see it the same way.
Now, you'd say that in some of these cases, this is just the first step of a process that will eventually result in the removal of dead code. Maybe so. But in the meantime, we're left with an #ifdef that makes much less sense than the original, which was generally self-documenting. We also have a revision control system.
When I see
#if defined(BOOST_NO_TEMPLATED_IOSTREAMS) || ( defined(__GNUC__) && (__GNUC__ < 3) )
I know that the following is a workaround for the lack of templated iostreams, and that for some (admittedly lost in time) reason, g++ 2.x lacks templated iostreams but does not define the config macro. Without the first portion, this information is no longer present. ... in the source code. It is still in the revision control system, which has logs which are file-specific and a 'blame' feature which is line-specific.
Few people would object to actual removal of dead code sections such as
#if defined(THIS) || defined(THAT)
...
#endif
when we know that neither THIS nor THAT will ever be defined (there are some rare exceptions to that). Fiddling with the ifdef conditions is another story. I just don't agree with your mail.
Steve, you don't agree with some of the authors/maintainer of the libraries you are modifying. Take in account that, at the end, it is up to the authors to maintain their code. I see your modifications quite intrusive and I would prefer that you fill Trac tickets for each library as Andrey suggested. This is the way we are working today and changing it merits some previous discussion. Please don't commit anything for Boost.Ratio/Chrono/Thread. Best, Vicente
#if defined(BOOST_NO_TEMPLATED_IOSTREAMS) || ( defined(__GNUC__) && (__GNUC__ < 3) )
I know that the following is a workaround for the lack of templated iostreams, and that for some (admittedly lost in time) reason, g++ 2.x lacks templated iostreams but does not define the config macro. Without the first portion, this information is no longer present.
... in the source code. It is still in the revision control system, which has logs which are file-specific and a 'blame' feature which is line-specific.
No I'm sorry, that doesn't cut it, code should be self documenting, users should have to resort to delving into some revision control system to figure this out. John.
Stephen Kelly <steveire <at> gmail.com> writes:
On 10/13/2013 02:30 PM, Joaquin M Lopez Munoz wrote:
Considering that authors and, particularly, users do not customarily scan Boost commits at svn.boost.org, chances are the majority of affected people won't notice until Boost 1.56.
Ideas for improving that are welcome. Do you have any ideas? What about keeping
http://www.boost.org/users/news/old_compilers.html
up to date with the changes/bumps?
Yes, I think this is a very appropriate place to provide information on the progress of the initiative.
and one has to investigate in order to find out what other compilers are effecively dropped as a consequence of TPS being required (the log mentions MPW and SunPro 5.3, but I guess Digital Mars and GCC 2.x are also affected, Only the config/compiler files for MPW and SunPro are affected by this commit. Which are not listed in changeset 85272.
You don't understand. Maybe I was not clear enough. Let me try again:
Only the config/compiler files for MPW and SunPro are affected by revision 86241.
In that context, your comment about revision 85272 makes no sense.
Do you understand now?
No (this is a candid no.) What I'm not getting is the point of your whole activity. After reviewing the discussions and your commits, I understand that there are two (more or less unrelated) tracks here: 1. Once changeset 85272 is commited and official news given about Digital Mars<8.41, GCC<3.3, Intel<6.0 and Visual C++<7.1 being no longer supported (Boost 1.55), eliminate obsolete code checking for these compilers or for defects no additional supported compiler has. 2. Require TPS support, which implies dropping more compilers than announced in the previous track, namely MPW and SunPro<5.4. Is this an accurate description of what you're doing? If so, I'd say going forward with #1 is not controcersial but #2 necessitates that some discussion happens so as to reach an agreement about what to do (probably dropping MPW and SunPro<5.4 is perfectly fine, but they're still officialy supported.) Look, in case I finally got it right after spending like a couple of hours looking into that, consider that many other readers without the time to do similarly might not have a clue yet: this is why I'm asking for more clarity, mail subject tagging, a prominent log page, etc.
* Consider adding some [xxx] subject tag in your communications to the mailing list so that users and maintainers can easily track them (for instance, [compiler support]) I'll never understand why people want '[compiler support]' prefixing a message titled 'Removing support for old compilers' (both keywords are there) or 'Bumping borland, SunPro, mwerks and MPW compiler requirements' (MPW is more-specific than 'compiler support', so if someone cares about MPW, that's what they'll notice). Prefixing, which is regularly used in Boost mailing lists, allows people interested in a particular initiative to easily filter and track related messages. Now, if I want to consult the prior discussions on your efforts I have to look for your name and filter out not related stuff.
Filtering for my name is enough. You can consider the [compiler support]/[modularization] implied on all messages from me.
That's OK with me, but not with the rest of the community who hasn't necessarily followed our discussion thread down to this point and still don't know about the [compiler support]<->skelly equivalence. Seriously, please make everybody and yourself a favor and strive for the greatest clarity in your communications. Thank you, and thank you for initiating this activity which, despite discussions around execution, is sorely needed. Joaquín M López Muñoz Telefónica Digital
On 14 October 2013 07:23, Joaquin M Lopez Munoz <joaquin@tid.es> wrote:
Stephen Kelly <steveire <at> gmail.com> writes:
On 10/13/2013 02:30 PM, Joaquin M Lopez Munoz wrote:
Considering that authors and, particularly, users do not customarily scan Boost commits at svn.boost.org, chances are the majority of affected people won't notice until Boost 1.56.
Ideas for improving that are welcome. Do you have any ideas? What about keeping
http://www.boost.org/users/news/old_compilers.html
up to date with the changes/bumps?
Yes, I think this is a very appropriate place to provide information on the progress of the initiative.
That particular page isn't, as it's a news story that will get bumped off the front page as others are written. People who use a feed reader probably won't see the updates. I realise the design could be clearer. The news feature of the site hasn't been used much, so not much work has gone into it. Probably should create a new story for further updates. Maybe it'd be worth hacking categories into it.
* Consider adding some [xxx] subject tag in your communications to the mailing list so that users and maintainers can easily track them (for instance, [compiler support])
I'll never understand why people want '[compiler support]' prefixing a message titled 'Removing support for old compilers' (both keywords are there) or 'Bumping borland, SunPro, mwerks and MPW compiler requirements' (MPW is more-specific than 'compiler support', so if someone cares about MPW, that's what they'll notice).
The Boost Developers mailing list is high-volume, and many people just scan the subject lines for bracketed keywords that are relevant to them. It's easier to scan for bracketed keywords than to read entire subject lines. The overhead for you to add the keyword is negligible, so I really don't see any reason not to do it. Regards, Nate
I realize that I've asked this before - but I never got a response which I found convincing. I'll try to ask my question better this time. The question - What is the value of undertaking this task. Let's look at the value of according to the type of boost participant. a) boost user - all this code in config and the libraries is internal to the libraries. After this change the look and usage of boost will not change at all. - no benefit and no cost to the boost user. b) author of a new library - this person can set the requirements to what ever he wants subject to the constaint that the code compile and work on any comforming C++ implementation. That is, there has never been a requirement to support non-conforming or older compilers. This won't change. Only authors who want to support an older compiler would be affected. It's safe to say there aren't many authors in this category. so no benefit and no cost to authors of new libraries. c) boost users on older platforms. They are to be stuck with the boost 1.54. I don't know how big this group is but I'm sure it has some members. A big loss for this (probably small) group as they won't benefit from things like bug fixes and enhancements. d) maintainers of boost libraries. When I first raised this question, I was assured that it would be totally transparent to me and that I would not have to be concerned about it. Hmmm - well OK - as long I don't have to wade in and muck around with ten year old code - (don't even think about addressing any changes which make old data sets unreadable). My worst nightmare is having to go back and re-debug 20 thousand lines of code running on 10 different compilers. Recent postings have made me doubt that one can really undertake this and guarentee that I won't have to do this. Soooooo - bottom line: No benefit to any boost participant Definite costs to some boost users. Possible big problems for library maintainers. So how can this be worth doing? If one sees real value in this - how about creating this on a branch or a fork. Robert Ramey
On Mon, Oct 14, 2013 at 8:20 PM, Robert Ramey <ramey@rrsd.com> wrote:
I realize that I've asked this before - but I never got a response which I found convincing. I'll try to ask my question better this time.
The question - What is the value of undertaking this task.
Let's look at the value of according to the type of boost participant.
a) boost user - all this code in config and the libraries is internal to the libraries. After this change the look and usage of boost will not change at all. - no benefit and no cost to the boost user.
Not quite true. Boost.Config is a library as any other, its macros are documented. I use these macros in projects outside Boost where I need portability across different compilers. I don't really care about the compilers we're dropping now, so the changes proposed so far don't affect me. But it doesn't mean it doesn't affect any other users.
d) maintainers of boost libraries. When I first raised this question, I was assured that it would be totally transparent to me and that I would not have to be concerned about it. Hmmm - well OK - as long I don't have to wade in and muck around with ten year old code - (don't even think about addressing any changes which make old data sets unreadable). My worst nightmare is having to go back and re-debug 20 thousand lines of code running on 10 different compilers. Recent postings have made me doubt that one can really undertake this and guarentee that I won't have to do this.
I didn't really understand your point here. Do you intend to support the old compilers, even if Boost in general drops them? Because otherwise I don't see how it affects you - the tests will be running on modern compilers as they did before. My understanding is that the most immediate benefit is exactly for Boost library maintainers. Dropping support for ancient compilers simplifies code (Boost.Config included), makes it more easily maintainable.
Andrey Semashev wrote:
On Mon, Oct 14, 2013 at 8:20 PM, Robert Ramey <ramey@rrsd.com> wrote:
a) boost user - all this code in config and the libraries is internal to the libraries. After this change the look and usage of boost will not change at all. - no benefit and no cost to the boost user.
Not quite true. Boost.Config is a library as any other, its macros are documented. I use these macros in projects outside Boost where I need portability across different compilers. I don't really care about the compilers we're dropping now, so the changes proposed so far don't affect me. But it doesn't mean it doesn't affect any other users.
OK - I'll amend the statement above - to say no cost to most boost users. Definite cost to boost users who use boost config to handle variations on a wide variety of compilers.
d) maintainers of boost libraries. When I first raised this question, I was assured that it would be totally transparent to me and that I would not have to be concerned about it. Hmmm - well OK - as long I don't have to wade in and muck around with ten year old code - (don't even think about addressing any changes which make old data sets unreadable). My worst nightmare is having to go back and re-debug 20 thousand lines of code running on 10 different compilers. Recent postings have made me doubt that one can really undertake this and guarentee that I won't have to do this.
I didn't really understand your point here. Do you intend to support the old compilers, even if Boost in general drops them?
I don't intend to specifically support old compilers - I don't intend to drop support for them either as it's already in there. Actually I don't intend to do any work on the serialization library that doesn't add functionality. It looks like that if this goes through, I'll have to to go back and re-debug the library to support a decrease of functionallity - not something I can justify the investment of time in - not to say that's it's no fun at all.
Because otherwise I don't see how it affects you - the tests will be running on modern compilers as they did before.
If that's the case - no problem. But I can't see how a change like this can be made without causing breakage that I will have to spend time tracking down.
My understanding is that the most immediate benefit is exactly for Boost library maintainers. Dropping support for ancient compilers simplifies code (Boost.Config included), makes it more easily maintainable.
on NEW libraries - but it has the potential of creating huge amount of unpleasant work for older libraries. - with not net benefit to anyone. Robert Ramey
On Mon, Oct 14, 2013 at 9:40 PM, Robert Ramey <ramey@rrsd.com> wrote:
Andrey Semashev wrote:
d) maintainers of boost libraries. When I first raised this question, I was assured that it would be totally transparent to me and that I would not have to be concerned about it. Hmmm - well OK - as long I don't have to wade in and muck around with ten year old code - (don't even think about addressing any changes which make old data sets unreadable). My worst nightmare is having to go back and re-debug 20 thousand lines of code running on 10 different compilers. Recent postings have made me doubt that one can really undertake this and guarentee that I won't have to do this.
I didn't really understand your point here. Do you intend to support the old compilers, even if Boost in general drops them?
I don't intend to specifically support old compilers - I don't intend to drop support for them either as it's already in there.
These are exclusive statements. Unless you regularly test your library on old compilers, the library can already be not working with them. This may be due to some fix/improvement/feature in the library, or to some change in a dependent library. Note that the compilers we're dropping are not tested by any of the testers, so you would have to run the tests yourself.
Actually I don't intend to do any work on the serialization library that doesn't add functionality. It looks like that if this goes through, I'll have to to go back and re-debug the library to support a decrease of functionallity - not something I can justify the investment of time in - not to say that's it's no fun at all.
Sorry, but I still don't understand. No one is removing any functionality, only the workarounds needed to make the library work on some broken compiler. Why would you need to spend time ensuring that the library no longer works on that compiler when the workarounds are removed?
My understanding is that the most immediate benefit is exactly for Boost library maintainers. Dropping support for ancient compilers simplifies code (Boost.Config included), makes it more easily maintainable.
on NEW libraries - but it has the potential of creating huge amount of unpleasant work for older libraries. - with not net benefit to anyone.
I was specifically referring to the current (and more likely, older) libraries in Boost, not the new ones. It is implied that the new libraries have no such issue.
Andrey Semashev wrote:
Why would you need to spend time ensuring that the library no longer works on that compiler when the workarounds are removed?
I don't do this and I wont do this. It seems to me that this has huge potential to break libararies on newer platforms. I've been assured that is won't happen hence it's not a problem. I'm skeptical about this. But I can tell you one thing for sure, I'm not going back to spend time to fix any breakage due to changes such as this. Robert Ramey
On Monday 14 October 2013 21:38:20 Peter Dimov wrote:
Andrey Semashev wrote:
My understanding is that the most immediate benefit is exactly for Boost library maintainers.
I can assure you as a maintainer that I see no immediate benefit. Perhaps my experience is atypical.
Just looking at the amount of hoops Boost.MPL has to jump though makes me think that the idea of dropping some compilers is not so bad. And I'd sure be happier if there were less #ifs in Boost.Log, although it may just be deficiency of my coding kung fu.
Andrey Semashev wrote:
On Monday 14 October 2013 21:38:20 Peter Dimov wrote:
Andrey Semashev wrote:
My understanding is that the most immediate benefit is exactly for Boost library maintainers.
I can assure you as a maintainer that I see no immediate benefit. Perhaps my experience is atypical.
Just looking at the amount of hoops Boost.MPL has to jump though makes me think that the idea of dropping some compilers is not so bad.
But that work is already done - it's a sunk cost! Taking out the support for the old compilers will cost effort - and not a trivial amount.
And I'd sure be happier if there were less #ifs in Boost.Log, although it may just be deficiency of my coding kung fu.
No one is suggesting that new libraries include any of this stuff. Since Boost Log is a recent edition, it shouldn't be effected by this initiative. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 14 October 2013 17:20, Robert Ramey wrote:
I realize that I've asked this before - but I never got a response which I found convincing. I'll try to ask my question better this time.
The question - What is the value of undertaking this task.
Let's look at the value of according to the type of boost participant.
a) boost user - all this code in config and the libraries is internal to the libraries. After this change the look and usage of boost will not change at all. - no benefit and no cost to the boost user.
I consider myself a "boost user" as I haven't contributed more than a few patches, but I often have to look at the implementations Even as a standard library author I find Boost code to be baroque and hard to follow, due largely to all the preprocessor conditions needed to support ancient non-standard compilers. I highly appreciate removing the cruft, it makes it much easier to read and debug Boost code, as a user.
c) boost users on older platforms. They are to be stuck with the boost 1.54. I don't know how big this group is but I'm sure it has some members. A big loss for this (probably small) group as they won't benefit from things like bug fixes and enhancements.
They can always pay someone to backport fixes to they version they use.
On 10/14/2013 06:20 PM, Robert Ramey wrote:
The question - What is the value of undertaking this task.
I think that you are overlooking some of the major advantages of open source in your reasoning. First, Boost users may need to investigate the Boost source code when the documentation and examples are insufficient for their tasks. The compiler workarounds makes this more difficult. Second, Boost maintainers are less likely to receive patches from contributors because of the added complexity introduced by compiler workarounds. The compiler workarounds is the one of the main reason why I have decided not to contribute to Boost.Serialization. Finally, compiler workarounds can generate incomprehensible compiler error messages when Boost users make mistakes in their own code. I have encountered several of these, although I cannot point you to concrete examples because I have not recorded them (they were temporary obstacles that I just needed to get past.)
Bjorn Reese wrote:
On 10/14/2013 06:20 PM, Robert Ramey wrote:
The question - What is the value of undertaking this task.
I think that you are overlooking some of the major advantages of open source in your reasoning.
First, Boost users may need to investigate the Boost source code when the documentation and examples are insufficient for their tasks. The compiler workarounds makes this more difficult.
Second, Boost maintainers are less likely to receive patches from contributors because of the added complexity introduced by compiler workarounds. The compiler workarounds is the one of the main reason why I have decided not to contribute to Boost.Serialization.
Finally, compiler workarounds can generate incomprehensible compiler error messages when Boost users make mistakes in their own code. I have encountered several of these, although I cannot point you to concrete examples because I have not recorded them (they were temporary obstacles that I just needed to get past.)
I'm willing to concede that these points have value. But I don't think the cost has been adequately appreciated. Take for example MPL. This is an incredible work. It's implementation depends upon exploitation of compiler features which have been left undefined by the C++ standard or added in by vendors. A very tiny unobvious error could take days to track down. Who is going to do this? I realise that the answer to that question is - that won't happen. I think this underestimates the complexity of lot's of library code. Robert Ramey
Robert Ramey wrote:
I'm willing to concede that these points have value.
But I don't think the cost has been adequately appreciated.
Exactly. The cost will only become to be appreciated when a release containing the changes goes out. The majority of our users do not use the trunk, do not try out a beta release, do not try the release candidates; many of them nowadays don't even get Boost from us. There are also people who are using (portions of) Boost on "non-supported" compilers. We only hear from them when something breaks.
Dear Boost Developers, I realize that I cannot ask you to support old compilers, but I would like to kindly ask you not to intentionally rule them out and to retain existing work-arounds for older compilers, if not otherwise than by separate folders and files containing "last version known to work". I think that newer versions of the libraries should *improve* support for all compilers instead of dumping a lot of work that has been put, by the original developers and by others, into getting them to work. And many of them *do* work, because for example even if they do not support Template Partial Specialization in *all* cases, they do support it in enough cases. And who supports, even that, in *all* cases ? At some time I had Boost.Thread working just fine with Borland, and the changes were two or three lines, but there was no answer from the developer to incorporate them for weeks... I gave up. Some seem to recommend dropping support for Borland C++ Builder (version 5, but as I am going to show you really soon, there is no much difference between version 5.5 aka 2000 and version XE5 aka 2013). But on older hardware (some of us do not have a job and cannot afford i7's), Borland (any version since 2000) is 2-or-3-or-4 times faster than Visual C++ (any version since 2003). As the list of actively developed native C++ compilers gets shorter and shorter (msvc, gcc, clang, dmc and just who else for Windows if I may ask ?), having more compilers to: - test our code on and - help us find bugs and - help us achieve portability and - help us achieve independence from one (commercial or otherwise) vendor are great things, very highly appreciated by many developers. Yes, my answer may be late. But I have humbly said it before: Maybe it is not the compilers failing Boost. Maybe it is Boost failing the compilers. Happy New Year ! -- Yours truly, Adder On 10/15/13, Peter Dimov <lists@pdimov.com> wrote:
Robert Ramey wrote:
I'm willing to concede that these points have value.
But I don't think the cost has been adequately appreciated.
Exactly. The cost will only become to be appreciated when a release containing the changes goes out. The majority of our users do not use the trunk, do not try out a beta release, do not try the release candidates; many of them nowadays don't even get Boost from us. There are also people who are using (portions of) Boost on "non-supported" compilers. We only hear
from them when something breaks.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Monday 06 January 2014 02:17:12 Adder wrote:
Dear Boost Developers,
I realize that I cannot ask you to support old compilers, but I would like to kindly ask you not to intentionally rule them out and to retain existing work-arounds for older compilers, if not otherwise than by separate folders and files containing "last version known to work".
I think that newer versions of the libraries should *improve* support for all compilers instead of dumping a lot of work that has been put, by the original developers and by others, into getting them to work.
And many of them *do* work, because for example even if they do not support Template Partial Specialization in *all* cases, they do support it in enough cases. And who supports, even that, in *all* cases ?
All these workarounds clutter the code and preclude further development of the libraries. And since old compilers (the ones that were proposed for dropping) are not tested, you cannot call them supported anyway. Some developers may want to keep the compatibility and cope with inconveniences and may even find ways to test on the old compilers. But in general I don't think it is good for Boost to be pulled back by decade-old compilers. The Standard is out for 15 years and if some compiler failed to implement crucial parts of it, such as PTS, then this compiler is not worth supporting.
At some time I had Boost.Thread working just fine with Borland, and the changes were two or three lines, but there was no answer from the developer to incorporate them for weeks... I gave up.
Some seem to recommend dropping support for Borland C++ Builder (version 5, but as I am going to show you really soon, there is no much difference between version 5.5 aka 2000 and version XE5 aka 2013). But on older hardware (some of us do not have a job and cannot afford i7's), Borland (any version since 2000) is 2-or-3-or-4 times faster than Visual C++ (any version since 2003).
From my memory, Borland was one of the worst compilers I had worked with, at least the free version available for download, not sure which version it was (I think it was 5.something). It always surprised me why people would pay for it when there are many better alternatives.
There are GCC and MSVS Express for Windows, which are free and implement the Standard sufficiently well. And let me say that Windows also costs money, so you could save it by using Linux, which is free and runs virtually on any hardware. Most distributions have recent GCC and clang. Intel compiler is available for free for non-commercial use. I'm not sure what you refer to as "2-or-3-or-4 times faster than Visual C++" but if you're not satisfied with compile times then I suggest you play with compiler options. At least with GCC, reducing optimization level makes it compile considerably faster. Staying on an older Boost version is another option. And believe me, if you're highly concerned with compile times you may want to do that anyway since in some cases compile times get longer with the more recent releases.
Maybe it is not the compilers failing Boost. Maybe it is Boost failing the compilers.
As I said, the Standard was released 15 years ago. The compilers that are not able to implement it by this time are the failure.
On 1/6/14, Andrey Semashev <andrey.semashev@gmail.com> wrote:
All these workarounds clutter the code and preclude further development of the libraries.
The code will never be free from preprocessor-controlled branches to support differences in even the newest compilers. There is also the possibility to keep the old files of the libraries for which the authors themselves wish to drop support in a separate sub-folder and include the old files instead of the new ones from a masterfile. Loki used to do and it worked great. Yes, I know they don't do it anymore, but what is relevant is that it solved the clutter problem at the time -- a time when reading the Loki book required an imaginary compiler for me. But messing with Boost.Config and introducing an #error directive upon detection of _MSC_VER <= 1300 is gratuitous and evil.
And since old compilers (the ones that were proposed for dropping) are not tested, you cannot call them supported anyway.
I have been testing (on my lonely computer, I recognize) ever since Boost switched from CVS to SVN, as much as possible against the HEAD revision, on the few compilers I could get my hands on. If it is any help, I would gladly like to contribute my modest and ugly patches and work-arounds.
Some developers may want to keep the compatibility and cope with inconveniences and may even find ways to test on the old compilers. But in general I don't think it is good for Boost to be pulled back by decade-old compilers. The Standard is out for 15 years and if some compiler failed to implement crucial parts of it, such as PTS, then this compiler is not worth supporting.
Incidentally, the compilers I mentioned *do* support Partial Template Specialization. Again, I do not ask for support. But I kindly ask for avoiding gratuitous and hardcoded #error directives. If a compiler can process boost::shared_ptr (for example) then I strongly believe that it is fair to allow users of that compiler to use the latest and greatest version of boost::shared_ptr, even if it fails to process some other libraries. Forcing the users to stick to an old, unpatched version of *all* the libraries just because they cannot compile *some* of the libraries does not sound fair at all to me.
From my memory, Borland was one of the worst compilers I had worked with, at least the free version available for download, not sure which version it was (I think it was 5.something).
Yes, that is the one ! (-:
It always surprised me why people would pay for it when there are many better alternatives.
One difference I mentioned is compile speed. It does make a difference on a 1600 MHz single core processor. Another is download size. 4 MB for Digital Mars, 9 MB for Borland, a few GigaBytes for new versions of Visual and CodeGear. As for Cygwin and GCC, Another is acquaintance with the build environment, the debugger... Another is the syntax of the inline assembler (and the amount of already written inline assembler code that still needs to be processed). And support for Windows-specific features such as the Active Template Library. I guess I am lucky that I have not used VCL !
There are GCC and MSVS Express for Windows, which are free and implement the Standard sufficiently well. And let me say that Windows also costs money, so you could save it by using Linux, which is free and runs virtually on any hardware.
Thank you -- I have kept my license from the days when I was in school. (-: But really, thank you kindly (and in no way ironically) for the good advice.
Most distributions have recent GCC and clang. Intel compiler is available for free for non-commercial use.
I'm not sure what you refer to as "2-or-3-or-4 times faster than Visual C++"
I mean "2-or-3-or-4 times faster than Visual C++". Any version of Borland since 2000 versus any version of Visual since 2003. Linking time is about the same. But I instead hack the output OBJ files and link with Digital Mars' linker instead which is 10 times as fast. Which means "10 times as fast". All these *do* make a difference (for me) for an executable file with a 5 MB code section...
but if you're not satisfied with compile times then I suggest you play with
compiler options. At least with GCC, reducing optimization level makes it compile considerably faster.
Staying on an older Boost version is another option. And believe me, if you're highly concerned with compile times you may want to do that anyway since in
some cases compile times get longer with the more recent releases.
Thank you, but I will rather have the latest patches and bug fixes and the features that the compiler affords. Some are just happy with a few libraries and even those not having all the features. But for the few libraries and the few features that I use, I would very much like to have the latest. And I truly believe that being granted this desire means in no way more work for any Boost developer or maintainer (as per the Loki approach described above). Otherwise I would not have asked for it.
[...] As I said, the Standard was released 15 years ago. The compilers that are not able to implement it by this time are the failure.
I see your point. But I do not think that *age* by iteself is not that important. For example, Borland 2002 (5.6 aka C++Builder 6) and 2006 (5.8 aka Developer Studio 2006 aka Turbo C++ 2006) have more issues in the front end than the free 2000 version (5.5). As for Microsoft Visual C++, the SSE2 optimizer is better in the 2003 than in the 2005 version in quite a few cases. Maybe isolated cases, but my point is not to judge and despise a compiler just for its age...
On Thursday 09 January 2014 07:10:32 Adder wrote:
On 1/6/14, Andrey Semashev <andrey.semashev@gmail.com> wrote:
All these workarounds clutter the code and preclude further development of the libraries.
The code will never be free from preprocessor-controlled branches to support differences in even the newest compilers.
Yes, but reducing the amount of these branches always helps. Also, there is difference between one-liner hacks or different attribute syntax and the lack of PTS. The former can often be wrapped in a macro and the latter requires reimplementing (duplicating) solid parts of the library.
There is also the possibility to keep the old files of the libraries for which the authors themselves wish to drop support in a separate sub-folder and include the old files instead of the new ones from a masterfile. Loki used to do and it worked great. Yes, I know they don't do it anymore, but what is relevant is that it solved the clutter problem at the time -- a time when reading the Loki book required an imaginary compiler for me.
You essentially ask to distribute the old version of the library alongside with the latest. As the library and the rest of Boost moves on, the old version needs to be adapted or diverges more and more, to the point when it can't reuse the code from the latest version. The old version would likely not get new features because they may involve parts of the language not supported by old compilers which are not tested. You can as well just use an older Boost release.
But messing with Boost.Config and introducing an #error directive upon detection of _MSC_VER <= 1300 is gratuitous and evil.
The error gives a good indication that the compiler is not capable enough and not supported and there's no point in reporting bugs related to it. OTOH, it looks like an overkill to issue the error in Boost.Config. Some libraries may miraculously work even on old compilers. It's better to issue the error on per-library basis, especially taking into account the modularization effort.
And since old compilers (the ones that were proposed for dropping) are not tested, you cannot call them supported anyway.
I have been testing (on my lonely computer, I recognize) ever since Boost switched from CVS to SVN, as much as possible against the HEAD revision, on the few compilers I could get my hands on.
That is good, but as long as the test results are not available for developers they don't see when something breaks, so it doesn't change the state of things. The best start to get a compiler supported is to join the test farm and publish test results on a regular basis. That said, I doubt that there would be many volunteers to support the ancient compilers even if they were tested.
If it is any help, I would gladly like to contribute my modest and ugly patches and work-arounds.
This would help, I appreciate the offer.
As I said, the Standard was released 15 years ago. The compilers that are not able to implement it by this time are the failure.
I see your point. But I do not think that *age* by iteself is not that important. For example, Borland 2002 (5.6 aka C++Builder 6) and 2006 (5.8 aka Developer Studio 2006 aka Turbo C++ 2006) have more issues in the front end than the free 2000 version (5.5).
That's the point, it didn't improve over the years. While e.g. MSVC 7.1 (aka VS 2003) already provided most of what Boost needs today. Granted, it had bugs of its own but in terms of the Standard support this was a major improvement.
As for Microsoft Visual C++, the SSE2 optimizer is better in the 2003 than in the 2005 version in quite a few cases.
Maybe isolated cases, but my point is not to judge and despise a compiler just for its age...
I'm not despising it. For its time it may have been a pretty decent compiler among the alternatives. But not today.
Adder wrote:
Maybe it is not the compilers failing Boost. Maybe it is Boost failing the compilers.
That is not quite true for Borland. It was about average in its conformance in the past; the problem is that all other compilers have significantly increased their conformance, whereas Borland has basically stood still. Nevertheless, I still try to not break things under Borland, but that's kind of hard because we don't even have a Borland tester. (And there isn't - to my knowledge - a free version.)
That is not quite true for Borland. It was about average in its conformance
in the past; the problem is that all other compilers have significantly increased their conformance, whereas Borland has basically stood still.
Nevertheless, I still try to not break things under Borland, but that's kind
of hard because we don't even have a Borland tester. (And there isn't - to my knowledge - a free version.)
I will gladly be your tester ! The download link currently is http://altd.embarcadero.com/download/bcppbuilder/freecommandLinetools.exe (8.5 MB). I (modestly) admit it has a few flaws that require a few patches to the RTL and shipped version of STL. I will try to upload those patches somewhere !
Nevertheless, I still try to not break things under Borland, but that's kind of hard because we don't even have a Borland tester. (And there isn't - to my knowledge - a free version.)
A very quick guide to using a free version of the Borland C++ Compiler (5.5) toolset may be found at the following address: http://adder.demo.iworks.ro/Go/2014-01-12_Borland/ It includes a few patches to the Standard Library implementation that are quite important (as demonstrated by the also-included mini test programs). As I have used them for a long time, I had almost forgotten about them. (Similar patches for std::auto_ptr are needed for all versions of Borland/CodeGear/Embarcadero including 2013 aka XE5, whethey they use RogueWave, STLport or Dinkumware. I also have versions for 2002 aka Builder 6, 2006 and 2007 and I am going to upload them too.) The mini-guide also describes a work-around for a long-standing bug in the linker. More recent versions can be used similarly, by downloading the trial versions from the CodeGear/Embarcadero website and then using the command line tools included. At least in older versions, the command line tools were not bound by the trial time limit. I am going to describe the modifications to borland.jam and other files that have proven helpful for me (e.g. to support DEF (module definition) files being passed to the linker) as soon as I have more time...
On Mon, Jan 13, 2014 at 10:31 AM, Adder <adder.thief@gmail.com> wrote:
Nevertheless, I still try to not break things under Borland, but that's kind of hard because we don't even have a Borland tester. (And there isn't - to my knowledge - a free version.)
A very quick guide to using a free version of the Borland C++ Compiler (5.5) toolset may be found at the following address:
http://adder.demo.iworks.ro/Go/2014-01-12_Borland/
It includes a few patches to the Standard Library implementation that are quite important (as demonstrated by the also-included mini test programs). As I have used them for a long time, I had almost forgotten about them.
While the patches for the compiler are useful for the end users, I'd say Boost libraries should be tested against the unmodified official version. You can't guarantee that every user has the patches applied.
Adder wrote:
A very quick guide to using a free version of the Borland C++ Compiler (5.5) toolset may be found at the following address:
I used to use 5.5 for local testing (years ago), but how relevant is it today? Does anyone still use it? The compiler may not have advanced much, but bugs were still fixed in later releases.
On 01/13/2014 01:31 AM, Adder wrote:
Nevertheless, I still try to not break things under Borland, but that's kind of hard because we don't even have a Borland tester. (And there isn't - to my knowledge - a free version.)
A very quick guide to using a free version of the Borland C++ Compiler (5.5) toolset may be found at the following address:
http://adder.demo.iworks.ro/Go/2014-01-12_Borland/
It includes a few patches to the Standard Library implementation that are quite important (as demonstrated by the also-included mini test programs). As I have used them for a long time, I had almost forgotten about them.
(Similar patches for std::auto_ptr are needed for all versions of Borland/CodeGear/Embarcadero including 2013 aka XE5, whethey they use RogueWave, STLport or Dinkumware. I also have versions for 2002 aka Builder 6, 2006 and 2007 and I am going to upload them too.)
The mini-guide also describes a work-around for a long-standing bug in the linker.
More recent versions can be used similarly, by downloading the trial versions from the CodeGear/Embarcadero website and then using the command line tools included. At least in older versions, the command line tools were not bound by the trial time limit.
And after the trial versions run out, how do you propose to test these compilers ?
I am going to describe the modifications to borland.jam and other files that have proven helpful for me (e.g. to support DEF (module definition) files being passed to the linker) as soon as I have more time...
I worked with Borland C++ and C++ Builder (3,4,5,6) a number of years ago. Given Borland's near total inability to fix longstanding bugs over the years I will never work with Borland/Codegear tools again, nor will I ever spend a nanosecond of time attempting to make any library I create work with Borland/Codegear compilers. Microsoft may be bad in the offhand way in which they refuse to fix or address C++ bugs which they have decided are not mainstream enough to spend time on but Borland/Codegear was truly hopeless. Others can do whatever they want of course but this is my own personal experience. I do not believe, as opposed to your own opinion, that implementors of Boost libraries should spend unnecessary time trying to accomodate ancient compilers. If the modern compilers are testable and have at least adequate support, then I can understand trying to work with them.
On 1/13/14, Edward Diener <eldiener@tropicsoft.com> wrote:
And after the trial versions run out, how do you propose to test these compilers ?
I think that it might be possible for the command line tools (compiler, linker, etc.) (as opposed to the IDE) to still work after the trial period ends.
I worked with Borland C++ and C++ Builder (3,4,5,6) a number of years ago. Given Borland's near total inability to fix longstanding bugs over the years I will never work with Borland/Codegear tools again, nor will I ever spend a nanosecond of time attempting to make any library I create work with Borland/Codegear compilers. Microsoft may be bad in the offhand way in which they refuse to fix or address C++ bugs which they have decided are not mainstream enough to spend time on but Borland/Codegear was truly hopeless. Others can do whatever they want of course but this is my own personal experience.
I respect that ! The part that is confusing for me is someone imposing that *no* authors should be able to use a specific compiler with Boost even if they wanted to. Which results in no users being able to use that compiler with the (updated) parts of Boost that otherwise happen to work, due to the library not relying on certain features or due to previous work or due to current work or due to miracles.
I do not believe, as opposed to your own opinion, that implementors of Boost libraries should spend unnecessary time trying to accomodate ancient compilers. If the modern compilers are testable and have at least adequate support, then I can understand trying to work with them.
I also do not believe that implementors should spend what they consider to be unnecessary time and effort on anything.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Adder Sent: Tuesday, January 14, 2014 7:38 AM To: boost@lists.boost.org Subject: Re: [boost] [Removing support for old compilers]
On 1/13/14, Edward Diener <eldiener@tropicsoft.com> wrote:
And after the trial versions run out, how do you propose to test these compilers ?
I think that it might be possible for the command line tools (compiler, linker, etc.) (as opposed to the IDE) to still work after the trial period ends.
I worked with Borland C++ and C++ Builder (3,4,5,6) a number of years ago. Given Borland's near total inability to fix longstanding bugs over the years I will never work with Borland/Codegear tools again, nor will I ever spend a nanosecond of time attempting to make any library I create work with Borland/Codegear compilers. Microsoft may be bad in the offhand way in which they refuse to fix or address C++ bugs which they have decided are not mainstream enough to spend time on but Borland/Codegear was truly hopeless. Others can do whatever they want of course but this is my own personal experience.
I respect that !
The part that is confusing for me is someone imposing that *no* authors should be able to use a specific compiler with Boost even if they wanted to.
Which results in no users being able to use that compiler with the (updated) parts of Boost that otherwise happen to work, due to the library not relying on certain features or due to previous work or due to current work or due to miracles.
I do not believe, as opposed to your own opinion, that implementors of Boost libraries should spend unnecessary time trying to accomodate ancient compilers. If the modern compilers are testable and have at least adequate support, then I can understand trying to work with them.
I also do not believe that implementors should spend what they consider to be unnecessary time and effort on anything.
There may be nothing to stop antique compilers users from using new features - by extracting just the new library code from a recent download and adding to your last working Boost version. But more and more libraries will take advantage of and require newish and especially C++11 features - and so just won't work. All we are saying is "no guarantees - but good luck!". Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
Le 06/01/14 01:17, Adder a écrit :
Dear Boost Developers,
I realize that I cannot ask you to support old compilers, but I would like to kindly ask you not to intentionally rule them out and to retain existing work-arounds for older compilers, if not otherwise than by separate folders and files containing "last version known to work".
I think that newer versions of the libraries should *improve* support for all compilers instead of dumping a lot of work that has been put, by the original developers and by others, into getting them to work.
And many of them *do* work, because for example even if they do not support Template Partial Specialization in *all* cases, they do support it in enough cases. And who supports, even that, in *all* cases ?
At some time I had Boost.Thread working just fine with Borland, and the changes were two or three lines, but there was no answer from the developer to incorporate them for weeks... I gave up.
Hi, what is the problem using the Boost version that worked with your compiler? Vicente
What is the problem using the Boost version that worked with your compiler?
Vicente
Not getting updates (new features/fixes for known/yet-unknown issues). And then there is the question of morality. There already exists an *implicit*, dare I say *natural* test that decides whether a compiler is supported or not (on a per-library or even per-library-feature basis -- and this paranthesis is important). Why should we draw *artificial* lines in a centralized manner ? And on what basis do we draw those lines ?
On 10 January 2014 03:25, Adder wrote:
Why should we draw *artificial* lines in a centralized manner ? And on what basis do we draw those lines ?
On the basis that noone is testing old compilers so noone even knows if the workarounds inside #if blocks work.
On 10 January 2014 09:12, Jonathan Wakely <jwakely.boost@kayari.org> wrote:
On 10 January 2014 03:25, Adder wrote:
Why should we draw *artificial* lines in a centralized manner ? And on what basis do we draw those lines ?
On the basis that noone is testing old compilers so noone even knows if the workarounds inside #if blocks work.
But people are testing with old compilers, including the person you replied to. Also, don't underestimate stability, even if we don't know something works, there's a good chance it will for stable code. This decision should be up to the library maintainer, so making it for them in config is clearly wrong.
On 10 January 2014 09:55, Daniel James <dnljms@gmail.com> wrote:
On 10 January 2014 09:12, Jonathan Wakely <jwakely.boost@kayari.org> wrote:
On 10 January 2014 03:25, Adder wrote:
Why should we draw *artificial* lines in a centralized manner ? And on what basis do we draw those lines ?
On the basis that noone is testing old compilers so noone even knows if the workarounds inside #if blocks work.
But people are testing with old compilers, including the person you replied to.
But are they submitting test results so the maintainers can see them?
Also, don't underestimate stability, even if we don't know something works, there's a good chance it will for stable code.
But if it's entirely stable code then it isn't benefitting from updates and fixes made to the rest of the code, and if there are no updates then there's no advantage to using Boost 1.55 over some older version that does still support the older compiler.
On 10 January 2014 10:26, Jonathan Wakely <jwakely.boost@kayari.org> wrote:
On 10 January 2014 09:55, Daniel James <dnljms@gmail.com> wrote:
On 10 January 2014 09:12, Jonathan Wakely <jwakely.boost@kayari.org> wrote:
On 10 January 2014 03:25, Adder wrote:
Why should we draw *artificial* lines in a centralized manner ? And on what basis do we draw those lines ?
On the basis that noone is testing old compilers so noone even knows if the workarounds inside #if blocks work.
But people are testing with old compilers, including the person you replied to.
But are they submitting test results so the maintainers can see them?
They submit bug reports. Which is not ideal, but is often good enough.
Also, don't underestimate stability, even if we don't know something works, there's a good chance it will for stable code.
But if it's entirely stable code
It's not entirely stable code.
if there are no updates
There are updates.
Can the platform/compiler capabilities checks be deactivated with a compilation flag? If yes, then doesn't it help people try unsupported compilers without having to change the code, and still have errors by default when some language features are not available?
Daniel James wrote:
But people are testing with old compilers, including the person you replied to.
I think that it's better to not talk of old compilers as a generic category. The classic old compiler, MSVC 6.0, is no longer relevant, and dropping support for it is both nearly free and enormously beneficial in terms of eliminating workarounds. I agree that Borland C++ is still both old and active, but support for it wasn't dropped at the config level.
On the basis that noone is testing old compilers
This statement is false.
so noone even knows if the workarounds inside #if blocks work.
This statement would be irrelevant even if it were true. The people who wrote the code inside the #if blocks have most probably tested the code and might be testing it even now. The code might be working even if untested (or recently untested). Portions of code *do* work, tested or not tested or not recently tested. For some people, the portions are enough. Those portions help them in their daily work. Why should they be denied updates to (example follows) the small object allocator for shared_count if their compiler does not have <insert-feature-name-here> which does not affect the (example follows) small object allocator for shared_count ? Or if there exists a work-around ? Why should authors be discouraged from providing work-arounds ? I am not saying "force them". But I would like to strongly encourage it.
Le 13/10/13 12:11, Joaquin M Lopez Munoz a écrit :
Stephen Kelly <steveire <at> gmail.com> writes:
On 10/12/2013 10:13 PM, Joaquin M Lopez Munoz wrote:
Hi Stephen
As part of your initiative of removing support for old compilers, are you building somewhere a change log in the form of either a list of compiler deficiencies or compiler versions no longer supported? I have not built such a thing, but it's easy to create by reading the recent log of boost/config. Not obvious to me: the message log for your changes at boost/config reads
* Remove remaining occurances of BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION These evaded scripting. * Require compiler support for partial template specialization. Remove support for the mac programmers workshop entirely. Bump the sunpro requirement to version 5.4. Version 5.3 seems to have had some bugs with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, so bump above that in the abundance of caution. This allows the removal of lots of workaround code:
src/boost-trunk{master}$ ../kf5/remove_def.py BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION src/boost-trunk{master}$ git diff --shortstat 192 files changed, 4798 deletions(-) * Remove obsolete MSVC check from pragma guard git grep -h -B1 "^#\s*pragma once" | grep -v pragma | sort | uniq is now clean. * Config: Remove obsolete MSVC version check
Frankly, it is hard to know what's going on by looking at this log alone. In particular, nowhere's stated which versions of MSVC have been dropped (I understand 6.0 and 7.0, but the log does not say it), and one has to investigate in order to find out what other compilers are effecively dropped as a consequence of TPS being required (the log mentions MPW and SunPro 5.3, but I guess Digital Mars and GCC 2.x are also affected, don't know about Borland, and maybe there are others as well). I have also the suspicion that along the way you have removed macros and workarounds not directly related to TPS or MSVC 6.0/7.0.
Where should it be and what should it say? As for the form of the doc, something like this would be IMHO fine:
* New minimal requirements on compilers/environments suported by Boost 1.56 - Template partial specialization support · Deleted BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION and [etc] from Boost.Config - [Additional new requirements, SFINAE for instance] · [Resulting changes in Boost.Config (macros removed and so on)] * Compilers dropped starting in Boost 1.56 - MSVC 7.0 and prior · [Boost.Config facilities removed as a consequencce] - GCC 2.x · [Boost.Config facilities removed as a consequencce] - [etc] * List of Boost libs directly modified [useful as a heads up for maintainers wishing to review your changes] +1 As for where to put it, the final destination would be
https://svn.boost.org/svn/boost/website/public_html/live/feed/history/ file boost_1_56_0.qbk
although this file has not been created yet. You can either ask for the file to be created or, in the meantime, publish your log somewhere for easy reference and public access. +1 Some other things that'd help:
* Consider adding some [xxx] subject tag in your communications to the mailing list so that users and maintainers can easily track them (for instance, [compiler support]) +1. I think that every changes set should contain [library] text * Allow for some time for people to express support/dissent on proposed removals before going ahead, and notify the list when a change is effective. It is important that a proposed change comes with a list of compilers affected (users don't necessarily know whether some compiler X they care about does support, say, TPS, so we need to make sure this is clear to everybody potentially affected.) +1. Authors and maintainer should be notified before commit. * With all due respect, I think you are being a little too aggresive at executing this. Removal of compiler support is a sensitive issue and sure enough we won't get unanimous consensus, but some form of general agreement should be reached, and time be given for awareness and discussion. That said, some assertiveness will be needed at the end of the day: it's a matter of finding the right balance and not going overboard with changes that could potentially harm existing Boost users.
+1. These kind of changes could seem simple but the possibility to break existing code is high. Best, Vicente
participants (16)
-
Adder -
Andrey Semashev -
Bjorn Reese -
Daniel James -
Daniel James -
Edward Diener -
Joaquin M Lopez Munoz -
John Maddock -
Jonathan Wakely -
Klaim - Joël Lamotte -
Nathan Ridge -
Paul A. Bristow -
Peter Dimov -
Robert Ramey -
Stephen Kelly -
Vicente J. Botet Escriba