C++ Deveria Ser C++
A rápida evolução do C++ e a sua complexidade crescente estão a polarizar os utilizadores: alguns elogiam os padrões modernos por tornarem a linguagem mais expressiva e poderosa, enquanto outros os veem como barrocos, difíceis de aprender e difíceis de adaptar a grandes codebases legadas. Os comentadores discordam sobre se o C++ deve priorizar ser uma linguagem de sistemas de alto desempenho, melhorar ergonomia e segurança (potencialmente em resposta às expectativas e regulações emergentes de “memory-safe”), ou mesmo aceitar que linguagens mais recentes como Rust, Zig ou Go podem ser mais adequadas para muitos domínios. Lacunas de tooling — especialmente em módulos, gestão de dependências e reprodutibilidade de builds — são vistas como grandes obstáculos práticos, independentemente da direção da linguagem.
Receção do C++ moderno
- Forte divisão: alguns consideram o C++20/23 um enorme salto de qualidade de vida (por exemplo,
optional,expected, filesystem, structured bindings, inicialização em if/switch, lambdas) e apreciam o “C++ moderno”. - Outros, especialmente utilizadores de longa data, veem os padrões mais recentes como barrocos e desagradáveis, preferindo “C com classes” ou um subconjunto muito pequeno.
- Muitos programadores, de facto, restringem-se a um subconjunto específico do projeto, mas isso é mais difícil em codebases grandes e à medida que novas funcionalidades (por exemplo, move semantics) introduzem boilerplate ou requisitos subtis.
Ferramentas, módulos e gestão de dependências
- Amplamente percebido como uma grande fraqueza: não há gestor de pacotes padrão, nem uma solução integrada para dependências, testes, logging, etc.
- Os módulos são vistos como promissores, mas praticamente inutilizáveis devido ao suporte desigual de compiladores e ferramentas.
- O vcpkg é criticado por comportamento frágil, fontes alteradas e versionamento fixado a commits; Bazel/Buck e Nix/Guix são mencionados como respostas parciais.
- Algumas equipas recorrem a verificar toolchains no controlo de versões ou a criar snapshots de VMs.
Modelo de compilação e desempenho
- Os tempos de compilação são vistos como um dos principais pontos de dor, muitas vezes com prioridade superior a novas funcionalidades de segurança.
- As causas discutidas: análise repetida de headers, instanciação de templates por unidade de tradução, trabalho extra do linker para remover duplicados e uma gramática difícil; há discordância sobre qual fator domina.
- Comparações com Go, Rust, Zig e C destacam como o modelo de preprocessing e compilação de C/C++ envelhece mal, mesmo com precompiled headers ou módulos.
Segurança de memória, regulações e direção da linguagem
- Há discordância sobre o quanto os utilizadores de C++ realmente exigem segurança de memória; alguns dizem que os que se importam já partiram, outros argumentam que muitos o querem, mas não através de ferramentas pagas adicionais.
- Segurança “meia medida” (opt-in, cobertura parcial, custo em runtime) é considerada de benefício limitado.
- O debate discute pressão governamental (orientações da NSA/CISA, regras em preparação nos EUA/UE) para linguagens seguras em termos de memória; não há proibições diretas, mas espera-se pressão de procurement e burocracia.
- Alguns veem o texto como uma reação defensiva ao Rust, que muitos consideram um substituto credível do C++ para trabalho de sistemas.
Biblioteca padrão, ergonomia e “zero-cost”
- Queixas de que o std não tem primitivas de alto desempenho (allocators especializados, estruturas lock-free/wait-free, IPC, threading de alto desempenho) e não é afinado para workloads de jogos/BDs/SO.
- Outros argumentam que isto deve ficar em bibliotecas externas e que nenhum design genérico de alto desempenho serve bem todos os workloads.
- O ideal de “abstração de custo zero” é posto em causa; fluxo de controlo oculto (construtores, destrutores, cópias) e exceções podem ter custo real se forem mal usados ou mal otimizados.
- Novas APIs como
std::printsão vistas como mais incómodas do que idioms mais antigos (streams) para personalização, reforçando perceções de ergonomia fraca.
Generalidade, legado e alternativas
- Debate prolongado sobre se “usado por milhões” prova que o C++ é uma boa linguagem de uso geral; alguns chamam a isso uma falácia, outros dizem que o uso amplo no mundo real, em vários domínios, é evidência de aptidão de facto.
- O legado e a inércia são citados repetidamente: muitas pessoas programam em C++ apenas porque o código anterior já existia; enormes codebases tornam mudanças disruptivas ou reescritas totais impraticáveis.
- Alguns defendem que o C++ deve apostar ainda mais em ser a linguagem de sistemas mais rápida; outros acham que a sua história e complexidade o tornam uma má escolha para novos programadores comparado com Rust ou Go.
- Propostas como Carbon, cppfront e “C with templates” são mencionadas como tentativas de novos começos, mas há ceticismo quanto à adoção e à capacidade do comité de fazer mudanças radicais e incompatíveis.