Meu primeiro encontro com o C ++ foi nos anos 90, quando era um dos verdadeiros Languages ™ que eu às vezes ouvi falar, pois ainda estava jogando na piscina infantil com o Visual Basic, PHP e JavaScript. A primeira versão formalmente padronizada do C ++ é o padrão ISO 1998, mas estava tornando as vigoras como um ‘melhor C’ há décadas naquele momento desde que Bjarne Stroustrup acrescentou esse operador de incremento a C em 1979 e lançou C ++ ao público em 1985.
Por que escolhi o C ++ como minha principal linguagem de programação? Principalmente porque era bem suportado e com ferramentas gratuitas: um compilador gratuito de Borland ou G ++ no lado do GCC. Alternativas como VB, Java e D pareciam nicho demais em comparação com idiomas estabelecidos, enquanto o C ++ deu acesso à língua franca de C, ao mesmo tempo em que adiciona muitos recursos modernos, como OOP e uma sintaxe mais simplificada, além da Biblioteca de Modelos Padrão (STL) com gobs de blocos de construção úteis.
Anos depois, como um desenvolvedor sênior de C ++ grisalho, cheguei a abraçar a noção de que ser bom em uma linguagem de programação também significa ter opiniões fortes sobre tudo o que há de errado com o idioma. Fiel à forma, embora o C ++ tenha muitos pontos positivos, ainda existem grandes verrugas e muitos aspectos fortemente negligenciados que levam a mim e a outros desenvolvedores de C ++ se irritaram.
Por que nos apaixonamos
O que me assustou com o C ++ inicialmente foi o quão grande e assustador parecia, com Gargantuan Ides como o Visual Studio da Microsoft, sistemas de construção complexos e interface gráfica do usuário que pareciam exigir magia negra muito além da compreensão do meu pequeno cérebro. Embora o uso da API Win32 baseada em C pura realmente exija sacrifícios virgens rituais, e os desenvolvedores do Windows falam apenas sobre MFC Quando colocado sob extrema coação, a verdade é que o próprio C ++ é bastante simples, e escrever aplicativos complexos é fácil quando você o divide em etapas. Para mim, o avanço veio depois de comprar uma cópia do Stroustrup’s A linguagem de programação C ++especificamente o Terceira edição que cobriu o padrão C ++ 98.
Mais do que apenas uma referência, apresentou claramente para mim não apenas como escrever programas básicos de C ++, mas também como estruturar meu código e projetos, bem como os raciocínio por trás de cada um desses aspectos. Por muitos anos, este livro foi meu recurso preferido, ao desenvolver minhas habilidades rudimentares e aflitadas por idiomas em algo mais robusto.
Provavelmente, a melhor parte do C ++ é sua flexibilidade. Nunca o limita a um único paradigma de programação, enquanto lhe dá a liberdade de escolher o caminho do desejo de sua escolha. Embora um número surpreendente de más escolhas possa ser feito aqui, com um pouco de cuidados e pesquisas, você não precisa acabar içado com seu próprio petard. A parte da parte da compatibilidade C do C ++ está especialmente repleta de perigos, mas é por isso que temos os bits C ++ para que não precisemos tocá-los.
Refletindo com C ++ 11
Levaria até 2011 para a primeira grande atualização do padrão C ++, quando eu usava C ++ principalmente para projetos de hobby cada vez mais elaborados. Mas então eu fui lançado em vários projetos comerciais C e C ++ que colocariam minhas habilidades em expansão à prova. Nessa época, encontrei os primeiros itens principais em C ++ que são realmente irritantes.
Questões comuns, como a ordem do cabeçalho e a ordem do link, que podem levar a dependências circulares, são alguns de aspectos realmente deliciosos. O primeiro é causado principalmente pela maneira bastante simplista de que os arquivos de cabeçalho são batidos diretamente no código -fonte pelo pré -processador. Como em C, o pré -processador simplesmente olha para o seu #include "widget/foo.h" e substitui -o pelo conteúdo de foo.h com absolutamente nenhuma consideração pelos efeitos colaterais e casos de combustão espontânea.
Ao longo do caminho, outras declarações de pré-processador acumulam ainda mais o código de maneiras felizes, e é por isso que o GCC g ++ e compiladores compatíveis como Clang têm o -E Sinalize apenas para executar o pré -processador apenas para que você possa inspecionar o barf pré -processado que seria enviado ao compilador antes dele explodir violentamente. O trauma sofreu aqui é o motivo pelo qual concordo com sinceridade com o Sr. Stroustrup que o pré -processador é basicamente mau e só deve ser usado para coisas mais básicas, como incluem constantes muito simples e compilação seletiva. Nunca tente ser fofo ou inteligente com o pré -processador ou quem herda sua base de código o encontrará.
Se você obteve os problemas arquitetônicos do seu código e o cabeçalho incluirá resolvido, verá que o vinculador do C ++ é tão burro quanto o de C. Depois de receber os arquivos de objeto compilado e olhar para os símbolos necessários, ele entrará na lista de bibliotecas, observe cada um e, felizmente, ignorará os símbolos previamente vistos mais tarde. Você sofrerá por isso com ferramentas como LDD e leitura Enquanto você tenta determinar se você é apenas denso, o ligante é denso ou ambos estão tendo problemas de flutuabilidade.
Somente esses pontos são bastante traumáticos, mas você aprende a lidar com eles como se lida com um bando de bebês definitivamente dentados algumas fileiras atrás de você naquele vôo transatlântico. A pior parte é provavelmente que nem o C ++ 11 nem os padrões subsequentes foram abordados em qualquer grau perceptível, com uma mudança de unidades de compilação no estilo C para módulos semelhantes a ADA provavelmente nunca vão acontecer.
O ‘módulos em casa‘O recurso introduzido com C ++ 20 é efetivamente apenas cabeçalhos limitados no estilo C sem a bagagem de pré-processador, sem a análise de dependência e outros recursos que fazem idiomas como a ADA uma alegria para construir código.
Inicialização não determinística
Embora C ++ e C ++ 11, em particular, removam muitos comportamentos indefinidos para os quais C é famoso, ainda existem muitas partes em que o comportamento esperado é efetivamente aleatório ou pelo menos específico da plataforma. Um exemplo é o de static inicialização, oficialmente conhecida como Fiasco de ordem de inicialização estática. Essencialmente o que isso significa é que você não pode contar com uma variável declarada static a ser inicializado durante a inicialização geral entre diferentes unidades de compilação.
Isso também afeta as mesmas unidades de compilação quando você está inicializando um static std::map instância com dados durante inicializaçãoao aprendi da maneira mais difícil durante um projeto quando vi falhas de segmentação aleatória na inicialização relacionadas à instância da estrutura de dados estática. O resumo executivo aqui é que você não deve assumir que algo foi implicitamente inicializado durante a inicialização do aplicativo e, em vez disso, deve fazer a inicialização explícita para essas estruturas estáticas.
Um exemplo disso pode ser encontrado no meu Nymphrpc Projeto, no qual usei a mesma solução para evitar falhas de inicialização. Isso envolve criar explicitamente o mapa estático, em vez de orar para que seja criado a tempo:
static map &methodsIdsStatic = NymphRemoteClient::methodsIds();
Com o methodsIds() função:
map& NymphRemoteClient::methodsIds() {
static map* methodsIdsStatic = new map();
return *methodsIdsStatic;
}
São esse tipo de negligência, juntamente com os problemas anteriores de tempo de construção cobertos que tendem a treinar muito tempo durante o desenvolvimento até que você aprenda a reconhecê-los com antecedência junto com as correções.
Amor desaparecendo
Não me interpretem mal, ainda acho que o C ++ é uma boa linguagem de programação em sua essência, é apenas que ele tem esses pontos difíceis e bordas afiadas que você deseja não estar lá. Há também a falta de melhorias em alguns aspectos bastante fundamentais no STL, como o C ++ não amado Biblioteca de cordas. Comparado ao ADA Strings de biblioteca padrãoa API de String STL C ++ é muito barebones, com muita manipulação de cordas exigindo a escrita do mesmo código tedioso repetidamente, já que as funções de conveniência estão aparentemente na lista de desejos de ninguém.
Uma coisa boa que o C ++ 11 trouxe para o STL foi o suporte multitarefa, com threads, mutexes e assim por diante, finalmente disponível. É uma pena que suas variáveis de condição sejam atormentadas por despertadores espúrios e uma sintaxe mais complicada do que o necessário. Isso fica ainda pior com o Biblioteca de sistemas de arquivos Isso foi adicionado no C ++ 17. Embora seja bom ter mais do que apenas E/S básico de arquivo em C ++ por padrão, ele é baseado na biblioteca em Impulsionarque usa um estilo de codificação, obsessão por encapsulamento de tipo e abuso de namespaces que você aparentemente ama ou odeia.
Eu pessoalmente encontrei o Bibliotecas Poco C ++ Para ser infinitamente mais fácil de usar, com uma implementação relativamente fácil de seguir. Eu até usei as bibliotecas poco para o Npoco Projeto, que adapta o código ao uso do microcontrolador e adiciona suporte à Freertos.
Finalmente, existem algumas mudanças no idioma central das quais discordo fundamentalmente, como a adição de inferência de tipo com o auto palavra -chave Fora dos modelos, que é um recurso fracamente digitado. Como se não fosse ruim o suficiente para ter o caos de fundição de tipo explícita e implícita mistaagora colocamos plenamente nossa fé no compilador, orarmos que ninguém atualize o código em outro lugar que possa causar explosões posteriormente e removemos quaisquer pistas relacionadas ao tipo que possam ser úteis para um desenvolvedor que leia o código.
Mas pelo menos temos constexpro que provavelmente é incrivelmente útil para as pessoas que usam C ++ para dissertações acadêmicas, em vez de programação real.
Esperança para o futuro
Provavelmente continuarei usando o C ++ no futuro próximo, enquanto resmunga a todos os Whippersnappers que adicionam coisas inúteis que ninguém estava pedindo. Como a opinião geral sobre a adição de novos recursos ao C ++ é que você precisa fazer todo o trabalho de braçadeira – como entrar nos grupos de trabalho do C ++ para promover seus recursos – é muito provável que poucos realmente precisassem de que os recursos sejam novos padrões de C ++, pois aqueles de nós que estão realmente usando o idioma estão ocupados demais para escrever o código de produção.
Felizmente, há uma excelente compatibilidade com versões anteriores em C ++, para que aqueles de nós nas trincheiras possam continuar usando o idioma da maneira que gostarmos, juntamente com todos os patches que escrevemos para aliviar as dores. É triste que agora exista uma divisão entre os desenvolvedores de C ++ e os acadêmicos de C ++.
É uma das razões pelas quais me senti cada vez mais motivado nos últimos anos a procurar outros idiomas, com Ada sendo um dos meus favoritos. Ao contrário do C ++, ele não possui os problemas de tempo de construção mencionados acima e, embora seu sistema de tipo super-forte torne o início da escrita da lógica de negócios mais lenta, ele impede tantos problemas mais tarde, juntamente com seus limites de tempo de execução universais. Não é sempre que o uso de uma linguagem de programação me faz sentir algo que se aproxima da alegria.
Desistir de uma linguagem de programação com a qual você cresceu literalmente é difícil, mas, como em qualquer relacionamento, você deve ser honesto sobre quaisquer problemas, não importa se você ou a linguagem de programação. Dito isto, talvez algum aconselhamento para relacionamentos retire as coisas novamente no futuro, com os desenvolvedores dos EUA estarem novamente envolvidos no desenvolvimento do idioma.
