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

On Thursday 09 January 2014 07:10:32 Adder wrote:

On 1/6/14, Andrey Semashev 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.