2011/7/19 James Mansion <james@mansionfamily.plus.com>:
On Mon, 18 Jul 2011 12:16:36 +0100, Sebastian Karlsson <sairony@gmail.com> wrote:
I think it's counter productive to tailor code around vendor specific work arounds, instead the vendors should fix their issues. It's better
This is an appalling attitude - not towards vendors, but towards users. The only way to get bug fixes in Boost is to rev forward to new releases, and you appear to have the attitude that if that requires compiler upgrades its just tough. Life, in reality, is not like that on any non-trivial production system: Boost is just one component: the compiler builds all the components. Its a non-trivial upgrade, and likely not an agile one.
James
To support all versions of all vendors is a maintenance nightmare, negatively affects readability and overall is just a whole lot of trouble. This is IMO already an issue when reading the boost source, where there's often multiple code branches for compilers with different quirks. Making sure that the most widely used compilers are supported is reasonable, but making sure that for example VS6 works for new features is more trouble than it's worth. Besides, projects still on VS6 are mostly just maintenance and likely won't upgrade boost anyway. 99% of all other 3rd party libs does not support as wide range of compilers as boost, so boost won't really be the first problem. Same goes for compilers with very low user count, it's better to contact the vendor in that case and pressure for a fix. It's a huge disservice to the user in the long term to have libraries tailor themselves to compiler specific workarounds, that's why we have a standard. Kind regards, Sebastian Karlsson