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