Subject: Re: [boost] The future and present of Boost
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2018-10-24 22:23:14
On 24.10.18 22:50, Edward Diener via Boost wrote:
> On 10/24/2018 12:43 PM, Peter Dimov via Boost wrote:
>> <...>
>
> I don't get this. Why can't library X, which needs C++11, depend on
> library Y, which needs C++03 but works fine if compiled with C++11. What
> am I missing here ?
Technically everything is possible.
It is just opposite to "practical" and redundant, and slows down
development and adoption.
- part of boost have redundancy with the C++ standard library. As a
developer, I do not like having redundancy and I want the minimum set of
dependencies, because otherwise my work gets harder.
- this makes libraries artificially bigger than what they would be or
need to be if I put the stdlib in the equation. Which in turn makes
integration of those libraries way too difficult and lower the ratio
pros vs. cons.
Note that this is (a bit) orthogonal to modularity.
Adding a layer of header switch/case is making the issue worse.
The adoption of Boost was catalyzed by the almost standard installation
of boost on their OS, because - among other things - boost was necessary
in the past for doing decent C++, but this is not the case anymore.
Better packaging solutions are not going to solve that neither, I still
have redundancy and big fat libraries.
Boost.test is a perfect example: it supports C++03 and C++11. Just
compare it to the adoption of google test and catch. Those are so easy
to integrate in any repository that "people" just do that. And this is
not about the level of features each library brings that is the
definitive game changer: simplicity of integration is a key component.
I remember that the proposed solutions in this ML, if the maintainers
were to drop C++03, would be to go through a formal review process of a
"new" library, bringing Signal/SignalV2 as an example. This is far from
ideal, especially this specific deprecation example of Signal last so
many years.
I remember also that some C++11 features were added to boost.test
without conditional testing on the C++ standard level. This commit has
received an incredible number of complains from this list, including the
promoters of C++11 in this list.
Those products are alive, but we constantly force them to look like the
past.
Any new C++ standard should give the opportunity to maintainers to
update their library, immediately after the support is adopted on a
minimal set of compilers, and without rebranding to boostv2 or
boost.test v4.
We see more and more "LTS" type of releases. Maybe we should think
adopting this to give a sense of stability.
Raffi