Recursos de C++ proibidos no Chromium

• O projeto Chromium define com clareza o escopo de uso e os itens proibidos dos recursos modernos do padrão C++ para manter a consistência e a segurança do código
• De C++11 a C++23, o status de cada recurso é classificado como permitido, proibido ou em análise (TBD), e a biblioteca Abseil segue o mesmo critério
• Entre os recursos proibidos estão std::shared_ptr, std::function, std::regex, std::filesystem, std::byte, char8_t, modules e outros
• Entre os recursos permitidos estão concepts, operador spaceship, designated initializer, std::to_underlying, algoritmos de std::ranges e outros
• Este guia se aplica ao Chromium e a todos os projetos derivados, funcionando como um critério central para garantir a estabilidade do código e a compatibilidade de build

---

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

• O Chromium não adota imediatamente os novos padrões de C++; em vez disso, eles são marcados como inicialmente suportados (initially supported) apenas depois que o suporte da toolchain estiver suficientemente consolidado
  • Depois disso, cada recurso é classificado como permitido (allowed), proibido (banned) ou em análise (TBD)
• Mudanças no status de novos recursos podem ser propostas pela lista de e-mails [e-mail]
• Dois anos após o suporte inicial, o recurso é movido para a lista de permitidos ou proibidos após revisão explícita

Recursos proibidos do C++11

• Recursos da linguagem: inline namespace, long long, literais definidos pelo usuário (user-defined literals)
• Recursos da biblioteca: <chrono>, <regex>, motores de <random>, <exception>, <ratio>, <thread> e outros
  • Exceções (exception) estão totalmente desativadas, e apenas noexcept é permitido
  • Em vez de std::bind, std::function, std::shared_ptr e std::weak_ptr, usam-se base::Bind, base::Callback, base::RefCounted

Recursos proibidos do C++17

• Literais de caractere UTF-8 (u8) são proibidos devido a problemas de compatibilidade com char8_t
• Itens de biblioteca proibidos:
  • funções matemáticas especiais, algoritmos paralelos (parallel algorithms), std::any, std::byte, std::filesystem, recursos de memória std::pmr e outros
  • algoritmos paralelos são proibidos por falta de suporte em libc++ e por risco de conflito com o modelo de threading do Chrome

Recursos permitidos e proibidos do C++20

• Recursos de linguagem permitidos:
  • concepts, consteval, designated initializers, operador spaceship, [[likely]], sintaxe de inicialização em range-for
• Recursos de biblioteca permitidos:
  • <bit>, <compare>, <concepts>, <numbers>, std::erase_if, std::ranges::subrange, std::to_underlying e outros
• Recursos proibidos:
  • char8_t, modules, [[no_unique_address]], std::bit_cast, <span>, std::bind_front, std::ranges::view_interface
• Em análise (TBD): coroutine, <format>, <source_location>, std::u8string

Recursos permitidos e em análise do C++23

• Recursos de linguagem permitidos: #elifdef, if consteval, operador estático (static operator)
• Recursos de biblioteca permitidos: std::byteswap, std::basic_string::contains, std::to_underlying, algoritmos estendidos de std::ranges
• Recursos em análise: std::expected, std::mdspan, std::generator, std::stacktrace, std::print, [[assume]], #warning e outros

Política da biblioteca Abseil

• Componentes proibidos do Abseil:
  • absl::any, absl::optional, absl::StatusOr, absl::Span, absl::FunctionRef, absl::Mutex, absl::Time, absl::btree_* e outros
  • a maioria é substituída por implementações do Chromium no namespace base (base::span, base::expected, base::Bind etc.)
• Em análise (TBD): absl::linked_hash_set, absl::linked_hash_map

Significado geral

• O Chromium não aceita automaticamente os recursos padrão de C++; eles são adotados seletivamente com base em estabilidade de build, segurança, desempenho e consistência do código
• A maior parte dos recursos proibidos se deve a implementações duplicadas (base::) ou a problemas de compatibilidade de toolchain e ABI
• Este guia funciona como um documento de referência para controle de qualidade de código C++ no ecossistema Chromium e é essencial em colaborações open source

[karikera]

É uma pena que o C++ continue ficando cada vez mais inchado por causa da compatibilidade retroativa...

[tsboard]

É realmente uma linguagem enorme, como foi dito na opinião do HN: C++ ...

[GN⁺]

Comentários no Hacker News

