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