Funciones de C++ prohibidas en Chromium

 (chromium.googlesource.com)
15 puntos por GN⁺ 2026-01-26 | 3 comentarios | Compartir por WhatsApp
  • El proyecto Chromium define con claridad el alcance de uso y los elementos prohibidos de las funciones estándar modernas de C++ para mantener la consistencia y la seguridad del código
  • Desde C++11 hasta C++23, cada estándar se clasifica por estado: permitido, prohibido o en revisión (TBD), y la biblioteca Abseil se rige por los mismos criterios
  • Entre las funciones prohibidas están std::shared_ptr, std::function, std::regex, std::filesystem, std::byte, char8_t, modules
  • Entre las funciones permitidas están concepts, el operador spaceship, designated initializer, std::to_underlying y los algoritmos de std::ranges
  • Esta guía se aplica a Chromium y a todos sus subproyectos, y funciona como un criterio central para asegurar la estabilidad del código y la compatibilidad de compilación

Política de uso de Modern C++ en Chromium

  • Chromium no adopta de inmediato los estándares más recientes de C++, sino que los marca como soporte inicial (initially supported) solo después de contar con suficiente soporte del toolchain
    • Después, cada función se clasifica como permitida (allowed), prohibida (banned) o en revisión (TBD)
  • Los cambios de estado de nuevas funciones pueden proponerse a través de la lista de correo cxx@chromium.org
  • Dos años después del soporte inicial, pasan a la lista de permitidas o prohibidas tras una revisión explícita

Funciones prohibidas de C++11

  • Funciones del lenguaje: inline namespace, long long, literales definidos por el usuario (user-defined literals)
  • Funciones de biblioteca: <chrono>, <regex>, motores de <random>, <exception>, <ratio>, <thread> y más
    • Las excepciones (exception) están completamente desactivadas y solo se permite noexcept
    • En lugar de std::bind, std::function, std::shared_ptr y std::weak_ptr, se usan base::Bind, base::Callback y base::RefCounted

Funciones prohibidas de C++17

  • Los literales de caracteres UTF-8 (u8) están prohibidos por problemas de compatibilidad con char8_t
  • Elementos de biblioteca prohibidos:
    • funciones matemáticas especiales, algoritmos paralelos (parallel algorithms), std::any, std::byte, std::filesystem, recursos de memoria std::pmr y más
    • Los algoritmos paralelos están prohibidos por la falta de soporte en libc++ y por posibles conflictos con el modelo de hilos de Chrome

Funciones permitidas y prohibidas de C++20

  • Funciones del lenguaje permitidas:
    • concepts, consteval, designated initializers, operador spaceship, [[likely]] y sintaxis de inicialización en range-for
  • Funciones de biblioteca permitidas:
    • <bit>, <compare>, <concepts>, <numbers>, std::erase_if, std::ranges::subrange, std::to_underlying y más
  • Funciones prohibidas:
    • char8_t, modules, [[no_unique_address]], std::bit_cast, <span>, std::bind_front, std::ranges::view_interface
  • En revisión (TBD): coroutine, <format>, <source_location>, std::u8string

Funciones permitidas y en revisión de C++23

  • Funciones del lenguaje permitidas: #elifdef, if consteval, operador estático (static operator)
  • Funciones de biblioteca permitidas: std::byteswap, std::basic_string::contains, std::to_underlying, algoritmos extendidos de std::ranges
  • Funciones en revisión: std::expected, std::mdspan, std::generator, std::stacktrace, std::print, [[assume]], #warning y más

Política de la biblioteca Abseil

  • Componentes de Abseil prohibidos:
    • absl::any, absl::optional, absl::StatusOr, absl::Span, absl::FunctionRef, absl::Mutex, absl::Time, absl::btree_* y más
    • La mayoría se reemplaza por implementaciones del namespace base de Chromium (base::span, base::expected, base::Bind, etc.)
  • En revisión (TBD): absl::linked_hash_set, absl::linked_hash_map

Significado general

  • Chromium no acepta automáticamente las funciones estándar de C++, sino que las adopta selectivamente según criterios de estabilidad de compilación, seguridad, rendimiento y consistencia del código
  • La mayoría de las funciones prohibidas se deben a implementaciones duplicadas (base::) o a problemas de compatibilidad del toolchain y del ABI
  • Esta guía funciona como un documento de referencia para el control de calidad del código C++ dentro del ecosistema Chromium y es indispensable al colaborar en proyectos de código abierto

Lecturas relacionadas

3 comentarios

 
karikera 2026-01-27

Es una lástima que C++ siga volviéndose cada vez más grande por mantener la compatibilidad hacia atrás..
 
