Boost logo

Boost :

Subject: Re: [boost] Foundational vs non-foundational libraries (was: Re: Thoughts on Boost v2)
From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2014-05-21 08:30:21

On 21 May 2014 12:45, Niall Douglas wrote:
> In thinking through on why Boost may be dying in a C++ 11 world,
> someone raised a very interesting point on foundational vs
> non-foundational libraries. If you look at all the stuff which made
> it from Boost into the C++ 11 standard (and excluding anything also
> entering C11), as a rule of thumb it was all foundational e.g.
> shared_ptr
> exception_ptr

Did exception_ptr come from Boost?

It first appeared in Boost 1.36, nearly two years after Beman's first
WG21 proposal for exception propagation and 18 months after Peter's
exception_ptr proposal that was closer.

> regex
> ... and so on. What is very obviously missing is frameworks except
> where those were also duplicated in C11,

I'm not sure the absence/presence of anything in C11 had much
influence on C++11, remember C++0x was feature-complete many years
ago, but it took a long time to bake the final standard (even /losing/
features along the way).

> so for example if C11 gained
> threads which it did, C++ 11 gained Boost's thread implementation

With non-Boost additions (move semantics, the <chrono> library, futures).

> rather than say a more C11 like thread implementation.

The C11 thread implementation arrived far too late to have been any
use to C++0x and locking without RAII would never have been taken
seriously by the C++ community :-)

So I'm not sure C11 is at all relevant to the discussion of what made
it into C++11.

> I personally found this pattern to be highly useful. It suggests to
> us what added to recent Boost will enter C++ 17 or TR3, so taking a
> guess:

There isn't going to be a TR2, let alone a TR3, instead there are
going to be several mostly-independent Technical Specification

> boost::optional

optional is already in the draft Library Fundamentals TS.

> boost::expected
> ... are very highly likely candidates, as are any of the
> single-purpose Boost libraries such as Boost.TypeIndex.

Unlikely given we already have std::type_index.

> What is of course very interesting here is that by their nature,
> foundational libraries have a strong low hanging fruit nature, so the
> number of new additions is going to exponentially decrease over time.
> For example, I can see a very conservative C++11/14 based MPL having
> some chance for a TR3, but a Boost.Hana as presently proposed would
> probably be deferred till the next major release after TR3 as it is
> too experimental.

The whole point of a TS is to be experimental, the contents are even
in namespace std::experimental (that said, what Boost considers
experimental and what WG21 considers experimental is not the same
thing :-)

> Rather harder is to predict what might happen to a conservative
> generic monadic continuations framework based on expected<> et al. If
> done right, that would provide a base framework for all async in C++,
> thus allowing futures to mix seamlessly with ASIO and therefore async
> i/o with async anything else. That *could* become Boost's primary
> contribution to TR3, and finally provide a valid path for getting
> something ASIO-like into the standard (I am not hopeful than ASIO
> will be approved for TR2 personally, ASIO isn't stable enough, plus
> ASIO's current design does not seamlessly interop with other async in
> a generic way).

Again, there is no TR2, there is not going to be a TR2.

> Bringing this back to the point of a Boost v2, if Boost defines
> itself as the staging ground for additions to the C++ standard - a
> highly valuable enterprise IMHO - then a C++ 11 only reboot of Boost
> into a new fresh collection of libraries is paramount

Very strongly agreed.

Those who want Boost to provide a bridge between C++03 and C++11
because they can't use C+11 should stick to "Legacy Boost" (whether
that's v1.x or some fork that goes into maintenance mode) and not hold
back interesting new development.

Boost list run by bdawes at, gregod at, cpdaniel at, john at