Les fonctionnalités C++ interdites dans Chromium

 (chromium.googlesource.com)
15 points par GN⁺ 2026-01-26 | 3 commentaires | Partager sur WhatsApp
  • Le projet Chromium définit clairement le périmètre d’utilisation et les éléments interdits des fonctionnalités des standards C++ récents afin de préserver la cohérence du code et la sécurité
  • De C++11 à C++23, chaque standard distingue les états autorisé, interdit et à examiner (TBD), et la bibliothèque Abseil est soumise aux mêmes critères
  • Parmi les fonctionnalités interdites figurent std::shared_ptr, std::function, std::regex, std::filesystem, std::byte, char8_t, modules, etc.
  • Parmi les fonctionnalités autorisées figurent concepts, l’opérateur spaceship, designated initializer, std::to_underlying, les algorithmes std::ranges, etc.
  • Ce guide s’applique à Chromium et à l’ensemble de ses sous-projets, et sert de référence clé pour garantir la stabilité du code et la compatibilité de build

Politique d’utilisation du C++ moderne dans Chromium

  • Chromium n’adopte pas immédiatement les nouveaux standards C++ et les classe en état « initially supported » uniquement une fois que le support de la toolchain est suffisamment assuré
    • Les fonctionnalités sont ensuite classées selon les statuts autorisé (allowed), interdit (banned) et à examiner (TBD)
  • Les propositions de changement de statut pour une nouvelle fonctionnalité peuvent être soumises via la mailing list cxx@chromium.org
  • Deux ans après le support initial, chaque fonctionnalité est déplacée vers la liste des éléments autorisés ou interdits après examen explicite

Fonctionnalités interdites de C++11

  • Fonctionnalités du langage : inline namespace, long long, user-defined literals
  • Fonctionnalités de bibliothèque : , , engines,, , , etc.
    • Les exceptions sont entièrement désactivées, et seul noexcept est autorisé
    • À la place de std::bind, std::function, std::shared_ptr, std::weak_ptr, Chromium utilise base::Bind, base::Callback, base::RefCounted

Fonctionnalités interdites de C++17

  • Les littéraux de caractères UTF-8 (u8) sont interdits en raison de problèmes de compatibilité avec char8_t
  • Éléments de bibliothèque interdits :
    • fonctions mathématiques spéciales, algorithmes parallèles, std::any, std::byte, std::filesystem, ressources mémoire std::pmr, etc.
    • Les algorithmes parallèles sont interdits en raison de l’absence de prise en charge dans libc++ et de craintes de conflit avec le modèle de threading de Chrome

Fonctionnalités autorisées et interdites de C++20

  • Fonctionnalités du langage autorisées :
    • concepts, consteval, designated initializers, l’opérateur spaceship, [[likely]], la syntaxe d’initialisation de range-for
  • Fonctionnalités de bibliothèque autorisées :
    • , , , , std::erase_if, std::ranges::subrange, std::to_underlying, etc.
  • Fonctionnalités interdites :
    • char8_t, modules, [[no_unique_address]], std::bit_cast, ``, std::bind_front, std::ranges::view_interface
  • À examiner (TBD) : coroutine, , , std::u8string

Fonctionnalités autorisées et à examiner de C++23

  • Fonctionnalités du langage autorisées : #elifdef, if consteval, static operator
  • Fonctionnalités de bibliothèque autorisées : std::byteswap, std::basic_string::contains, std::to_underlying, extensions des algorithmes std::ranges
  • Fonctionnalités à examiner : std::expected, std::mdspan, std::generator, std::stacktrace, std::print, [[assume]], #warning, etc.

Politique pour la bibliothèque Abseil

  • Composants Abseil interdits :
    • absl::any, absl::optional, absl::StatusOr, absl::Span, absl::FunctionRef, absl::Mutex, absl::Time, absl::btree_*, etc.
    • La plupart sont remplacés par les implémentations du namespace base de Chromium (base::span, base::expected, base::Bind, etc.)
  • À examiner (TBD) : absl::linked_hash_set, absl::linked_hash_map

Sens général

  • Chromium n’accepte pas automatiquement les fonctionnalités du C++ standard et les applique de façon sélective selon des critères de stabilité de build, de sécurité, de performance et de cohérence du code
  • La plupart des fonctionnalités interdites le sont à cause de doublons d’implémentation (base::) ou de problèmes de toolchain et de compatibilité ABI
  • Ce guide sert de référentiel de gestion de la qualité du code C++ dans l’écosystème Chromium et constitue un document de référence indispensable pour la collaboration open source

À lire aussi

3 commentaires

 
karikera 2026-01-27

C’est dommage que le C++ continue de s’alourdir pour préserver la rétrocompatibilité...
 
tsboard 2026-01-26

C’est vraiment un langage immense, comme le disent les avis sur HN, ce C++ ...
 
