Re: [boost] List of C++ 11 only Boost libraries and their status?

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

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

Niall

[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
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/