C++C++に様々な比較用のカスタマイズ可能な共通ライブラリを追加する提案。order、そしてequivalenceがある。アルゴリズムやデータ構造によって、要求する比較の強さや、提供できる比較の強さは異なる。pointは、単一の演算子のオーバーロードで提供されてきた。pointを提供するものである。T&);また、同値比較としては以下の関数が追加される。SpecificationSG6による数値まわりの提案をまとめた文書。Aliasesメタプログラミングにより数値計算をして、コンパイル時に値を保持するのに必要な数値型のビット数を求めることができる。問題は、その求めたビット数から整数型を選択するライブラリが提供されていない。そこで、この提案では、そのようなライブラリを提案する。少なくとも7bitを持つ高速な符号付き整数型この提案で興味深いのは、符号付き整数型は、負数を2の補数で表現すると厳密に規定されていることだ。754で規定されている浮動小数点数表現を使うと厳密に規定されている。MAX_BITS_2IEEEFLOATも追加される。プリプロセッサーマクロである理由は、コンパイル時に分岐できるようにするためだ。Operationsオーバーフローを検出できる整数演算ライブラリと、演算結果を2倍のサイズの整数型で返してくれるライブラリと、演算結果を同サイズの整数型2つに分けて返してくれるライブラリの提案。結論から言うと、クソコード生成ライブラリ。2つの符号付き整数を加算する場合は以下のようになる。;overflow_xxxは、第一引数に結果を格納する整数型へのポインターを取り、第二引数以降に演算する整数の値を取る。演算結果がオーバーフローした場合、trueが返され、ポインターには書き込まれない。演算結果がオーバーフローしなかった場合、falseが返され、演算結果がポインターを関節参照して書き込まれる。提案は他にも、倍精度演算を提供している。結果は、演算に使った型の倍のサイズの整数型でうけとるか、2つの整数型で受け取ることができる。型は、<cstdint>から持ってくるか、P0102で提案されている型を使うなどする。この提案では整数型は規定しない。;2つの整数型で受け取る場合、上位ビット列を戻り値で返し、下位ビット列を第一引数のポインターを介した間接参照で書き込んで返す。下位ビット列は必ず符号なし整数型になる。Crowlで、GCCが提供しているオーバーフロー検知機能付きの演算ライブラリを引数の順序などを少し手直しした他はそのまま持ち込んできた様子だ。原始的でわかりにくい設計をしていて、これを使ったコードはLinusも激怒するほどのクソになる。Torvals、クソコードにブチギレオーバーフロー検知機能付きの演算はほしいが、ライブラリで提供するのは無理がある。思うに、コア言語でのサポートが必要だろう。Types任意のワード長での整数演算ができるmulti_int/multi_uintの提案。multi_uint;実装が提供する最大の組み込み整数型ですら演算精度が足りない場合、複数の整数型のオブジェクトを組み合わせて、多倍長精度演算を行う必要がある。そのような演算を手で書くのは難しい。標準で提供されているべきである。multi_int/multi_uintは、組み込み型が提供している演算子を同じ意味でオーバーロードしている。通常の整数と同じように、暗黙にboolに変換できるようboolへの変換関数もある。提案では、このような演算を整数型の配列に対して行う低級な関数も提供している。これによりユーザーは自前の多倍長演算も実装できる。提案では関数のシグネチャに(が足りずに文法が間違っていることと、divがないように見える。無限精度整数ライブラリも標準にほしいが、こちらもほしい。丸め方法はすでに、numeric_limitsのround_styleで取得したり、fenv.hで設定できる。既存の方法ではある重要な場合における挙動がかけている。値が表現可能な2つの値から等しく離れていた場合、どちらの方向に丸められるのかということだ。論文では、これに対して、以下の方向を考察している。生成コード最小どうでもいいこの考察を元に、提案では以下のenumがある。supportedとなっている。規格準拠の実装はサポートする義務がない。round(mode,U)という関数に渡すことで使用する。モードは以下のようになっている。完全に正しいプログラムでありオーバーフローは数学的に決して起こらない。オーバーフローは極めてまれにしか起こらない。オーバーフローが起こったらabortする。2の補数表現による挙動こちらの設計のほうがまだ比較的読みやすい。提案では丸め方法とオーバーフロー挙動を同時に指定できる関数も提案している。Arithmetic2進数固定小数点数ライブラリの提案。提案を読んだがどうにも使い方が難しい設計と命名だ。筆者に数学的素養がないためかもしれないが、もう少し誰でも簡単に使える設計になっていた方がいいのではないか。PL/1を挙げている。CORALとJOVIALは初めて聞いたプログラミング言語だ。std::arrayconstexprが暗黙にcosntを意味しなくなったので、std::arrayがconstexpr対応ではなくなってしまったのを修正する提案。(TLS)SIMDやGPGPUなどの軽量実行媒体では、TLSはうまく動かない。これは既存のライブラリが動作しない問題を引き起こす。問題になるのは、math.hだ。多くのmath関数は、エラー通知にerrnoを使う。MATH_ERRNOが非ゼロである場合、errnoに具体的なエラー内容が書き込まれる。errnoは、互換性のために必要だが、その特性からTLSが使われている。SIMDやGPGPUによる並列化が行われるコードは、特に数学関数を使いたいはずだ。数学関数はerrnoに書き込むために競合を起こして使えない。この問題はどうにかして解決しなければならない。軽量実行媒体でもTLSを使えるようにする案もあるが、ここでは、数学関数側で対処する案が考察されている。制約を加える軽量実行媒体の文脈では、数学関数はmath_errhandlingやerrnoにアクセスしない。errnoを関数の引数を経由して受け取るerrnoにアクセスするすべての数学関数に、例えば以下のようにオーバーロードを追加しなければならない。errnoを戻り値で返す。tupleなどを使わなければならない。;そもそも、errnoでエラー処理をしているプログラマーは少ないと思うので、1.が最も妥当な案だと思う。本当にエラー処理をしたければ実装依存の方法を使うのではないか。Typedefs3つもの大きめの変更が提案されているので、提案を分割してほしい気がする。Aliasを提案している。Aliasかつて、強いtypedefとも呼ばれていた機能。以下のようなエイリアス宣言に似た文法を持つ。opaque-definitionaccess-specifierは、お馴染みのpublic/protected/privateだ。それぞれ、以下のような意味を持つ。is-implemented-as関係。opaque型の定義の中でのみ暗黙の型変換を認める以下が利用例だ。aliasは、あらゆる箇所で内部型との暗黙の型変換を許可する。そのため、int型で初期化できる。"x+x"の結果の型がintになるのは驚くかもしれないが、仕組みを知れば当然だ。+(int,int)が呼ばれる。そのため、結果はint型になる。+のような基本的な操作で、完全に暗黙の型変換を許すか、全面的に許さないかだけでは使いづらい。式を評価した結果の型についても、柔軟に決めたい。aliasには、opaque-definitionを記述することができる。opaque定義では、このようにトランポリン関数を定義できる。することによって、任意の演算子の挙動を変えられる。-(int,int)が呼ばれる。-を使う事自体が想定できない場合がある。そのために、deleted定義が使える。引数の型を変更するだけのトランポリン関数の場合、default化することもできる。;あらゆる演算子に対してdeleted定義を書くのは面倒だ。そこで、アクセス指定子にprotectedを指定すると、opaque定義以外の暗黙の型変換をしないようになる。aliasをクラス型に対して適用する場合、メンバー関数に対しては、自動的にトランポリン関数が作られる。元のクラス型をtype型にしたトランポリン関数を呼び出す。aliasはテンプレート宣言できる。;}エイリアス型と元の型は、is_sameやis_base_ofなどの型の関連性を調べるtraitsでは、異なる型で派生関係にもないと判断される。typeidも別の型になる。is_integralなどの単一の型を調べるtraitsでは、エイリアス型は元の型と同じになる。sizeofの結果は元の型と同じで、メモリレイアウトなどは全て同じ。aliasを使うことによる実行時コストは発生せず、reinterpret_castを使って元の型にキャストしても動作する。P0109は、関数エイリアスを提案している。関数に別名を付けたい需要は昔からある。*lt;を使う版と、比較関数を受け取る版の関数が存在する。それぞれ、やっていることは同じなのにコードが異なる。<を割り当てることができれば、同じように自然に書ける。;}また、P0109は、派生に対する拡張も提案している。配列とCV修飾されている型を除く、基本型から派生できるようにする拡張だ。;ドワンゴ広告ドワンゴは本物のC++プログラマーを募集しています。aliusやらnewtypeやら。なんか重複機能の提案が見受けられるので整理してほしいですね。多倍長精度演算は決まらないですねぇ。競技プログラミングなんかではそろそろ需要が出始める頃かと思います。自作していたのでは全く効率よくないですし、さっさと入らないかなー。(Atom)C++11参考書C++11の参考書、アマゾンお気に入りリストを公開中。アマゾンの江添のほしい物リストC++11の参考書、C++の文法と機能をGitHubで公開中。EvangelistC++標準化委員会の委員ドワンゴ社員C++11本を執筆した。株式会社ドワンゴで働いている。江添のほしい物リスト筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。Texts.ただし、必要である範囲において他の著作物を引用していることがあります。