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!

Este post tem 3 comentários

  1. Fabio Galuppo

    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. Felipe Andrade

    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.

  3. Fabiano Arruda

    Oi pessoal, deixando meus 10cents. C++ ainda é uma linguagem bastante utilizada e existe industrias(Automobilistica, Aero Espacial) fora um conjunto enorme de RTOS que dependem dela, dificilmente vc vai encontrar uma industria que use embarcados usando alguma tecnologia que substitua C++. Rust é algo bastante interessante e se voce vem de linguagens como Python, GoLang, e principalmente Scala (apesar de ter uma base OO nela) você terá uma evolução rápida na linguagem. Concordo quando voce diz que hoje em dia não existe muito como justificar o uso de C++, mas adicionaria em cenários como: Web Applications, Sistemas distribuídos, Line Of Business Applications. Existe também dogmas criados e abraçados pelos engenheiros de software em geral, baseado em má interpretação de alguns livros o que nos leva a criar software cebola, cheio de camadas e abstracoes, onde o que vale mesmo é a quantidade de Dynamic Dispatching (V-Table) que temos no codigo. Um codigo bem escrito e projetado em Csharp da conta de muita coisa com certeza, a parte mais dificil hoje em dia é convencer engenheiros que o codigo escrito irá gerar instrução de cpu e que isso conta =D

    Sobre Rust: “O problema, entretanto, é que a linguagem exige uma mudança de mindset tão grande que dificulta a adoção.”, depende demais se voce for um dev Java ou Csharp e for usar fsharp, erlang, scala ou mesmo Go, vc vai bater bastante cabeça. Mas se voce for um programador C, Go, Python e Scala e for aprender Rust, irá sofrer muito menos. Muito de Scala está em Rust em termos de Sintaxe, mas tambem parece com Go, C e outras linguagens quando vc pensa em arquivos e funcoes e nao mais em classes e objetos. Vale demais aprender.

    para quem gosta de embarcados: https://github.com/tock/tock (rtos escrito em Rust)

Deixe uma resposta