From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2004-03-11 06:25:37
Described is an idea how Boost can move on in the future.
By future I mean 2-5 years, definitely not tomorrow or next
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
- 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'.
- 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
- if/when the world moves to C++0x it will be easier
to move Boost there (this is beyond horizont of this
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk