On Mon, Oct 14, 2013 at 8:20 PM, Robert Ramey
I realize that I've asked this before - but I never got a response which I found convincing. I'll try to ask my question better this time.
The question - What is the value of undertaking this task.
Let's look at the value of according to the type of boost participant.
a) boost user - all this code in config and the libraries is internal to the libraries. After this change the look and usage of boost will not change at all. - no benefit and no cost to the boost user.
Not quite true. Boost.Config is a library as any other, its macros are documented. I use these macros in projects outside Boost where I need portability across different compilers. I don't really care about the compilers we're dropping now, so the changes proposed so far don't affect me. But it doesn't mean it doesn't affect any other users.
d) maintainers of boost libraries. When I first raised this question, I was assured that it would be totally transparent to me and that I would not have to be concerned about it. Hmmm - well OK - as long I don't have to wade in and muck around with ten year old code - (don't even think about addressing any changes which make old data sets unreadable). My worst nightmare is having to go back and re-debug 20 thousand lines of code running on 10 different compilers. Recent postings have made me doubt that one can really undertake this and guarentee that I won't have to do this.
I didn't really understand your point here. Do you intend to support the old compilers, even if Boost in general drops them? Because otherwise I don't see how it affects you - the tests will be running on modern compilers as they did before. My understanding is that the most immediate benefit is exactly for Boost library maintainers. Dropping support for ancient compilers simplifies code (Boost.Config included), makes it more easily maintainable.