Boost logo

Boost :

Subject: [boost] Foundational vs non-foundational libraries (was: Re: Thoughts on Boost v2)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-05-21 07:45:40

On 20 May 2014 at 1:17, Jonathan Wakely wrote:

> >> "Boost used to be about all the stuff you really wanted in the
> >> standard. Now Boost looks like all the stuff that wasn't good enough
> >> to get into the standard"
> >
> > I disagree with it completely and fighting the urge to use the word
> > "ridiculous". There are no tools like Boost.Intrusive, Boost.Spirit,
> > Boost.Interprocess or Boost.ASIO, not to mention things like XML, advanced
> > networking (HTTP, FTP, SSL, etc.), encryption, the holy grail of GUI and many
> > other domains not covered by Boost. You got threading, regex and a couple new
> > containers and think you're covered? I think the previously hopelessly lacking
> > STL got a little less hopelessly lacking.
> I didn't read that quote as saying that the standard library has
> everything you want, only that the things you want aren't in Boost
> either.

I think that was exactly the sentiment of the original speaker. For
example, everyone recognises that something ASIO-like ought to enter
the standard, it just isn't present ASIO.

> Maybe XML, advanced networking, encryption and GUI libraries are "the
> stuff you really want in the standard" but you won't find them in
> Boost.

Which neatly brings me onto reporting on the discussions at C++ Now
after I made the OP on Friday.

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.


... and so on. What is very obviously missing is frameworks except
where those were also duplicated in C11, so for example if C11 gained
threads which it did, C++ 11 gained Boost's thread implementation
rather than say a more C11 like thread implementation.

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


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

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.

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).

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 (and once
again, I stress that the 03 Boost isn't going anywhere, think of it
like the Python 2.x vs 3.x split), especially as one can fix many
problems like CI testing, build, distribution, dependencies and even
directory layout (a big thing we really also need is formal
organisation around C++ Modules, present Boost would need substantial
refactoring, even more than the git translation).

I also still think that we can do a lot better with libraries in the
review queue seeing as that list is likely to keep growing. Someone
suggested that my earlier metric scoring proposal could be applied to
those libraries in the queue with the top ranked in quality appearing
in a separate category of "unreviewed" source distro, I think that a
reasonable idea.


ned Productions Limited Consulting

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