C++ Coding Pains 18/Jun/2009
Tal como referi num artigo anterior, PolyglotProgramming: Scala, vou neste artigo enumerar as diversas “dores” que tenho sentido ao codificar sistemas em C++.
Antes de mais, saliento que os problemas que vou enumerar não são porque a linguagem de programação C++ seja péssima ou porque outras linguagens de programação são melhores ou porque eu seja um guru em C++, muito pelo contrário. Os pontos negativos que aqui enumero têm todos origem na minha experiência (e são portanto totalmente pessoais e subjectivos) em codificar em C++, a maioria das vezes com código legado por outros programadores.
Historicamente, foi na Universidade que tive contacto com C++ pela primeira vez e foi num projecto da cadeira de Programação Orientada a Objectos que codifiquei pela primeira vez em C++, procurando perceber minimamente os conceitos do paradigma OOP. Até então, as linguagens que conhecia e usava eram, por ordem cronológica: Basic, Assembly, Pascal e C. O projecto dessa cadeira demonstrou-me que eu era mais fluente em C do que em C++. Só anos mais tarde, ao aprender Java, é que comecei a perceber as vantagens de programar segundo o paradigma OOP.
O sistema ao qual actualmente dou suporte técnico enquanto programador é um sistema baseado em C++ e Oracle Pro*C, numa arquitectura cliente/servidor. Todo o sistema foi legado à equipa actual, e a maioria dos pontos que aqui enumero têm como ponto de origem este código legado.
- O código na linguagem C++ requer compilação, em vez de ser executado por um interpretador.
- A linguagem não é puramente orientada a objectos, e permite o uso de tipos primitivos (int, long, char, ...).
- É muito frequente ter código mais de segundo o paradigma procedimental do que segundo o paradigma orientado a objectos, o que inviabiliza o uso mais adequado da linguagem C++ em sistemas onde o paradigma OOP tem diversas vantagens.
- A linguagem é estaticamente tipificada. Mas herdou da linguagem C o uso frequente de casts.
- É preciso um cuidado e atenção por parte do programador em questões de alocação e libertação de memória. Não existe um mecanismo de Garbage Collection.
- É habitual trabalhar-se com ponteiros.
- É preciso entender e saber usar a passagem de argumentos por valor ou por referência.
- A linguagem C++ é recheada de funcionalidades, por exemplo herança múltipla, mas por isso mesmo é também de elevada complexidade, com muitas nuances e caminhos à escolha do programador – que requerem ou impõem uma grande experiência com a linguagem antes do programador se poder considerar ou ser considerado fluente.
- O código não é – habitualmente – multi-plataforma. É frequente existir no código “ruído” para fixar uma rotina ou funcionalidade consoante a plataforma host. O melhor exemplo desta falta de portabilidade do código é demonstrada pela necessidade que houve em desenvolver o mecanismo autoconf/automake.
- O código é ruidoso e com um elevado nível de verbosidade. O que leva, frequentemente, ao uso e abuso da “clonagem de código”, com recurso ao copy&paste.
- É habitual definir e implementar as funcionalidades em código separado em dois ficheiros distintos: “.hpp” e “.cpp”.
- A ferramenta de build, por omissão, é a Make. Mas este é um problema mais da ferramenta em si do que da linguagem de programação. Nada evita que se usem outras ferramentas, tais como a Jam por exemplo. Mas ainda assim, é habitual virem ficheiros Makefile juntamente com o código em C/C++. E a codificação destes ficheiros não é trivial.
- É habitual “ignorar” os warnings de compilação que vão surgindo, o que é estranho dado que se é uma ciência (Ciência da Computação) então deveriam-se resolver os warnings em vez de os ignorar. Mas diversos warnings são habitualmente provocados pelo tentativa de ter código mais “multi-plataforma”.
- Inexistência de – ou pelo menos grande dificuldade em encontrar – libraries ou ferramentas FLOSS de apoio à codificação.
- O que leva frequentemente à inclusão de 3rd-party libraries ou ferramentas que causam mais tarde vendor lock-in.
- Inexistência de um layer de independência a motores de base de dados. Existem no entanto diversas 3rd-party libraries que providenciam este nível de abstracção, mas são habitualmente escolhidas pela equipa de desenvolvimento em vez de serem como que um “standard” na comunidade de programadores dessa linguagem.
Uma nota para salientar que alguns destes pontos negativos são também eles pontos positivos, dependendo da opinião pessoal de cada programador. Nomeadamente se a linguagem é estaticamente ou dinamicamente tipificada.
Update 2009.06.23: Actualizei a listagem dos pontos “dolorosos” a nível dos warnings de compilação e da inexistência de um nível de abstracção no acesso a base de dados.
- Posted in : doCoding
- Author : José Carlos Monteiro
Comments»
no comments yet - be the first?