C++17トライグラフ除去の可否を問う投票で、賛成票が多数派であったが、その中でIBMは強く反対の立場であった。トライグラフは現に利用者がいて、ASCIIが多数派なC++では、マイノリティといえど、実際の利用者がいる機能を除去するのは、C++のためにならないという主張である。Stroustrupから、その現実の利用者をまとめて報告せよと言われたので、IBMはこの文書を提出した。IBMによれば、機密のため顧客名は明かせないものの、現実に利用者が多数いるという。重要な利用者の、ある北アメリカの大手の某銀行は、IBMメインフレームを使い続けている。処理は極めて重要である。彼らは長年の多大な労力をデバッグにつぎ込んでおり、安定していて、他の環境に移行することは決してない。C++はASCIIが多数派であるが、物言わぬマイノリティの声を代弁するためにもIBMはトライグラフ除去に反対するという。私にはよくわからない世界だ。2)40年前のコピペ技術である#inludeにかわるモジュール機能の提案。現在、C++が使っているコンパイルとリンクモデルは、C言語から受け継いだものである。各翻訳単位は、他の翻訳単位のことを一切知らずに処理される。翻訳単位を超えるには、名前リンケージ(シンボル名)を使う。名前に対応する定義はひとつだけでなければならない(ODR)。翻訳単位の外に見える名前である外部名を、手動によるコピペで管理することを防ぐために、我々は40年前の技術である自動コピペ技術、プリプロセッサーによるヘッダーファイルを未だに使っている。これは、コンパイラーからみれば、コピペである。ヘッダーファイルの中身はマクロによって書き換わってしまうおそれがあり、誤りの元である。変数や関数の宣言ぐらいしか書かれていなかった昔のC言語ならば、まだ十分に耐えられたのだが、モダンなC++では、ヘッダーファイルには実行されるコードが記述されている。コンパイラーは翻訳単位ごとに重複した内容を処理しなければならず、現代のC++のコンパイル時間の増大の原因になっている。この論文では、C++に近代的なコンポーネント化をもたらすための機能、モジュールの設計を考案している。モジュールは、既存のプリプロセッサーと組み合わせて使うことができる。これは穏やかな移行のために必要である。既存のプログラムはプリプロセッサーによる自動コピペ技術でコンポーネント化されていて、自動的にモジュールに書き換わってはくれない。今後もしばらくはぷりプロセッサーを使う必要がある。この地上からプリプロセッサーを一掃して、純粋なモジュールのみを使う素晴らしき新世界になるまでは。モジュールの使い方だが、論文では以下のような文法を想定している。;}モジュールを使う側からすれば、#includeの機械的な置換ぐらいで対応可能だ。ライブラリ側がモジュールに対応するにはどうすればいいのだろうか。これには二つの設計が考えられる。コンパイラー側が自動的に対応する方法と、ソースファイル中に宣言を記述するものだ。論文では、コンパイラーに推測させるよりも、明示的な宣言の方が好ましいとしている。モジュールは、モジュール宣言で宣言する。;この宣言の意味は、この翻訳単位のこれ以降の宣言は、module-nameという名前のモジュールの一部であるという宣言だ。モジュール宣言は翻訳単位に一つしか存在できない。前回の論文では、翻訳単位の最初の宣言でなければならないとしていたが、今回の論文では、そのような制約は必要ないということで緩和された。移行を簡単にするために、module宣言の前に宣言されているものは、グローバルモジュールに属するものになる。モジュールによるインターフェース宣言は、実装と同じソースファイルに記述することもできるし、別のソースファイルに記述することもできる。これは、どちらか片方だけに制限するのは現実的ではないためだ。モジュールは外部へのテントリーポイントを、export宣言で宣言する。;このように記述した場合、Xはグローバルモジュールに属する。YはモジュールMに属するが、エクスポートされていない。ZはモジュールMに属するexportされている名前だ。toplevel-declarationは、import宣言かmodule宣言か、通常の宣言のいずれかである。export宣言にimport宣言を指定した場合、import宣言で指定したモジュールがエクスポートする宣言が、現在のモジュールから見えることになる。;}export宣言でmodule宣言を指定すると、現在のモジュールのサブモジュールの名前を宣言したことになる。;export宣言でトップレベルの宣言をすると、その宣言は外部に公開される。;}まだまだ文法は変わるだろうし、具体的な実装が出てきてからが面白いところだろう。memory_order_consumememory_order_consumeの存在意義の解説。ロックやアトミックのような命令を発行することなく、コンパイラーの一部の最適化を抑制するだけで実装可能だが、なかなかそういう高品質の実装が出てこない現状について書いている。Air)値とは、何の脈略も関連性もなく現れる値のことである。何らの排他的制御も同期処理も行わずに同じオブジェクトに複数のスレッドから値を書き込んだ場合、その結果の値は未定義となる。未定義である以上、結果の値がどのようになってもかまわない。脈絡のない値が出てきてもいいものか。議論の結果、規格では実装に対しOOTAを避けるように記述されているが、具体的なOOTAについて記述されていない。この論文では、具体的なOOTAについて記述している。1std::randを廃止したい。std::randはあまりにもお手軽に使うことができる。1から6までの乱数をひとつ生成したいとする。大昔のrandならば、以下のように書ける。このようなコードを書いてはならない。;}まずstd::time()で初期化するのはお勧めできないし、剰余を使う方法は、均一に分布しない。C++11ではどう書けばよいのか。;}このコードは毎回初期化されるし、均一に分布するが、やや長過ぎる。C++11の乱数ライブラリをまともに使うには、乱数エンジンやら乱数分布やらの概念を学ばなければならない。std::randのような手軽さを持っていて、モダンな小さい乱数ライブラリが欲しい。そこでこの論文では、そういうライブラリを提案している。;}結局、手軽でなければ普及しないのであれば、入るべき提案だろう。union型安全なunionであるvariantライブラリの提案。Boost.Variantに似たインターフェースになっている。ビジターなし、Variantを再帰的に使った場合の特殊な対応なし。;}テンプレート仮引数に指定した型のみ入れられる型安全なunionだ。論文で言及しているが、variantは空の状態になりうるという。空になりうるこの場合、aにbを代入するために、まずaに入っているTのオブジェクトを破棄して、次にUを構築するが、Uの構築に失敗した場合は、空の状態になる。2)universal-character-nameに対する実装の挙動の提案。ドワンゴ広告この記事はドワンゴ勤務中に書かれた。最近、街コロというボードゲームに興味を持っているが、いまいち戦略が見いだせない。ドワンゴは本物のC++プログラマーを募集しています。said...トライグラフには死んで欲しいです。日本語使用者である自分であってもです。3という数字が今のコンピュータには不吉すぎます。モジュールは面白いですね。今後constexprが普及してコンパイル速度が激遅になる可能性を加味して、入ってほしい機能です。自分はヘッダー書くの苦手ですし。ファイルシステムは難航してますね。Randのようなお手軽関数はまぁ毎度宣言を書くよりはお手軽なので入ってほしいです。注文を付けるならエンジンを選べるようにしてほしいです。ゲームでは一様乱数が必ずもベストではないことがあるんですよ。あー、でもそうすると初期化コストであんまり記述量変わらないですねぇ・・・。Orzバリアントかタイプイレーザーが入ってほしいと思います。個人的な夢としてオレオレ言語を作りたいと思っています。その時の変数システムのサイズを減らしたいのでどうしても言語機能として備わってほしい機能に思います。ベーシック畑で育ったのでそっちの方が肌に合うというのもありますが。触ってないので思ってるだけかもしれません。(Atom)C++11参考書C++11の参考書、アマゾンお気に入りリストを公開中。アマゾンの江添のほしい物リストC++11の参考書、C++の文法と機能をGitHubで公開中。EvangelistC++標準化委員会の委員ドワンゴ社員C++11本を執筆した。株式会社ドワンゴで働いている。江添のほしい物リスト筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。Texts.ただし、必要である範囲において他の著作物を引用していることがあります。