C++ の二つの派閥

Zero Ranger. トグルオリジナル/ディザ画像 C++ の未来を巡って、多くの争いや議論があるようです。Reddit や特定のオレンジ色のウェブサイトでは間違いなく、公式の C++ 標準委員会会議でも同様です。それほど遠くまで見る必要はありません。 編集 (2024年11月25日): タイプミスと表現。 HN、r/cpp、lobste.rs で言及。 C++ の絶対的な状態 状況は以下のようになっているようです。 C++ Evolution Working Group (EWG) は、P3466 R0 - (再)確認された C++ の将来の進化のための設計原則 の採用で合意に達しました。これは、ABI の破壊がなく、C および以前の C++ とのリンク互換性を維持することを意味します。また、「バイラルアノテーション」（例えばライフタイムアノテーションなど）もないことを意味します。 これは、ABI の破壊なしとゼロオーバーヘッド原則という、互換性のない目標を倍増させるものです。 これが良いか悪いかは別として、これは C++ 言語の現在の軌道を文字通り倍増させるものです。 その一方で: 米国政府は人々が C++ の使用をやめることを望んでいます。 CISA NSA ホワイトハウス、明らかに。 いいえ、本気です。 米国政府の様々な部門が、メモリ安全でない言語の使用に対して業界に警告する論文、レポート、推奨事項を発表しました。 あらゆる種類のビッグテック企業が Rust を採用しています。 Microsoft は明らかにコアライブラリを Rust で書き直しています。 Google は Rust にコミットしているようで、実際、双方向 C++/Rust 相互運用ツールの開発に着手しました。 AWS は Rust を使用しています。 など。 ビッグテックといえば、Herb Sutter が Microsoft を去り、MSVC が C++23 の機能を実装するのが遅く、コミュニティに優先順位付けを求めていることに気づきましたか？ 悪名高いプラハ ABI 投票が行われました (要約: 「C++23 は ABI を壊しません。将来壊すかどうかは不明です。」)。Google は C++ 開発プロセスへの参加を大幅に減らし、代わりに独自の C++ 後継言語の開発に着手したとされています。彼らは、C++ を改善しようとした際の問題点をすべてまとめた概要さえ作成しています。 長年にわたって C++ 標準委員会のプロセスに参加しようと最善を尽くした人々が、結局は消耗して追放されたという話は、コミュニティ全体で広く知られ、共有されています。 (機能が最初に C で利用可能になることも役立ちません。) モジュールはまだ実装されていません。私たちはまだモジュールですか？ 「セーフティプロファイル」は、既存の C++ コードに一定の安全性を後付けしようとしながら、既存のコードへの変更を最小限に抑えようとしていますが、まだ奇妙な状態にあり、実装がありません。 Sean Baxter 自身もプロファイルに反対の立場を取り、C++ を「仕様不足」と評しました。 さらに深く掘り下げれば、より多くの情報源を見つけることができます。例えば、読者が書いて私と共有してくれたこのレポート/分析をご覧ください。 あなたはどうかわかりませんが、もし私がこれをすべて外部の人間として見たら、C++ が基本的に崩壊しており、非常に多くの人々が C++委員会の能力に、どうにかしてこれを乗り切るという信頼を失っているように見えるでしょう。 二つの文化 人々は他の解決策を探しているようです。例えば、Google です。 Google は ABI 投票以来、「プロセス」への信頼を明らかに失いました。これは言語自体への信頼の喪失ではありません。Google は世界で最も大規模な C++ コードベースの一つを持っており、それは彼らにとって非常に役立ってきました。これは、圧力が増す中で（潜在的な政府規制、競合言語、主要プレイヤーからのより良いパフォーマンスと安全保証への欲求など）言語が進化する能力への信頼の喪失です。 では、問題は何でしょうか？ なぜ C++ はただ…変わらないのでしょうか？ それを理解するのは簡単です。Herb Sutter がプロファイルに関する論文で述べたことを見てみましょう。 「既存のコードを変更する必要性を最小限に抑えなければなりません。既存のコードへの採用において、数十年の経験は、大規模なコードベースを持つほとんどの顧客は、規制要件が強制しない限り、厳格なルールを満たすためにコードの1%すら変更できないし、変更しないということを一貫して示しています。」 – Herb Sutter クール。誰か驚いていますか？ 私はそう思いません。 さて、これを Chandler Carruth の WG21 メンバーページでの経歴と対比させてみましょう。 私は Clang 上に構築され、現在は Clang プロジェクトの一部である C++ ツーリングと自動リファクタリングシステムの設計を主導しました。 […] Google では、Clang ベースの自動リファクタリングツールを、1億行を超える C++ コードの全コードベースに拡張する取り組みを主導しました。20分で全コードベースにわたる分析とリファクタリングの適用が可能です。 ああ。 見えますか？ (はい、見えます。私が強調しました。) それは「自動化されたツーリング」です。 それだけではありません。自動移行ツーリングは頂点であり、唯一明るく輝く例です。 私たちは基本的に、C++ ユーザーの二つの starkly 異なる陣営の間の対立を見ています。 比較的モダンで有能なテクノロジー企業で、自社のコードが資産であることを理解している企業。(これは厳密にはビッグテックではありません。健全なグリーンフィールド C++ スタートアップもこのカテゴリーに入ります。) それ以外のすべて。 人々がまだコードのインデント方法について争っており、若いエンジニアがリンターの設定を許可してくれるよう経営陣に懇願しているような、あらゆる古い企業。 これらのグループのうち一方は、移行をある程度優雅に処理できる能力があり、それはバージョン管理されたソースから C++ スタックを構築できるグループであり、1998 年の古いプリビルドライブラリを使用しているグループではありません。 この、依存関係スタック全体をバージョン管理されたソースから (できれば自動テスト付きで) ビルドできる能力は、おそらく二つのキャンプ間の最も重要な分割線です。 実際には、もちろん、これは勾配です。 ビッグテックのコードベースを恐ろしい泥沼から、半管理可能で、ビルド可能で、リンティングされ、適切にバージョン管理され、少しだけ恐ろしくなくなった泥沼に変えるために、どれだけの汗、涙、請求書、血が流れたか想像できます。 後知恵のバイアスがあれば、これをすべて避けられないことだと考えるのは簡単です。 Google のような企業 (比較的モダンな C++ を使用し、自動化されたツーリングとテスト、最新のインフラストラクチャを持っている) のニーズと、(非常に強力な) 後方互換性への欲求との間には、明確な断絶がありました。 あえて言うなら、単一の、方言のない統一された C++ という概念は、何年も前に死んでいたように思えます。 少なくとも、私たちは二つの主要な C++ のフレーバーを持っています。 ほぼモダンな C++。 バージョン管理されたソースから、何らかの専用でクリーンで統一されたビルドプロセス (生の CMake よりは少し洗練されている) を使用して構築できるすべてのもので、少し目を細めれば機能するように見えます。 何らかの静的アナライザー、フォーマッター、リンター。 コードベースをクリーンでモダンに保つことが価値があるという合意。 おそらく少なくとも C++17 で、unique_ptr、constexpr、ラムダ、optional などがありますが、それは問題ではありません。重要なのはツーリングです。 レガシー C++。 それ以外のすべて。 古い、埃をかぶったサーバーに何年も置かれている、中規模銀行の C++。 ソースが失われ、元の作者が連絡不能になった、完全に古いコンパイル済みコードの塊に依存している C++。 ペットタイプのサーバーにデプロイされており、それをどこか別の場所に起動するだけで、エンジニアがすべての暗黙の依存関係、設定、環境変数を理解するのに1ヶ月かかるような C++。 主にコストセンターとして分類されるコードベース。 使用されているバイナリをソースからビルドするのに数回のボタン操作以上を必要とする、または完全に不可能なコード。 ここで、主な違いは C++ 自体には全くないことに気づくでしょう。 違いはツーリングと、クリーンで明確に定義された方法でソースからビルドできる能力です。 理想的には、前の人がすべてが爆発しないようにするために通常設定していたあのフラグや環境変数を覚えておく必要なしにデプロイできる能力さえも。 Google のコードベースのどのくらいの割合が「モダンな」C++ のイディオムに従っているかは、ツーリングが優れているかどうか、そしてソースからビルドできるかどうかよりも、ほとんど二次的なものです。 多くの人が、ツーリングは責任ではないと言うでしょう