Re: [boost] Guidelines to implement Boost library evolution policy (was Boost 2.0)

On 6/8/2014 6:46 AM, Stephen Kelly wrote:

Rob Stewart wrote:

...

On June 8, 2014 5:16:29 AM EDT, Stephen Kelly wrote:

...

Rob Stewart wrote:

...

...

The Jeff Garland case study tells us that the past problem is already solved using Boost from the present or the past. You don't need to solve that problem again.

Who was suggesting that?

The author of the document about the future of Boost currently being discussed.

From the document:

...

... illustrates why Boost continues to support older compilers and standard libraries

And it then illustrates that 'older' means 1996 era compilers.

As you said, that problem is already solved. There's nothing that must be done to solve it. The point is that creating a new version of Boost with no support for old platforms does not provide a transition to the brave new world of C++11, 14, and beyond.

Migrating to that brave new world requires modularization. Otherwise foo_library can not bump its compiler requirements unless that's ok for all of its dependees.

Given the current cyclic dependencies that is a real blocker for everything in the strongly connected graph. So the current work on removing those cycles will prove useful to this discussion.

Also, I urge you not to think in terms of language standards. Think in terms of compiler versions and their features.

Realistically this requires a knowledge of particular compilers and their versions that it is nearly impossible for any particular developer to have. Am I really expected to use or not use a C++ language feature in a particular release of my theoretical library because Compiler X, version Y does or does not support some C++11/C++14 feature ? I do not believe such thinking is conducive to expert programming. OTOH I agree with you that it is realistic for some version of a library to say that older and/or non-compliant compilers/versions which do not support C++ feature X are not usable with version Y of a library. So that if the end-user is still using that compiler/version they must use some earlier version of the library ( or not use the library at all if it is a new library using some advanced C++ feature to accomplish what it needs ).