- C++26が正式に技術完了。リフレクション、メモリ安全性強化、Contracts、std::execution など4つの中核機能が含まれる
- コンパイル時リフレクション は、テンプレート導入以来のC++史上最も強力な抽象化エンジンであり、言語が自らを記述しコードを生成できるようになる
- 既存のC++コードをC++26で 再コンパイルするだけで、未初期化のローカル変数に関する未定義動作（UB）が除去され、強化された標準ライブラリによって bounds 安全性が保証される
- Googleでの展開結果として、1,000件以上のバグ修正 と本番環境での segfault 30% 減少が実測された
- GCCがすでにリフレクションとContracts機能を trunk にマージ完了するなど、コンパイラ実装による迅速な採用 が見込まれる
C++26完成: C++11以降で最も重要なリリース
- 英国ロンドン・クロイドンで開かれた ISO C++ 委員会会議で、C++26の技術作業が 最終完了 した
- 約210名が参加（対面130名、Zoomリモート80名）、24か国の正式代表が参加
- 夏に受理された 411件の国際コメント（CD段階） の処理に会議の大半が割かれた
- 新機能の追加や削除は行わず、完成度の調整（fit-and-finish）に集中
- 今回の会議で仕上げられたC++26は、国際承認投票（DIS） に向けた最終文書作成段階に入った
C++26の4大中核機能
(1) リフレクション（Reflection）
- テンプレート発明以来の C++開発史上最大のアップグレード であり、言語が自分自身を記述しコードを生成できる機能
- 2025年6月、C++委員会は コンパイル時リフレクション をC++26ドラフトに含め、言語史の転換点を刻んだ
- 「効率的な抽象化を表現するための最も強力な新しいエンジンであり、このロケットが何をできるのかを発見するには今後10年が必要だ」と紹介されている
(2) メモリ安全性の強化
- 再コンパイルだけで、既存のC++コードにおける未初期化ローカル変数読み取りのUB（未定義動作）のカテゴリ全体がC++26で除去される
- 強化された標準ライブラリ（Hardened Standard Library） が標準化され、vector、span、string、string_view など主要型の bounds 安全性を保証
- 性能オーバーヘッドは平均 0.3%（1%未満）と実測された
- AppleプラットフォームとGoogleサービスで、すでに数億行のコードへ展開済み
- Google展開結果の数値:
- 1,000件以上のバグ修正 を完了
- 年間 1,000〜2,000件のバグ予防 効果を見込む
- 本番全体で segfault 発生率 30% 減少
- GoogleのC++コード全体のうち、全面 opt-out のサービスは 5件 のみ、安全でないアクセスAPIの使用箇所も 7か所 にすぎない
(3) Contracts: pre, post, contract_assert
- C++26で 言語レベルのContracts機能 を導入 — 関数宣言の事前条件（precondition）、事後条件（postcondition）、および assertion 文をサポート
- Cの assert マクロよりはるかに強力な機能と評価されている
- Contracts採用時の投票結果:
- 2025年2月（working draft マージ）: 賛成 100、反対 14、棄権 12
- 2026年3月（C++26最終確定）: 賛成 114、反対 12、棄権 3
- 一部の委員会専門家による技術的懸念は続いたが、3回の会議と多数の電話会議で十分に議論された
- 2025年11月以前の会議で、フィードバックを反映してContracts仕様の バグ2件を修正 済み
(4) std::execution（Sender/Receiver）
- C++の 非同期モデル であり、並行性と並列性を表現・制御する統合フレームワーク
- structured concurrency（ライフサイクルが厳密に入れ子になる並行性）を容易に記述でき、data race を構造的に防ぐ安全性の特性を持つ
- 注意: 現時点では文書化が不足しており、「fingers-and-toes」ライブラリも不十分なため、採用の難易度は他のC++機能より高い
- すでによく知る専門家の支援や、既存の非同期コードと連携するためのアダプタライブラリ作成が必要になる可能性がある
C++26の迅速な採用が見込まれる理由
- C++11以降で最も需要の高い機能セット であり、大多数のC++開発者が日常的に活用するリフレクションと安全性強化が含まれる
- C++17、C++20、C++23の並列STL、concepts、コルーチン、モジュールなどは、すべてのC++開発者にC++11ほど広範な影響を与えられなかったとの評価
- GCCとClangはC++26開発全体を通じて、機能の3分の2を事前実装 済みの状態を維持してきた
- GCCはすでに リフレクションとContractsを trunk にマージ 済みで、リリース待ちの状態
C++29の作業開始: メモリ安全性のさらなる深化
- 今回の会議では C++29の日程も採択 され、3年周期のリリースサイクルを維持
- C++29の主要な焦点は、型・メモリ安全性の追加強化 と確定
- 未定義動作（UB）のさらなる削減提案を検討中
- SG23（安全・セキュリティサブグループ）では、Bjarne StroustrupのP3984型安全性プロファイル と Gabriel Dos Reis の汎用プロファイルフレームワークを基盤に作業が進行中
- AppleのOliver Huntが P4158R0「メモリ安全性のためのC++サブセット化と制約」 を発表
- WebKitの 400万行以上のコード に subset-of-superset アプローチを適用
- 「多くの脆弱性クラスを遮断し、現在のポリシーなら過去の大半のエクスプロイトを防げただろう」と報告された
- メモリ安全性のテーマは、委員会過半数が参加した水曜夜のセッションと、約90名が参加した金曜午後のEWG専用セッションで深く議論された
- 量・単位ライブラリ（P3045R7 "Quantities and units library"） が SG6・SG18 から LEWG（メインライブラリ進化サブグループ）へ進展した
今後の日程
- 次の2回の会議は チェコ・ブルノ（6月） および ブラジル・リオデジャネイロ州ブジオス（11月） で開催予定
- 両会議で C++29 working draft への機能追加作業 が開始される
- 今から次回会議までの間にも、多数のサブグループテレコン（ビデオ会議）がすでに予定に組み込まれている
7件のコメント
zzz
Hacker Newsの反応
C++に Contracts 機能が標準採用されたのは残念
すでに複雑さが限界に達している言語に、さらに別の複雑さを加える感じがする
Bjarne Stroustrupもこの機能を 「未完成で委員会的に水増しされた設計」 と表現していた
機能自体の危険要素（footgun）も多く、正当性に欠けると思う
でも誰も関心を示さなかった
関連資料は ここ
AdaやRustのように 形式検証（proof assistant） と統合され、テストの代わりに静的検証を可能にする中核要素だからだ
Ada Sparkが参考になる
cppreferenceの文書 の最初の例は、むしろ状態を変更する例外的なケースになっている
構文も直感的ではない
たとえば
asserts_pre(num >= 0)のような形のほうがpre(num >= 0)よりはるかに明確だったはずだだが簡潔さが優先されたようだ
複雑さを増すというより、各自の実装を統合して相互運用性を高める方向だ
むしろReflectionのような機能のほうが複雑さを増していると思う
C#、Java開発者として気になることがある
最近C++でどんな種類の アプリケーション を作っているのか知りたい
実際にどんな問題を解いているのか聞く機会があまりない
初期化されていない変数の 「erroneous behavior」再定義 が興味深い
標準文書 によるとランタイムコストが発生し、
[[indeterminate]]属性を使えば再びundefined behaviorに戻せるという本当に初期化したくないなら
int x = void;のように明示的に書かなければならないうっかりそう書いてしまうことはほとんどない
[[indeterminate]]がなぜ再び UB（Undefined Behavior） に戻るのか疑問だ依然として手動初期化を好むプロジェクトもあるはずだ
[[indeterminate]]を目にする人のことを思うとぞっとする結局意味を調べるのに時間を無駄にするか、そのうち単に無視するようになるだろう
Rustでジェネリクスやトレイトが多すぎてコードが読みにくかった経験を思い出す
90年代にMSのC++チームで働いていた
当時は RTTI がC++で持ち得る反射（reflection）システムの限界だと思っていた
今の進展には驚かされる
Croydonで会議を開き、署名するまで誰も帰らせなかったのは、かなり 巧妙な戦略 だった
二度とあそこで働きたくない
GCCとClangのC++26実装状況が気になっていた
GCCはすでに reflectionとcontracts をtrunkにマージしているが、Clangはどの程度進んでいるのだろうか
GCCのページ では「yes」と表示されている
すでにCompiler Explorerでも利用可能で、simdjson へのreflection追加にも使われている
今回の標準における モジュールシステムの変更 が、実際により広く使われるきっかけになるのか疑問だ
Rustの Cargo がC++を圧倒している理由はまさにそこにある
cargo add1行で依存関係を追加できないことが、新しい世代を遠ざけているClangの2段階コンパイルモデルをCMakeが採用すればビルド速度は大きく改善し、
そのとき初めてモジュールが本格的に採用されるだろう
主流になる可能性はほとんどない
新機能が多すぎて追いかけるのが大変だ
ビルドシステムもひどいし、ヘッダーファイル はもう消えるべきだ
話題とは少し違うが、「London Croydon」という表現は奇妙に聞こえる
普通は「Croydon, London」と言わないだろうか？
旅行計画を立てるときは、大きい地域から小さい地域の順で読むほうが自然だ
「London, Croydon」と書いたのは、おそらく「ロンドンで会議した」という印象を与えるためだろう
「Croydon, London」だと「ロンドン郊外のCroydonでやった」という感じで、少しかっこよくない — 冗談まじりの解釈 だ
「言語の寿命が尽きる直前に出てきた」というような 皮肉な反応 もある
C++29が 品質改善と既存機能の磨き込み だけに集中するなら、コミュニティもそれほど不満はない気がする
C++標準が出てから産業で採用されるまで、5年以上は経たないとようやく採用され始めるような雰囲気……。魅力的だけど、絵に描いた餅みたいなやつ（泣）
メモリ安全性のために機能を追加するのではなく、ダングリングポインタや可変参照だけでも禁止すればメモリ安全性は高まるのに、むしろ機能追加でコードの複雑さだけを増やしていますね
苦労してRustに移行したのに、C++26の標準案に待ち望んでいた機能のかなり多くが反映されたのは心強いですね。でも、再びC++に戻ることはないと思います……（笑）
パッケージング関連は CMake の方からも出ています.. https://www.kitware.com/common-package-specification-is-out-the-gate/
contract、本当に待ち望んでいた機能だけど、ついに来た