Re: [boost] [Removing support for old compilers]

Subject: Re: [boost] [Removing support for old compilers]
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-01-09 04:12:46

On Thursday 09 January 2014 07:10:32 Adder wrote:
> On 1/6/14, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
> > All these workarounds clutter the code and preclude further development of
> > the
> > libraries.
> 
> The code will never be free from preprocessor-controlled branches to
> support differences in even the newest compilers.

Yes, but reducing the amount of these branches always helps. Also, there is 
difference between one-liner hacks or different attribute syntax and the lack 
of PTS. The former can often be wrapped in a macro and the latter requires 
reimplementing (duplicating) solid parts of the library.

> There is also the possibility to keep the old files of the libraries
> for which the authors themselves wish to drop support in a separate
> sub-folder and include the old files instead of the new ones from a
> masterfile. Loki used to do and it worked great. Yes, I know they
> don't do it anymore, but what is relevant is that it solved the
> clutter problem at the time -- a time when reading the Loki book
> required an imaginary compiler for me.

You essentially ask to distribute the old version of the library alongside 
with the latest. As the library and the rest of Boost moves on, the old 
version needs to be adapted or diverges more and more, to the point when it 
can't reuse the code from the latest version. The old version would likely not 
get new features because they may involve parts of the language not supported 
by old compilers which are not tested. You can as well just use an older Boost 
release.

> But messing with Boost.Config and introducing an #error directive upon
> detection of _MSC_VER <= 1300 is gratuitous and evil.

The error gives a good indication that the compiler is not capable enough and 
not supported and there's no point in reporting bugs related to it. OTOH, it 
looks like an overkill to issue the error in Boost.Config. Some libraries may 
miraculously work even on old compilers. It's better to issue the error on 
per-library basis, especially taking into account the modularization effort.

> > And since old compilers (the ones that were proposed for
> > dropping)
> > are not tested, you cannot call them supported anyway.
> 
> I have been testing (on my lonely computer, I recognize) ever since
> Boost switched from CVS to SVN, as much as possible against the HEAD
> revision, on the few compilers I could get my hands on.

That is good, but as long as the test results are not available for developers 
they don't see when something breaks, so it doesn't change the state of 
things. The best start to get a compiler supported is to join the test farm 
and publish test results on a regular basis.

That said, I doubt that there would be many volunteers to support the ancient 
compilers even if they were tested.

> If it is any help, I would gladly like to contribute my modest and
> ugly patches and work-arounds.

This would help, I appreciate the offer.

> > As I said, the Standard was released 15 years ago. The compilers that are
> > not
> > able to implement it by this time are the failure.
> 
> I see your point. But I do not think that *age* by iteself is not that
> important. For example, Borland 2002 (5.6 aka C++Builder 6) and 2006
> (5.8 aka Developer Studio 2006 aka Turbo C++ 2006) have more issues in
> the front end than the free 2000 version (5.5).

That's the point, it didn't improve over the years. While e.g. MSVC 7.1 (aka 
VS 2003) already provided most of what Boost needs today. Granted, it had bugs 
of its own but in terms of the Standard support this was a major improvement.

> As for Microsoft Visual C++, the SSE2 optimizer is better in the 2003
> than in the 2005 version in quite a few cases.
> 
> Maybe isolated cases, but my point is not to judge and despise a
> compiler just for its age...

I'm not despising it. For its time it may have been a pretty decent compiler 
among the alternatives. But not today.