Re: [boost] Which compilers are not supported for 1.48 ?

Subject: Re: [boost] Which compilers are not supported for 1.48 ?
From: Sebastian Karlsson (sairony_at_[hidden])
Date: 2011-07-18 07:16:36

2011/7/15 Lars Viklund <zao_at_[hidden]>:
> On Sat, Jul 16, 2011 at 01:00:37AM +0400, Antony Polukhin wrote:
>> Are really old and broken compilers still supported? Do we need them?
>>
>> For example VC++6. It gives thousands of warnings on type_traits and
>> boost PP headers. Tests for VC++6 do not compile. Nobody tested boost
>> libraries on that compiler for years.
>>
>> May be we shall get rid of compilers, that do not support template
>> partitial specialization, ADL or SFINAE?
>> If not, shall we try to make the tests pass (or at least compile) for them?
>
> These kinds of threads pop up every now and then. The last time I
> believe the violent consensus was that it was a bit counter-productive
> to touch code uncessarily, especially such code that isn't clearly
> delimited by feature test or workaround macros.
>
> Sure, it might not be worth keeping code targeting inferior compilers
> around if rewriting or otherwise doing heavy work in the code, but
> intentionally destroying functionality for the people that, probably due
> to a lack of choice, _do_ use such compilers, sounds a bit evil.
>
> Note that not all compilers are as clearly broken as VC6, which is
> properly pre-standard and works mostly out of coincidence.
>
> VisualAge for example is under active development and is generally
> competent, tracking several 0x features, on the level of other competing
> compilers. It however has some quirks regarding some of the things you
> mention. Should it be destroyed as well?
>
> What about SunStudio? It's really broken in some ways, but perfectly
> sane in others. Should code that currently is broken be excised, even if
> a compiler is improving?
>
> The world needs more compilers, and it saddens me when new libraries are
> developed and deployed claiming to be portable but only really builds on
> recent GCC and maybe MSVC.
>

I think it's counter productive to tailor code around vendor specific
work arounds, instead the vendors should fix their issues. It's better
if the vendors were to work closer with for example boost to make sure
that they follow the standard. Otherwise we'll end up with what we
have in the web development world, where instead of the vendors
getting their act together we have every single web develop in the
world spending obscene amounts of time just getting consistency across
browsers. I do however agree that there's nothing gained from
deliberately undoing current work arounds, especially for compilers
which aren't in development.

Kind regards,
Sebastian Karlsson