Bronek Kozicki wrote:
Maciej Sobczak <prog@msobczak.com> wrote:
Having said that and being still completely serious, I'd drop support for 2.95 and for everything else (VC++6.0, others?)
BCB ?
Just released a new version in the last few weeks, and from initial tests is not significantly improved in its performance on Boost regression tests (although there ARE significant bug fixes in this compiler - Boost tests simply did not stress those cases) I was going to submit the BCB2006 patches last week, but suffered a hardware failure on my test box - so will be without PC for a week or so while it is mailed away for repair. I would be quite upset if library authors stopped accepting workarounds to support this compiler if I submit them - I have no problems with library authors waiting for BCB users to submit patches, rather than researching them themselves. If it was easy to move to a more conforming compiler I suspect a lot of Borland customers would already have done so (many of those who could, have) These customers are not in the same position as VC6 or GCC2.95 users, where the vendor has already delivered several generations of significantly more conforming compilers - we ARE using the latest and greatest Borland offering, and are still pressuring the company over commitments to a better compiler. Borland have finally woken up to BCB again after a long rest focussing in different directions, and it would be something of a disaster for us (Borland customers) if Boost were to drop support now. I would like a cleaner Boost codebase without workarounds, no doubt. But until we are talking about removing the clutter from all libraries (and I suspect the 80/20 rule applies - 80% of workarounds are for the 20% of broken compilers you want to stop supporting) I will fight for BCB to continue being supported - as we are already paying for the pollution in the codebase already. -- AlisdairM