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!
