On Sun, 8 Jan 2006 19:50:14 -0500, Douglas Gregor wrote

On Jan 8, 2006, at 7:18 PM, Beman Dawes wrote:

...

I could just mark all the failures as expected, but if no one cares anymore then we ought to stop testing 2.95.3, free up the testing resources and stop pestering Boost developers about 2.95.3 failures.

Seems like a good idea. Let's get rid of 2.95.3.

I concur -- it's time to drop support for this old thing. Jeff

On Jan 8, 2006, at 9:45 PM, David Abrahams wrote:

"Jeff Garland" <jeff@crystalclearsoftware.com> writes:

...

On Sun, 8 Jan 2006 19:50:14 -0500, Douglas Gregor wrote

...

On Jan 8, 2006, at 7:18 PM, Beman Dawes wrote:

...

I could just mark all the failures as expected, but if no one cares anymore then we ought to stop testing 2.95.3, free up the testing resources and stop pestering Boost developers about 2.95.3 failures.

Seems like a good idea. Let's get rid of 2.95.3.

I concur -- it's time to drop support for this old thing.

Again I have to ask: what does it mean for Boost to support (or not) a particular compiler?

In my opinion, it means: 1) We have consistent testing resources verifying the status of Boost on that compiler, e.g., the nightly regression tests that OSL is running for GCC 2.95.3 2) The platform is marked as "required" in the explicit-markup- failures.xml file, so tests for that library need to either run correctly, marked unusable, or marked as an expected failure. 3) The platform will be listed as "Supported" for releases (see the bottom of the main Boost page). Actually, #1 and #2 are the criteria I used for creating the list of supported compilers, which is new as of the 1.33.x series.

Maybe we ought to be instituting a firmer notion of what "supported" means.

Does the above qualify? Doug

On Sun, 08 Jan 2006 21:45:49 -0500, David Abrahams wrote

"Jeff Garland" <jeff@crystalclearsoftware.com> writes:

...

On Sun, 8 Jan 2006 19:50:14 -0500, Douglas Gregor wrote

...

On Jan 8, 2006, at 7:18 PM, Beman Dawes wrote:

...

I could just mark all the failures as expected, but if no one cares anymore then we ought to stop testing 2.95.3, free up the testing resources and stop pestering Boost developers about 2.95.3 failures.

Seems like a good idea. Let's get rid of 2.95.3.

I concur -- it's time to drop support for this old thing.

Again I have to ask: what does it mean for Boost to support (or not) a particular compiler?

NOT supported means to me the following: 1) No regression tests are run against the compiler 2) No new libraries will be ported to the compiler/platform 3) Existing libs can remove work-arounds in code The big one, to me, is #1 because it removes work for testers and library authors.

Maybe we ought to be instituting a firmer notion of what "supported" means.

Agreed. Jeff

Vladimir Prus wrote:

Not that I care about 2.95 either, but I think the reasoning in this thread is a bit faulty. Developers just say "it's too old and non-conforming". But who knows what's used in practice, especially outside of bleeding-edge Linux distros?

Even conservative distributions like Debian use gcc 3 now. If a Linux (or any other OS) distribution still uses gcc 2 then it is unlikely the distribution wants to support modern versions of Boost, anyway (if it supports Boost at all). Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com

Martin Wille wrote:

Vladimir Prus wrote: If a Linux (or any other OS) distribution still uses gcc 2 then it is unlikely the distribution wants to support modern versions of Boost, anyway (if it supports Boost at all).

FWIW the latest QNX 6.3.0 distro has gcc 2.95.3 as its default compiler although it also ships with gcc 3.3.5. I did try running regression tests with it at one stage but it threw up many errors. I don't think anyone in their right mid would start a new project with gcc 2.95.3, but I know there are developers out there using gcc 2.95.3 on existing long-term projects. At least one of them has enquired whether he can use the smart_ptr library to solve a problem that has been bothering them for some time. The work involved in changing compiler versions during a project is not insignificant. Maybe I could suggest that we could clearly mark those libraries that will/not work with 2.95.3 and gradually withdraw support for new development? Bear in mind that in my case I have to consider the use of the old 2.95.3 compiler with the much more modern Dinkum C++ standard library (as well as the associated old GNU C++ library). I will try to ascertain what QSSL's future plans are for the older compiler and library and report back. Regards Jim Douglas

Roger Leigh <rleigh@whinlatter.ukfsn.org> writes:

