Re: [boost] Boost 2 - development in long term

From: John Fuller (jfuller_at_[hidden])
Date: 2004-03-11 07:40:41

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
>