GN⁺ 2026-01-26
Avis Hacker News

  • Rien de particulièrement frappant, mais l’essentiel revient à dire : « utilisons des bibliothèques internes adaptées à nos usages ».
    Le reste paraît assez raisonnable, comme éviter les problèmes de locale. Il y a aussi des options pour lisser les aspérités de la bibliothèque standard, donc cela se comprend.

    • On voit souvent ce genre de choses dans des entreprises avec une vieille base de code. À l’époque, il n’y avait pas chrono, donc ils ont créé leur propre type de temps, et ils utilisaient déjà leurs propres conteneurs avant la stabilisation de la STL.
      Si on lançait un nouveau projet aujourd’hui, la plupart de ces règles n’auraient probablement plus de sens.
    • La raison de l’interdiction de char8_t est intéressante. Il n’existe quasiment plus d’encodages autres que l’UTF-8, et comme char8_t* n’est pas compatible avec char*, ils recommandent d’utiliser std::string ou std::string_view pour éviter une prolifération de castings.
    • En tant que personne ayant géré cette page pendant plus de 10 ans, je trouve surprenant que ce document soit apparu le même jour sur r/c++ et sur HN. Il n’a rien de particulièrement nouveau, donc je me demande pourquoi il est soudain devenu un sujet de discussion.
    • Certains choix ne relèvent pas simplement de l’inertie : l’implémentation de Google a, dans certains cas, une conception objectivement plus rigoureuse que la norme. Les types standard auraient pu être mieux conçus.
    • Il existe cette idée que Google a une version maison de presque toutes les technologies. Le problème, c’est que certains copient cela aveuglément et perdent le contexte. L’exemple typique, c’est une organisation de 20 développeurs avec 50 services qui décide d’adopter Kubernetes.

  • En lisant les commentaires sur les vieilles bases de code, je me suis souvenu du moment où Chromium est sorti pour la première fois.
    C’est toujours frappant de réaliser que cette base de code a commencé il y a déjà 20 ans.

  • Interdire <regex> était une bonne décision. On ne pouvait pas vraiment l’utiliser, car il ne gérait pas correctement l’UTF-8. C’est étonnant qu’une conception aussi défaillante ait été standardisée.

    • Aujourd’hui, la plupart des bibliothèques de regex prennent en charge un mode Unicode. Les regex sont une technologie plus ancienne que l’UTF-8 lui-même.

  • Il y a des documents plus intéressants dans le répertoire parent.
    Le guide de style C++ de Chromium mérite le détour.

  • Les exceptions sont interdites, mais il y a une exception pour Windows.

    • Le code Google est historiquement basé sur le style C, donc il n’est pas sûr vis-à-vis des exceptions. Si l’on repartait de zéro, il vaudrait mieux utiliser les exceptions, mais c’est difficile à cause de la compatibilité avec le code existant.
      Ce n’est donc pas un rejet philosophique des exceptions, mais une interdiction pour des raisons pratiques. Ils disent eux-mêmes qu’ils feraient autrement s’ils recommençaient depuis le début.
    • Ce document n’est pas le Google Style Guide, mais le document Chromium Modern C++ Features. Il ne traite ni des exceptions ni des aspects spécifiques aux plateformes.
    • J’ai fait un grep sur “exception” et “Windows”, et je n’ai trouvé qu’une mention liée à [[no_unique_address]], donc j’imagine que j’ai raté la blague.

  • La liste des fonctionnalités interdites est si longue qu’elle semble plus grande que l’ensemble des fonctionnalités du C. C’est écrasant.

    • Le C++ est vraiment un langage énorme.

  • Interdire les littéraux u8"..." est un bon choix. Si le code source est déjà en UTF-8, il n’y a pas besoin de préfixe supplémentaire.
    C’est le genre de littéral où la solution est arrivée avant le problème.

  • J’aimerais trouver les alternatives aux fonctionnalités interdites. Par exemple, il est dit que <filesystem> manque de support pour les tests et présente des failles de sécurité.

    • Pour la plupart des éléments interdits, une bibliothèque de remplacement est indiquée juste à côté. <filesystem> fait exception.
    • Il y a probablement des informations à ce sujet dans la documentation développeur de Chromium.
    • En pratique, ils utilisent généralement base/files.

  • Les modules sont interdits. J’aurais préféré qu’ils copient simplement le système de modules du langage D.

    • La raison est le manque de support des compilateurs.

  • Cette liste d’interdictions montre que, plus que les fonctionnalités récentes, c’est le contexte qui compte. Dans une petite application, cela passe, mais dans un projet à grande échelle, cela devient risqué.

    • L’idée centrale des directives de Google est de permettre à des gens qui ne sont pas des experts du langage de contribuer sans danger. L’objectif est donc moins la taille du projet que la cohérence organisationnelle.
      La portabilité entre différentes plateformes entre aussi en ligne de compte.
    • Il arrive aussi qu’ils conservent des implémentations maison pour des raisons historiques ou de compatibilité. Certaines existaient avant même la standardisation, donc elles sont difficiles à remplacer.
    • Moi aussi, je pense qu’au lieu de mélanger partout de nouvelles fonctionnalités, il vaut mieux préserver la cohérence avec les règles existantes, car cela allège la charge pour les lecteurs.