Reading mailing lists and usenet, the only people who are still dependent upon GCC 2.95 are typically proprietary software vendors who are stuck with it for ABI reasons, and rarely the odd person who finds a regression in a newer GCC, but didn't bother reporting it, and lazy people who couldn't be bothered to upgrade. Those using it purely for ABI stability will generally never move to a newer GCC or libstdc++, or even upgrade any of the system libraries, so I wouldn't treat them too seriously for ongoing development.

The embedded world always lags quite a bit in their ability to upgrade, yet they really want (and can benefit from) the facilities of Boost. Witness QNX. -- Dave Abrahams Boost Consulting www.boost-consulting.com

On Mon, 9 Jan 2006 12:24:51 +0300, Vladimir Prus wrote

On Monday 09 January 2006 12:00, Gennadiy Rozental wrote:

...

I support this. Pre 3.0.0 release is a cause for huge number of workarounds. Specifically related to classic IO and weak templates support. Lets get rid of these.

Not that I care about 2.95 either, but I think the reasoning in this thread is a bit faulty. Developers just say "it's too old and non- conforming". But who knows what's used in practice, especially outside of bleeding-edge Linux distros?

I agree it would be nice to know what's used in practice, but that's hard to gauge directly. GCC 2.95.3 was released in March 2001, GCC 3.0 in June 2001. I can't remember the last major Linux distro I played with using 2.95.x as the compiler, but I think it was some version of Mandrake in 2002. Stepping back to a more global perspective, software needs to move on and it's my view that boost in particular needs to shed the harness of old compilers. The talented people on this list waste too much time with the burden of issues for these old compilers. gcc 2.95.x and msvc 6 still have support by old boost releases for folks that can't move forward. Maybe we need a page on the website to describe that 1.34 is the end of support for the old guard compilers. Yes, it means they don't have access to the latest and greatest stuff in boost, but that's also true of C++ since they are using old bad compilers.

Maybe, the procedure for retiring compilers should including posting a message with prominent subject to boost-users and waiting for a couple of weeks for feedback?

No disagreement with that. Jeff

"Paul A Bristow" <pbristow@hetp.u-net.com> writes:

May I suggest an announcement at each release of Boost of 'things to become no longer supported in the next release'? This might include Boost code that has gone beyond the 'deprecated' state (which might longer), as well as support for platforms, compilers etc.

This would give people a bit more time to adjust their plans.

Great idea. -- Dave Abrahams Boost Consulting www.boost-consulting.com

Vladimir Prus wrote:

Not that I care about 2.95 either, but I think the reasoning in this thread is a bit faulty. Developers just say "it's too old and non-conforming". But who knows what's used in practice, especially outside of bleeding-edge Linux distros?

LynxOS here (distributed real-time control systems), with g++ 2.95 toolchain. No way to upgrade for the foreseeable future due to the complex net of dependencies between components, some of which are not our own. Since g++ changed ABI in the meantime, upgrading the compiler means that the whole world needs to be recompiled and relinked. This is what makes the upgrade near to impossible. I try to promote Boost for development here and there's a lot of "resistance". If Boost drops support for 2.95, it might be an additional argument against using Boost at all. (On the other hand, if we're using stone-age compilers, we might as well stick to some existing Boost version - if it's accepted for use - and just not follow its evolution. That's still fine, because the most fundamental Boost libraries are already stable and useable.) This is not to tell you that you should keep supporting stone-age compilers forever, just to show that the world is not composed of only latest Linux distros that we can get with the Sunday's newspaper. There are companies and institutions that are bound to older compilers and cannot just press the "upgrade" button. Having said that and being still completely serious, I'd drop support for 2.95 and for everything else (VC++6.0, others?) that's already not supported even by the company or organization that made it. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/

Bronek Kozicki wrote:

Maciej Sobczak <prog@msobczak.com> wrote:

...

Having said that and being still completely serious, I'd drop support for 2.95 and for everything else (VC++6.0, others?)

BCB ?

