Boost logo

Boost :

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-11-28 16:57:03

On 11/28/2020 7:28 AM, Paul A Bristow via Boost wrote:
>> -----Original Message-----
>> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Emil Dotchevski via Boost
>> Sent: 27 November 2020 23:26
>> To: Boost <boost_at_[hidden]>
>> Cc: Emil Dotchevski <emildotchevski_at_[hidden]>
>> Subject: Re: [boost] The new Boost 17.0.0
>> Deleting support for C++11 and older versions means breaking user code.
>> Therefore, forking means fracturing of the community. I don't see how this is helpful to the
> users.
> Nearly all of Boost is still C++03 compatible - It is only key or core libraries that have this big
> and bad effect.
> (People using Boost.Math to calculate a probability will still be able to - nothing much has
> changed).
> We have an excellent track record for providing workarounds that keep the old version working where
> possible, while using macros to allow improvements from using new language features.
> Eventually library authors run of out road, and/or patience, and say "enough - I need Cxx-more" but
> it's a slow and continuous process.
> Our continuous progress but keep as much working as possible strategy has worked very well for
> decades.
> The difficulty with our strategy is selling it to potential users who are desperate to be able to
> tick a box marked 'Cxx-supported'.
> It gives them a warm feeling, but little in reality.
> Somehow we don't seem to be able to sell our strategy.
> But if we get to Boost 17, Boost 20 and Boost 23 will soon follow. Won't more Boost 1 (and then 17,
> 23...) users be frightened off/confused?

I agree with this completely.

There is only one other issue which I believe is important for end-users
using Boost libraries in relation to the C++ standard level, which is
that when end-users compile with a certain C++ standard level they are
most likely using in their own code C++ standard libraries at that level
while Boost libraries compiled at that same C++ standard level may often
be using one or more Boost library equivalents to C++ standard library.
The end-user I think has a right to be a bit annoyed at this bifurcation
of C++ standard library/Boost library equivalent which must then occur
in their code in order to use for them useful Boost libraries. Therefore
in this sense, and in this sense only, can I understand a call for Boost
to provide a set of libraries which, when compiled at the C++11 ( or
above ), only use the equivalent C++ standard libraries. This is not in
any way to denigrate the Boost equivalent libraries to various C++
standard libraries, since the Boost equivalent libraries sometimes
contain more and/or better features or are better designed than their
C++ standard library equivalents. But it is still fairly reasonable to
understand that, for some given Boost library which an end-user would
find useful in his code, dependence on a Boost library when the
equivalent C++ standard library is available, might be a strong negative
from the end-users point of view not only based on an added dependency
but also based on the complication in the end-user's code.

Boost list run by bdawes at, gregod at, cpdaniel at, john at