mongoDBを少し触った。mongo-cxx-driverを触ってみたらなにやらgridfsでシークができない。
仕方ないので、空読みしてシークする処理を自前で書いた。もうちょっといいやり方はないか。
https://gist.github.com/Kiterai/d0696eca57dd2e002d9563c27ac65672
cpprefjpを読み進めた。コルーチンとコンセプトの読解を後回し。
エイリアステンプレート経由でのクラステンプレートのテンプレート引数推論
確かにこれは出来て欲しい気はする。コンパイラ実装者は大変だが。
ほとんどのvolatileを非推奨化
volatileの想定使用法をあんまりちゃんと知らなかった。なんか最適化されたら困る用途ということだが、より厳密に言うとこれは組み込みや低レイヤにおけるメモリマップドIOとかを想定したものらしい。
なのでアプリの外側とのメモリを介したやり取りを想定し、プログラマが書いた通りに厳密に制御できるよう最適化抑制がかかるが、一方でアプリ内部でのスレッド間通信には適さない。volatileでない箇所のプログラムとは順序が前後する可能性が全然ある。
というわけでここまでが前提で、この変更は何かというと「volatile変数にアクセスする箇所では1文の中でただ1回だけ領域にアクセスする」ことをなるべく明確にしてプログラムを安全にすることを求めるための変更のようだ。分かりやすい代入と読み取り以外の命令、+=とか++みたいなやつはよろしくない。またa=b=cみたいなワンライナーもよろしくない。そういう話のようだ。
throw()による例外送出しない指定を削除
あ、それ消しちゃうんだ。cpprefjpを網羅的に読み始める前はC++と言えば互換性！！というイメージだったが、最近は非推奨→削除という流れがそれなりにあることを理解してきた。
new式での配列要素数の推論
その用法は思いつかなかったな。new式は領域を確保するものなのだからいくつ確保するのかプログラマが明確に采配するものというイメージがあったが、確かに配列変数の宣言で推論が入るならnew式でも入っていい。
friend指定された関数内から構造化束縛を使用して非公開メンバ変数にアクセスすることを許可
friendは好きじゃないが、構造化束縛だけ特別扱いで不許可になるのは一貫性がない。正しい変更だ。しかしなぜ構造化束縛だけだめだったんだ？実際にメンバにアクセスする主体がfriend指定されたその関数ではなくstd::getとかになるから、とかだろうか。憶測でしかないが。
const修飾されたメンバポインタの制限を修正
それ許可されるの違和感ありすぎる。左辺値じゃなきゃダメー！という指定なのに、右辺値でもconstメンバ関数ならOKなんだ。謎。
constメンバ関数ならオブジェクトに影響を与えないから右辺値に対して呼ばれても問題ないとかそういう話なのだろうか？ちょっと意図が分からない。
constexpr関数内で未評価のインラインアセンブリを許可することによる組み込み関数のconstexpr有効化
一応前に読んで知ってはいた。constevalと違ってconstexprは実行時にも評価されうるということを踏まえればまあ分かる。
constexpr関数内でのトリビアルなデフォルト初期化を許可
どんどんconstexprで出来ることが増える。未初期化のintとかを読み出したりしなければ怒られる道理は確かにない。
しかし「UBが発生しなければなんでもいいよ」にはならないのは、ちょっとずつ許可していく方が安全ということだろうか。実行時ではなくコンパイル時になんかヤバいことが起きてコンパイラ自体が爆散したりするのを危惧しているとか？
constexpr関数内でのtry-catchブロックを許可
これは面白いが、throwは出来ないんだ。まあconstexprでない呼び出し元関数に伝播しちゃったりしたらコンパイル時と実行時の境界が崩れるから、そりゃそうか。std::vectorとかをconstexprで使えるようにするためにこれが必要だったという解説は面白かった。納得。
char16_tとchar32_tの文字・文字列リテラルを、文字コードUTF-16/32に規定
「実際にはすべての実装でこれらの文字・文字列リテラルはUTF-16とUTF-32にエンコーディングされるため」で爆笑した。
Categories: 未分類