Just released a new version in the last few weeks, and from initial tests is not significantly improved in its performance on Boost regression tests (although there ARE significant bug fixes in this compiler - Boost tests simply did not stress those cases) I was going to submit the BCB2006 patches last week, but suffered a hardware failure on my test box - so will be without PC for a week or so while it is mailed away for repair. I would be quite upset if library authors stopped accepting workarounds to support this compiler if I submit them - I have no problems with library authors waiting for BCB users to submit patches, rather than researching them themselves. If it was easy to move to a more conforming compiler I suspect a lot of Borland customers would already have done so (many of those who could, have) These customers are not in the same position as VC6 or GCC2.95 users, where the vendor has already delivered several generations of significantly more conforming compilers - we ARE using the latest and greatest Borland offering, and are still pressuring the company over commitments to a better compiler. Borland have finally woken up to BCB again after a long rest focussing in different directions, and it would be something of a disaster for us (Borland customers) if Boost were to drop support now. I would like a cleaner Boost codebase without workarounds, no doubt. But until we are talking about removing the clutter from all libraries (and I suspect the 80/20 rule applies - 80% of workarounds are for the 20% of broken compilers you want to stop supporting) I will fight for BCB to continue being supported - as we are already paying for the pollution in the codebase already. -- AlisdairM

Edward Diener wrote:

I am not trying to get Boost to not support BCB, since I have used it significantly in the past and am using its prior release, BCB6, currently on a project on which I am working but...

I appreciate that, and your many contributions to the Borland community at the time.

1) I submitted a number of compiler bug reports in Borland's bug tracking system circa late 2002, and one even in 2000, many of which were taken from Boost's reports and verified by myself. I provided test code to show the bugs in the compiler.

2) Very few of these have been fixed in the latest release of their compiler, while a great many still remain, are supposedly still open and being "investigated" still over 3 years later.

The public status of bug reports at Borland is a little strange. There is not a lot between 'bug reported' and 'bug fixed', so it is hard to see when work is happening. Note that quite some time in those 3 years was spent developing another C++ product, C++BuilderX, which would not be back-compatible for existing projects, but would have a new conforming compiler based on an EDG front end. That project seems to be on hold, as customers obviously wanted to take their old code with them! So progress on BCB6 issues will appear slow if you think in terms of 4 years work - unfortunately that has not been the case.

This shows to me, unfortunately, that Borland is still not serious about fixing compiler bugs

I know Borland spent significant time solving bugs with object lifetimes. These are far more significant to 'regular' users and would affect usage of Boost libraries too - simply not in your average regression test case that does not look for how many times destructors were called, or that they are called on valid objects. The fixes for intialization, and aggregate handling that comes with it, at least mean BCB2006 should pass the array tests - although I am not aware of any other new passes yet. I am not sure if the benefit shows up anywhere else in Boost though. Many of the assertions in the compiler now give error messages where they could not be easily fixed - so at least there is a chance of diagnosing the problem and putting in a workaround. It would be better if there was no compiler bug at all, but this is progress. I know there were also fixes in preprocessor, and a little bit on the template handling. There clearly remains quite a bit of work though :?( Now that a lot of re-engineering of the toolchain has been finished, I am optimistic that we will continue to see compiler fixes at a faster rate - although I fear it will be some time before we see a 'fully' conforming compiler. -- AlisdairM

David Abrahams wrote:

Edward Diener <eddielee@tropicsoft.com> writes:

...

So while I have always been a supporter of Borland in the past I do not see that they are serious about fixing their compiler bugs, or even consider it important to do so.

Maybe we should move on, then. At this point they may need us more than we need them.

Discussions of "us" (Boost) and "them" (Borland) is leaving someone out: the developers who need both us /and/ them to play nice. That said, I haven't seen any Borland regression results in a loooong time. Borland support is pretty much a non-starter unless we can get regular test results. -- Eric Niebler Boost Consulting www.boost-consulting.com

David Abrahams wrote:

No developers need us to play nice with Borland in 1.34. Anyone currently using Boost could stick with 1.33.

The difference between BCB and MSVC6 and GCC 2.95 is that Borland are still releasing compilers. There is a new Borland compiler out that will not work with Boost out-the-box because workarounds need updating for the version check. Not all code is written with BOOST_TESTED_AT, and some code makes assumptions that Borland finally gave up with the last compiler. If Boost stop taking workarounds, Borland customers have the option of staying with Boost 1.33 AND THE OLD COMPILER, or migrating their whole codebase to another toolchain - which is not very appealing when your entire GUI is designed around the Borland libraries. My guess is that most customers where it was economical to migrate to another vendor have already done so, given the last 4 years lack of support from Borland. Most of the rest really need both the continued compiler fixes, and ongoing boost support for those existing libraries that compile today. -- AlisdairM