Boost logo

Boost :

Subject: Re: [boost] List of C++ 11 only Boost libraries and their status?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-11-28 21:20:17

On 27 Nov 2014 at 16:26, Gottlob Frege wrote:

> And, the reverse question (which Niall is asking), how much of Boost
> has moved to C++11 or greater, even if a large(?) percentage of the
> community hasn't.

If you would replace that choice of wording with "how much of _new
boost development_ has moved to C++11 or greater ..." then I am in
complete agreement.

> And if so, what does that say about Boost and/or C++ adoption. ie is
> Boost pushing the adoption of C++11? Would boost push C++11 better if
> its libraries were backwards compatible (so as to "ease" people into
> C++11) or should a library abandon old C++ and "force" users to move
> forward?
> If I was to write a new library, that _could_ be old-C++ compatible,
> but with extra work, should I put in that extra work?
> I think there are interesting questions here for Boost and C++. Not
> sure if Niall is heading towards those questions or others.

I'm not sure if I'm heading towards those questions either, mainly
because I don't think myself competent to judge right now.

Currently right now I am intending to simply do a review and report
of libraries close to ready for community review at C++ Now 2015. If
during the preparation for that presentation I feel there is a bigger
picture there I probably would pivot, but I am currently thinking
that such synthetic analysis is better done in 2016 after a bit more

> The further question, which I think should be discussed here or at
> BoostCon/C++Now, is what is Boost's role *today*? Is boost still a
> stepping stone to the standard? (I find that with the standard's new
> pace, and with its push to use TS's, "stepping stone" is now a more
> minor role for boost. For better or worse - ie I'm not sure if it is
> good for the standard.)
> Or is boost now a place for good libraries, most of which aren't
> general enough to be in std, but are really good and really useful
> when you need them?
> Or is boost a maintenance effort for old libraries for older
> compilers. (I don't think Boost is just that, but is it part of its
> role?)

I'm of the opinion, much to the annoyance of some on the committee,
that the current transference of new library forms to
std::experimental under the aegis of WG21 is unsustainable and
inevitably doomed to fail. I think it will yield huge gains
initially, but cannot work well over time simply because library
design by committee very rarely works well in the long run. In my
opinion, the correct and proper way of doing new standard library
design is through attracting and retaining a substantial user base in
a competitive market place of libraries. That is what made Boost
popular and unique in the first place - it offered tools which other
libraries, including the STL, aspired to.

My current employment has me work regularly with ASIO and the ASIO
way of thinking about concurrency as epitomised by N4045. I find much
disagreeable about that whole way of thinking about concurrent
design, but I would never claim it isn't battle hardened and proven
good. As much as how ASIO does things is ugly, it is very effective
and not far from ideal efficiency when designed around its
assumptions [1].

This does present me a quandry though. If I had to vote on something
like N4045 entering the standard my gut says vote no because I think
we can do a lot better. But don't get me wrong, N4045 is currently
the only game in town remotely approaching standards quality
readiness through actual empirical practice rather than ivory tower
top down deesign [1]. And if I were on the committee, I'd probably
end up voting yes precisely because it is the only game in town.


[1]: ASIO's design is "zero copy to the kernel" rather than "zero
copy to the NIC DMA engine" where the overwhelming problem child is
Linux, as OS X and FreeBSD and Windows "do the right thing" with zero
copy DMA if ASIO is properly prodded with 4k aligned no-COW
scatter-gather buffers. Much of why Linux is that problem child is
due to Linus personally himself, but we'll skip that for now (search
google if you want to know more). Suffice it to say that Linux
provides proprietary syscalls, and ASIO does not use them, but it
probably wouldn't require too much effort to construct a framework
where ASIO /could/ invoke proprietary Linux syscalls if certain
additional restrictions were placed on ASIO using code. I may have
some facilities regarding this in proposed Boost.KernelAlloc, but if
benchmarking doesn't show enormous performance benefits I am inclined
to consign Linux to second tier support status to be honest, I don't
see the payback for the maintenance overhead for a special code path
just for Linux alone here.

ned Productions Limited Consulting

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