Re: [boost] The future and present of Boost

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