Subject: Re: [boost] Guidelines to implement Boost library evolution policy (was Boost 2.0)
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-06-08 09:51:15
On 6/8/2014 6:46 AM, Stephen Kelly wrote:
> Rob Stewart wrote:
>> On June 8, 2014 5:16:29 AM EDT, Stephen Kelly <hello_at_[hidden]> wrote:
>>> Rob Stewart wrote:
>>>>> The Jeff Garland case study tells us that the past problem is already
>>>>> using Boost from the present or the past. You don't need to solve
>>>>> problem again.
>>>> Who was suggesting that?
>>> The author of the document about the future of Boost currently being
>> >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 ).