Re: [boost] Permanently retire VC++ 6?
----Original Message---- From: Peter Dimov [mailto:pdimov@mmltd.net] Sent: 05 December 2005 13:19 To: boost@lists.boost.org Subject: Re: [boost] Permanently retire VC++ 6?
Paul A Bristow wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Victor A. Wagner Jr. Sent: 05 December 2005 01:02 To: boost@lists.boost.org; boost@lists.boost.org Subject: Re: [boost] Permanently retire VC++ 6? (was:Re:Math/Quaternions compile problem in VC++6)
and I'm all for retiring vc++6.0 support from boost (I've argued this before).
This is long overdue and now that we have a reasonably compliant MSVC compiler that works on Windows 2000 up I can't see any excuse for not dropping support. Things that this work will still work, but if not - tough. (I am not proposing ripping out all the #ifdefs relating the MSVC 6, despite the improvement in readability that might result).
Should we have a straw poll of the lurkers - so that diehards can have their say - and then make a decision?
What do you mean by "dropping support"?
Excellent question.
I am against dropping VC 6 regression tests in general because I want to see what works on it, either for not introducing a regression, or for ensuring compatibility where it's reasonably easy to do so.
I agree with this.
I do not oppose dropping VC 6 and 7 from the list of "release" compilers. I think it is too soon to drop VC 7.1 from the list of "release" compilers. (But VC7.0 could probably go).
-- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
Martin Bonner wrote:
I do not oppose dropping VC 6 and 7 from the list of "release" compilers.
I think it is too soon to drop VC 7.1 from the list of "release" compilers.
I doubt that 7.1 would ever be dropped, as it's too close to conforming and VC 8 has some features that could hinder its acceptance.
(But VC7.0 could probably go).
That's what I meant.
"Peter Dimov" <pdimov@mmltd.net> writes:
Martin Bonner wrote:
I do not oppose dropping VC 6 and 7 from the list of "release" compilers.
I think it is too soon to drop VC 7.1 from the list of "release" compilers.
I doubt that 7.1 would ever be dropped, as it's too close to conforming and VC 8 has some features that could hinder its acceptance.
(But VC7.0 could probably go).
That's what I meant.
That sounds great to me. Now what about Borland (wrings hands like Snively Whiplash)? If anything, that's harder to support than vc6 and 7.0! -- Dave Abrahams Boost Consulting www.boost-consulting.com
That sounds great to me. Now what about Borland (wrings hands like Snively Whiplash)? If anything, that's harder to support than vc6 and 7.0!
Let's remove Borland together with msvc and vc7 (but not vc7.1 !) from "release list" but keep running regression tests for them. It would be nice to put an extra sentence in boost 1.33.1 release notes that "this version of boost is the last one that officialy supports some old compilers" B. -- Bronek Kozicki brok@spamcop.net http://b.kozicki.pl/
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
Martin Bonner wrote:
I do not oppose dropping VC 6 and 7 from the list of "release" compilers.
I think it is too soon to drop VC 7.1 from the list of "release" compilers.
I doubt that 7.1 would ever be dropped, as it's too close to conforming and VC 8 has some features that could hinder its acceptance.
(But VC7.0 could probably go).
That's what I meant.
That sounds great to me. Now what about Borland (wrings hands like Snively Whiplash)? If anything, that's harder to support than vc6 and 7.0!
I understand you are referring to past BCB compilers but I just want to note that Borland is putting out a new release of BCB in case Boost becomes interested. The product, part of the BDS 2006 suite, was supposed to come out December 1 but has been delayed for approximately a month, not a good sign, with the next exact date not given yet. I have made efforts to find out whether the new compiler will be more standard C++ compatible but this has been met by a wall of silence. Borland has pointedly said almost nothing about standard C++ compatibility, while touting all the other IDE related features of the new release, and others who might be privy to this information on Borland's NG are bound by the NDA not to say anything until the product is released. Just a heads up in case no one from Boost is paying attention to this in the wake of MS's much touted Visual Studio 2005 and VC 8.0.
Edward Diener wrote:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
Martin Bonner wrote:
I do not oppose dropping VC 6 and 7 from the list of "release" compilers.
I think it is too soon to drop VC 7.1 from the list of "release" compilers.
I doubt that 7.1 would ever be dropped, as it's too close to conforming and VC 8 has some features that could hinder its acceptance.
(But VC7.0 could probably go).
That sounds great to me. Now what about Borland (wrings hands like Snively Whiplash)? If anything, that's harder to support than vc6 and 7.0!
I understand you are referring to past BCB compilers but I just want to note that Borland is putting out a new release of BCB in case Boost becomes interested. The product, part of the BDS 2006 suite, was supposed to come out December 1 but has been delayed for approximately a month, not a good sign, with the next exact date not given yet.
Just a heads up in case no one from Boost is paying attention to this in the wake of MS's much touted Visual Studio 2005 and VC 8.0.
It may be useful to have 3 levels of support: * officially supported (e.g. CodeWarrior 9.x, gcc, VC8) - compilers that Boost is expected to work with; * not officially supported (e.g. VC6, BCB) - some libraries may work, but there is no requirement to support these compilers; * not supported (e.g. OpenWatcom) - these haven't been tested for and do not have any Boost.Config/workaround magic to support them. It may also be useful to make Boost.Config issue a warning that compilers like BCB and VC6 are not officially supported if they are removed from the supported list. - Reece
"Reece Dunn" <msclrhd@hotmail.com> writes:
It may be useful to have 3 levels of support: * officially supported (e.g. CodeWarrior 9.x, gcc, VC8) - compilers that Boost is expected to work with; * not officially supported (e.g. VC6, BCB) - some libraries may work, but there is no requirement to support these compilers;
Sounds good, but I'd like to know, as a practical matter, what the difference between these two is. Less pressure on developers to support the 2nd category?
* not supported (e.g. OpenWatcom) - these haven't been tested for and do not have any Boost.Config/workaround magic to support them.
It may also be useful to make Boost.Config issue a warning that compilers like BCB and VC6 are not officially supported if they are removed from the supported list.
<shiver> Wouldn't people hate us for adding diagnostics? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Reece Dunn" <msclrhd@hotmail.com> writes:
It may be useful to have 3 levels of support: * officially supported (e.g. CodeWarrior 9.x, gcc, VC8) - compilers that Boost is expected to work with; * not officially supported (e.g. VC6, BCB) - some libraries may work, but there is no requirement to support these compilers;
Sounds good, but I'd like to know, as a practical matter, what the difference between these two is. Less pressure on developers to support the 2nd category?
The first would mean that Boost guarantees support for the specified compiler/version. The second (possibly with a better name) would mean that there is limited support. That is: * less pressure (or none for VC6 ;)) on developers to support it (as you mention); * no requirement to fix regressions for that toolset (although it might be useful for the users to see the regression results for these compilers so they know what libraries will work).
* not supported (e.g. OpenWatcom) - these haven't been tested for and do not have any Boost.Config/workaround magic to support them.
It may also be useful to make Boost.Config issue a warning that compilers like BCB and VC6 are not officially supported if they are removed from the supported list.
<shiver> Wouldn't people hate us for adding diagnostics?
I don't know. Don't Boost.Python and Boost.Serialize produce warnings/notifications if they aren't configured properly? Ok, maybe a diagnostic message is a bad idea :). However, the information about there not being any (official) support for these compilers should be visible to someone who is casually scanning the documentation and any release notes/information. - Reece
"Reece Dunn" <msclrhd@hotmail.com> writes:
David Abrahams wrote:
"Reece Dunn" <msclrhd@hotmail.com> writes:
It may be useful to have 3 levels of support: * officially supported (e.g. CodeWarrior 9.x, gcc, VC8) - compilers that Boost is expected to work with; * not officially supported (e.g. VC6, BCB) - some libraries may work, but there is no requirement to support these compilers;
Sounds good, but I'd like to know, as a practical matter, what the difference between these two is. Less pressure on developers to support the 2nd category?
The first would mean that Boost guarantees support for the specified compiler/version.
What does that mean? Every developer is obligated to make his library work on that compiler? That would be unprecedented (though not out of the question).
The second (possibly with a better name) would mean that there is limited support. That is: * less pressure (or none for VC6 ;)) on developers to support it (as you mention); * no requirement to fix regressions for that toolset (although it might be useful for the users to see the regression results for these compilers so they know what libraries will work).
* not supported (e.g. OpenWatcom) - these haven't been tested for and do not have any Boost.Config/workaround magic to support them.
It may also be useful to make Boost.Config issue a warning that compilers like BCB and VC6 are not officially supported if they are removed from the supported list.
<shiver> Wouldn't people hate us for adding diagnostics?
I don't know. Don't Boost.Python and Boost.Serialize produce warnings/notifications if they aren't configured properly?
Boost.Python produces one during the boost install/build process if it isn't going to be built. No diagnostics are intentionally issued from within headers. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote: "Reece Dunn" [1]<msclrhd@hotmail.com> writes: David Abrahams wrote: Sounds good, but I'd like to know, as a practical matter, what the difference between these two is. Less pressure on developers to support the 2nd category? The first would mean that Boost guarantees support for the specified compiler/version What does that mean? Every developer is obligated to make his library work on that compiler? That would be unprecedented (though not out of the question). If only highly conformant compilers were on the list of 'guaranteed' compilers, then the obligation could be restated that the developers write conformant code and that the compilers be at least X conformant. Then the developers can concentrate not on catering to a broken compiler, and those who insist on using such compilers can bear the brunt of the brokenness - instead of the developers who are donating their time and efforts to help others through their work. Just one lurker's opinion - hopefully one for illumination and not inflamation. Brian References 1. mailto:msclrhd@hotmail.com
Brian Allison <brian@dtmr.com> writes:
David Abrahams wrote:
"Reece Dunn" [1]<msclrhd@hotmail.com> writes:
David Abrahams wrote:
Sounds good, but I'd like to know, as a practical matter, what the difference between these two is. Less pressure on developers to support the 2nd category?
The first would mean that Boost guarantees support for the specified compiler/version
What does that mean? Every developer is obligated to make his library work on that compiler? That would be unprecedented (though not out of the question).
If only highly conformant compilers were on the list of 'guaranteed' compilers, then the obligation could be restated that the developers write conformant code and that the compilers be at least X conformant. Then the developers can concentrate not on catering to a broken compiler, and those who insist on using such compilers can bear the brunt of the brokenness - instead of the developers who are donating their time and efforts to help others through their work. Just one lurker's opinion - hopefully one for illumination and not inflamation.
But how would it change anything? We don't "guarantee" anything today, and I'm pretty sure we won't guarantee anything a year from now either. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote: Brian Allison [1]<brian@dtmr.com> writes: David Abrahams wrote: "Reece Dunn" [1][2]<msclrhd@hotmail.com> writes: David Abrahams wrote: Sounds good, but I'd like to know, as a practical matter, what the difference between these two is. Less pressure on developers to support the 2nd category? The first would mean that Boost guarantees support for the specified compiler/version What does that mean? Every developer is obligated to make his library work on that compiler? That would be unprecedented (though not out of the question). If only highly conformant compilers were on the list of 'guaranteed' compilers, then the obligation could be restated that the developers write conformant code and that the compilers be at least X conformant. Then the developers can concentrate not on catering to a broken compiler, and those who insist on using such compilers can bear the brunt of the brokenness - instead of the developers who are donating their time and efforts to help others through their work. Just one lurker's opinion - hopefully one for illumination and not inflamation. But how would it change anything? We don't "guarantee" anything today, and I'm pretty sure we won't guarantee anything a year from now either. I wasn't suggesting any guarantees be put forth; that's why I used quotes around 'guaranteed'. Perhaps it would have been less imprecise if I had said: If only highly conformant compilers were in the 1st category - presuming such a category had sufficient usefulness to the developers to warrant the concept of categorization - then the users of Boost could be less likely to miss the fact that the only obligation the developers assigned to themselves was attempting to write compliant code which a conforming compiler would therefore accept. Then the developers could concentrate on the expressing the thoughts into code instead of concerning themselves to any great degree with non-conformant platforms. Which would then make it more obvious to the non-developers that the burden of non-conformant compilers is intrinsically on the shoulders of those who choose the non-conformant compilers. Sorry if that's too verbose, I'm under significant workload and didn't take much time on the explanation. Also, I didn't think that the most concise message was the empty set - aplogies if I was mistaken. Brian References 1. mailto:brian@dtmr.com 2. mailto:msclrhd@hotmail.com
Brian Allison <brian@dtmr.com> writes:
But how would it change anything? We don't "guarantee" anything today, and I'm pretty sure we won't guarantee anything a year from now either.
I wasn't suggesting any guarantees be put forth; that's why I used quotes around 'guaranteed'. Perhaps it would have been less imprecise if I had said: If only highly conformant compilers were in the 1st category - presuming such a category had sufficient usefulness to the developers to warrant the concept of categorization - then the users of Boost could be less likely to miss the fact that the only obligation the developers assigned to themselves was attempting to write compliant code which a conforming compiler would therefore accept. Then the developers could concentrate on the expressing the thoughts into code instead of concerning themselves to any great degree with non-conformant platforms. Which would then make it more obvious to the non-developers that the burden of non-conformant compilers is intrinsically on the shoulders of those who choose the non-conformant compilers. Sorry if that's too verbose, I'm under significant workload and didn't take much time on the explanation. Also, I didn't think that the most concise message was the empty set - aplogies if I was mistaken.
The problem is that as you make it more precise, you also make it clear that it's not very meaningful. Even most compilers we'd consider to be "quite conformant" are not without their issues. So, I'd like to see some way of formulating this so that we can all understand what it really means for: users library developers testers (anyone I left out?) -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Brian Allison <brian@dtmr.com> writes:
But how would it change anything? We don't "guarantee" anything today, and I'm pretty sure we won't guarantee anything a year from now either.
The problem is that as you make it more precise, you also make it clear that it's not very meaningful. Even most compilers we'd consider to be "quite conformant" are not without their issues. So, I'd like to see some way of formulating this so that we can all understand what it really means for:
users library developers testers (anyone I left out?)
Ok. Here goes... == Users == There are two categories of users: (1) those who are supporting legacy code bases that rely on or use old compilers (e.g. VC6); (2) those who are flexible about what compiler they use and move to either the latest or previous release of a compiler (e.g. VC7.1 and VC8). The main compilers in question here (disregarding Borland for the moment) are VC6 and GCC2.95.x. Now that MS have dropped support for VC6, should Boost do the same? GCC2.95 is 2 generations old (GCC3 and GCC4 have been released, with GCC3.0 being in the field for some time now). Given that, are there any users that still require GCC2 support? ==> Therfore, it would be reasonable to officially support the most recent version and the one previous. The next question is what compiler vendors should be supported... I think the most popular/used compilers for a platform should be supported: 1. GCC on Linux; 2. GCC and CodeWarrior on Mac; 3. GCC and VC on Windows. I know that this is not a complete picture. Other compilers can be added that are viewed as critical for a given platform. This then gives the core set of compilers that need to be supported. == Library Developers == Other compilers that are not on this list, but are reasonably conformant (i.e. above 90%) should also be supported. Boost doesn't require a library to support broken compilers, so motivation for support here would come from users that target those compilers. The question then becomes how broken should a compiler be before it is not supported. This is blurry and is mainly up to the library developer and how much effort they are willing to spend supporting those compilers [*]. [*] This effort is in terms of finding a workaround, testing that on the target compiler and on other compilers to see if there aren't any regressions. This can be difficult if you don't have access to the compiler/version in question. This may mean cooperating with others in the group who do have access to those compilers, although this can be difficult if the library is in a state of flux and is changing from day-to-day (synchronising effort between you and the Booster who is helping you). == Testers == This is down to how many resources a tester can put into running the tests. It takes a reasonable amount of time and hard drive space to run the regression tests *per compiler, version and platform*. I know that this is distributed across several testers, but there are only a few core testers that run the tests frequently. It also costs money and effort to set up a new compiler/version. - Reece
"Reece Dunn" <msclrhd@hotmail.com> writes:
David Abrahams wrote:
Brian Allison <brian@dtmr.com> writes:
But how would it change anything? We don't "guarantee" anything today, and I'm pretty sure we won't guarantee anything a year from now either.
The problem is that as you make it more precise, you also make it clear that it's not very meaningful. Even most compilers we'd consider to be "quite conformant" are not without their issues. So, I'd like to see some way of formulating this so that we can all understand what it really means for:
users library developers testers (anyone I left out?)
Ok. Here goes...
== Users ==
There are two categories of users: (1) those who are supporting legacy code bases that rely on or use old compilers (e.g. VC6); (2) those who are flexible about what compiler they use and move to either the latest or previous release of a compiler (e.g. VC7.1 and VC8).
The main compilers in question here (disregarding Borland for the moment) are VC6 and GCC2.95.x. Now that MS have dropped support for VC6, should Boost do the same?
Good question. I'm trying to ask you: ** what would doing so mean for users? **
GCC2.95 is 2 generations old (GCC3 and GCC4 have been released, with GCC3.0 being in the field for some time now). Given that, are there any users that still require GCC2 support?
Good question. ** what is GCC2 support? ** ** what would withdrawing it -- assuming we currently offer it -- mean for users? **
==> Therfore, it would be reasonable to officially support the most recent version and the one previous.
I'm trying to ask you: What would making that decision mean for users library developers testers
The next question is what compiler vendors should be supported...
I think the most popular/used compilers for a platform should be supported: 1. GCC on Linux; 2. GCC and CodeWarrior on Mac; 3. GCC and VC on Windows.
I know that this is not a complete picture. Other compilers can be added that are viewed as critical for a given platform. This then gives the core set of compilers that need to be supported.
== Library Developers ==
Other compilers that are not on this list, but are reasonably conformant (i.e. above 90%) should also be supported.
I'm trying to ask you: What would that mean for library developers? For example, are they required to make their libraries work on those supported compilers? Would they lose the ability to see test results for unsupported compilers? etc. Please expound
Boost doesn't require a library to support broken compilers, so motivation for support here would come from users that target those compilers. The question then becomes how broken should a compiler be before it is not supported. This is blurry and is mainly up to the library developer and how much effort they are willing to spend supporting those compilers [*].
[*] This effort is in terms of finding a workaround, testing that on the target compiler and on other compilers to see if there aren't any regressions. This can be difficult if you don't have access to the compiler/version in question. This may mean cooperating with others in the group who do have access to those compilers, although this can be difficult if the library is in a state of flux and is changing from day-to-day (synchronising effort between you and the Booster who is helping you).
== Testers ==
This is down to how many resources a tester can put into running the tests. It takes a reasonable amount of time and hard drive space to run the regression tests *per compiler, version and platform*. I know that this is distributed across several testers, but there are only a few core testers that run the tests frequently. It also costs money and effort to set up a new compiler/version.
How is that any different from today? As far as I can tell, you failed to address my core question. What does making some compilers "supported" and others "not supported" mean for our process, our developers, our users, and our testers? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Good question.
** what is GCC2 support? **
** what would withdrawing it -- assuming we currently offer it -- mean for users? **
Whay it would mean to me, without putting on any user/maintainer/whatever hat, is that the release manager takes it out the list of compilers that must pass regression tests before a new Boost distribution can be released. Current support means that OSL3 runs these tests during a release cycle so maintainers can track/fix bugs on a compiler they may not have installed, or approriately mark up the XML. It improves the chances of customers concerned about supporting that compiler submitting patches. I have an implicit assumption that if a compiler is 'supported' during a release cycle, library maintainers will accept and process workarounds for compilers they do not have access to themselves, when submitted. Taking it off this list would leave me wondering if patches would or would not be accepted. If a maintainer is no longer accecpting patches for a compiler, I would recommend marking the library unsupported on that platform too, for regression tests - even if the library is still in a usable state. That would be a new guideline though, not part of Boost practices today. All my own opinion and of course, inferring meaning from existing non-documented practice. -- AlisdairM
"Alisdair Meredith" <alisdair.meredith@uk.renaultf1.com> writes:
David Abrahams wrote:
Good question.
** what is GCC2 support? **
** what would withdrawing it -- assuming we currently offer it -- mean for users? **
Whay it would mean to me, without putting on any user/maintainer/whatever hat, is that the release manager takes it out the list of compilers that must pass regression tests before a new Boost distribution can be released.
IIUC, what that means is that it be allowed to regress: tests that currently do not fail with GCC2 may start failing with the next release. Is that the effect you are after?
Current support means that OSL3 runs these tests during a release cycle so maintainers can track/fix bugs on a compiler they may not have installed, or approriately mark up the XML. It improves the chances of customers concerned about supporting that compiler submitting patches.
I have an implicit assumption that if a compiler is 'supported' during a release cycle, library maintainers will accept and process workarounds for compilers they do not have access to themselves, when submitted.
Yeah, but they generally will do that for any compiler if adding the workaround doesn't amount to a major rewrite of the library. See, IME the cost of maintaining existing workarounds is next to nothing. It's the cost of adding workarounds for new library features, or for reimplementing workarounds when a library is substantially rewritten, that really hurts. I would have liked it if some of the newer libraries (e.g. Serialization, Range, ...) had been developed without vc6/7 support, because that support forces compromises in the quality of their interfaces. I wonder if Boost declaring those compilers "officially not supported" would have prevented the authors of those libraries from trying to support them anyway. If so, I can see some use in such an official declaration. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> skrev i meddelandet news:uwtiivxay.fsf@boost-consulting.com...
"Reece Dunn" <msclrhd@hotmail.com> writes:
This is down to how many resources a tester can put into running the tests. It takes a reasonable amount of time and hard drive space to run the regression tests *per compiler, version and platform*. I know that this is distributed across several testers, but there are only a few core testers that run the tests frequently. It also costs money and effort to set up a new compiler/version.
How is that any different from today?
As far as I can tell, you failed to address my core question. What does making some compilers "supported" and others "not supported" mean for our process, our developers, our users, and our testers?
It may save us from code looking like this (is_reference.hpp): #ifndef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_reference,T,false) BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_1(typename T,is_reference,T&,true) #if defined(__BORLANDC__) && !defined(__COMO__) && (__BORLANDC__ < 0x600) // these are illegal specialisations; cv-qualifies applied to // references have no effect according to [8.3.2p1], // C++ Builder requires them though as it treats cv-qualified // references as distinct types... BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_1(typename T,is_reference,T& const,true) BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_1(typename T,is_reference,T& volatile,true) BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_1(typename T,is_reference,T& const volatile,true) #endif #if defined(__GNUC__) && (__GNUC__ < 3) // these allow us to work around illegally cv-qualified reference // types. BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_1(typename T,is_reference,T const ,::boost::is_reference<T>::value) BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_1(typename T,is_reference,T volatile ,::boost::is_reference<T>::value) BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_1(typename T,is_reference,T const volatile ,::boost::is_reference<T>::value) // However, the above specializations confuse gcc 2.96 unless we also // supply these specializations for array types BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_2(typename T,unsigned long N,is_reference,T[N],false) BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_2(typename T,unsigned long N,is_reference,const T[N],false) BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_2(typename T,unsigned long N,is_reference,volatile T[N],false) BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_2(typename T,unsigned long N,is_reference,const volatile T[N],false) #endif #else where there is plenty of workarounds, but no real C++ code in sight. This is really more of a Boost specification language than standard C++. If we skip all of the "terribly nonstandard" compilers, we can also remove most of this kind of code. I would see this as a great improvement to the library! Bo Persson
"Bo Persson" <bop@gmb.dk> writes:
As far as I can tell, you failed to address my core question. What does making some compilers "supported" and others "not supported" mean for our process, our developers, our users, and our testers?
It may save us from code looking like this (is_reference.hpp):
<snip> Not likely.
where there is plenty of workarounds, but no real C++ code in sight.
And anyway, why do you care what that code looks like?
This is really more of a Boost specification language than standard C++. If we skip all of the "terribly nonstandard" compilers, we can also remove most of this kind of code.
I would see this as a great improvement to the library!
I would see it as a great way to destabilize something that works for very little benefit. -- Dave Abrahams Boost Consulting www.boost-consulting.com
I haved *no* idea what happened to the formatting of my prior e-mail. First - and hopefully last - time I've ever seen it. David Abrahams wrote: "Reece Dunn" [1]<msclrhd@hotmail.com> writes: David Abrahams wrote: "Reece Dunn" [2]<msclrhd@hotmail.com> writes: It may be useful to have 3 levels of support: * officially supported (e.g. CodeWarrior 9.x, gcc, VC8) - compilers that Boost is expected to work with; * not officially supported (e.g. VC6, BCB) - some libraries may work, but there is no requirement to support these compilers; Sounds good, but I'd like to know, as a practical matter, what the difference between these two is. Less pressure on developers to support the 2nd category? The first would mean that Boost guarantees support for the specified compiler/version. What does that mean? Every developer is obligated to make his library work on that compiler? That would be unprecedented (though not out of the question). If only highly conformant compilers were on the list of 'guaranteed' compilers, then the obligation could be restated that the developers write conformant code and that the compilers be at least X conformant. Then the developers can concentrate not on catering to a broken compiler, and those who insist on using such compilers can bear the brunt of the brokenness - instead of the developers who are donating their time and efforts to help others through their work. Just one lurker's opinion - hopefully one for illumination and not inflamation. Brian References 1. mailto:msclrhd@hotmail.com 2. mailto:msclrhd@hotmail.com
"Reece Dunn" <msclrhd@hotmail.com> skrev i meddelandet news:BAY101-F16FC3D58169D196846F4FDA0410@phx.gbl...
Edward Diener wrote:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
Martin Bonner wrote:
I do not oppose dropping VC 6 and 7 from the list of "release" compilers.
I think it is too soon to drop VC 7.1 from the list of "release" compilers.
I doubt that 7.1 would ever be dropped, as it's too close to conforming and VC 8 has some features that could hinder its acceptance.
(But VC7.0 could probably go).
That sounds great to me. Now what about Borland (wrings hands like Snively Whiplash)? If anything, that's harder to support than vc6 and 7.0!
I understand you are referring to past BCB compilers but I just want to note that Borland is putting out a new release of BCB in case Boost becomes interested. The product, part of the BDS 2006 suite, was supposed to come out December 1 but has been delayed for approximately a month, not a good sign, with the next exact date not given yet.
Just a heads up in case no one from Boost is paying attention to this in the wake of MS's much touted Visual Studio 2005 and VC 8.0.
It may be useful to have 3 levels of support: * officially supported (e.g. CodeWarrior 9.x, gcc, VC8) - compilers that Boost is expected to work with; * not officially supported (e.g. VC6, BCB) - some libraries may work, but there is no requirement to support these compilers;
Slightly supported? :-) One problem with these are that there are *tons* of work around code in most libraries. In some cases there are definitely more fixes that real code. If the support is officially removed, so can workarounds be. This might make some of the code actually readable. :-) Bo Persson
Reece Dunn wrote:
It may also be useful to make Boost.Config issue a warning that compilers like BCB and VC6 are not officially supported if they are removed from the supported list.
As predominantly a BCB user, I obviously have a great concern about this! If the plan is to simply stop supporting these compilers, but leave all the existing workarounds in place, I would be very much against this move - obviously from pure self interest <G> If the intent is to produce clearer maintainable libraries by stripping out the large number of workarounds for very broken compilers, then I could probably swallow my self interest in favour of a cleaner boost. I really don't want the worst of both worlds though - rampant workarounds polluting code, but no actual support. My most pressing concern is that a new Borland compiler just landed in my hands with a new version number, __BORLANDC__ == 0x580. This instantly fails more libraries than the last version, because some libraries coded a workaround specifically for 0x564. I would really like to see those workarounds updated (and will be submitting a list of patches this week) but why would these patches be accepted if there is no more support? As a final note, I could live with future libraries opting not to support these older compilers, but am worried about regressions losing support for the libraries we already have. It might be interesting to pull out a subset of libraries that will go above and beyond the call of duty to continue supporting these products - namely those that already make the effort today, and especially the TR1 libraries. How easy this would be to pull off in the regression testing reports I don't know, but if the trend is for future libraries we will soon have few libraries supported than not, and making the distinction will become more interesting. BTW, early experiments with the new Borland compiler show it has some very significant fixes in the code generator, which never really showed up in the Boost tests. The front end, which Boost does catch, seems to have a similar level of 'boost compatibility' to the previous compiler though. I think it is going to pass more test, but it will be better support for existing libraries, rather than supporting more libraries. Need to do a detect-outdated-workarounds build to be sure though. -- AlisdairM
"AlisdairM" wrote:
If the intent is to produce clearer maintainable libraries by stripping out the large number of workarounds for very broken compilers, then I could probably swallow my self interest in favour of a cleaner boost.
I'd suggested such move (under name Boost 2.0) some time ago: http://lists.boost.org/Archives/boost/2004/03/62626.php In discussion I got convinced this is huge undertaking, not feasible even in long term.
My most pressing concern is that a new Borland compiler just landed in my hands with a new version number, __BORLANDC__ == 0x580. This instantly fails more libraries than the last version, because some libraries coded a workaround specifically for 0x564. I would really like to see those workarounds updated (and will be submitting a list of patches this week) but why would these patches be accepted if there is no more support?
The #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x???)) is used in libraries I had chance to look at. I hope at least this works.
BTW, early experiments with the new Borland compiler show it has some very significant fixes in the code generator, which never really showed up in the Boost tests. The front end, which Boost does catch, seems to have a similar level of 'boost compatibility' to the previous compiler though. I think it is going to pass more test, but it will be better support for existing libraries, rather than supporting more libraries.
Ouch. Not a good news :-( The workarounds using BOOST_TESTED_AT can be switched off (described in docs). It may be interesting to compare number of errors with existing workarounds and without them, whether something in front-end actually got better. /Pavel
Pavel Vozenilek wrote:
I'd suggested such move (under name Boost 2.0) some time ago: http://lists.boost.org/Archives/boost/2004/03/62626.php In discussion I got convinced this is huge undertaking, not feasible even in long term.
That was my understanding too - more work than people wanted to do. However, I would certainly drop my request to maintain Borland support if that was the goal.
The
#if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x???))
is used in libraries I had chance to look at. I hope at least this works.
Not all workarounds are using BOOST_TESTED_AT, but checking <=0x564 as the last released compiler (or 0x570 for Kylix). Many of those still need updating for the new compiler :?( Fortunately, most workarounds ARE using BOOST_TESTED_AT, so it is just a matter of seeing how many are still needed.
It may be interesting to compare number of errors with existing workarounds and without them, whether something in front-end actually got better.
Front end is definitely better, but maybe not in ways that show up in Boost tests. As often commented, Boost tests are not an ISO conformance test, just one heck of a workout ;?) Many of the improvements do not show up, or simply open up the path to the next blocker. Note that Borland admit this compiler is not ready for prime-time yet, and are already planning a further update around the end of the year (so quite soon!) Will see how much more that buys us, but I don't think we will see significant improvements until the next product cycle again. Still has problems with integral constants. Still can't do SFINAE. still has problems with template templates and other constructs it seems to support at first glance. And still no support for TR1 function :( On the bright side, now shipping Dinkumware as the standard library - 3 different vendors for the last 3 versions! (Rogue Wave, STLport, now Dinkumware) -- AlisdairM
AlisdairM wrote:
Pavel Vozenilek wrote:
I'd suggested such move (under name Boost 2.0) some time ago: http://lists.boost.org/Archives/boost/2004/03/62626.php In discussion I got convinced this is huge undertaking, not feasible even in long term.
That was my understanding too - more work than people wanted to do. However, I would certainly drop my request to maintain Borland support if that was the goal.
The
#if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x???))
is used in libraries I had chance to look at. I hope at least this works.
Not all workarounds are using BOOST_TESTED_AT, but checking <=0x564 as the last released compiler (or 0x570 for Kylix). Many of those still need updating for the new compiler :?(
Fortunately, most workarounds ARE using BOOST_TESTED_AT, so it is just a matter of seeing how many are still needed.
It may be interesting to compare number of errors with existing workarounds and without them, whether something in front-end actually got better.
Front end is definitely better, but maybe not in ways that show up in Boost tests. As often commented, Boost tests are not an ISO conformance test, just one heck of a workout ;?) Many of the improvements do not show up, or simply open up the path to the next blocker.
Note that Borland admit this compiler is not ready for prime-time yet, and are already planning a further update around the end of the year (so quite soon!)
What you have is not the real release of their C++ compiler for BDS 2006. They had already announced that they would hold up the official release of the C++ personality of their suite for another month, while they worked out kinks, and that whatever is shipped as part of the C++ personality, to people who ordered the suite under its Delphi or C# name, is merely a trial version. The "further update around the end of the year" which you mention is the real version of their C++ personality for BDS 2006. Still I have little personal hope that Borland will have significantly improved their compiler's C++ standard conformance with the official release but we will not know until that really happens.
On Mon, 5 Dec 2005 20:20:34 +0000 (UTC), AlisdairM wrote
Reece Dunn wrote:
It may also be useful to make Boost.Config issue a warning that compilers like BCB and VC6 are not officially supported if they are removed from the supported list.
As predominantly a BCB user, I obviously have a great concern about this! If the plan is to simply stop supporting these compilers, but leave all the existing workarounds in place, I would be very much against this move - obviously from pure self interest <G>
How about using old versions of Boost until BCB can compile newer ones?
If the intent is to produce clearer maintainable libraries by stripping out the large number of workarounds for very broken compilers, then I could probably swallow my self interest in favour of a cleaner boost.
I'm kinda inclined to do this. There's a ton of ugliness to support these old bad compilers. Problem is that getting rid of these doesn't get rid of all the hacks. We have platforms like MINGW with gcc that work fine -- except for the wide char support. Or the compilers that have weak or no dll support...
...snip...
As a final note, I could live with future libraries opting not to support these older compilers, but am worried about regressions losing support for the libraries we already have. It might be interesting to pull out a subset of libraries that will go above and beyond the call of duty to continue supporting these products - namely those that already make the effort today, and especially the TR1 libraries. How easy this would be to pull off in the regression testing reports I don't know, but if the trend is for future libraries we will soon have few libraries supported than not, and making the distinction will become more interesting.
Well, technically date-time is at mostly supported on some of these old compilers. However, I've been saying for at least 6 months that 1.33 is the last release I'm dealing with VC6. I'm more than happy to ditch Borland too. If someone really has to have an older library they can pull an older version of Boost. A couple of general points I'll make on this. To me the biggest benefit to dropping these old compilers is the reduction in time spent running regression tests, looking at failures, trying to find hacks, etc. The time spent on this takes away from building new libraries, porting to new platforms, and improving C++ libraries. So I'm strongly for this move away from the past -- glad to see it gathering steam... Jeff
Edward Diener <eddielee@tropicsoft.com> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
Martin Bonner wrote:
I do not oppose dropping VC 6 and 7 from the list of "release" compilers.
I think it is too soon to drop VC 7.1 from the list of "release" compilers.
I doubt that 7.1 would ever be dropped, as it's too close to conforming and VC 8 has some features that could hinder its acceptance.
(But VC7.0 could probably go).
That's what I meant.
That sounds great to me. Now what about Borland (wrings hands like Snively Whiplash)? If anything, that's harder to support than vc6 and 7.0!
I understand you are referring to past BCB compilers but I just want to note that Borland is putting out a new release of BCB in case Boost becomes interested. The product, part of the BDS 2006 suite, was supposed to come out December 1 but has been delayed for approximately a month, not a good sign, with the next exact date not given yet.
Right. The fabled EDG-based borland compiler is an old story, full of disappointments. We can always change our mind about BCB later, but I think we have to deal with the compilers we have /today/.
I have made efforts to find out whether the new compiler will be more standard C++ compatible but this has been met by a wall of silence. Borland has pointedly said almost nothing about standard C++ compatibility, while touting all the other IDE related features of the new release, and others who might be privy to this information on Borland's NG are bound by the NDA not to say anything until the product is released.
Just a heads up in case no one from Boost is paying attention to this in the wake of MS's much touted Visual Studio 2005 and VC 8.0.
I'm not paying *a lot* of attention ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com
Edward Diener wrote:
I have made efforts to find out whether the new compiler will be more standard C++ compatible but this has been met by a wall of silence. Borland has pointedly said almost nothing about standard C++ compatibility, while touting all the other IDE related features of the new release, and others who might be privy to this information on Borland's NG are bound by the NDA not to say anything until the product is released.
I hear that on a recent developer conference they claimed ~100% Boost success rate with the new compiler. We'll see.
At 06:28 2005-12-05, Martin Bonner wrote:
----Original Message---- From: Peter Dimov [mailto:pdimov@mmltd.net] Sent: 05 December 2005 13:19 To: boost@lists.boost.org Subject: Re: [boost] Permanently retire VC++ 6?
Paul A Bristow wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Victor A. Wagner Jr. Sent: 05 December 2005 01:02 To: boost@lists.boost.org; boost@lists.boost.org Subject: Re: [boost] Permanently retire VC++ 6? (was:Re:Math/Quaternions compile problem in VC++6)
and I'm all for retiring vc++6.0 support from boost (I've argued this before).
This is long overdue and now that we have a reasonably compliant MSVC compiler that works on Windows 2000 up I can't see any excuse for not dropping support. Things that this work will still work, but if not - tough. (I am not proposing ripping out all the #ifdefs relating the MSVC 6, despite the improvement in readability that might result).
Should we have a straw poll of the lurkers - so that diehards can have their say - and then make a decision?
What do you mean by "dropping support"?
Excellent question.
I am against dropping VC 6 regression tests in general because I want to see what works on it, either for not introducing a regression, or for ensuring compatibility where it's reasonably easy to do so.
I agree with this.
I don't. I've said it before, and I'll say it again. it _costs_ (money, time, effort) to keep the support there, and _not_ just the authors, it cost all of us (unreadable workarounds, extra source (extra time to compile), extra regresson tests being run (the source changed)) For cryng out loud Microsoft has NOT updated KNOWN BUGS in the STL implementation...not even with their (criminal, IMO) SP6 released last year. <opinion...if you don't like my language or "not being complimentary to ALL enteties involved in C++" stop reading now> The ONLY reason MS could have had for that SP6 release was to convince some people that it was still a product, it isn't, hasn't been for 4 years... ALL it has done is kept ALL C++ programmers needing to be aware of that broken compiler</opinion> It's time to let it go along the lines of someone suggesting getting rid of all the #ifdefs etc for vc6, I thnk it would be an interesting idea to see a flavor of the boost libraries that have NO workarounds, period!! straight up "pure" ISO C++.... just so we can all see what "correct" code would really look like. We might also discover that we're still doing workarounds that don't need to be there.
I do not oppose dropping VC 6 and 7 from the list of "release" compilers. I think it is too soon to drop VC 7.1 from the list of "release" compilers. (But VC7.0 could probably go).
-- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
I guess big question here is how Boost.Test behave in this regard. Once Boost.Test drops support for the configuration regression tests became much less useful. I currently struggle exactly with these problems for my update. So I would definitely prefer to drop this annoying legacy. Gennadiy
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
For cryng out loud Microsoft has NOT updated KNOWN BUGS in the STL implementation...not even with their (criminal, IMO) SP6 released last year. <opinion...if you don't like my language or "not being complimentary to ALL enteties involved in C++" stop reading now> The ONLY reason MS could have had for that SP6 release was to convince some people that it was still a product, it isn't, hasn't been for 4 years... ALL it has done is kept ALL C++ programmers needing to be aware of that broken compiler</opinion> It's time to let it go
This isn't about your language -- it's about accuracy. MS wanted to stop all support for VC6, and they tried hard to. Their customers essentially wouldn't let them. MS would like vc6 to die as much as anyone. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u8xuy1hml.fsf@boost-consulting.com...
"Victor A. Wagner Jr." <vawjr@rudbek.com> writes:
For cryng out loud Microsoft has NOT updated KNOWN BUGS in the STL implementation...not even with their (criminal, IMO) SP6 released last year. <opinion...if you don't like my language or "not being complimentary to ALL enteties involved in C++" stop reading now> The ONLY reason MS could have had for that SP6 release was to convince some people that it was still a product, it isn't, hasn't been for 4 years... ALL it has done is kept ALL C++ programmers needing to be aware of that broken compiler</opinion> It's time to let it go
This isn't about your language -- it's about accuracy. MS wanted to stop all support for VC6, and they tried hard to. Their customers essentially wouldn't let them. MS would like vc6 to die as much as anyone.
Sigh, had MS left the IDE alone and only fixed the compiler and related libraries the transition would have happened very quickly. IMHO, of course. Jeff Flinn
David Abrahams <dave@boost-consulting.com> wrote:
This isn't about your language -- it's about accuracy. MS wanted to stop all support for VC6, and they tried hard to. Their customers
I think they actually did : according to http://support.microsoft.com/lifecycle/?p1=3003 , all support for MSVC6 ended 2 months ago. B.
"Bronek Kozicki" <brok@rubikon.pl> writes:
David Abrahams <dave@boost-consulting.com> wrote:
This isn't about your language -- it's about accuracy. MS wanted to stop all support for VC6, and they tried hard to. Their customers
I think they actually did : according to http://support.microsoft.com/lifecycle/?p1=3003 , all support for MSVC6 ended 2 months ago.
Finally! -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
Alisdair Meredith -
AlisdairM
-
Bo Persson -
Brian Allison -
Bronek Kozicki -
Bronek Kozicki -
David Abrahams -
Edward Diener -
Gennadiy Rozental -
Jeff Flinn -
Jeff Garland -
Martin Bonner -
Pavel Vozenilek -
Peter Dimov -
Reece Dunn -
Victor A. Wagner Jr.