Re: [boost] Permanently retire VC++ 6?

From: AlisdairM (alisdair.meredith_at_[hidden])
Date: 2005-12-05 15:20:34

Reece Dunn wrote:

> It may also be useful to make Boost.Config issue a warning that
> compilers like BCB and VC6 are not officially supported if they are
> removed from the supported list.

As predominantly a BCB user, I obviously have a great concern about
this!  If the plan is to simply stop supporting these compilers, but
leave all the existing workarounds in place, I would be very much
against this move - obviously from pure self interest <G>

If the intent is to produce clearer maintainable libraries by stripping
out the large number of workarounds for very broken compilers, then I
could probably swallow my self interest in favour of a cleaner boost.

I really don't want the worst of both worlds though - rampant
workarounds polluting code, but no actual support.

My most pressing concern is that a new Borland compiler just landed in
my hands with a new version number, __BORLANDC__ == 0x580.  This
instantly fails more libraries than the last version, because some
libraries coded a workaround specifically for 0x564.  I would really
like to see those workarounds updated (and will be submitting a list of
patches this week) but why would these patches be accepted if there is
no more support?

As a final note, I could live with future libraries opting not to
support these older compilers, but am worried about regressions losing
support for the libraries we already have.  It might be interesting to
pull out a subset of libraries that will go above and beyond the call
of duty to continue supporting these products - namely those that
already make the effort today, and especially the TR1 libraries.  How
easy this would be to pull off in the regression testing reports I
don't know, but if the trend is for future libraries we will soon have
few libraries supported than not, and making the distinction will
become more interesting.

BTW, early experiments with the new Borland compiler show it has some
very significant fixes in the code generator, which never really showed
up in the Boost tests.  The front end, which Boost does catch, seems to
have a similar level of 'boost compatibility' to the previous compiler
though.  I think it is going to pass more test, but it will be better
support for existing libraries, rather than supporting more libraries.

Need to do a detect-outdated-workarounds build to be sure though.

-- 
AlisdairM