.をオーバーロード可能にする提案。この提案は、リファレンスを返す提案とは異なり、コンパイラーが関数オブジェクトを生成する提案となっている。.をオーバーロードしてるユーザー定義型がある。}};その結果、以下のように書ける。OKメンバー関数の場合は、以下のような型が生成される。}};これを使って、例えばスマートリファレンスを作成できる。C++17SG-6が推奨している機能テストマクロに含まれている、__has_includeと__has_cpp_attributeを正式にC++17に提案している。__has_includeは指定したヘッダーファイルがあるかどうかを調べることができる。__has_cpp_attributeはattributeが存在するかどうか調べることができる。atomics?atomicではすべての最適化が無効になると考えている者もいるが、atomicは最適化できる。)に変換することができる。loadが使われてはいないからといって、消してしまうのは異論が多い。この論文では、c++std-parallelで議論された、異論のある最適化についてまとめている。}}このようなコードがあるとする。atomic変数progressは処理の進行具合を記録していて、他のスレッドはこの変数を参照してユーザーに処理の進行具合をプログレスバーで表示している。過剰に最適化するコンパイラーは、以下のようにコードを変換するかもしれない。my_progress;}コードがこのように変換されると、他のスレッドがprogressを参照した時に、0か999999しか見えない。他には以下のような例がある。ループコンパイラーは以下のように変換するかもしれない。}x.store(1);これも規格上問題ないが、ループを始める前にアトミック操作を行って他のスレッドに通知したいと考えるプログラマーの意図とは異なるだろう。Dimovによれば、過剰な最適化は好ましいという。shared_ptrのカウンターの増減を除去できる。McKennryによれば、上記のプログレスバー問題を解決するのによく使われる手法は、アトミック変数をvolatile修飾することだという。これでは問題のない好ましい最適化まで抑制されてしまう。コンパイラーがそこまで過剰に最適化を行わない場合はパフォーマンスの損失につながる。Boehmの考えでは、コンパイラーはアトミック変数を過剰に最適化するべきではない。属性などで過剰に最適化させる方法を提供すべき。過剰な最適化は、shared_ptrの例のようにとてもよいこともあれば、プログレスバーの例のようにとても悪いこともある。コンパイラーにとって、良い悪いは判断できない。判断できないのであれば、どちらがわにも倒さずにコードをそのままにしておくべきだ。いえ、過剰な最適化の利点はあるので、そのための方法を提供すべきだ。論文は最後に、規格の文面に追記する注釈案を載せている。C99C++規格が参照するC規格をC99からC11に引き上げる提案。参照先を買えるだけではない変更も考察されている。シグナルハンドラー内ではthread_local変数は使えない。新たに追加されたCヘッダーに対してはC++規格からは参照しない。Atomicsについては、_Atomic(T)がatomic<T>になっていると嬉しい。C言語に新しく追加された有益な機能のC++版がないなど。そのため要素をムーブできない。*を返すbegin/endを持ったown_initializer_list<T>を提案している。初期化リストから推定される型Tが、非トリビアルなムーブコンストラクターを持っている場合は、型はown_initializer_list<T>になる。extension一時オブジェクトをリファレンスに束縛すると、一時オブジェクトの寿命がリファレンスの存在期間中延長されるが、現行の規程は問題が多い。;}initializer_listだけはこのような一時オブジェクトの寿命延長をコンパイラーマジックによって行っている。一時オブジェクトの寿命延長を関数やクラスのサブオブジェクトを経由してもユーザーが行えるようにする寿命修飾子を提案しているのだが、どう考えても非現実的な机上の空論のクソ機能にしか思えない。ABIに変更をもたらすのもクソだ。真面目に読んで損をした。from_stringの提案。JSONやXMLなどのテキストベースのフォーマット利用が拡大している現代では、数値と文字列間の高速な変換が必要である。変換はinternationalizationを行う必要はない。そのためには、以下の要件を満たす必要がある。フォーマット文字列の実行時パースを行わないインターフェース上動的メモリ確保をしない(大抵のインターフェースは必要とする)localeを考慮しない関数ポインターを経由した関節アクセスを行わないバッファーオーバーランを防ぐ文字列をパースするとき、エラーと有効な数値は区別できる文字列をパースするとき、空白文字などが静かに無視されたりしない既存の標準ライブラリで提供されている方法はすべて、localeに依存している。変換処理は、教科書通りの実装では速くない。高速な実装方法が多数ある。この提案では、極めて原始的なインターフェースを採用している。*型のイテレーターベースのインターフェースだ。end)に書き込まれる。戻り値は書き込んだ最後の要素の一つ次のポインターになる。文字列を書き込むスペースが足りない場合、endが返される。スペースが足りない場合に書き込まれる内容は未規定である。整数型は以下のような関数になる。10);baseの範囲は2から36までで、10から36までの数値はaからzで表現される。valueが負数の場合、マイナス符号が先頭に書き込まれる。value);valueが負数の場合はマイナス符号が先頭に書き込まれる。文字列は10進数で、整数部が少なくともひと桁あり、オプショナルで小文字eに続いてexponentが記述される。表現は最小文字数かつ、from_stringによって元のvalueが正確に復元できるものとなる。valueが無限大の場合、infか-infとなる。NaNの場合、nanか-nanとなる。precision);小数部の桁数はprecisionになる。);戻り値はパターンにマッチしない最初の文字へのポインター。ec);文字列に変換する際のinfやnanも正しく認識される。attributeの提案。[[unused]][[unused]]が指定されたエンティティは、何らかの理由で使われていないように見えるという意味を持つ。これによって、実装による未使用警告を抑制できる。警告が抑制される[[nodiscard]][[nodiscard]]が指定された関数は、戻り値がdiscardされてはならないことを意味する。戻り値が捨てられた場合、警告が出る。}}[[nodiscard]]が型に指定された場合、その型を戻り値の型に使う関数が[[nodiscard]]指定される。;[[fallthrough]][[fallthrough]]は文のように記述される。これをfallthrough文という。;[[fallthrough]]はcaseラベルの直前に書く。これによって、複数のケースを突き抜けたコードに対しての警告を抑制できる。ComputingGPU用に現在提案されているGPUのサポートも視野に入れた機能をC++コンパイラーに実装した経験の報告書。Compiler)は、Clang/LLVMベースのコンパイラーだ。GPU/HSA)を同時に生成する。HCC自体は公開されていないようだ。問題となるのは、コードのどこの部分をどちらのプロセッサー用のコードで生成するかだ。すべてのコードをすべてのプロセッサー向けにコード生成を行うと、コンパイル時間が増大する上に、プロセッサーごとの特性もあるので、逆に遅くなる。C++提案では、特定の領域に対して機能を制限してコンパイラーにヒントを与える機能があるが、これはあまり役に立たなかったと報告している。HCCがかわりに開発したのは、プログラマーがコンパイラーがコード中の並列部分を指示できる機能云々なんだかOpenMPのようだ。モダンなGPUはC++の機能のほとんどを実行できるようになった。間接的な関数呼び出し、バイト単位のメモリアクセス、基本型、アライメントされていないメモリへのアクセス、スタック、gotoなどだ。HCCはC++のほとんどの機能をアクセラレーター向けにコード生成できる。例外はtry/catchブロックなどだ。try/catchブロックの実装は技術的に可能であるが、現在のところ実装していない。論文著者は、アクセラレーター向けにC++のサブセットを定義する必要はないと報告している。ドワンゴ広告ドワンゴは本物のC++プログラマーを募集しています。said...from_stringのstd::string版が別途ほしいです。競合させる気はないです。オペレータドットがなんかちょっと混乱してます。理解が追い付いてないです。CPUとGPUの関係は、CPUがGPUになるのが先かGPUがCPUになるのが先かと思っていましたが、GPU側がすり寄ってきましたねぇ。コンテキストスイッチングが弱いとはいえ一応それなりのことができるのであればC++のフルセットを提供したほうが後々の幸せも大きいかもしれません。C11のヘッダってよく知りませんけど有用なものはCSTDxxx形式などで選択的に取り込まなかったということは有用なものがなかったということですか?[[nodiscard]]がちょっとうざそうですねぇ。毎度ありがとうございます。VC超絶バージョンアップしないかなー。std::string版が別途ほしいです。オペレータドットがなんかちょっと混乱してます。名前が見つからなかった場合「名前検索を任意のオブジェクトでやり直すためのオブジェクト」がoperator.に引数として渡されるので好きなオブジェクトをそれに渡して名前解決するだけ。有用なものがなかったC++側でやってることと重複したりするからでしょう。取り込むべきは取り込んで、衝突するものは調整。[[nodiscard]]がちょっとうざそうですねぇ。「やるな」って言われたことをやって警告が出ることを「うざい」って...安全意識をもうちょい持とう。(Atom)C++11参考書C++11の参考書、アマゾンお気に入りリストを公開中。アマゾンの江添のほしい物リストC++11の参考書、C++の文法と機能をGitHubで公開中。EvangelistC++標準化委員会の委員ドワンゴ社員C++11本を執筆した。株式会社ドワンゴで働いている。江添のほしい物リスト筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。Texts.ただし、必要である範囲において他の著作物を引用していることがあります。