- Chromiumプロジェクトは、最新のC++標準機能の使用範囲と禁止項目を明確に定義し、コードの一貫性と安全性を維持している
- C++11〜C++23まで、各標準ごとに許可・禁止・検討中（TBD）の状態が区分され、Abseilライブラリにも同じ基準が適用される
- 禁止されている機能には std::shared_ptr, std::function, std::regex, std::filesystem, std::byte, char8_t, modules などが含まれる
- 許可されている機能には concepts, spaceship演算子, designated initializer, std::to_underlying, std::rangesアルゴリズム などがある
- このガイドは Chromium とその下位プロジェクト全体に適用され、コードの安定性とビルド互換性の確保のための中核的な基準として機能する
ChromiumのModern C++利用ポリシー
- Chromiumは最新のC++標準をすぐには導入せず、ツールチェーンのサポートが十分に確保された後に「初期サポート（initially supported）」状態として指定する
- その後、機能ごとに 許可（allowed）、禁止（banned）、検討中（TBD） に分類される
- 新しい機能の状態変更は cxx@chromium.org メーリングリストを通じて提案できる
- 初期サポートから2年が経過すると、明示的なレビューを経て許可または禁止の一覧へ移される
C++11で禁止されている機能
- 言語機能: inline namespace, long long, ユーザー定義リテラル（user-defined literals）
- ライブラリ機能:
<chrono>, <regex>, <random> エンジン, <exception>, <ratio>, <thread> など
- 例外（exception）は完全に無効化されており、
noexcept のみ許可される
std::bind, std::function, std::shared_ptr, std::weak_ptr の代わりに base::Bind, base::Callback, base::RefCounted を使用する
C++17で禁止されている機能
- **UTF-8文字リテラル（u8）**は禁止。
char8_t との互換性の問題があるため
- ライブラリの禁止項目:
- 数学の特殊関数、並列アルゴリズム（parallel algorithms）、
std::any, std::byte, std::filesystem, std::pmr メモリリソースなど
- 並列アルゴリズムは libc++ が未対応であり、Chromeのスレッドモデルと衝突する懸念があるため禁止
C++20の許可機能と禁止機能
- 許可されている言語機能:
- concepts, consteval, designated initializers, spaceship演算子, [[likely]], range-for初期化構文
- 許可されているライブラリ機能:
<bit>, <compare>, <concepts>, <numbers>, std::erase_if, std::ranges::subrange, std::to_underlying など
- 禁止されている機能:
- char8_t, modules, [[no_unique_address]],
std::bit_cast, <span>, std::bind_front, std::ranges::view_interface
- 検討中（TBD）: coroutine,
<format>, <source_location>, std::u8string
C++23の許可機能と検討中の機能
- 許可されている言語機能:
#elifdef, if consteval, 静的演算子（static operator）
- 許可されているライブラリ機能:
std::byteswap, std::basic_string::contains, std::to_underlying, std::ranges 拡張アルゴリズム
- 検討中の機能:
std::expected, std::mdspan, std::generator, std::stacktrace, std::print, [[assume]], #warning など
Abseilライブラリのポリシー
- 禁止されているAbseilコンポーネント:
absl::any, absl::optional, absl::StatusOr, absl::Span, absl::FunctionRef, absl::Mutex, absl::Time, absl::btree_* など- その多くは Chromium の base名前空間の実装で置き換えられる（
base::span, base::expected, base::Bind など）
- 検討中（TBD）:
absl::linked_hash_set, absl::linked_hash_map
全体的な意味
- Chromiumは標準C++機能を無条件に受け入れるのではなく、ビルドの安定性・セキュリティ・性能・コードの一貫性を基準に選別して適用している
- 禁止されている機能の大半は 重複実装（base::） または ツールチェーン・ABI互換性の問題 によるもの
- このガイドは Chromium エコシステムにおける C++コード品質管理の基準文書であり、オープンソース協業時の必須の参照文書として機能する
3件のコメント
C++は下位互換性のために言語がどんどん肥大化していくのが残念です……
本当にHNの意見にある言葉の通り、C++は巨大な言語です...
Hacker Newsのコメント
特に目立つものはないが、大半は「自分たちの用途に合う社内製ライブラリを使おう」という趣旨の内容だと思う
残りも、ロケール問題を避けるなど妥当なものが多い。標準ライブラリの荒い部分を整えるための選択肢もあって納得できる
chronoがなかったので独自の時間型を作り、STLが安定する前から独自コンテナを使っていたいま新規プロジェクトを始めるなら、こうしたルールの大半は意味がない気がする
char8_tが禁止されている理由は興味深い。UTF-8以外のエンコーディングはほとんどなく、char8_t*はchar*と互換性がないので、キャストの乱立を防ぐためにstd::stringやstd::string_viewを使うよう勧めている古いコードの話を見て、Chromiumが最初に出た頃を思い出した
このコードベースがもう20年前に始まったという事実に改めて驚く
<regex>が禁止されているのは良い判断だ。UTF-8をきちんと扱えず、使いものにならなかった。こんな欠陥ある設計が標準化されたのは驚きだ上位ディレクトリにはもっと興味深い文書がある
Chromium C++スタイルガイド は参考になる
例外(Exception)は禁止されているが、Windowsだけは例外になっている
例外を哲学的に反対しているのではなく、実用的な理由で禁止している。最初からやり直すなら違っていただろうとのことだ
[[no_unique_address]]に関する言及しかなかったので、たぶん冗談を取り逃したのだと思う禁止機能の一覧が多すぎて、C全体の機能より多く見える。圧倒的だ
u8"..."リテラルを禁止したのは良い判断だ。ソース自体をUTF-8で書けば、別に接頭辞は不要だこういうリテラルは問題より先に解決策が出てきた例だ
禁止された機能の代替手段を知りたい。たとえば
<filesystem>はテスト支援が不十分で、セキュリティ脆弱性があるとされている<filesystem>だけが例外だbase/filesを使うモジュール(Modules)は禁止されている。いっそD言語のモジュールシステムをコピーすればよかったのにと思う
禁止リストは、「最新機能より文脈のほうが重要」であることを示している。小さなアプリでは問題なくても、大規模プロジェクトでは危険だ
さまざまなプラットフォーム間の移植性も考慮されている