As sombras do Ambiente de Programação C++

Estou realmente escrevendo sobre este assunto! É claro que, até reunir material suficiente para um livro maneiro, vai demorar muito tempo. Até lá espero encontrar alguma publicação legal que aceite artigos.

Minha motivação inicial para entender os mistérios do ambiente de programação C++ foi estudar a ABI do C++, que seria necessário implementar no sistema operacional C++.

Existem outros aspectos interessantes desse ambiente, porém, que são pouco focalizados pelas obras educativas sobre a linguagem.

Um deles é o relacionamento entre o mundo restrito da norma ISO C e o mundo maior do sistema. C fala a você sobre unidades de tradução e estabelece regras mínimas sobre como múltiplas unidades de tradução podem compor um programa válido. Ao redor da linguagem, porém, existe o problema de processar cada uma dessas unidades e produzir de fato um negócio único equivalente a este programa. Existirão então diversos blocos intermediários, os "objetos compilados", e existirá um componente ligador. A norma C não descreve este ligador, apenas impõe seus requisitos.

Outro é o modo como os mecanismo de linguagem e do sistema são usados na prática como mecanismos de abstração, e como os projetos de engenharia fazem uso desses mecanismos para lidar com problemas reais de configuração. O ambiente como um todo provê diversas maneiras de abstrair certos trechos de código; desde a seleção de arquivos a compilar, onde um arquivo pode conter a listagem para o sistema A enquanto outro contém a listagem para o sistema B; até a composição de bibliotecas dinâmicas no momento da carga na memória, onde o programa usa a versão A da biblioteca no sistema A, e a versão B da biblioteca no sistema B.

Para lidar com toda essa parafernália sistêmica ao redor do C são imprescindíveis ferramentas que operam fora da linguagem, dirigindo todas as ferramentas de forma conveniente. O projeto de middleware de televisão digital da TQTVD tem, por exemplo, aproximadamente mil unidades de tradução individuais a processar. Certamente o programador não deve chamar as ferramentas uma vez para cada um desses arquivos, sob pena de tornar o dia de trabalho um desperdício de horas absurdo. Existem portanto ferramentas para apoiar essa tarefa que, apesar de não fazer parte da definição da linguagem ou do compilador, são absolutamente imprescindíveis para se trabalhar com ela.

Tudo isso implica que a expertise no desenvolvimento de sistemas em C++ envolve diversas outras habilidades e técnicas individuais, fora aquelas envolvendo a expressão de programas em C++. Essas outras habilidades e técnicas se tornam tão mais importantes quanto o projeto pressione o programador para fora da abstração de um sistema para o mundo concreto das diversas máquinas.

Sob outro ângulo, posso comparar as listas de componentes teórica e prática que compõe o pipeline de transformação de código-fonte. Teoricamente, o pipeline C é: pré-processador, compilador, ligador ou arquivador. Na prática do projeto onde estou envolvido é: configurador de build, ferramenta de build, compilador.

Uma lição que estou tirando de tudo isso é que os melhores pensamentos sobre a linguagem de programação ideal nunca resultariam em um excelente sistema construído se essa linguagem não for implementada em ferramentas adequadas, que suportem um ciclo de desenvolvimento extremamente conveniente. O esquema de compilação separada do C oferece bons mecanismos de abstração, sem dúvida, mas torna o tempo de compilação uma infinitude de "começa e termina" processos.

Em contra-partida, opiniões sobre características de linguagem de programação do tipo "viagem na maionese" ou "impossível" parecem refletir o fato de que, até então, ninguém soube produzir uma ferramenta que a implementasse. O mecanismo de "export" do C++ por exemplo foi considerado um fracasso; agora que as técnicas de LTO e serialização de ASTs de programas estão se tornando mais difundidas, talvez com mais cinco ou dez anos "export" seja trivial.