• Não há nada especialmente chamativo, mas a maior parte é basicamente “vamos usar bibliotecas internas feitas para o nosso caso de uso”
  O restante também parece razoável, como evitar problemas de locale. Também faz sentido haver opções para aparar arestas da biblioteca padrão

  • Vejo isso com frequência em empresas com codebases antigas. Antigamente não havia chrono, então criaram seu próprio tipo de tempo, e já usavam contêineres próprios antes de a STL se estabilizar
    Se alguém começasse um projeto novo hoje, provavelmente a maioria dessas regras não faria sentido
  • É interessante o motivo de char8_t ser proibido. Quase não existem codificações que não sejam UTF-8, e char8_t* não é compatível com char*, então recomendam usar std::string ou std::string_view para evitar uma proliferação de casts
  • Como alguém que manteve essa página por mais de 10 anos, acho curioso que esse documento tenha aparecido no r/c++ e no HN no mesmo dia. Não há nada particularmente novo, então fico me perguntando por que isso virou assunto
  • Em alguns casos, não é apenas inércia: a implementação do Google tem um projeto estritamente melhor do que o padrão. Os tipos padrão poderiam ter sido melhor projetados
  • Existe a percepção de que o Google tem sua própria versão de quase toda tecnologia. O problema é quando algumas pessoas copiam isso cegamente e perdem o contexto. Um exemplo clássico é adotar Kubernetes numa organização com 20 desenvolvedores e 50 serviços

• Falando em código antigo, isso me fez lembrar de quando o Chromium saiu pela primeira vez
  É impressionante pensar de novo que esse codebase começou há 20 anos

• Proibir <regex> foi uma boa decisão. Não dava para usar porque ele não lidava direito com UTF-8. É surpreendente que um design tão defeituoso tenha sido padronizado

  • Hoje em dia, a maioria das bibliotecas de regex suporta modo Unicode. Regex é uma tecnologia mais antiga que UTF-8

• Há documentos mais interessantes no diretório acima
  Vale a pena ver o guia de estilo C++ do Chromium

• Exceções são proibidas, mas há uma exceção para Windows

  • O código do Google originalmente era baseado em estilo C, então não é exception-safe. Se começassem do zero, talvez fosse melhor usar exceções, mas isso é difícil por causa da compatibilidade com o código existente
    Ou seja, não foi uma proibição filosófica, e sim por motivos práticos. Dizem até que, se recomeçassem do zero, fariam diferente
  • Este documento não é o Google Style Guide, e sim o documento Chromium Modern C++ Features. Ele não trata de exceções nem de conteúdo específico por plataforma
  • Procurei por “exception” e “Windows” com grep, mas só apareceu uma menção relacionada a [[no_unique_address]], então talvez a piada tenha passado batida

• A lista de recursos proibidos é tão grande que parece maior do que todos os recursos de C. É esmagadora

  • C++ realmente é uma linguagem enorme

• Proibir literais u8"..." foi uma boa escolha. Se o próprio código-fonte já está em UTF-8, não há necessidade desse prefixo
  Esse tipo de literal parece um caso em que a solução veio antes do problema

• Quero encontrar as alternativas para os recursos proibidos. Por exemplo, dizem que <filesystem> tem pouco suporte para testes e vulnerabilidades de segurança

  • Na maioria dos itens proibidos, a biblioteca alternativa está indicada logo ao lado. <filesystem> é a exceção
  • Talvez haja informação relacionada na documentação para desenvolvedores do Chromium
  • Em geral, usam base/files

• Módulos estão proibidos. Quase seria melhor terem copiado o sistema de módulos da linguagem D

  • O motivo é a falta de suporte dos compiladores

• A lista de proibições mostra que “o contexto importa mais do que recursos modernos”. Em apps pequenos isso talvez não seja problema, mas em projetos grandes é arriscado

  • As diretrizes do Google têm como foco permitir contribuições seguras mesmo de quem não é especialista na linguagem. Ou seja, o objetivo é mais consistência organizacional do que o tamanho do projeto
    A portabilidade entre várias plataformas também é considerada
  • Em muitos casos, mantêm implementações próprias por razões históricas ou de compatibilidade. São recursos que já existiam antes da padronização, então é difícil substituí-los
  • Eu também acho que, em vez de sair misturando recursos novos por todo lado, manter a consistência com as regras existentes torna a leitura menos pesada para quem vem depois