Re: [boost] Deprecation and Boost

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2006-05-08 03:48:50

Jeff Garland wrote:

> Nicola Musatti wrote:
> 
>>I don't agree. Why remove a support that is there and has been through 
>>several Boost releases? I understand that library authors wishing to 
>>evolve their libraries are entitled to choose which compilers they plan 
>>t osupport and the amount of effort they wish to devote to supporting 
>>obsolete compilers, but if it works, why break it?
> 
> Because, I have to maintain several versions of code that have the 
> potential for different bugs.  In date_time the from_string/to_string 
> methods were written early on and were carefully crafted to work with 
> VC6, Borland, etc.  Even now, like yesterday actually, a new failure 
> mode will show up in these functions.  In the meantime, I've completely 
> rewritten the i/o subsystem -- it's much more flexible and robust.  It 
> supports wide chars, is heavy on templates, and breaks on a bunch of old 
> compilers -- basically it's disabled on all the legacy compilers.

Actually I meant something different. I agree that library authors 
should feel free to exploit the language in full and not waste time in 
trying to support hopelessly uncompliant compilers, especially since, as 
you say later in your post, they're a species becoming extinct.

Even from my personal point of view although such an evolution means 
that I'll be even more deeply stuck with an older version of Boost, this 
state of things provides me with more arguments with which to press 
Borland for a change of things.

What I would not like is libraries that do work with my compiler to 
suddenly break just because a #error directive was put in some config 
header.

> Now I could trivially rewrite the from_string/to_string using the new 
> i/o code and fix any issues in one place, but I can't do it without 
> breaking old compiler support.  In addition, I have a second variant of 
> i/o code on the old compilers to maintain and fix bugs for. And last, 
> but not least, the only reason date_time isn't header-only at this point 
> is the legacy i/o code.

I don't know enough about your library to comment; I'm just happy to use 
it, albeit in an earlier incarnation. I do wonder however whether 
header-only is a goal worth pursuing in itself.

> So all of this is a big pain for me and that's why I'm so vocal about 
> this release being the end of the line for date_time support of old 
> compilers and standard libraries.  When I look at the global boost 
> situation it pains me to see library authors dedicated to defining and 
> evolving the future of C++ spending their time trying to make these 
> non-compliant tools work.  Every minute they spend adjusting for the old 
> compilers is a minute taken away from something better for the future of 
> C++ programmers overall. It's my judgment overall that we've crossed 
> over the line where it's far better for us to focus on the future rather 
> than the past.  A Boost-wide deprecation of the old compilers/standard 
> libs takes the brakes off the forward progress.

I understand your point of view and, again, I agree that library authors 
should feel free not to waste time supporting non compliant compilers, 
but why constrain those that are willing to do so?

> BTW, as a little note of history, when I first used Boost 5 or 6 years 
> ago now, many of the libraries were only 'marginally portable' -- mostly 
> because typical compilers of the day were VC6 and g++ 2.93.  All sorts 
> of libraries broke different compilers in different ways.  The standard 
> libraries of the day were mostly just bad. Now we have a whole breed of 
> excellent compilers/standard libs that will compile and run a much 
> larger collection of Boost libraries.  This is a huge leap forward from 
> where we were.  I believe part of that progress was brought about by 
> Boost "pushing things" forward.  The way I see it, without Boost 
> continuing to push, much of the life would come out of the C++ 
> evolution.  I want to maximize the push now because we still have much 
> work to do.

Don't I know it! When I started using Boost the Borland compiler could 
be considered better compliant than both VC++ and g++ and wasn't 
supported as well as the others were only because it was much less 
popular. Now the other compilers and Boost have leapt forward and I'm 
stuck with virtually the same compiler I had back then.

In a way I'm sort of happy I wasn't around when the Borland compiler 
*was* the leading edge. I don't think I would have survived that kind of 
frustration :-)

Cheers,
Nicola Musatti