For typical programming needs, C++11 was a great milestone — we replaced 95% of Boost code with standard library.
Yet what is the current status of its libraries that are not yet covered in the standard library?
I started wondering due to the need of Signals2 and Lockfree.
I won't repeat what has already been done concerning networking, algorithms, filesystem, variant and any. However, I can discuss your point about signals2 and a little bit more.
Boost.Signals2 has been proposed in the past by N2086 for inclusion into TR2. Actually it was more of a mix between Boost.Signals2 and libsigc++. From what I have read, people were rather favorable to the inclusion of signals into the standard, but the paper needed more work and this work has never been finished [citation needed].
Now, even more work should be done in order to adapt the paper so that it suits C++17, but if anybody is up for the task, signals could probably still be a good candidate for inclusion.
Don't get me wrong, Boost.Container has not been proposed for inclusion into C++17 as a whole. However, the library does have some influence on some proposals. Here is why:
N4510 proposes that some of the standard containers can contain incomplete types so that you can have "recursive" types. Here is a minimal example straight from the paper:
struct Entry
{
std::list<Entry> messages;
// ...
};
The paper only proposes that std::vector
, std::list
and std::forward_list
have these requirements so that GCC, Clang and MSVC libraries are C++17-standard-compliant out of the box, and encourages them to implement the other standard containers so that they can also fit the idiom. This kind of recursive containers is actually one of the first improvements brought by Boost.Container over the standard library containers.
N4526 discusses the concerns of the game industry and embedded industry about C++ and its standard library. Among other things, it notes that many people are actually just waiting for somebody to write a paper to propose the inclusion of boost::flat_map
and boost::flat_set
from Boost.Container into the standard library. While it might not be written at all, or at least not in time for C++17, a well-written paper could be accepted. Update: P0038 actually proposes to consider the inclusion of flat containers into the standard library.
While this library is fairly new (2012, Boost 1.50) it helped to shape some new algorithms that have been included in the Library Fundamentals TS and/or in C++17:
N4536 and P0025 propose to standardize a clamp
function to clamp a value between a pair of boundary values. The proposals mention the clamp
function from Boost.Algorithm as a source of inspiration for the design.
N3905 and subsequent papers aimed at fixing a design mistake propose to standardize new searching algorithms, most notably the Boyer-Moore and Boyer-Moore-Horspool string searching algorithms, which have lived in Boost.Algorithm since its creation.
A list of the other features from Boost that are discussed or have strongly influenced some proposals:
It didn't make it into C++14, but std::optional
, inspired by Boost.Optional, should make it into C++17 without a problem.
The Special Math Functions was merged into C++17. These functions were part of TR1 and Boost.Math has included them for years already.
std::not_fn
was merged into C++17 and has already lived in Boost for years.
P0013 proposes to add the metafunctions and_
, or_
and not_
to the standard library and cites Boost.MPL as one of the standard libraries having implemented such features for a long time. Update: adopted in C++17 as std::conjunction
, std::disjunction
and std::negation
.
P0033 states that std::enable_shared_from_this
is weakly specified and recommends standardizing the same behavior as Boost's version of the utility. It also proposes to standardize boost::weak_from_this
to complete the family.
Many of the proposed concurrency features are already in Boost (std::barrier
, std::latch
...). However, it should be noted that they have been implemented in Boost because they have been proposed for inclusion into the standard library. For once, it worked the other way around. That's also the case for some modifications to other already existing classes.
any
and variant
have received a lot of interest, and the searching stuff from Boost.Algorithm is in the Library Fundamentals TS.
No one has proposed Signals2 or Lockfree as far as I know.
a networking library based heavily on boost.asio
,
a filesystem library based on boost.filesystem
I don't know if the proposal is\will make it for C++17, but range-v3 (loosely based on boost range) is proposed for inclusion in the C++ standard.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With