second_argument_typeというネストされた型名の廃止。これらのネストされた型名はdecltype以前の機能であり、もはやその役割は別の機能(result_ofなどのtraits)で担うことができる。labmda式のクロージャーオブジェクトなどresult_typeを持たない型が多数あり、もはやresult_typeなどを使うコードは、ジェネリックではない。<random>にあるresult_typeなどは意味があるため、残す。Templates以前の機能であり、いまはより優れたnot_fnで代替できる。Compatibilityに移動。互換性のために、これらの除去した機能を実装するコンパイラーはC++17規格準拠であるという例外的な文面を追加する。deduction)をクラステンプレートのコンストラクターにも提供する提案。関数テンプレートには、テンプレート実引数を関数の実引数から推定してくれる機能がある。f<double>}しかし、クラステンプレートにはそのような機能はないため、テンプレート実引数を手書きしなければならない。OK}この問題に対する伝統的な解決方法は、関数テンプレートに実引数推定させてクラステンプレートを返す方法がある。X<int>}この解決方法の問題は、まずmake_x関数テンプレートを書かなければならないということだ。ライブラリごとにそのようなmake関数のインターフェースは異なるので、ライブラリごとにmake関数を使う際にドキュメントを参照しなければならない。コピーもムーブもできない型に対してはmake関数を提供できない。この提案による機能は2つある。>もうひとつは、コンストラクターがクラステンプレートのテンプレート実引数に依存していない場合でも、実引数推定を行えるようにする機能。vectorのイテレーターを取るコンストラクターは、上記の方法では実引数推定できない。;このため、コンストラクターからクラステンプレートのテンプレート仮引数に依存を発生させ、実引数推定をさせるためのマッピング機能が提案されている。iterator_traits<InputIterator>::value_type>極めて読みづらい文法だ。これはライブラリ作者が書くものであって、単なるライブラリのユーザーは存在を気にする必要はないのが救いか。empty保証のある強いvariantの提案。empty保証をするためには、ダブルバッファリングが必要になる。これはvariantのサイズを2倍にしてしまう。論文は、プログラマーはコストを犠牲にしてもプログラムの正確性を重視すると主張している。Memoryの発展によって、将来はあらゆる型でダブルバッファリングをしなくてもすむようになる(かなり疑わしいが)ので、将来の拡張性があることなどを挙げている。VariantP0093の省略版のような文書。N0093とほぼ同じ。Variantコア言語でvariantに対応する提案。純粋にライブラリベースのvariant実装は使いづらい。一般ユーザーにすらSFINAEによるコンパイル時条件分岐を強いる。そこで、コア言語による対応が必要だとしている。提案では、以下のようにvariantを宣言できる。;コア言語で対応するので、switch文もvariantに対応できる。;}やはりコア言語で対応すると使いやすい。C++プリプロセッサーマクロによる機能テストのためのライブラリ。C++17機能に対応する機能テストが追加されている。StorageTLSの利用例を示した文書。スレッドローカルストレージには長年の歴史があるが、近代的な並列実行において、利用価値はあるのかどうか疑問視されることがある。この文書は、TLSは現代でも利用価値があると解説している。問題は、SIMDやGPGPUではTLSはサポートしづらい。TLSがサポートされないのでは有益なコードが書きにくい。提案では、SIMDやGPGPUという実行媒体の特性を解説した上で、TLSを現実的にサポートするための案をいくつか出している。TLSに複数の種類を作る案。SIMDやGPGPUで使うTLSは全TLSの一部なので、その一部だけを絞り込めれば実用的なパフォーマンスになる。SIMDやGPGPUのTLSは、非トリビアルなコンストラクターが実行されない制約をつけるなど。switchingN4397の改訂版。switchのための低級APIの提案。ドワンゴ広告ドワンゴはプログラミング講師を募集しているそうだ。正解が「オブジェクト指向プログラミング」となる問題文を作成せよという課題が興味深い。「最大200文字以内」という条件はいいとして、「正答の直接的な記載を禁ずる」ことと、「プログラミング言語名の記載を禁ずる」という条件がある。Kayが研究していたプログラミングのパラダイム」とか、「UMLで記述されるプログラミングのパラダイム」である。Kayといえばわかりやすいが、しかしこれは歴史問題のようだ。UMLは一般にプログラミング言語とは認識されていないので、当然条件を満たすはずだ。それはそうと、C++のオブジェクト指向は、Simulaの影響を受けている。Kay自身もプログラミング言語を開発しているのだが、C++を始めとする真面目な実務向きのプログラミング言語におけるオブジェクト指向のサポートは、Simulaの影響が大きい。Kay自身のオブジェクト指向を具体化したプログラミング言語の実装、Smalltalkは、実務向けのプログラミングにはあまり影響を与えなかった。Objective-Cや、あまり知らないがひょっとしたらSwiftがその影響を受けているかもしれない。Smalltalkは、単なるプログラミング言語ではなく、smalltalkというシェルでもあり、エディタでもある、プログラミング環境であり、プログラミング言語単体で切り離せなかったため、実務からは遠くなってしまったのだと思う。ところで、最近のC++は、というよりも最近の言語は、あまりオブジェクト指向対応を謳っていない気がする。これは、いまさらに構造化プログラミング対応言語を謳わないのと同じで、オブジェクト指向が十分に一般化したためではないかと思う。オブジェクト指向のプログラミング言語での取り入れ方もだいぶ変わった。オブジェクト指向の黎明期は、やたらと派生と継承ベースの設計が流行ったが、複雑な派生関係をユーザー側に露出させてしまうと、ライブラリが使いづらくなる。最近は汎用的なインターフェース(制約)によるライブラリ設計が多いようだ。コンセプトが議論されているのもそのためだ。ドワンゴは本物のC++プログラマーを募集しています。said...今回のドワンゴ広告、広告ではあるのだが長いし面白いので、独立した記事に意見をまとめた方がいいのでは。said...手続きとデータを一つの塊として扱う機構を一般的になんというか。そのようなプログラミング手法をなんというか。