From: Robert Geiman (rgeiman_at_[hidden])
Date: 2004-03-11 10:33:59
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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk