典型的なプログラミングのニーズにとって、C++11 は大きなマイルストーンでした。Boost コードの 95% を標準ライブラリに置き換えました。
それでも、標準ライブラリでまだカバーされていないそのライブラリの現在の状況はどうですか?
Signals2 と Lockfree が必要なため、疑問に思い始めました。
ネットワーク、アルゴリズム、ファイルシステム、バリアントなどに関して、すでに行われたことについては繰り返しません。ただし、signals2 についてのあなたの意見ともう少し議論することができます。
Boost.Signals2は、TR2 に含めるためにN2086によって過去に提案されました。実際には、Boost.Signals2 と libsigc++ が混在していました。私が読んだことによると、人々は信号を標準に含めることにかなり好意的でしたが、この論文にはさらに多くの作業が必要であり、この作業はまだ完了していません [要出典]。
この論文を C++17 に適合させるためには、さらに多くの作業を行う必要がありますが、その作業に適した人がいるとすれば、シグナルはおそらく含めるのに適した候補である可能性があります。
誤解しないでほしいのですが、Boost.Containerは C++17 全体に含めることは提案されていません。ただし、ライブラリはいくつかの提案に影響を与えます。理由は次のとおりです。
N4510は、「再帰」型を使用できるように、一部の標準コンテナーに不完全な型を含めることができることを提案しています。これは、論文から直接得た最小限の例です。
struct Entry
{
std::list<Entry> messages;
// ...
};
このペーパーでは、GCC、Clang、および MSVC ライブラリがすぐに使用できる C++17 標準に準拠するようにこれらの要件を持ちstd::vector
、他の標準コンテナーを実装してイディオムにも適合できるようにすることのみを提案しています。この種の再帰的なコンテナーは、Boost.Container によって標準ライブラリ コンテナーにもたらされた最初の改善点の 1 つです。std::list
std::forward_list
N4526では、C++ とその標準ライブラリに関するゲーム業界と組み込み業界の懸念について説明しています。とりわけ、Boost.Container を標準ライブラリに含めたり、Boost.Container から標準ライブラリに含めたりすることを提案する論文を誰かが書くのを待っている人が実際には多いことに注意してboost::flat_map
くださいboost::flat_set
。まったく書かれていないか、少なくとも C++17 に間に合わないかもしれませんが、よく書かれた論文は受け入れられる可能性があります。更新: P0038は実際にフラット コンテナーを標準ライブラリに含めることを検討することを提案しています。
このライブラリはかなり新しいものですが (2012 年、Boost 1.50)、Library Fundamentals TS および/または C++17 に含まれているいくつかの新しいアルゴリズムを形成するのに役立ちました。
N4536とP0025clamp
は、境界値のペア間の値をクランプする関数を標準化することを提案しています。提案では、clamp
Boost.Algorithm の機能がデザインのインスピレーションの源として言及されています。
設計ミスを修正することを目的としたN3905およびその後の論文では、新しい検索アルゴリズムを標準化することが提案されています。最も注目すべきは、作成以来 Boost.Algorithm に組み込まれてきた Boyer-Moore および Boyer-Moore-Horspool 文字列検索アルゴリズムです。
議論されているか、いくつかの提案に大きな影響を与えた Boost の他の機能のリスト:
C++14 にはなりませんでしたがstd::optional
、Boost.Optional に触発されて、問題なく C++17 にできるはずです。
Special Math Functionsは C++17 にマージされました。これらの関数は TR1 の一部であり、Boost.Math には何年も前から含まれていました。
std::not_fn
は C++17 にマージされ、すでに何年も Boost に住んでいます。
P0013and_
は、メタ関数or_
およびを標準ライブラリに追加することを提案し、not_
Boost.MPL をそのような機能を長い間実装してきた標準ライブラリの 1 つとして挙げています。更新: C++17 でstd::conjunction
、std::disjunction
およびとして採用されましたstd::negation
。
P0033は、指定が弱いと述べてstd::enable_shared_from_this
おり、Boost のバージョンのユーティリティと同じ動作を標準化することを推奨しています。boost::weak_from_this
また、家族を完成させるために標準化することも提案しています。
提案された同時実行機能の多くは、既に Boost ( std::barrier
, std::latch
...) に含まれています。ただし、標準ライブラリに含めることが提案されているため、Boost に実装されていることに注意してください。かつて、それは逆に機能しました。これは、他の既存のクラスを変更する場合にも当てはまります。
any
多くの関心を集めておりvariant
、Boost.Algorithm の検索機能は Library Fundamentals TS にあります。
私の知る限り、誰も Signals2 や Lockfree を提案していません。