Andrey Semashev wrote:
On Mon, Oct 14, 2013 at 8:20 PM, Robert Ramey <ramey@rrsd.com> wrote:
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.
OK - I'll amend the statement above - to say no cost to most boost users. Definite cost to boost users who use boost config to handle variations on a wide variety of compilers.
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?
I don't intend to specifically support old compilers - I don't intend to drop support for them either as it's already in there. Actually I don't intend to do any work on the serialization library that doesn't add functionality. It looks like that if this goes through, I'll have to to go back and re-debug the library to support a decrease of functionallity - not something I can justify the investment of time in - not to say that's it's no fun at all.
Because otherwise I don't see how it affects you - the tests will be running on modern compilers as they did before.
If that's the case - no problem. But I can't see how a change like this can be made without causing breakage that I will have to spend time tracking down.
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.
on NEW libraries - but it has the potential of creating huge amount of unpleasant work for older libraries. - with not net benefit to anyone. Robert Ramey