Pathsfilesystemライブラリに相対パスを作り出す関数の追加。型システムに含まれていない。例外指定された関数へのポインターについて僅かに言及があるだけである。これにより、違法であるべきコードが合法になってしまったり、合法になって欲しいコードが違法になってしまったりする。解決には、例外指定を型システムに含めるしかない。それぞれ以下のように宣言される。not_vも提供される。enginestd::regexにregex_constants::multilineを追加する提案。^と$とが、文字列全体の先頭と末尾ではなく、各行の先頭と末尾にマッチするようになる。std::common_typestd::common_typeの実装を変えて、ユーザーが特殊化するときにCV修飾子はリファレンス修飾子の違いによって何種類も明示的特殊化を書かずにすむようにする提案。initializationアグリゲート初期化を拡張して、基本クラスを持つ型でも初期化できるようにする提案。C++11のアグリゲート初期化は、基本クラスがある場合には使えない。;そのため、基本クラスがある場合には、面倒なコンストラクターを書かなければならない。}このようなボイラープレートコードは書きたくない。そこで、アグリゲート初期化を拡張して、基本クラスもメンバーのように初期化できるようにする。;複数の基本クラスがある場合は、記述された順番に初期化する。Valuelambda式で*thisを値でキャプチャできるようにする提案。OK、*thisはコピーキャプチャされている}キャプチャーデフォルト*は=とほぼ同じだが、thisポインターではなく、*thisを値でコピーキャプチャーする。*thisだけをコピーキャプチャする、*thisもシンプルキャプチャーとして書ける。View非アトミック型のオブジェクトに対してアトミック操作をするviewライブラリの提案。atomic_viewは、非アトミック型の単一のオブジェクトに対してアトミック操作を提供する。ai破棄、aiへの操作がiに反映される実装方法として最も汎用的なものは、mutexのような排他的ロックを使うことだ。効率的な方法としては、まずアトミック型にコピーして、アトミック型のオブジェクトを経由して操作を行い、viewオブジェクトが破棄されるときに元のオブジェクトに結果をコピーするというものだ。atomic_array_viewは、非アトミック型の配列に対するアトミック操作を効率的に行う意図で用意されている。排他的ロック実装の場合、ロックを要素ごとではなく配列全体に対して単独で用意できる。想定用途は巨大な配列に対する高パフォーマンス演算だ。以下のような用途を想定している。並列の競合しない読み込みを非アトミック操作で高速に行うatomic_global_viewは、グローバルにアクセス可能なアトミック型のオブジェクトをアトミックに操作するためのviewだ。インターフェースはatomic_viewと同じ。意図としては、アトミック型へのコピーを行わず、元となる非アトミック型を直接操作するものらしい。View非アトミックな浮動小数点数型に対するアトミック操作を提供するatomic_viewに、整数型と同等のメンバーを追加する提案。ドワンゴ広告この記事はドワンゴ勤務中に書かれた。ドワンゴは本物のC++プログラマーを募集しています。said...P0018r00はもうちょっとですね。ポインタをコピーキャプチャしたうえで、ラムダを関数ポインタへ変更したいんですよ。ポインタが局所的グローバル変数のようにふるまってくれれば問題ない感じです。ラムダはノリのように使いたいのですが、なかなか現状の仕様ではできることが限られていておおむねうまくいってますが、かゆいところに手が届かない感じです。said...ラムダを関数ポインタ化し、キャプチャーした変数をグローバル扱いするには、関数本体のどこかにその変数あるいはその参照が直接埋め込まれる必要があります。ラムダのオブジェクトのインスタンスごとに別々の関数の実体が生成される必要があります。なると、そのようなラムダを関数ポインタ化する際には、新しい関数の実体を生成するためにJITコンパイル(雛形をコピーしてジャンプテーブルを書き換えるだけですが)が必要になるわけです。具体的には、ラムダそのものの寿命が尽きたり、コピーされたりした時、どのような挙動をするのが望ましいか、という事です。破壊しなければポインタを取る度にメモリが圧迫されるし、破壊するなら「ムーブのつもりでコピーした」瞬間に元々ポインタを取って作ってあった実体が破壊されて悲惨な事になるし、その辺りをどのように解決するのか?そもそも、JITコンパイルにより生成された実行コードは当然書き込み可能なメモリ領域に配置されるため、必ずしも実行可能であるという保証はありません(現代的なアーキテクチャであれば、権限がないとできないのが多いはず)。よって、このようにしてポインタを作るC++ソースコードは、必ず移植不能なコードとなります。これはC++の機能として実装されるべきではなく、せいぜいC++コンパイラが独自に実装すべきものでしょう。said...なるほど、なんとなくわかります。関数の多層コピーはテンプレートが実体化されるときに静的には行われています。これを動的にする必要があるというのはわかりました。