むかしむかし、私のサポートに図書館がありました。 彼女にはすべてが順調でした。Linuxで動作し、クラッシュせずに動作しています。 人々がWindowsでそれを組み立てる要求（要件）を受け取ったとき。 どうして？ しかし、最初はうまくいきませんでした。 悪の根源は手書き暗号であることが判明し、ある時点で2つの64ビット整数が乗算されました。 このような乗算の結果を保存するには、128ビットの数値が必要であり、タイプ__int128がライブラリで使用されました。 それは美しいです：それは自然なインターフェースを持ち、いくつかのコンパイラ（gcc、clang）によってサポートされ、メモリ割り当てなしで動作しますが、主なことはそれです。
Microsoftコンパイラの開発者は、このタイプのサポートを提供していないか、類似物を思い付かないか、見つけられませんでした。 頭に浮かんだ唯一のクロスプラットフォームソリューションは、OpenSSLのBig Numbersですが、多少異なります。 その結果、自転車でこの問題を明確に解決しました。限られた操作セットでuint128_tだけが必要でした。 いくつかの外部ソリューションから、UInt128クラスをアセンブルし、ライブラリソースに配置しました。 「自転車」はまさにその痛みです。 タスクは解決されました。
同じ日の夕方、「Working Group 21」（WG21）の人々がC ++ファイルの処理方法について話したイベントでくつろぎに行きました。 「cppにはint128が必要です」というトピックに関する2つの文章の短い手紙を聞いて、cpp-proposal @ yandex-team.ruに書きました。 これに対してアントン・ポルキンは、標準の開発者はこの問題を完全に解決したいと考えていると語った。 論理的には、128ビットの数値が必要になり、512ビットの数値を扱う必要があります。そして、この誰かも便利なツールを求めています。
アントンはまた、解決するための2つの方法があると言いました。言語のコアを介する方法とライブラリを使用する方法です。 言語の構文はすでに非常に複雑であるという意見があります。クロスプラットフォームで、異なる精度の数を使用する効率的な機能を提供する構成を言語に追加することは非常に困難です。 しかし、ライブラリのフレームワーク内では、対処することは非常に可能です。テンプレートがすべてです。 「実用的なプロトタイプが必要です」とアントンは言いました。 「そしてできればテストで。」 また、より多くの人々にアピールするために、タイプは単純な古いデータ（POD）でなければならないことも判明しました。
そして、プロトタイプを作りに行きました。 wide_intという名前は、意識的に選択されました。この名前との安定した関連付けはありません。 たとえば、big_numberは誤解を招く可能性があります-ヒープ（ヒープ）に値を格納し、決してオーバーフローしないと彼らは言う。 基本的な型の動作に似た動作を持つ型を取得したかった。 私は、8、16、32、64 ... 128、256、512などのサイズが進行し続けるタイプを作成したかったのです。しばらくして、動作するプロトタイプが登場しました。 作成するのは難しくありませんでした。コンパイルと動作が必要でしたが、必ずしも効率的かつ迅速ではありませんでした。
アントンはそれを研究し、多くのコメントをした。 たとえば、浮動小数点数への変換が十分ではなかったため、メソッドの最大数をconstexprおよびnoexceptとしてマークする必要がありました。 アントンは、数字のサイズの選択を制限するという考えから私を思いとどまらせました。64の倍数を作りました。その後、アントンと一緒に、提案のテキストを書きました。 ドキュメントを書くことは、コードを書くよりもはるかに難しいことがわかりました。 もう少し磨きをかけると、Anton（次に何をすべきかを理解している唯一の人）が、標準化委員会の人々に私たちの提案を示し始めました。
少し批判した。 たとえば、オーバーフローしない整数型を作成したいという要望がありました。 または、サイズをビット単位で正確に設定できるタイプ（たとえば、719ビットのサイズを取得できます！）。 ビット数に縛られることを拒否するが、機械語の数を設定するという提案は、私にとって最も奇妙なように思えました。 一意のユーザー識別子は、64ビットの符号なし整数であり、1つの符号なしlong longではありません。
一言で言えば、これらは他のタイプのアイデアでした。 私たちは批判に耳を傾けましたが、重要なコメントはありませんでした。 その後、アントンは規格の提案を発表し、次の委員会でそれを弁護しに行きました。
防御は成功しました。私たちの提案は実行に移されました-つまり、会議などで検討されます。 多くのコメントが行われました。 現在、必要な修正を行っています。 特に、委員会はそれにもかかわらずwide_intの機械語の数を使用するように頼みました。 引数は単純です。型は何らかの方法で実装されますが、これらの非常に機械語を使用すると、より効率的になります。 私は、便利なエイリアスuint128_tが標準に落ちることを望んでいます。他の誰かがそれを見る前にUInt128型を捨てることができます。 =）
実装の現在のバージョンはここで見つけることができます 。 stdcpp.ruに関する ドキュメントと小さな議論もあります 。 最初の手紙がcpp-proposal@yandex-team.ruに送信された日から合計で約4か月が経過しました。 これらのうち、私はこの提案に費やした非作業時間の約40時間。 この記事の執筆時点では、実装は1622行に拡大し、テストでさえ1940行が追加されています。
このすべてが私に与えることを伝えることは重要だと思います。 まず、意思決定プロセスがどのように構築され、標準ライブラリのインターフェイスを設計する際に何が重要かを学ぶことは興味深いです。
次に、C ++を好きな方向に変更できます。 もちろん、重要なアイデアを実現するには、志を同じくする人々が必要であることをここで覚えておくことが重要です。 たとえば、コンテナと文字列のインターフェイスをもう少し表現力豊かで明白にするというアイデアがあります。コンテナに演算子bool（）を追加したかったのです。 しかし、C ++に無関心な同僚は、私が間違っていることを明らかにしました 。
第三に、C ++のテンプレートについて多くのことを学びました。
第四に、彼らはこれが私の履歴書を何らかの形で強化するだろうと言います...私はまだそれをチェックしていませんが、私は経験豊富な同僚から私の言葉を受け取ります。
第5に、Bjarne Straustrupがあなたの作品について話し合うことに専念した通信で誰かに「+1」を書くとき、それは楽しいです。 =）彼が誰かの批判を支持しても。
最後に、Twitterでstdcppruを購読することで、RG21 C ++のニュースやイベントについて知ることができます。