Subject: [boost] The future and present of Boost
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-10-24 16:19:56
> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> 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
> 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)
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk