5月24日、HFT Universityが「The C++ Standard Library Has Been Walking Itself Back for Fifteen Years, and the Receipts Are Public」と題した記事を公開した。
記事の発端は、Sandor Dargoが公開したstd::copyable_functionに関する記事の一覧表に書かれた衝撃的な一行だ。C++11で導入されたstd::functionについて、こう記されている。
std::function: Legacy. Avoid in new code.（遺産。新しいコードでは避けよ）
C++11はわずか15年前の仕様だ。にもかかわらず、その目玉機能の一つがすでに「遺産」扱いされている。これは異常事態ではない。C++標準委員会は過去15年間、驚くほど一貫して自らの機能を否定し続けているのだ。
Rust対C++で58倍の性能差が生まれる理由
最も深刻なのは、C++初心者が最初に学ぶコンテナが他言語の基準で明らかに劣っていることだ。記事の著者らが行ったRust対C++のベンチマークでは、同一ワークロードでRustの標準ライブラリがC++より58倍高速なP99レイテンシを記録した。
この性能差の原因はstd::unordered_mapの設計にある。C++11仕様はバケット安定性とイテレータ安定性を要求しており、これは事実上オープンアドレス法（キャッシュフレンドリーなハッシュテーブル実装）を禁止している。オープンアドレス法は過去15年間で他の言語が標準化した手法だが、C++標準ライブラリはABI互換性の制約により、デフォルトを修正することができない。
Google、Facebook、その他の主要企業が独自のハッシュテーブル実装（absl::flat_hash_map、folly::F14FastMapなど）を使用するのはこのためだ。C++標準ライブラリを信頼して使用するエンジニアだけが、遅いコンテナを使い続けている。
委員会が正式に認めた「失敗作」の数々
最も明確な歴史は、委員会が論文番号付きで正式に非推奨化・削除した機能群だ。
**std::auto_ptr**（C++98）は、コピー時の移動セマンティクスが標準コンテナを破綻させた。C++11で非推奨化、C++17で削除された（N4190）。
動的例外仕様（throw(X, Y)）は18年間標準にあったが、C++11で非推奨、C++17で削除された（P0003R5）。代替はnoexceptである。
最も恥ずかしいのはC++11のガベージコレクション・インターフェースだ。委員会はstd::declare_reachableなどを標準化したが、主要実装は一度も真のガベージコレクタを提供しなかった。この機能はC++23で削除された（P2186R2）。12年間、誰も使わない機能のために標準文書が費やされたのだ。
「皆が避けることを知っている」非公式な後退
正式に非推奨化されていないが、業界のシニアC++エンジニアが皆、新人に初日から避けるよう教える機能もある。
**std::regex**（C++11）について、委員会自身の論文P1844R1は「std::regexのパフォーマンスは他の利用可能な解決策と比較して非常に劣る」と記録している。
**std::list**については、Bjarne Stroustrupが2012年のGoingNative基調講演で、「大きなコンテナの中央への挿入」というstd::listの教科書的用途でさえ、std::vectorが勝つことを実証した。線形スキャンが支配的で、ポインタチェースがキャッシュミスを引き起こすためだ。
**std::async**（C++11）も同様だ。返されるfutureのデストラクタが非同期操作の完了までブロックし、N3679にはデッドロックの罠が文書化されている。代替は15年後のC++26でようやく導入されるsender/receiver（P2300）である。
Technical Specificationの完全な書き直し
さらに深刻なのは、Technical Specification（技術仕様書）として一度標準化されながら、完全に再設計された機能群だ。Concepts TS、Modules TS、Coroutines TSはすべてC++20で再設計された。Reflection TSは完全に拒否され、C++26ではP2996という全く異なる設計に置き換えられる予定だ。
C++の現在地と今後への影響
C++は現在、Stack Overflow Developer Survey 2024で「最も恐れられている言語」の上位にランクインしている。一方で、システムプログラミング分野では依然として重要な地位を占めており、ISO/IEC 14882として国際標準化されている。
この15年間の後退パターンは、C++標準化プロセスの構造的問題を浮き彫りにしている。ABI互換性の制約により、問題のある機能を根本的に修正できず、代わりに新しい名前の新しい機能を追加し続けている。その結果、新しいC++機能が「革命的」だと宣伝されるたびに、それが次の論文で非推奨化されるまでの期間を推定できるような状況が生まれている。
詳細はThe C++ Standard Library Has Been Walking Itself Back for Fifteen Years, and the Receipts Are Publicを参照していただきたい。