tsboard 2026-01-26

De verdad es un lenguaje enorme, C++... como decía una opinión en HN.
 
GN⁺ 2026-01-26
Comentarios de Hacker News

  • No hay nada particularmente llamativo, pero la mayoría va por la línea de “usemos bibliotecas internas hechas a medida para nuestro caso de uso”
    Lo demás también parece razonable, como evitar problemas de locale. Además hay opciones para pulir asperezas de la biblioteca estándar, así que se entiende

    • Esto se ve seguido en empresas con bases de código antiguas. Antes no existía chrono, así que crearon su propio tipo de tiempo, y usaban contenedores propios desde antes de que STL se estabilizara
      Si hoy se empezara un proyecto nuevo, probablemente la mayoría de estas reglas ya no tendría mucho sentido
    • Es interesante la razón por la que char8_t está prohibido. Casi no hay codificaciones que no sean UTF-8, y como char8_t* no es compatible con char*, recomiendan usar std::string o std::string_view para evitar una proliferación de casts
    • Como alguien que administró esta página por más de 10 años, me sorprende que este documento haya aparecido el mismo día en r/c++ y en HN. No tiene nada especialmente nuevo, así que me intriga por qué se volvió tema de conversación
    • En algunos puntos no es solo por inercia, sino porque la implementación de Google tiene un diseño estrictamente mejor que el estándar. Los tipos estándar podrían haber estado mejor diseñados
    • Existe la percepción de que dentro de Google hay una versión propia de casi toda tecnología. El problema es que algunos copian eso a ciegas y pierden el contexto. Un ejemplo típico es adoptar Kubernetes en una organización con 20 desarrolladores y 50 servicios

  • Hablando de código antiguo, me hizo recordar cuando Chromium salió por primera vez
    Sigue sorprendiendo pensar que esta base de código empezó hace ya 20 años

  • Fue una buena decisión prohibir <regex>. No podía manejar UTF-8 correctamente, así que no servía. Sorprende que un diseño defectuoso así haya sido estandarizado

    • Hoy la mayoría de las bibliotecas de regex soportan modo Unicode. Las regex como tecnología son anteriores a UTF-8

  • En el directorio superior hay documentos más interesantes
    Vale la pena revisar la guía de estilo C++ de Chromium

  • Las excepciones están prohibidas, pero Windows es la excepción

    • El código de Google originalmente está muy basado en estilo C, así que no es seguro frente a excepciones. Si se empezara desde cero, sería mejor usarlas, pero por compatibilidad con el código existente es difícil
      No es que las hayan prohibido por razones filosóficas, sino por motivos prácticos. Dicen que si comenzaran de nuevo desde cero, lo harían distinto
    • Este documento no es la Google Style Guide, sino el documento de Chromium Modern C++ Features. No trata excepciones ni contenido específico por plataforma
    • Busqué con grep “exception” y “Windows” y solo aparece una mención relacionada con [[no_unique_address]], así que probablemente no entendiste el chiste

  • La lista de funciones prohibidas es tan larga que parece más grande que todas las funciones de C. Abruma

    • C++ realmente es un lenguaje enorme

  • Prohibir el literal u8"..." fue una buena decisión. Si el propio código fuente ya está en UTF-8, no hace falta un prefijo aparte
    Este tipo de literal es un caso de solución antes que problema

  • Quisiera encontrar las alternativas a las funciones prohibidas. Por ejemplo, dicen que <filesystem> tiene poco soporte para testing y vulnerabilidades de seguridad

    • En la mayoría de los elementos prohibidos, la biblioteca alternativa está indicada justo al lado. <filesystem> es la excepción
    • Probablemente haya información relacionada en la documentación para desarrolladores de Chromium
    • En general usan base/files

  • Los módulos (Modules) están prohibidos. Ojalá simplemente hubieran copiado el sistema de módulos de D

    • La razón es la falta de soporte de los compiladores

  • La lista de prohibiciones muestra que “el contexto importa más que las funciones modernas”. En apps pequeñas no hay problema, pero en proyectos grandes se vuelve riesgoso

    • El objetivo central de las guías de Google es permitir contribuir con seguridad incluso sin ser experto en el lenguaje. Es decir, más que el tamaño del proyecto, buscan consistencia organizacional
      También consideran la portabilidad entre distintas plataformas
    • En muchos casos mantienen implementaciones propias por razones históricas o de compatibilidad. Son funciones que existían desde antes de su estandarización, así que es difícil reemplazarlas
    • Yo también creo que, en vez de mezclar funciones nuevas por todos lados, es mejor mantener la consistencia con las reglas existentes para que sea menos pesado para quien lo lee