[boost] The future and present of Boost

-----Original Message----- From: Boost On Behalf Of Peter Dimov via Boost Sent: Wednesday, October 24, 2018 5:00 PM

Mike Dev wrote:

...

- Unnecessary dependencies. All the projects I'm working on nowadays are c++14 or even 17. Why the hell does the latest version of my preferred boost library X still have a dependency on boost library Y that has been merged into the standard since c++11 or been superseded by c++11 language feature? It just adds complexity to the build process, increases compile times and sometimes leads to subtle bugs. I'm paying (sometimes little sometimes heavily) for something I don't use/need (c++98 compatibility).

We've been over this a few times already. We can't simultaneously support C++03 and C++14 (without heroics) because these are ABI- and API-incompatible.

[...]

We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest MSVC is ~fully C++11 compliant.)

That's my point: I don't want boost libraries to invest any more effort in maintaining c++03 support (I think I made that clear in the last ml-thread about this 2-3 month ago). It either makes everything more complicated or it requires more dependencies and/or - in the worst case - leads to compile and/or run-time overhead, because an efficient c++11 language construct is emulated with some wicket macro/TMP-library solution (which are even more wicket in c++03) or we have additional conversions between boost types and std types. At the very least, it requires more test-effort, because you want to support the newer standards anyway. Before someone puts up a strawman: Of course that doesn't necessarily mean you should remove boost::X from your code if it provides other benefits (other than backwards compatibility) over std::X. And no, I'm also not suggesting to just drop a useless c++11 feature into your code just out of malice (but realistically, almost every c++03 boost library could either shed dependencies or improve the code by using c++11 features/types). I don't know what the majority of the boost user base needs and what your personal needs (as a maintainer and most likely user of your own library) are but I'm saying that, while maintaining backwards compatibility is probably important for some users, the side effects of it drive others (such as me) away from boost. It is a tradeoff and I'm certainly not so arrogant to believe that dropping backwards compat would be a net win for boost, but for me personally it would make boost more attractive again. Most other pieces of software can just bump their major version, when they think breaking backwards compat is beneficial, and the user can then either upgrade too or stick to the old version if he can't accommodate for the changes (yet). Often the old version still gets bugfix support for some time. But in boost the only way to create a v2 seems to be the introduction of a totally new library. I think that is at least one drawback of the common (non-modular) release model. Btw.: Feature/library wise, I believe the only c++11 thing missing from MSVC2015 is full constexpr support and expressions sfinae and even MSVC2013 provides most of the library and language bits. Any other conformance bugs (e.g. two-phase lookup) have to be dealt with anyway and are orthogonal to the c++03 / c++11 question. Mike