Em defesa do C++

C++ é uma linguagem de programação velha, charmosa para os iniciados, assustadora para aqueles que conhecem pouco dela. Bjarne Stroustrup desenvolveu o C++ em 1983 no Bell Labs como uma evolução à linguagem C.

Na criação da linguagem, computadores pessoais tinham poucos KB de memória RAM. Por isso, fazia tanto sentido compilar um arquivo por vez, de forma totalmente independente, mantendo abertas referências para funções que eram implementadas em outros arquivos, fazendo a ligação só mais tarde.

Quando C++ foi criada, ter controle total sobre alocações e desalocações em memória era muito importante. Graças a esse controle maior, foi possível desenvolver em hardware muito limitado funcionalidades que, hoje em dia, programadores mais jovens, em linguagens mais modernas, “apanham” para desenvolver em hardware muito mais poderoso.


C++ sobreviveu e resistiu à centenas de distribuições de sistemas operacionais, mantendo quase que total compatibilidade retroativa. Trata-se, ainda, da linguagem mais utilizada em cenários onde uma das demandas é performance bruta.

Sendo muito velha, tem especificação muito grande. Em minha nem tão humilde opinião, esse é seu grande problema.

Há mais de uma década, toda alocação de memória em C++ era feita “na unha”. Embora isso não seja necessário há muito tempo, devido aos famosos smart pointers, é difícil mudar os hábitos de gente que se acostumou a fazer as coisas de maneiras diferentes.

Algo muito simples, como representar strings , não é tão simples para C++. Afinal, a forma como strings são representadas mudou muito nas últimas décadas. Se você estiver “atualizado” tudo é fácil, mas, se não estiver, poderá ter dificuldades realmente.

Por décadas, arrays eram abstrações simples para ponteiros. Por isso, coisas simples como, por exemplo, determinar o comprimento de um array era algo difícil. Felizmente, há mais de uma década há um conjunto extenso de contêineres que e algoritmos que facilitam o processo. Entretanto, o “jeito antigo” continua disponível e ainda é muito utilizado, tanto do jeito antigo, quanto do novo.


C++ que tem quase quarenta anos e tem código quase da mesma idade ainda em produção. Isso é verdade no Windows, por exemplo. Visual Studio, que tem quase 20 anos, também é escrito predominantemente na linguagem e não há sinais de que isso mude em curto prazo.

Por sua origem, C++ interopera bem com C. Entretanto, não sem algumas dificuldades. C++, por exemplo, tem suporte a exceptions, C retorna códigos de erro. Assim, quando um programador C++ está escrevendo código para a API do Windows ou do Linux (que foram projetadas para C), precisará lidar com códigos de erro e não com exceções, tornando tudo mais difícil.


Visando performance e se aproveitando do poder do compilador, C++ sofreu diversos abusos. Bom exemplo disso são as famosas macros do MFC da Microsoft. Além, é claro, da mania de criar “apelidos” para tipos primitivos.


C++, livre da herança de uma especificação que cresceu intensivamente por décadas, é uma linguagem moderna. Aliás, ela também é memory safe desde que se use os recursos mais novos.

Software hoje, é muito mais complexo do que era há décadas atrás. Por isso, C++ também pode ser um pesadelo se tentarmos fazer código para software de hoje usando recursos comuns na linguagem na década de 1990.


Recentemente, têm ganho destaque alguns relatos do desconforto de empresas como Microsoft e Google em manter bases de código escritas em C++.

No caso da Microsoft, é fato que a base de código legada deve estar escrita usando recursos mais antigos da linguagem. Pelas descrições do pessoal da Google, parece que o problema deles também é código velho ou escrito por gente usando técnicas velhas.

Modernamente, se fala bastante de Rust – que, a propósito, é uma alternativa incrível. De fato, a linguagem é “novinha” e, por isso, não sente o peso do tempo. O problema, entretanto, é que a linguagem exige uma mudança de mindset tão grande que dificulta a adoção.

Culpar C++ por problemas, principalmente, por gestão da memória, parece ser injusto. É fato que a UX da linguagem é frágil, principalmente por não impedir que se continue utilizando recursos defasados e perigosos – heranças de tempos onde eram realmente necessários. Entretanto, a utilização desses recursos é opção.


O envelhecimento das linguagens mantendo suporte a especificação antiga é um problema em potencial. C#, que é bem mais jovem que C++, já começa a dar sinais disso.

Há algum tempo, seria fácil culpar C# por gerar “lixo” em demasia e prejudicar a performance de aplicações. Embora, fosse possível evitar os impactos do GC, as abordagens, até pouco tempo, eram nada intuitivas. Recentemente, novas features tanto de C# quanto de .NET passaram a permitir tanto expressividade quanto performance.

