C++の二つの派閥

 (herecomesthemoon.net)
10 ポイント 投稿者 GN⁺ 2024-11-26 | 3件のコメント | WhatsAppで共有
  • 方言（Dialect）のない単一のC++という夢は、すでにかなり前に消え去ったように見える
  • Redditやあのオレンジ色のウェブサイト（HN）、そして公式のC++標準委員会会合で、C++の未来をめぐる多くの議論がある

C++の現状

  • C++進化ワーキンググループ（EWG）は、P3466 R0を採択することで合意した。
    • ABI（アプリケーション・バイナリ・インターフェース）を壊さず、Cおよび過去のC++とのリンク互換性を維持する。
    • 「バイラル注釈」を使用しない。
    • ABIの破壊とゼロオーバーヘッド原則という相反する目標に固執する。
  • 米国政府はC++の使用中止を勧告している。
    • CISA、NSA、ホワイトハウスなど複数の機関が、メモリ安全でない言語の使用に関する警告を出している。
  • 大手テック企業がRustを採用している。
    • Microsoft、Google、AWSなどがRustを使用している。
    • GoogleはC++/Rust相互運用ツールまで開発している
  • C++コミュニティ内の内部対立
    • Herb SutterがMicrosoftを離れ、MSVCのC++23機能実装が遅れているという話がある。
    • GoogleはC++開発プロセスへの参加を減らし、独自のC++後継言語を開発中である。
    • 従来のC++標準委員会プロセスに対する信頼不足
    • モジュール機能は依然として未完成の状態
    • 「安全プロファイル（‘Safety Profiles’）」は奇妙な状態にある

C++の二つの文化

  • モダンで自動化されたツールを使うグループ
    • Googleのような大手テック企業が主な例
    • 最新のC++標準（C++17以降）を使用し、自動化されたビルドおよびテストツールの支援がある
    • コード品質の維持に投資し、継続的にコードベースをモダナイズしている
  • レガシーC++グループ
    • 古い環境やツールで運用されるコードベース
    • ソースコードなしで運用されていたり、ビルドシステムが旧式だったりする
    • 保守コストが高く、モダナイズの障壁が大きい
  • 主な違いはツールとプロセス
    • モダンC++グループは、統合ビルドシステムや静的解析器、フォーマッタ、リンタなどのツールに依存している
    • レガシーグループは、こうしたツールやプロセスの不在により運用効率が低い

結果と影響

  • 安全プロファイル
    • 既存のレガシーコードを変更せずに安全性を強化しようとする目的
    • モダンC++の要求よりも既存コード維持に重点を置いている
  • モジュール
    • ヘッダーファイルをモジュールとして簡単に取り込めるよう設計されている
    • レガシーコードとの互換性を考慮して設計されている
  • C++コミュニティの分裂
    • モダン派とレガシー派の要求の不一致により、コミュニティ内の対立が深まっている
    • C++標準委員会の保守的なアプローチは、こうした対立を和らげようとする試みに見える

代替的な視点

  • Safe C++のような代替的なアイデアは、コミュニティ内で歓迎されていない
  • 標準委員会の一部メンバーが個人的な美的基準に固執し、変化に抵抗している場合があるという批判がある

関連記事

3件のコメント

 
aer0700 2024-11-27

Rust は GUI 開発のエコシステムがまだ整っていないので、採用できずにいるんですが、
Rust で使えるまともな GUI フレームワークが出てきてほしいですね……
 
ndrgrd 2024-11-26

RustがC++を置き換えられるかどうかはよく分かりませんが、
新規のC++プロジェクトがほとんど見当たらないのは事実ですよね...
C++委員会は、変容よりも本来の価値を重視する方向が正しいと判断したようですね。
 
GN⁺ 2024-11-26
Hacker Newsの意見

  • GoogleのC++コードはしばしば最新バージョンで動作せず、開発者がそれを修正する意思を持たないことも多い。これはGoogleのコードが古いものとモダンなものの中間地点にとどまっているためだとされる

    • GoogleのC++コードは、状態機械と手動の弱参照ポインタによりメモリ破損を引き起こす可能性がある
    • GoogleがC++エコシステムから離れることを前向きに見ている
    • Rustエコシステムに対するGoogleの関心は好ましいものにはならないだろうと考えている

  • C++標準の策定者たちに対して、現在のC++の方向性を支持し、C++の将来についてオンラインで出てくる雑音は無視するよう助言している

    • 静的ライフタイム検査を望んでRustを使う人には、Rustを使うよう勧めている
    • 政府請負業者ならRustを使うよう提案している
    • 既存のC++開発プロセスはうまく機能していると主張している

  • C++を使い続ける唯一の集団は、リファクタリングするには大きすぎるレガシーコードベースを抱えた集団だけになるだろうと主張している

    • WG21への信頼を失った別の集団は、新しい言語へ移行している
    • Herb Sutterが、C++にライフタイム注釈を追加することは他言語への「出口ランプ」を作ることになると述べたことに触れている

  • Rustのエディションシステムは非常によく機能していると評価している

    • C++にもこのようなシステムが導入されれば、モジュール境界に制約はあるかもしれないが、両陣営を満足させられる方法になり得ると提案している

  • Herb SutterがMicrosoftを去るという知らせは、Microsoftにとって良くない影響を及ぼすのではないかと懸念している

    • HerbはC++標準の採用を主導し、より良い未来像のために努力してきたと評価している
    • Microsoft提案のstd::spanが境界検査を除いて採用されたことに触れ、Herbの努力が必要だったと主張している

  • 自動化テストが二つの陣営を分ける主要な要素だと強調している

    • レガシーC++アプリで自動化テストがなければ、コード変更がアプリを壊すリスクがあると説明している
    • C++の特性上、無害に見えるコード変更でも問題を引き起こし得ると警告している

  • C++の魅力を下げた主な要因はモジュールの不在だと主張している

    • モジュールがあればC++コミュニティが形成され得たはずだと評価している

  • Herb Sutterは妥協を導くのが得意だった一方で、Googleは自分たちの議題を押し通していたと比較している

  • 大規模コードベースを持つ顧客は、厳格なルールを満たすためにコードの1%ですら変更したがらないと述べている

    • 多くの企業が新しい標準へアップグレードするために時間を投資していると主張している

  • PythonやJavascript/Node/Typescriptにも複数の派閥が存在すると説明している

    • Rustはこうした派閥を避けようとしたが、その分学習曲線が高くなったと評価している
    • Goは派閥を防いで広く採用されることを目指したが、ジェネリクスを導入せざるを得なかったと述べている