A segurança é um dos termos usados com mais frequência e, ao mesmo tempo, definidos com menos precisão no debate atual sobre linguagens de programação. Frequentemente, o conceito é instrumentalizado sem ser examinado em todo o seu escopo. No discurso público, a segurança costuma ser reduzida à segurança de memória, ignorando que ela não é uma propriedade binária, mas um contínuo multidimensional.
A segurança em C++ vai muito além de evitar erros de “uso após liberação” (use after free)
Para sistemas reais, a segurança não começa apenas com a ausência de erros de memória. Ela envolve a capacidade de um sistema:
- Permanecer estável ao longo do tempo.
- Responder de forma previsível sob carga.
- Implementar corretamente todos os requisitos funcionais.
- Degradar-se graciosamente em caso de falha, em vez de colapsar.
- Manter controle total sobre seus recursos e evoluir por décadas sem invalidar bases de código testadas.
A segurança abrange garantias de tempo de execução, correção funcional, segurança de recursos, segurança de dados, robustez e evolução a longo prazo. O C++ oferece liberdade aos desenvolvedores, o que traz uma responsabilidade extensiva, sendo uma decisão arquitetural deliberada para resolver problemas universais que não podem ser reduzidos a um único modelo de segurança.
O que são os Perfis (Profiles) propostos por Bjarne Stroustrup?
Os Perfis são uma proposta (embora não tenham entrado no C++26) para tornar a responsabilidade do desenvolvedor explícita.
- Eles permitem que suposições de segurança sejam definidas claramente e verificadas mecanicamente sem fragmentar a linguagem.
- Um perfil descreve sob quais suposições o C++ é usado em um contexto específico.
- Eles são multivalorados, representando diferentes níveis de segurança e cenários de uso.
A segurança torna-se gradual e sensível ao contexto, refletindo melhor a realidade de grandes sistemas do que uma classificação binária.
O que há de errado com a segurança de memória do Rust?
Embora o Rust ofereça garantias formais fortes, seu modelo de segurança é considerado monocausal.
- Ele foca quase exclusivamente na segurança de memória e impõe uma visão específica de propriedade (ownership) e tempos de vida (lifetimes).
- Este modelo não é arquiteturalmente neutro e pode se tornar um obstáculo estrutural para certos problemas.
- A segurança no Rust permanece binária (seguro ou inseguro), o que ignora riscos como erros lógicos, deadlocks, problemas de latência e violações de protocolo.
Por que a segurança do C++ é melhor do que você imagina?
A segurança possui uma dimensão temporal; o software deve permanecer mantível e adaptável por décadas. O C++ evolui de forma incremental, introduzindo novos mecanismos de segurança gradualmente sem invalidar abstrações existentes.
Além disso, há uma dimensão econômica: sistemas inseguros surgem muitas vezes de restrições de custo e tempo. Uma linguagem que trata a segurança como “tudo ou nada” incentiva o desvio de mecanismos de segurança. A segurança gradual dos perfis permite aumentar os requisitos de segurança de forma economicamente viável.
Como o C++ é superior à abordagem do Java?
A experiência com Java mostra que confundir proibição com segurança não elimina riscos, apenas os torna invisíveis fora do espaço de segurança monitorado. A segurança real não surge da descapacitação do desenvolvedor, mas de modelos explícitos, qualificação e ferramentas. O C++ é uma ferramenta para especialistas responsáveis, onde os perfis servem para apoiar o aprendizado e tornar a experiência eficaz.