As modificações previstas para C# este ano são ainda mais agressivas. Em pouco tempo, o problema de programadores C++ utilizarem estilos completamente diferentes dificultando entendimento um dos outros também passará a ocorrer com C#.


Felizmente, hoje, poucos são os programadores com demandas reais para o poder de C++, ou mesmo de Rust. Há muita coisa que conseguimos fazer em linguagens de nível mais alto sem tantas dores de cabeça.

Também há de se considerar que os celulares que temos em nossos bolsos são centenas de vezes mais poderosos que, por exemplo, o super-computador que derrotou Gary Kasparov em 1997. De certa forma, é vergonhoso que argumentemos problemas de performance de aplicativos por “limitações de hardware”.


Se for programar em C++ hoje, por favor, faça uso das bibliotecas. Use smart pointers e os outros contêineres. Não use a linguagem hoje, como se estivesse na década de 1990. Principalmente, não fale mal dela sem a conhecer direito.

Se estiver disposto a arriscar, use Rust. A linguagem ainda é nova e vem enfrentando problemas de adoção. Mas, vale a aposta se você estiver disposto a investir na reescrita de bases de código colossais – mas lembre-se: ela também vai envelhecer, eventualmente!

Compartilhe este insight:

2 respostas

  1. Elemar, tudo bom?

    O C++ foi criado para possibilitar controle e acesso ao hardware como C, bem como, permitir a criação de abstrações com OO, vulgo “C com classes”.

    Acho importante deixar claro a história do C++ e seu propósito. Por isso, selecionei três referências sobre a motivação da criação do C++:
    Bjarne Stroustrup – Why I Created C++: https://www.youtube.com/watch?v=JBjjnqG0BP8
    A history of C++: https://dl.acm.org/doi/10.1145/234286.1057836
    Software Development for Infrastructure: http://www.stroustrup.com/Software-for-infrastructure.pdf

    A linguagem C++ não é velha. Ela é madura e não parou no tempo. Seu desempenho ainda é um ponto de destaque:
    https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html

    Essa maturidade trás consigo um legado e isso se reflete numa estratégia: continuar mantendo a compatibilidade e a estabilidade da linguagem. Inclusive para coisas onde “não deveria ser” usada:
    https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=fortune
    https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=query
    https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=json
    https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=update

    Quando o C++ padrão foi publicado em 1998, já estava incorporado nele os famosos containers, iterators e allocators da STL.
    Então, supostamente, os news (mallocs) e deletes (frees) poderiam ser eliminados ou encapsulados através do idioma RAII.
    Independentemente de memory safety ou smart pointer, controlar alocação e uso da memória ainda é um fator chave para o desempenho de uma aplicação (vide Software Development for Infrastructure, e sobre Arena Allocation).

    Para suportar a STL, a programação genérica (com templates) foi necessária. A partir dela, surgiu a prática e o termo C++ moderno, influenciado pelo Modern C++ do Alexandrescu.
    O termo C++ moderno foi repaginado a partir do C++ 11, onde alguns smart pointers se tornaram padrão: https://docs.microsoft.com/en-us/cpp/cpp/welcome-back-to-cpp-modern-cpp?view=vs-2019

    Portanto, reforçando sua defesa, se for programar C++ hoje, siga as práticas que já são divulgadas por décadas pela comunidade C++.

    Aos interessados que desejam saber um pouco mais, segue a referência de 2017 “A linguagem de programação C++ e por que você deveria aprendê-la”: http://bit.ly/devxp2017

    Além disso, também é muito importante conhecer outras linguagens como: Rust, Go, Python, D, etc. Porém, nem todas elas alcançarão a imortalidade: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/ECOOP-July09.pdf

    Grande abraço,

    Fabio Galuppo

  2. Elemar, cheguei ao seu texto por acaso e fiquei pela quantidade de conhecimento passado. Um texto denso sem ser de dificil compreensão e enfadonho. Obrigado! Quando você diz: “De certa forma, é vergonhoso que argumentemos problemas de performance de aplicativos por “limitações de hardware””, tem toda razão. Se existir um lema dessa geração atual, certamente seria algo como “o recurso é infinito e está na nuvem”. Não sei se ainda ensinam estrutura de dados e C nos cursos superiores, seu que está fazendo uma falta tremenda.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

Já está disponível o registro da conversa com os meninos da Lambda3, meus amigos Giovanni Bassi e Victor Cavalcante, sobre...
In this post, I’m going to share with you one of the RavenDB 4 features that I like the most:...
Em minhas consultorias, quando questionado sobre escalabilidade, recorro sempre ao scale cube, compartilhado no excelente livro “The Art of Scalability”,...
In this post, I would like to share my current reading list. If you are reading some of these books,...
Este é o primeiro post de uma série onde pretendo compartilhar, com considerável nível de detalhe, como resolver problemas de...
Are you interested to know more about the internals of the .NET Runtime? So you should spend some time reading...