typeは、それぞれが独自のvisitorインターフェースを提供している。std::experimantal::variantはvisitを、Boost.variantはapply_visitorを提供している。ライブラリごとに異なる方法で要素にアクセスするのは汎用的ではない。erasureされた要素にアクセスできるmatch関数テンプレートを提案している。matchは以下のように宣言されている。);戻り値の型Rがないバージョンもある。pointであり、ライブラリが対応させる。Boost.variantをmatchに対応させる場合は、以下のような実装になる。}}std::variantでvisitを使うには、以下のように書く。;これをmatchで書き直すと、以下のようになる。;variantのvisitがvisitorを先に書くのに対し、matchは後に書く。P0051が提案するoverloadライブラリを使うと、以下のように書くこともできる。typeに対するvisitorも書ける。pointとしてどの関数を洗濯するかmatchより既存のvisitの方がわかりやすいか、引数の順序などの議論があるらしい。function選択した関数オブジェクト群を保持する関数オブジェクトを返し、呼び出すとオーバーロード解決して最適関数を呼び出してくれるoverload関数テンプレートの提案。std::string簡易的な実装は以下の通り。()をusing宣言で最も派生したクラスのスコープに持ち込むことにより、オーバーロード解決を実現している。この実装では、関数オブジェクトが関数ポインターやメンバー関数ポインターの場合は動かないが、ラッパーを挟めばオーバーヘッドなしに対応できる。提案では関数ポインターやメンバー関数ポインターもサポートするようになっている。興味本位でざっと実装したら以下のようになった。提案では、登録順で呼び出し可能な最初の関数を呼び出す、first_overloadも提案している。doubleこれは、おそらくtupleのようなものに格納した上で、is_callable(実装方法はN4446を参照)のようなメタ関数を適用するのだろう。Library汎用RAIIラッパーとライブラリ版finallyの提案。ヘッダーファイル<scope>をincludeすることで使える。scope_exitscope_exitは、ライブラリ版のfinallyだ。ブロックスコープを抜ける際に指定した関数オブジェクトを実行してくれる。デストラクターが自動的に処理を実行してくれる}自動ストレージ上に確保する習慣をつけさせるため、make_scope_exit関数も用意されている。デストラクターがデリーターを実行してくれる}はやくほしい。Ostream同期バッファつきostream、osyncstreamの提案。ストリーム出力は競合を起こさないと規定されているが、結果については規定されていない。そこで、出力をバッファして、途中に他の出力を挟まずに一括して出力できる機能の提案。field現在提案中のコルーチン、レジューム可能関数を実装しているコンパイラーがでてから丸一年になる。実際の使用経験から得られた知見をもとに、設計を見直す提案。様々な変更が提案されている。Libraryネットワークライブラリの非同期処理は、futureによる継続ベースの処理と、コールバック関数による処理ができるが、コルーチンを使うとオーバーヘッドがさらに削減できるのでコルーチンに対応させる提案。関係ないが、コルーチンは[[nodiscard]]の恩恵を受けるということが書かれていて面白い。f()と書くべきレジューム可能関数fを、f()のみで使った場合はコンパイルエラーにできる。Keywordsソフトなキーワードを導入する提案。C++標準化員会の会議では、よく、「いいヤツは全部使われてるから、変なヤツを使わなきゃならん」という発言が行われる。ヤツというのは、キーワードのことだ。whenは、すでに変数名やフィールド名や引数名や名前空間名として使われている。そこでこの提案では、ソフトキーワードを提案している。ソフトキーワードは、std名前空間に暗黙に定義されるエンティティである。キーワード}名前の衝突がない場合、using宣言を使うことでスコープ解決演算子を省略できる。;}しかし、using宣言を書くのも面倒だ。提案では、ソフトキーワードに対する名前検索が何も見つけられなかった時に、ソフトキーワードだと認識するようにする提案もしている。}ただし、この変更を受け入れた場合でも、テンプレートの場合は、依存名の解決のために、std::が必要だ。lookupについてはすでに知られているので、テンプレートコードを書くプログラマーならば対処できる些細な問題だろう。stdを使った既存のコードが壊れる可能性がある。directiveはソフトキーワードには働かない例外条項を付け加えればよいという提案もしている。確かに便利だが、ものすごいツギハギ感がある。3)コルーチンの文面案。awaitとyeildのキーワードが固まっていない。久しぶりに文面案を見ると、だいぶ変わっている。キーワードとして、await-keywordとyeild-keywordがある。このキーワードはプレイスホルダーで、将来的には何らかのキーワードが割り当てられる。await式は、オペランドの式の実行が完了するまで、コルーチンの評価を停止させる。value)を呼び出す。シンタックスシュガーだ。yeild式は、generatorを作るのに使える。;}しかし、戻り値の型がよくわからない。await式のみが使われているとき、await式とyeild式が両方使われているとき、yeild式のみが使われているときで、型が変わる。その型はコルーチンpromiseを実装した型で、どうもユーザーが実装しなければならないようだ。Execution様々な実行媒体を隠匿して扱えるライブラリの提案。実行媒体には、スレッドプールを始めとして、ファイバーやGPUスレッドやSIMDなど様々なものがあるが、この提案では、それらの多種多様な実行媒体を効率的に隠匿できる設計にしていると主張している。Libraryリングアダプターの提案。既存のコンテナーをリングと呼ばれる固定サイズのキューとして扱えるコンテナアダプター。既存のキューアダプターは、dequeやlistの上に構築されていて、動的にサイズを増加させる。これはメモリを断片化させる問題がある。リングアダプターは、arrayやvectorといった連続したストレージを使うコンテナーのアダプターで、動的にサイズを増やすことがない。Boostにはcircular_bufferがあるが、これはあまりにもでかすぎる。双方向である上にランダムアクセスイテレーターまで提供している。インターフェースは既存のqueueを模倣している。pushとemplaceに加えて、try_pushとtry_emplaceが追加されている。これはリングが満杯の時に呼び出すと失敗する。arrayがデフォルトのコンテナーになっているfixed_ringと、vectorがデフォルトのコンテナーになっているdynamic_ringがある。dynamic_ringという名前だが、サイズを実行時の初期化時に指定できるだけで、サイズがあとから伸長されることはない。後からサイズを増やしたければ、すでにあるqueueにvectorを指定して使えばいいだけだ。4が解禁されるために有給を取る。ドワンゴは本物のC++プログラマーを募集しています。said...リングアダプタよさそうですねぇ。新規実装とするよりアダプタとするほうが、多様な構造を扱えて確かにうまいかも。コルーチンの文面はリビジョン変わってもタイトルのRxは増えなかったですね。タイプイレーザーが早く入ってほしいです。said...yeildではなくyieldでは?本文中で全箇所間違ってます。(Atom)C++11参考書C++11の参考書、アマゾンお気に入りリストを公開中。アマゾンの江添のほしい物リストC++11の参考書、C++の文法と機能をGitHubで公開中。EvangelistC++標準化委員会の委員ドワンゴ社員C++11本を執筆した。株式会社ドワンゴで働いている。江添のほしい物リスト筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。Texts.ただし、必要である範囲において他の著作物を引用していることがあります。