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

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 
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