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