Boost 2 - development in long term
Described is an idea how Boost can move on in the future. By future I mean 2-5 years, definitely not tomorrow or next month. Support for sub-standard compilers is taking away lot of time and energy of library writers. It also makes result code quite hard to understand and modify. Shouldn't only so many people be stuck with old equipment... What could be done: - create branch or fork of Boost in CVS, say Boost 2. - this project will have exactly the same structure as current Boost (directories/libraries/tests). - the project will be initially empty. - one by one, libraries will be removed of kludges, and workarounds (all of them, w/o exceptions) and copied into Boost 2. This includes: - fixes for nonconforming compilers (#ifdef BOOST_MSVC ...) - fixes for substandard STL (e.g. old Dinkumware) - fixes to deal with missing exception support - the converted libraries will be tested only with very recent compilers which are supposed to be conformant (GCC 3.4, VC8, Intel C++ 8, Metrowerks 9.2, Comeau). Why this may work: - all existing infrastructure (the tests) could be reused w/o change. - no need to deal with non-standard systems makes the cleanup less time consuming. - with no need to deal with non-standard systems it may be interesting work and fun for library writers, again. - compiler vendors may take it as incentive to improve their system, rather to rely on people will find workarounds. This effect can be already seen today. What would it require: - some site with latest compilers which would continually and automatically run all the tests. Not all people have access to newest tools. - the cleanup could be done by original library author or by someone who feels knowledgeable with it. - core libraries need to be identified and ported first. What to do with current Boost 1.XX: - the development will continue as it is now, as long as needed and feasible (my guess are few years more). - new libraries will be added into Boost 1.XX and may or may not contain legacy compilers support (as it is now). They will be eventually added into Boost 2 in 'clean state'. Problems: - how to keep both branches up to date with fixes and changes? This is real problem and should be solved by requiring every change in Boost 1.XX be considered for Boost 2. Backporting from Boost 2 to Boost 1.XX would be optional but rare. Hopefully most libraries are rather mature and don't go through major rewrites. Even if so, making clean version should be relatively painless. - should there be two sets of documentation? No, the documentation should not change except removing information about old systems support. This should be reasonably easy. - woudln't people with old compilers feel abandoned? Yes, but development for 1.XX should continue as long as needed/feasible. In few years hopefully support for VC6 and Borland will dimish. - there's no time to do yet more work: this should be long term project. Individual libraries can be ported at individual pace and independently. - code without kludges may not compile on ANY existing compiler: so be it. Next version of compiler will be hopefully better. Workarounds should be forbidden or very, very rare. Who will benefit of this all: - library writers who do not want to support old systems (less pressure on them) may spend more time with design. This gets more important if more powerfull/complex libraries will emerge. - users with new compilers (they can be more sure the library remains maintainable and may even be able to understand its inner, too). Their existing code using Boost should compile without changes. - compiler vendors will be able catch more errors. - standard comittee may be more interested in clean code. - if/when the world moves to C++0x it will be easier to move Boost there (this is beyond horizont of this idea though). What it it all fails: - Boost 1.XX should be unaffected by branching and could continue as if nothing had happened. I remind again this idea is about long term development of Boost. I think it has biggest effect for the effort spent. /Pavel
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> writes:
Who will benefit of this all: - library writers who do not want to support old systems (less pressure on them) may spend more time with design. This gets more important if more powerfull/complex libraries will emerge.
All this for less pressure on a few authors? These authors may simply refuse to support older compilers today.
- users with new compilers (they can be more sure the library remains maintainable and may even be able to understand its inner, too). Their existing code using Boost should compile without changes.
That sounds like a break-even to me.
- compiler vendors will be able catch more errors.
How?
- standard comittee may be more interested in clean code.
I doubt it. Historically, the committee isn't particularly interested in our implementations, only in our interfaces.
- if/when the world moves to C++0x it will be easier to move Boost there (this is beyond horizont of this idea though).
How so? Sorry, but I just don't see what problem this is solving. The proposal is a huge undertaking, today or next year, and I don't see any benefits that would make it worth the trouble. Furthermore, compilers will always be broken and require workarounds here and there; you won't be able to keep them from creeping in, and I don't think it's desirable to. Part of the point of Boost is to have code that's usable in the real world. -- Dave Abrahams Boost Consulting www.boost-consulting.com
I appreciate the idea of phasing out support for older compilers, but the lifecycle of the language strikes me as different from a binary compliant./noncompliant decision since the language and the features supported by compilers come out iteratively and in different development cycles. It seems like compilers are perpetually in some stage falling short of the standard. While many now support partial specialization, there aren't a lot that support the export keyword for example, and I imagine with C++0x (2008?) there will be a similar extent of time while compilers catch up with sets of supported features at a time. On Mar 11, 2004, at 5:25 AM, Pavel Vozenilek wrote:
Described is an idea how Boost can move on in the future. By future I mean 2-5 years, definitely not tomorrow or next month.
Support for sub-standard compilers is taking away lot of time and energy of library writers. It also makes result code quite hard to understand and modify. Shouldn't only so many people be stuck with old equipment...
What could be done: - create branch or fork of Boost in CVS, say Boost 2.
- this project will have exactly the same structure as current Boost (directories/libraries/tests).
- the project will be initially empty.
- one by one, libraries will be removed of kludges, and workarounds (all of them, w/o exceptions) and copied into Boost 2. This includes: - fixes for nonconforming compilers (#ifdef BOOST_MSVC ...) - fixes for substandard STL (e.g. old Dinkumware) - fixes to deal with missing exception support
- the converted libraries will be tested only with very recent compilers which are supposed to be conformant (GCC 3.4, VC8, Intel C++ 8, Metrowerks 9.2, Comeau).
Why this may work: - all existing infrastructure (the tests) could be reused w/o change.
- no need to deal with non-standard systems makes the cleanup less time consuming.
- with no need to deal with non-standard systems it may be interesting work and fun for library writers, again.
- compiler vendors may take it as incentive to improve their system, rather to rely on people will find workarounds. This effect can be already seen today.
What would it require: - some site with latest compilers which would continually and automatically run all the tests. Not all people have access to newest tools.
- the cleanup could be done by original library author or by someone who feels knowledgeable with it.
- core libraries need to be identified and ported first.
What to do with current Boost 1.XX: - the development will continue as it is now, as long as needed and feasible (my guess are few years more).
- new libraries will be added into Boost 1.XX and may or may not contain legacy compilers support (as it is now). They will be eventually added into Boost 2 in 'clean state'.
Problems: - how to keep both branches up to date with fixes and changes? This is real problem and should be solved by requiring every change in Boost 1.XX be considered for Boost 2. Backporting from Boost 2 to Boost 1.XX would be optional but rare.
Hopefully most libraries are rather mature and don't go through major rewrites. Even if so, making clean version should be relatively painless.
- should there be two sets of documentation? No, the documentation should not change except removing information about old systems support. This should be reasonably easy.
- woudln't people with old compilers feel abandoned? Yes, but development for 1.XX should continue as long as needed/feasible. In few years hopefully support for VC6 and Borland will dimish.
- there's no time to do yet more work: this should be long term project. Individual libraries can be ported at individual pace and independently.
- code without kludges may not compile on ANY existing compiler: so be it. Next version of compiler will be hopefully better. Workarounds should be forbidden or very, very rare.
Who will benefit of this all: - library writers who do not want to support old systems (less pressure on them) may spend more time with design. This gets more important if more powerfull/complex libraries will emerge.
- users with new compilers (they can be more sure the library remains maintainable and may even be able to understand its inner, too). Their existing code using Boost should compile without changes.
- compiler vendors will be able catch more errors.
- standard comittee may be more interested in clean code.
- if/when the world moves to C++0x it will be easier to move Boost there (this is beyond horizont of this idea though).
What it it all fails: - Boost 1.XX should be unaffected by branching and could continue as if nothing had happened.
I remind again this idea is about long term development of Boost. I think it has biggest effect for the effort spent.
/Pavel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, 11 Mar 2004 12:25:37 +0100, Pavel Vozenilek wrote I appreciate the sentiment of trying to save time, but unfortunately I believe the 'branch' approach creates the opposite result. As ugly as the code for the old compilers is, it is still easier to maintain than 2 branches.
...lots o stuff snipped... Why this may work: - all existing infrastructure (the tests) could be reused w/o change.
Not true. Tests in date-time adapt themselves based on the config so that some tests are excluded/automatically failed for some compilers without actually compiling the code. Other libraries may need similar changes to support your proposal.
...more details snipped... - new libraries will be added into Boost 1.XX and may or may not contain legacy compilers support (as it is now). They will be eventually added into Boost 2 in 'clean state'.
I believe this is the best idea in your post. I would be fine if new libraries ignore regression tests for old compilers. I think we already have a way of marking this in the regression tests, but this might be a way of saving the folks that run the regression tests time. And this would have the effect of freezing boost at the current level for users of old compilers. Over time this might become a significant incentive to move forward.
Hopefully most libraries are rather mature and don't go through major rewrites. Even if so, making clean version should be relatively painless.
I don't think you can assume this. For example, there is still work on smart pointers which have been around forever. Jeff
Jeff Garland wrote:
On Thu, 11 Mar 2004 12:25:37 +0100, Pavel Vozenilek wrote
I appreciate the sentiment of trying to save time, but unfortunately I believe the 'branch' approach creates the opposite result. As ugly as the code for the old compilers is, it is still easier to maintain than 2 branches.
This is true only for a little while. Eventually support for Boost 1.x would go away and only changes would be made to the new Boost 2.x, which would be much easier to maintain.
...lots o stuff snipped... Why this may work: - all existing infrastructure (the tests) could be reused w/o change.
Not true. Tests in date-time adapt themselves based on the config so that some tests are excluded/automatically failed for some compilers without actually compiling the code. Other libraries may need similar changes to support your proposal.
...more details snipped... - new libraries will be added into Boost 1.XX and may or may not contain legacy compilers support (as it is now). They will be eventually added into Boost 2 in 'clean state'.
I believe this is the best idea in your post. I would be fine if new libraries ignore regression tests for old compilers. I think we already have a way of marking this in the regression tests, but this might be a way of saving the folks that run the regression tests time. And this would have the effect of freezing boost at the current level for users of old compilers. Over time this might become a significant incentive to move forward.
The problem I have is, if leaving the decision of what compilers to support up to the library author results in one Boost library that works with compiler A and B, but not C, while others work with compiler A and C, but not B. It can be very confusing to someone who's looking at using Boost and they want to know if Boost supports their compiler. There REALLY should be a standard for this. Or is there and I'm missing something? Look at the Tiny Template Library versions of some of the Boost libraries and tell me it's 100x easier to read, understand, and make changes to because it's written only for compliant compilers. It's also much faster to compile as well. Now, I understand that Boost should be usable on as many compilers as possible. However, there's a point where you just need to use the features of C++ and forget about some of the older non-compliant compilers. Many older libraries that are still in use today don't use namespaces or templates, because at the time they were written there wasn't much support for it. These libraries now seem old and outdated because of this. Boost supports namespaces and templates even though there are still old compilers out there that don't support them. Why? Because most compilers DO support them. If you always tried to write software for the lowest common denominator of compilers then you couldn't write anything useful. My point is, there will be a point in time where most compilers support template partial specialization, etc, and all that extra code that adds support to outdated compilers is way more trouble than it'll be worth. We obviously aren't at that point right now, but at some point we will be. I don't think having Boost 2.x contain NO compiler hacks is a good thing, but it would be nice if there was a Boost feature list of all C++ features compilers must support to use Boost. These features could be added to the list when it's generally accepted that most compilers support these features, so then library writers can stop writing hacks to support those outdates compilers and even remove hacks to make the code smaller, cleaner, and easier to understand and maintain. Rob
Robert Geiman wrote:
The problem I have is, if leaving the decision of what compilers to support up to the library author results in one Boost library that works with compiler A and B, but not C, while others work with compiler A and C, but not B. It can be very confusing to someone who's looking at using Boost and they want to know if Boost supports their compiler. There REALLY should be a standard for this. Or is there and I'm missing something?
Spirit has already made bcc32 obsolete in boost-1.31 so I've stuck with 1.30.2. I know I can get spirit elsewhere and not use the boost version, but I like the fact that I have a single external library to keep track of the version. I am happy with boost-1.30.2 but as one library has already dropped support for my compiler, I'll probably stick with 1.30.2 until Borland's new compiler comes out or I move to a different compiler (which definitely won't happen in the near future). As I've said before, I'm happy for support for this compiler to stop because once one library that did work doesn't new versions of boost can suddenly become useless if your current work depends on that library. The replies to this were leave it up to the individual library maintainers. This is fine, but some of them may be going through much effort to support an old compiler the other maintainers have decided to drop, consequently users of that compiler may not move to newer versions of boost because parts they rely on nolonger function. Cheers Russell
Robert Geiman <rgeiman@buckeye-express.com> writes:
My point is, there will be a point in time where most compilers support template partial specialization, etc, and all that extra code that adds support to outdated compilers is way more trouble than it'll be worth. We obviously aren't at that point right now, but at some point we will be.
I don't think having Boost 2.x contain NO compiler hacks is a good thing, but it would be nice if there was a Boost feature list of all C++ features compilers must support to use Boost. These features could be added to the list when it's generally accepted that most compilers support these features, so then library writers can stop writing hacks to support those outdates compilers and even remove hacks to make the code smaller, cleaner, and easier to understand and maintain.
Are you volunteering to manage this project? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Robert Geiman <rgeiman@buckeye-express.com> writes:
My point is, there will be a point in time where most compilers support template partial specialization, etc, and all that extra code that adds support to outdated compilers is way more trouble than it'll be worth. We obviously aren't at that point right now, but at some point we will be.
I don't think having Boost 2.x contain NO compiler hacks is a good thing, but it would be nice if there was a Boost feature list of all C++ features compilers must support to use Boost. These features could be added to the list when it's generally accepted that most compilers support these features, so then library writers can stop writing hacks to support those outdates compilers and even remove hacks to make the code smaller, cleaner, and easier to understand and maintain.
Are you volunteering to manage this project?
LOL, no, I unfortunately barely have enough free time to keep up with the posts on the Boost mailing list. ;) Rob
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
I appreciate the sentiment of trying to save time, but unfortunately I believe the 'branch' approach creates the opposite result. As ugly as the code for the old compilers is, it is still easier to maintain than 2 branches.
Yes, it is easier to keep with current state now and 'cleanup' would take many months or couple of years effort. It may (or may not) be outweighted in future with better maintenability and lower entry barier for users.
- all existing infrastructure (the tests) could be reused w/o change.
Not true. Tests in date-time adapt themselves based on the config so that some tests are excluded/automatically failed for some compilers without actually compiling the code. Other libraries may need similar changes to support your proposal.
- new libraries will be added into Boost 1.XX and may or may not contain legacy compilers support (as it is now). They will be eventually added into Boost 2 in 'clean state'.
I believe this is the best idea in your post. I would be fine if new libraries ignore regression tests for old compilers. I think we already have a way of marking this in the regression tests, but this might be a way of saving the folks that run the regression tests time. And this would have
The test may be left unchanged. Config would be used only by them. the
effect of freezing boost at the current level for users of old compilers. Over time this might become a significant incentive to move forward.
I use now BCB heavily and prefere new libraries working there, if possible. However in few years I'll surely be using conformant system and then clean code will be advantage. /Pavel
participants (2)
-
David Abrahams -
David Bergman -
Jeff Garland -
John Fuller -
Pavel Vozenilek -
Peter Dimov -
Robert Geiman -
Russell Hind