ハクソク

世界を動かす技術を、日本語で。

C++26が完了 - ISO C++規格会議の報告

2026年3月30日原文(herbsutter.com)

概要

  • C++26 の技術的作業が完了し、ISOによる最終承認段階へ移行
  • 反射（Reflection）、 メモリ安全性向上、 契約（Contracts）、 std::execution が主な新機能
  • 業界での迅速な採用 が見込まれる理由と背景
  • C++29 に向けた更なるメモリ安全性強化の議論
  • 標準化作業の進行状況 と今後の展望

C++26の技術的作業完了と最終承認プロセス

  • ISO C++委員会 がロンドン・クロイドンにてC++26の技術作業を完了
  • 国際コメント 411件の対応を終え、最終文書（DIS）をISOへ提出準備
  • Phil Nash（Shaved Yaks）とStandard C++ Foundation がホスト、6日間の高品質な会議運営
  • 参加者は 24カ国・約210名 （現地130名・リモート80名）、新規ゲスト24名
  • 23のアクティブな分科会 が並行して議論、技術セッションも開催

C++26の注目機能：Fab Four Features

  • 反射（Reflection）
    • C++言語史上最大の進化、コンパイル時反射機能の導入
    • 言語自身の構造を記述・生成可能、抽象化表現力の飛躍的向上
  • メモリ安全性の向上
    • 未初期化ローカル変数の読み取りによる未定義動作（UB）を排除
    • 標準ライブラリの境界安全性強化（vector, span, string等でバグ防止）
    • GoogleやAppleで既に大規模導入、バグ修正・セグフォ率30%減少実績
  • 契約（Contracts）
    • 関数宣言に事前条件・事後条件・assert文を言語レベルで導入
    • 技術的懸念が残るも、委員会の大多数が導入を支持
  • std::execution（Sender/Receiver）
    • C++の非同期モデル、並列・並行処理の統一的フレームワーク
    • 安全な構造化並行性、データ競合抑止
    • ドキュメント・周辺ライブラリ不足のため、初期学習コストに注意

C++26の業界導入が早い理由

  • 高いユーザ需要
    • C++11以来の「全員が毎日使う」レベルの大型機能群
    • 反射・安全性強化など、幅広い現場で即時価値を発揮
  • 実装の進捗
    • GCC・ClangともにC++26機能の2/3以上を既に実装
    • reflection・contractsはGCCのtrunkに統合済み

C++29に向けた議論と安全性強化

  • 3年サイクルでC++29リリース予定
  • メモリ安全性の更なる強化 が大きな議題
    • 未定義動作の追加削減
    • SG23（安全性・セキュリティ分科会）でのプロファイル議論
    • Bjarne Stroustrupの型安全プロファイル案、Gabriel Dos Reis提案の一般プロファイル枠組み
    • AppleのOliver HuntによるWebKit大規模安全化事例報告
  • 「安全がデフォルト、ゼロオーバーヘッド原則は維持」
    • 必要に応じてopt-out可能、パフォーマンス重視の現場にも配慮

その他の進捗と機能安全関連

  • 契約チェックの適用拡大計画 の検討
  • 数量・単位ライブラリ（P3045R7） の進捗
    • SG6（数値分科会）、SG18（ライブラリ分科会）で議論
    • 安全性への寄与、現実の事故防止への可能性

今後の展望

  • C++26は新時代の幕開け
    • メモリ安全性・抽象化力・並列性の大幅向上
    • 実装・現場の両面からの速やかな普及が期待
  • C++29以降も「安全かつ効率的」な言語進化
    • 業界・学術界・OSSコミュニティの連携による更なる発展

Hackerたちの意見

一番の疑問は、この標準のモジュールシステムの小さな変更が、実際にもっと広く採用されることにつながるのかどうかだね。

└

いや、モジュールは失敗したアイデアだと思う。今の時点で主流になるとは全然思えないな。

└

C++のWGができる一番いいことは、モジュールとパッケージングに全リリースサイクルを使うことだと思う。新機能があるのはいいけど、C++を本当に殺してるのはCargoなんだよね。新しい世代の開発者が、cargo addで必要なものを簡単に追加できない言語を学ぼうと思うとは思えない。

└

いや、ほとんどの主要なコンパイラがヘッダーユニットをサポートしてないし、C++26の標準ライブラリヘッダーユニットなんてなおさらだよ。採用を促進するのは、CMakeがClangの二段階コンパイルモデルを採用することだと思う。それが実現すれば、冗長な前処理を避けられるから、すぐに全プロジェクトが移行するだろうね。今は並列処理の損失が採用を妨げてる。

└

正直、C++の開発をやめてほしいと思ってる。新しい不要な機能がどんどん追加されて、追いかけるのが大変なんだ。最近のC++コードを読んで、C++を知ってると思ってた自分が恥ずかしい。そんなレベルだよ。それに、C++のビルドシステムはひどい。ヘッダーファイルなんて必要ないはずだ。

これ、すごい！90年代にMSのC++チームで開発者やってたけど、RTTIが言語にとって真のリフレクションシステムに最も近いものだと思ってたんだよね。

ようやくリフレクションが来たね。最後にC++のコードに触ったのが5年前だけど、デストラクティングムーブを導入するのに委員会がどれくらいかかるのか気になるな。

└

うん、同じ気持ちだよ。5年前にRustに切り替える前にあったら助かった機能がたくさんあるね。

契約が受け入れられたことに少しがっかりしてる。すでに複雑さの限界を超えた言語にさらに複雑さを加える感じがするし、この機能には自分で足を引っ張る要素もあるから、正当化されるのか疑問だな。ビャーネの言葉を引用すると、>「約1年前に戻って、標準に入る前に投票できたら、何人かは反対票を投じた。今はもっと難しい問題がある。これは標準提案の一部だ。悪いと思う機能があるからといって、標準に反対票を投じるべきか？私はこれが悪いと思ってる。それはもっと難しい問題だ。人々は『ああ、これでたくさんの良いものが得られる』と思って賛成票を入れるけど、彼らは正しい。私たちは多くの複雑さと悪いものも得ている。この提案は、私の意見では膨れ上がった委員会のデザインで、しかも不完全だ。」

└

C++の契約設計については詳しくないけど、悪い選択がされた可能性はあるね。でも、契約はC++が次の進化のステップに必要なものだと思う。正しい設計のソフトウェアに使われるプログラミング言語（Ada、C++、Rust）は、テストではなく静的に任意のプロパティを示すために、証明アシスタントとの深い統合を可能にする必要がある。そのために契約が/その/重要な部分なんだよね。例えば、Ada Sparkを見てみて。

└

まあ、C++だしね。複雑さの予算はアメリカ政府の債務上限みたいなもんだよ。

└

C++のコントラクトは、すでにC++でやってることを標準化してるだけだよ。それに複雑さはどこにあるの？言語が標準的な相互運用可能な実装を提供してくれるから、自分で実装を書く必要がなくなるんだ。リフレクションのようなC++26の機能が複雑さを加えるという意見もあるけど、コントラクトに関してはその意見には賛成できないな。

Hacker Newsで議論の続きを見る