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