C++標準化委員会の論文(提案文書)公開がコロナウィルスの影響もあって月1になり量がお手頃になったので、4/20公開の提案文書をさらっと見てみます。
文書の一覧
www.open-std.org
提案文書で採択されたものは今回はありません。
C++20 CD (committee draft)の投票時に各国委員会およびそのメンバーから寄せられたコメントとその対応および理由の総覧です。
N4859/N4860/N4861
N4860/N4861のN4849との差分を記したEditors' Report。新たに採択された提案文書の一覧、解決されたIssueの一覧、Github上での軽微な修正コミットの一覧、などが載っています。
C++20のDIS (draft international standard)。この後FDIS (final draft international standard)を経てIS (international standard)へと至ります。
残念ながら委員会のメンバーしか見られないようです・・・
C++23のWD (working draft)第一弾。でもC++23向けに導入されたものはないはず。
N4860との差異は、表紙とヘッダ、フッダ、C++17規格とのクロスリファレンスの有無(無い)だけのようで、内容としてはDIS(N4860)と同一とのこと。C++17(N4659)も最終的に公開されているのはDIS相当のWDなので、これがC++20規格として参照されることになりそうです。
<cmath>
と<cstdlib>
の一部の関数をconstexpr
対応する提案。
<cmath>
からは、logb()
、modf()
、scalbn()
、abs()/fabs()
、ceil(),floor()
等丸め系関数、fmod()
、copysign(), nextafter()
、fmax()/fmin()/fdim()
、fma()
、fpclassify(),isunordered()
等数値分類・数値比較系関数、等が対象です。
<cstdlib>
はなぜかそっちに含まれている数学関数(abs()
とかdiv()
)だけが対象です。
筆者は、<cmath>
の関数群は全てconstexpr
指定できるはずだけど、コンパイラ/標準ライブラリベンダーの過度な負担とならない一部だけをconstexpr
対応させる、と述べています。その一部には、sin(),cos()
等の数学関数は含まれません・・・
また、これらの関数はerrno
や丸めモードなどグローバルフラグに依存し、またそれらを更新します。errno
をセットすべき時(定義域エラーやゼロ割)は単にコンパイルエラーを発生させ、グローバルフラグの状態はコンパイル時には変更しない、と言うようにすれば良いのですがC++17以前ではそれは少し難しい実装を要求していました。
しかし、C++20にてstd::is_constant_evaluated()
が導入されたことでこの問題は解決されるため、単純な実装によって多くの<cmath>
関数を追加でconstexpr
対応させられるようになりました。
丸めモードに関しては色々議論があるようで、この提案では丸めモードへの依存が強い(変更することで精度が1%以上変化しうる)関数を除外しています。
型T
が別の型U
へ縮小変換(narrowing conversion)によって変換可能かを調べるメタ関数is_narrowing_convertible<T, U>
を追加する提案。
これは例えば、std::optional
やstd::variant
のようなラッパー型において、縮小変換が起こる場合に変換や構築を禁止する制約をかけるのに利用できます。
意図しない縮小変換の発生は実行時において浮動小数点数の精度低下などの発見しづらいバグにつながります。縮小変換(発生の可能性)をコンパイル時に検出し禁止しておくことで、C++の型システムをユーザーの手によって多少ロバストにして運用することができます。
提案されている宣言。
namespace std {
template <class From, class To>
struct is_narrowing_convertible;
template <class From, class To>
inline constexpr bool is_narrowing_convertible_v = is_narrowing_convertible<From, To>::value;
}
これは例えば、次のように実装できます(提案文書より)。
template<class From, class To>
inline constexpr bool is_narrowing_convertible_v = false;
template<class T, class U>
concept construct_without_narrowing = requires (U&& x) {
{ std::type_identity_t<T[]>{std::forward<U>(x)} } -> std::same_as<T[1]>;
};
template<class From, class To> requires std::is_convertible_v<From, To>
inline constexpr bool is_narrowing_convertible_v<From, To> =
!construct_without_narrowing<To, From>;
[Wandbox]三へ( へ՞ਊ ՞)へ ハッハッ
std::optional
やポインタ等のmaybeモナドな対象を、その状態によって要素数0か1のシーケンスに変換するRangeアダプタviews::maybe
の提案。
例えば、std::optional
のシーケンスを無効値を持つかによってフィルタする処理をわざわざ書く必要がなくなったり、std::optional
の状態をチェックして中身を取り出して・・・といったお決まりのコードを隠蔽することができます。
{
auto&& opt = possible_value();
if (opt) {
use(*opt);
}
}
for (auto&& opt : views::maybe(possible_value())) {
use(opt);
}
views::maybe
を通した場合、possible_value()
が無効値を返した場合はループが実行されません(シーケンスが空なので)。
std::vector<int> v{2, 3, 4, 5, 6, 7, 8, 9, 1};
auto test = [](int i) -> std::optional<int> {
switch (i) {
case 1:
case 3:
case 7:
case 9:
return i;
default:
return {};
}
};
auto&& r = v | ranges::views::transform(test)
| ranges::views::filter([](auto x){return bool(x);})
| ranges::views::transform([](auto x){return *x;})
| ranges::views::transform(
[](int i) {
std::cout << i;
return i;
}
);
auto&& r = v | ranges::views::transform(test)
| ranges::views::transform(views::maybe)
| ranges::views::join
| ranges::views::transform(
[](int i) {
std::cout << i;
return i;
}
);
特定のメモリ領域の値を確実に消去するための関数secure_clear()
の提案。
パスワード等のセキュアなデータを扱う場合、不用になったらすぐにその内容を消し去り、コアダンプ等によってキャプチャ可能な時間を少しでも短くする必要があります。このことは、近年の脆弱性(MeltdownやSpectre等)の影響によって重要度が増しています。
しかし、単純にメモリ領域をクリアするだけの処理はその領域がその後使用されない事からコンパイラの最適化によって削除される可能性があります。
void f()
{
constexpr std::size_t size = 100;
char password[size];
getPasswordFromUser(password, size);
usePassword(password, size);
std::memset(password, 0, size);
}
この様な問題(すなわちコンパイラ最適化)を回避するのにはいくつもの方法がありますが、それらの方法は非自明であったり、移植性が無く容易に利用できるものではなかったりします。
そのような機能を標準によって提供しポータブルかつ容易に利用できるようにするために、secure_clear()
関数を提案しています。
namespace std {
template <class T>
requires is_trivially_copyable_v<T>
and (not is_pointer_v<T>)
void secure_clear(T & object) noexcept;
}
効果は上に示した通り、受け取った参照先のオブジェクトの占めるメモリ領域をゼロクリアします。
なお、この提案は同時にC標準に対しても行われているようです(N2505)。
void secure_clear(void * data, size_t size);
こちらはポインタとゼロクリアする領域サイズを取ります。
C++からはstd::secure_clear()
としてこの2つのオーバーロードが利用可能になります(採択されれば)。
フリースタンディング処理系に要求されるライブラリ機能についての文言を変更する提案。
現在はライブラリヘッダ毎にフリースタンディングで要求されるかを規定していますが、ヘッダの一部分の機能および対応する機能テストマクロを個別にフリースタンディング指定することができるように文言を追加・変更しようというもの。主に<cstdlib>
の文言を改善するのが目的っぽい?
ABIの破損問題について、委員会メンバからのコメントをまとめた報告書。
C++標準がABI破損を伴う変更を受け入れるのか、どのように受け入れるのかについて、次の4つのケースが考えられます。
- ABIを絶対に壊さない
- 実行パフォーマンスが低下するが、もっとも安定している。何も懸念がなければこれを選択すべき
- ケースバイケース(例 :
std::string
のSSO)
- 以前に行ったことがあるが、ユーザーはそれが行われることを予測できない
- 特定のリリースを境界としてABI破壊を許可する(例えば12年毎など)
- 任意のタイミングで自由にABIを破壊する
- 一番素早く動けて実行パフォーマンスを高められるが、安定性がもっとも低い
どれを選ぶのかを慎重に検討するために委員会メンバからのコメントを募集し、過去に行われたABI破壊や、ABI破壊を理由に採択されなかった提案について、また将来必要になるかもしれないABI破壊などについてまとめられています。
識別子(identifier)の構文において、不可視のゼロ幅文字や制御文字の使用を禁止する提案。
現在C++では識別子に使用可能なUnicode文字列をコードポイントの範囲として規定していますが、その中にはゼロ幅文字など人間の目で見て区別できない文字が含まれてしまっており、万が一使用されればバグの元となりえます。そのため、それらの使用を禁止しそのような文字列が使用されていた場合はコンパイルエラーにすることを提案しています。
Unicode Standard Annex 31というのはどうやら、プログラミング言語において汎用的に識別子として使用可能な文字列および文字列の形式を定めたものです。C++11時点ではこれは安定しておらず使用されませんでしたが、現在は安定しており後々のUnicodeの規格で破壊的な変更が行われないことが保証されるようになっているようです。
そのため、それを参照して識別子の構文を規定することで識別子として適切な文字だけが使用できるように標準を変更します。
Unicode Standard Annex 31で規定されている識別子の構文規則(EBNF)は次のようになります。
<Identifier> := <Start> <Continue>* (<Medial> <Continue>+)*
ここで、<Start>
はXID_Start
という特定の文字(コードポイント)の集合、<Continue>
はXID_Continue
という特定の文字の集合、<Medial>
は<Continue>
の文字の間に現われることができる文字の集合です。
C++では、<Start>
に_
(U+005F、アンダーバー)を追加し<Medial>
は空になります(<Continue>
はそのまま)。上記の文法に照らせば、次のようになります。
<Identifier> := <Start> <Continue>*
<Start> := XID_Start + U+005F
<Continue> := <Start> + XID_Continue
XID_Start
にどんな文字が含まれているのか及びXID_Continue
にどんな文字が含まれているのかは正直良く分からないくらい大量の文字がありますが、多分制御文字やゼロ幅文字はないはずで、絵文字も含まれていないようです。
また、採択されたとしたら、これらのことは欠陥報告としてC++20以前のバージョンに遡って適用されることになりそうです。
x |> f(y);
をf(x, y);
と評価する新しい演算子|>
の提案。
この演算子はオーバーロード可能ではなく、右辺の値を左辺の関数呼び出しの第一引数に渡すように式全体を書き換えるだけです。
Unified Function Call Syntax(UFCS)に近いものに見えますが、この演算子による書き換えは常に非メンバ関数を呼び出します。
x->f(y);
x.f(y);
x |> f(y);
一見すると何の意味があるのか分からない演算子ですが、Rangeのパイプライン演算子|
にまつわる以下の様な諸問題を解決するためのものです。
- パイプラインスタイルを使用するためのサポートコードが複雑かつ大量に必要になる
- コンパイラの最適化がそれらのコードを完全に取り除けない場合、オーバーヘッドが発生しうる
- それらサポートコードによるコンパイル時間の増大
- 一部のアルゴリズムをパイプライン演算子にアダプトできない場合がある
Rangeのパイプライン演算子がやっていることは要するに、左辺の式の結果オブジェクトを右辺の関数の第一引数に渡すようなもので、それによって関数呼び出しのネストを分解しています。
#include <iostream>
#include <vector>
#include <ranges>
int main()
{
std::vector v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
auto&& range = std::views::reverse(
std::views::transform(
std::views::filter(v, [](auto n){ return n % 2 == 0;}),
[](auto n) { return n * 2;}
)
);
for (auto e : range)
{
std::cout << e << std::endl;
}
}
int main()
{
std::vector v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
for (auto e : v | std::views::filter([](auto n){ return n % 2 == 0;})
| std::views::transform([](auto n) { return n * 2;})
| std::views::reverse)
{
std::cout << e << std::endl;
}
}
[Wandbox]三へ( へ՞ਊ ՞)へ ハッハッ
[Wandbox]三へ( へ՞ਊ ՞)へ ハッハッ
ここで、2つのスタイルの例に現れているfilter
やtransform
等の関数はそれぞれ異なるオーバーロードが使用されています(例えば、filter(Rng&&, Pred&&)
とfilter(Pred&&)
)。|
演算子はあくまで演算子オーバーロードでありその呼び出しよりも引数に与えられた式の評価が先になるので、パイプラインスタイルの時に|
演算子の右辺に来る関数(filter(Pred&&)
)は渡された関数オブジェクトを|
に引き渡す為のラッパを生成するだけの処理になります。一方、第一引数にrangeオブジェクトが直接渡っている最初の例(filter(Rng&&, Pred&&)
)では受け取った処理の適用準備の済んだrange viewオブジェクトを返します。
どちらが読みやすいかを考えるとパイプラインスタイルの威力は圧倒的ですが、この裏側では大量の黒魔術が発動しています・・・
このような|
の行なっていることを式の書き換えによって行う|>
演算子を言語サポートすることで、パイプライン演算子を使用するためのそのような黒魔術コードを削減することができ、それに伴う諸問題の解決を図ることができます。
|>
演算子でも|
と同様に書けます。
#include <iostream>
#include <vector>
#include <ranges>
int main()
{
std::vector v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
for (auto e : v |> std::views::filter([](auto n){ return n % 2 == 0;})
|> std::views::transform([](auto n) { return n * 2;})
|> std::views::reverse)
{
std::cout << e << std::endl;
}
}
|>
演算子の場合はこれを一番最初の関数呼び出しネストコードに書き換えることによって|
演算子と同じことを達成します。これによって演算子オーバーロードもそれに対応するためにfilter
等に不要なオーバーロードを追加する必要もなくなります。
また、|>
の両辺は書き換え前に評価されません。つまり、他の演算子とは少し振る舞いが異なります。オーバーロード不可能とされているのはこの性質によります。
フリースタンディング処理系においては、オーバーロード可能なグローバル::operator new
を必須ではなくオプションにしようという提案。
フリーストア(ヒープ)を持たないかその使用が著しいオーバーヘッドとなる環境では、意図しない::operator new
が使用された場合にコンパイルエラー(リンクエラー)となってほしい場合があります。また、OSのカーネルの動作環境のように、メモリ割り当てを正しく行う方法が無い環境でも同様です。このような環境ではすでに::operator new
の実装を提供できておらず、結果としてそれらの環境のC++ユーザーは::operator new
を使わないか、(使うために)独自実装をするかの2択を迫られているのが現状です。そのため、あえて::operator new
を定義しないという選択肢を標準化し、その場合の振る舞いを規定する必要がある、というのが要旨です。
提案では、オーバーロード可能なグローバル::operator new
の提供を実装定義とし、提供するならば全てのオーバーロードを提供する必要があるが、提供しない場合は全てのオーバーロードを提供しない、という規定を追加します。結果として、::operator new
が提供されない場合、プログラム中でのそれらの使用はill-formedであり、おそらくリンカエラーを引き起こします。
ちなみにそのような場合には、<coroutine>
ヘッダはグローバル::operator new
に依存しているので存在そのものがill-formedになります(#include or import
しなければok)。
なお、::operator delete
は仮想デストラクタにおいて参照されるのでそのままであり、constexpr new
は使用可能となるように文言が調整されています。
記載されているEWG等での投票結果を見るに受け入れられそうな雰囲気です。
ラムダ式の全体をmutable
とするのではなく、一部のキャプチャだけをmutable
指定できるようにする提案。
パフォーマンスが求められるコールバック関数オブジェクトではその内部に個別に利用するローカルメモリを持つことがあります。また、mutex
等の参照をメンバに持つこともあるでしょう。それらは外部から観測不可能な内部状態であり、そのオブジェクトは意味論的にはimmutableです。
struct MyRealtimeHandler {
private:
const Callback callback_;
const State state_;
mutable Buffer accumulator_;
public:
void operator()(Timestamp t) const {
callback_(state_, accumulator_, t);
}
};
struct MyThreadedAnalyzer {
private:
const State& state_;
std::mutex& mtx_;
public:
void operator()(Slice slice) const {
std::lock_guard<std::mutex> lock{mtx_};
analyze(state_, slice);
}
};
例えばこの様な典型的な型はラムダ式を使えば定義を必要とせずに簡単に書くことができますが、現在はこの様に部分的にmutable
/非const
なメンバを持つようなラムダ式を書くことが出来ません。全部const
が全部mutable
かの二者択一です。
提案では、次のようにキャプチャを個別にmutable
指定できるようにします。
auto a = [mutable x, y]() {};
struct A {
mutable X x;
const Y y;
void operator()() const {}
} a;
この様に、その物理的な状態を変更したとしてもそのオブジェクトの論理的(意味論的)な状態を変更しないような不変オブジェクト(に対する操作)の事をlogical constと呼びます。
さらに、std::any_invocable
というCV
修飾やnoexcept
を指定できるstd::function
が議論されており、それを踏まえるとlogical constなラムダ式はより必要とされます。
また、この提案では更なる議論を前提としていて、他にも以下の様な書き方を可能にすることが提案されています。
auto b = [x, const y]() mutable {};
auto b = [&x, const &y]() {};
auto c = [x]() const {};
auto c = [const x]() const {};
auto c = [mutable x]() mutable {};
ローカルクラスでメンバテンプレートを使用できるようにする提案。
ローカルクラスとは関数の中で定義されたクラスで、関数テンプレートと利用するとインターフェースの自動実装を行えたりとなかなか便利なやつです。ローカルクラスのスコープはその関数の中に閉じられ、関数外部からクラス名を参照することはできないため名前が衝突したりせず、インターフェースクラスを継承して自動実装する場合はアップキャストされるのを完全に防止できます。なお、ローカルクラスのメンバは普通に外から参照できます。
しかし、ローカルクラスでは囲む関数テンプレートのテンプレートパラメータなど囲む関数からアクセスできるものは全てアクセスできますが、メンバテンプレートを持つことができないなどいくつかの制限があります(ローカルクラス自体がテンプレートになることはできます)。
ローカルクラスがメンバテンプレートを持つことができるようになると、あるインターフェースを別のインターフェースへ変換するアダプタの自動生成などをローカルクラスで書くことができるようになります。
template<typename Callable>
auto callable_to_call(Callable&& f) {
struct call_impl {
Callable m_f;
template<typename... Args>
auto call(Args&&... args) {
return m_f(std::forward<Args>(args)...);
}
};
return call_impl{std::forward<Callable>(f)};
}
実装クラスを関数外部に持っておいてもいいのですが、クラス名が漏洩しないというのと、見た目的にも気持ち的にもコードがコンパクトになるのが個人的お好みポイントです。
MSVCの実装者はこの変更は問題ないと言っているそうですが、Clangは熱心にテンプレートの実体化を行う結果思わぬコンパイルエラーが起こる可能性があるとのことです。しかし、すでにジェネリックラムダが限定的とはいえ同じことが可能になっているのであまり壁は高くなさそうです。
変数テンプレートの部分特殊化を明確に規定するように文言を変更する提案。
現在の書き方だと変数テンプレートの部分特殊化についてが不透明なので、クラステンプレートの部分特殊化に関する文言を一般化して変数テンプレートの部分特殊化を規定するように文言を調整しています。これが通ったとしても多くのユーザーにとっては関係ない話です。パッと見では、クラステンプレートの部分特殊化やプライマリクラステンプレート、などと書かれていたところからクラステンプレートというワードが消されています。仮に採択された場合はこの辺を読むときは注意しないと分かりづらいかもしれません。
std::complex<T>
とstd::complex<double>
のように、ある型T
が別の型P
の特殊化となっているかを調べるメタ関数is_specialization_of<T, P>
の提案。
例えばテンプレートの文脈で、std::complex<T>
やstd::optional<T>
、std::vector<T>
など、その要素型はともかくとして型がその特殊化であるかを知りたい!という場合はよくあります。幸いこれを判定するメタ関数を書くのは難しくないのでテンプレート好きな人は多分1度は書いたことがあるでしょう。そのように、よく利用されるものであるので標準に追加しようという提案です。ただし、あるテンプレート毎に個別にそのようなメタ関数を追加するわけにはいかないので、より一般化した任意の型のペアの間でそれを判定するものを追加します。
template<class T, template<class...> Primary>
struct is_specialization_of;
template<class T, template<class...> Primary>
inline constexpr bool is_specialization_of_v = is_specialization_of<T,Primary>::value;
例えば次の用に使います。
static_assert(std::is_specialization_of_v<T, std::optional>);
template< class T >
inline constexpr bool is_complex_v = is_specialization_of_v<T, std::complex>;
ただ、std::array<T, N>
のように非型テンプレートパラメータを取るものは判定できません。それは諦めているようです。また、これはクラスの継承関係を判定するものではありません。
(タイトルの<=>は宇宙船演算子ではありません)
CWGとEWGの間で使用されているwording reviewに関するルールの修正と、それをLWGとLEWGの間でも使用するようにする提案。
C++標準会員会の作業プロセスの改善に関するお話なので、完全にユーザーには関係ありません。CWGとかEWGとかは次の図参照。
コア言語の提案はEWG(Evolution Working Group)で基礎設計が詰められてからCWG(Core Working Group)へ送られ、CWGでは標準としての文言の確認と調整を行います。その際、EWGである程度設計に基づく文言が整っていることが要求されますが、設計を文言が表現しきれていなかったり、議論していない文言が含まれていたり、とそうなっていない事があったようです。
そのため、EWGとCWGの間ではそう言う事が無いようにするためのルールが設けられていました。とはいえ、そのルールは文書化されたものではなかったためか、CWGに送られた段階でしっかりと文言が整っていない事がまだあるようです。
EWGが設計とそれを表現する文言を決定しCWGは文言を確認するだけ、という役割分担を明確にしCWGの時間を無駄にしないようにするためにルールを変更し、同じことをLWG(Libraly Working Group)とLEWG(Libraly Evolution Working Group)の間でも行うようにする。というのが提案の要旨です。
std::byte
によるバイナリシーケンスのI/Oのための新ライブラリ、std::io
の提案。
C++20現在、バイナリファイルのIOをやろうとするとiostreamを使用することになりますが、iostreamもベースにあるCのIO関数もテキストストリームへの入出力前提なものをバイナリモードという特殊な状態にしたうえでバイナリIOに使用することになるので、使いづらく、また非効率です。
#include <fstream>
int my_value = 42;
{
std::ofstream stream{"test.bin", std::ios_base::out | std::ios_base::binary};
stream.write(reinterpret_cast<const char*>(&my_value), sizeof(my_value));
}
int read_value;
{
std::ifstream stream{"test.bin", std::ios_base::in | std::ios_base::binary};
stream.read(reinterpret_cast<char*>(&read_value), sizeof(read_value));
}
assert(read_value == my_value)
これには以下の欠点があります。
std::byte
非対応のため、reinterpret_cast<const char*>
が必要
- バイト数を明示的に指定しなければならない
- バイトの読み書きにエンディアンを考慮してくれない(するようにできない)
std::char_traits
が使われるがバイナリIOには不要、std::ios::pos_type
は多くのIO操作に必要だが使いづらい。
- バイナリIOに必要なのは常に
std::ios_base::binary
、オープンモード指定は不用
- ストリームオブジェクトはテキスト形式フラグをいくつも持っているが、バイナリIOには不要。メモリの無駄
- デフォルトのストリームは例外を投げない。これはストリーム状態を調べて例外を発生させるラッパーコードを追加する手間の元
- メモリ内で完結するIOのために
std::string
を使用するstd::stringstream
が用意されているが、無駄なコピーが発生するなど使いづらい。バイナリデータはほとんどの場合std::vector<std::byte>
が適当であり、span
で参照すれば十分
- 現行のiostreamには、バイナリIOとシリアライズのためのカスタマイゼーションポイントが無い
これらの欠点をすべて解決したバイナリIOのための新ライブラリの導入を目指すのがこの提案です。
生バイト列のIOサンプル
#include <io>
#include <iostream>
int main() {
std::array<std::byte, 4> initial_bytes{
std::byte{1}, std::byte{2}, std::byte{3}, std::byte{4}
};
{
std::io::output_file_stream stream{"test.bin"};
std::io::write_raw(initial_bytes, stream);
}
std::array<std::byte, 4> read_bytes;
{
std::io::input_file_stream stream{"test.bin"};
std::io::read_raw(read_bytes, stream);
}
if (read_bytes == initial_bytes) {
std::cout << "Bytes match.\n";
} else {
std::cout << "Bytes don't match.\n";
}
}
カスタマイゼーションポイントによる任意クラスのカスタムシリアライズとエンディアン指定のサンプル。
#include <io>
#include <iostream>
struct MyType {
int a;
float b;
void read(std::io::input_stream auto& stream) {
std::io::default_context context{stream, std::endian::big};
std::io::read(a, context);
std::io::read(b, context);
}
void write(std::io::output_stream auto& stream) const {
std::io::default_context context{stream, std::endian::big};
std::io::write(a, context);
std::io::write(b, context);
}
};
int main() {
MyType my_object{1, 2.0f};
std::io::output_memory_stream stream;
std::io::write(my_object, stream);
const auto& buffer = stream.get_buffer();
for (auto byte : buffer) {
std::cout << std::to_integer<int>(byte) << ' ';
}
std::cout << '\n'
}
他にも、span
やメモリのためのI/Oストリームが用意されていたり(これらはconstexpr
対応!)、エンディアンを途中で切り替え可能だったり、整数型の特殊なフォーマット(LEB128など)をサポート可能だったり、ISO 60559以外もサポート可能な浮動小数点数バイナリフォーマット変換も考慮されていたり(ドロップされそうですが)、コンセプトベースだったりとイケてる雰囲気のライブラリです。
筆者の方が並行してリファレンス実装を作っています。なかなか本気のようです。
Networking TSからsystem_executor
とsystem_context
を削除する提案。
system_context::get_executor()
はデフォルト構築したsystem_executor
を返して、そのメンバ関数であるsystem_executor::context()
は静的記憶域期間に配置された(つまりグローバル変数の)system_context
オブジェクトへの参照を返します(これは必ずしもMeyer’s singletonではないかもしれない、つまり本物のグローバル変数かもしれない)。
しかも、そのようなグローバルなsystem_context
オブジェクトはmutableです。
グローバルなオブジェクトであるがゆえに、それを利用するユーザーのコンポーネントのRAIIとは無縁の所で動いています。プログラム、あるいはコンポーネントの終了時にそのグローバルsystem_context
に何かしなければいけないかどうかは、system_context
とやり取りをしたコンポーネントが自分も含めて存在しているかによって決まります。また、この様なグローバルなオブジェクトにはその構築と破棄の順序の不定性など様々な問題があります。
Networking TSの仕様ではsystem_context
を直接使用するのはsystem_executor
だけで、system_executor
はassociated_executor(_t)
の仕様においてフォールバックExecutorとして使用されています。
従って、グローバルな状態に依存しないような代わりのexecutor
を用意して、現在のsystem_executor
とsystem_context
を削除しよう、という事のようです(良く分かりません・・・)
本質的には、グローバル変数として複雑な状態を持ってしまっていることが問題のようです。
標準ライブラリのパートから不用なtypename
を消し去る提案。
C++20からいくつかの場所でtypename
が不用になったのに伴って(P0634R3 : Down with typename!)、標準ライブラリの規定部分からも取り除こうという話です。
どこで不要になるかはこのページを参照。
進行中のExecutor(簡単に言えばスレッドプールサポートライブラリ)に関するもので、NUMAのようなアーキテクチャ向けに、スレッドとそこで使用するメモリを同じノード内で確保しバインドするように指示するポリシーを追加する提案。
NUMAでは1つのプロセッサとそこに接続されたローカルメモリを1ノードとして、複数のノードで構成されることになりますが、そのシステム上での論理スレッド(OS上プロセスのスレッド)はOSによって任意のノードの物理スレッド(CPUコア)に割り当てられる可能性があり、また、そのスレッド内で確保し使用しているメモリはそのスレッドを実行している物理スレッドの属するノードとは別のノードに属するメモリを使用している可能性があります。
OSのスケジューリングによってこれはほとんど予測不可能となりますが、ノードを超えたスレッドスケジュールやメモリアクセスは当然ノード内で行われるよりも高コストになり、全体のパフォーマンスに影響を与えます。この様な実行スレッドに対する割り当てメモリの位置の事をメモリアフィニティ(memory afinity)、あるいは単にアフィニティと呼びます。
このようなことが起こりえる場合にもパフォーマンスを向上させるための1つの方法は、ある論理スレッドを物理スレッドとそのローカルメモリにバインドしスケジューリングやメモリ割り当てをあるノード内で完結するように強制してしまう事です。
NUMAの様なシステムにおいてC++開発者が現在および将来のアーキテクチャに渡って最高のパフォーマンスを得るためには、この様なスレッドとメモリの配置の制御をC++標準機能としてネイティブサポートする必要がある、というのが提案の要旨です。
次のようなadjacency
プロパティグループを定義しておき、これを実行ポリシーに与えることで、Excecutor実装に対してアフィニティ制御に関するヒントを提供できるようにします。
namespace std {
namespace experimental {
namespace execution {
struct adjacency_t {
struct no_implication_t;
struct constructive_t;
struct destructive_t;
constexpr no_implication_t no_implication;
constexpr constructive_t constructive;
constexpr destructive_t destructive;
};
constexpr adjacency_t adjacency;
}
}
}
このように、アフィニティ制御をどのように行うかを指定するポリシーを渡すことで実装へのヒントとし、実装の抽象化度を維持し移植性を持たせたまま必要なら高パフォーマンスな実装を選択できるようになります。
提案文書よりサンプルコード(Executor分からないから読めない
std::vector<std::unique_ptr<float>> data{}; data.reserve(SIZE);
numa_executor numaExec;
auto indexRng = ranges::iota_view{SIZE};
auto adjacencyPar = std::execution::require(std::par, adjacency.constructive);
auto initialize = [=](size_t idx, std::vector<unique_ptr<float>> &value) {
value[idx] = std::make_new<float>(0.0f);
};
auto compute = [=](size_t idx, std::vector<unique_ptr<float>> &value) {
do_something(value[idx]);
};
auto sender = std::execution::just(data)
| std::execution::via(numaExec)
| std::execution::indexed_for(indexRng, adjacencyPar, initialize)
| std::execution::indexed_for(indexRng, adjacencyPar, compute);
std::execution::sync_wait(sender, std::execution::sink_receiver{});
属性指定時に同じ属性を重複して指定しても良いようにする提案。
現在の規定では、一つの属性指定[[]]
の中で同じ属性が複数回現れることは出来ません。しかし、属性指定を複数に分割すれば同じ属性が何回重複してもokです。
[[noreturn, carries_dependency, deprecated, noreturn]]
void f();
[[noreturn]] [[carries_dependency]] [[deprecated]] [[noreturn]]
void g();
[Wandbox]三へ( へ՞ਊ ՞)へ ハッハッ
この挙動は一貫していないので、属性指定の重複を認める(上記NGの例f()
を適格にする)方向に変更すべし、という提案です。
EWGの見解としては、属性指定を分ければ重複可能なのはマクロによって属性を条件付きで追加していくことをサポートするためのもので、一つの属性指定のなかでそれを行う事はレアケースなのでこの制限を解除する必要はない、という事。
しかし、これをそのままにしておくと、重複不可能な属性を標準に追加するたびにその旨を一々記述しておく必要があり、逆に重複可能な属性に対しては重複した時の振る舞いを記述しておく必要が生じます。これは明らかに標準を太らせ望ましくないので重複可能をデフォルトにするべき、というのが筆者の主張です。また、これは欠陥として過去のバージョンにさかのぼって適用されるのが望ましいとも述べています。
次
onihusube.hatenablog.com
この記事のMarkdownソース