C++は二つの陣営に分裂している：モダンなツールを持つ企業と、レガシーコードに縛られた企業
The Two Factions of C++
C++の未来をめぐる議論は、標準化委員会の決定（ABI互換性の維持や「バイラル注釈」の拒否）と、安全性を求める政府やRustを採用する大手テック企業の動きによって、ますます激化している。この記事は、C++ユーザーが「モダンなツールチェーンとソースからのビルド能力を持つ企業」と「レガシーコードに依存し、移行が不可能な企業」という二つの陣営に分かれていると指摘。委員会が後者を優先するため、Safe C++のような抜本的改革は採用されず、溝は広がるばかりだと論じる。
「既存コードへの変更を最小限に抑えなければならない。大規模なコードベースを持つ顧客の大半は、安全性のためであっても、コードの1%すら変更しないだろう。」
HNでの議論
78- tonyedgecombe
「既存コードの変更を最小限に抑えなければならない。既存コードへの採用に関しては、数十年の経験が一貫して示しているのは、大規模なコードベースを持つほとんどの顧客は、厳格性ルールを満たすためにコードの1%さえも変更できず、変更しようとしないということだ。たとえ安全性の理由であっても、規制要件で強制されない限りは。」
しかし、主要プレイヤーたちはC++コードをRustに置き換えることをいとわないようだ。
そろそろ後方互換性を緩めてもいい頃かもしれない。特にAIの時代には。
- tialaramex
私の見たところ、これは(2024)という注釈を付けるべきだ(記事を読み終えていないが、当時「ちょうど起こった」ばかりの出来事についてのもののようだ)
また、当時HNはこれについてこう書いていた: https://news.ycombinator.com/item?id=42231489
- vintagedave
記事が言及している、Sean BaxterのSafe C++を事実上排除した投票に、私は深く悲しんだ。それは、解決策を議題に載せること自体を妨げるような動きに感じられた。もしSafe C++がその価値に基づいて議論されていたなら、それはそれで一つのことだが、これは(私には)そこに到達することさえ妨げているように思えた。それが意図だったかどうかは誰にもわからない: 結果が私を失望させたのだ。
私の見解では、主要なコンパイラベンダーの一つがSafe C++を引き受けて、サポートを始める必要がある...そして、コードベースをそこに移行するためのリファクタリングツールも含めて。なぜなら、この記事が言うように、ツールが鍵だからだ。
- abbefaria27
委員会に公平を期すために言うと、C++コンパイラのアップグレードは、変更が小さいものであっても、すでに面倒な作業だ。ラムダのキャプチャの仕組みが変わったためにラムダを更新するのに時間を費やしたいか(これはつい最近実際に起きた破壊的変更だ)、それとも実際に価値のあることをしたいか? 私たちがようやくPython 2.7から3にアップグレードした唯一の理由は、OSベンダーがサポートを打ち切ったからだが、それは実質的に時間の無駄だった。
それはさておき、ABIの破壊がなぜ大ごとなのか理解できない。おそらく良い理由があるのだろうが、ABIはすでに非常に壊れやすく、異なるコンパイラバージョンを混在させることはできないし、同じコンパイラでも異なるフラグを使うと混在できない。`-std=c++29`のようなものを設定してABIを壊すことが、`-fno-rtti`が同じことをするのと比べて、なぜ重要になるのか?
C++委員会は、ライブラリ作者向けの難解な機能を追加するのをやめて、一般ユーザー向けのものに焦点を当てるべきだ。ツールもその一つだし、記事が言うように、あるいはようやくNetworking TSを導入するというのはどうか? これはおそらく、基本的なネットワークサポートすら持たない最後の主流言語だ。
- mgaunard
委員会だ、多くの人が関わっていて、皆それぞれ異なる意見を持っているが、どんな決定にもコンセンサスが必要だ。
なぜ誰もが大きな広範な変更を期待するのか? そして歴史的に、強制された妥協を通じてそういう変更が起こったとしても、一貫して実装されなかったために失敗に終わった。
うまくいく唯一の方法は、小さく互換性のある反復的な変更だ。