> langages de plus haut niveau pour accélerer le cycle de développement,
Mouaif, bof. Developper en Python/Perl/Ruby je veux bien que ce soit plus rapide qu'en C standard. Mais concernant le C++, je suis pas sur.
J'ai personnellement developpe 2 projets de complexite equivalente, l'un en C, l'autre en C++. Celui en C est paradoxalement plus facile a maintenir; paradoxalement car il est vrai que tout le monde (ou presque) semble s'accorder pour dire que le C++ est plus maintenable.
Le probleme du C++, c'est que:
- il est moins standardise. Concretement, tu peux avoir des problemes de format de binaire (gcc 2.x vs gcc 3.x). Certains toolkits super utiles comme STL marchent bizarrement sur certaines plates-formes (Visual C++ pour ne pas le citer...), et d'une maniere generale il est plus facile de trouver un plus petit denominateur commun en C qu'en C++.
- les temps de compilation en C++ sont redhibitoires. Avec mon projet C++, je suis monte a 45 minutes de compilation sur un P200. Maintenant sur un Athlon 1.4GHz ca va un peu mieux, mais par rapport a du C c'est je jour et la nuit. Donc concretement, je passe la moitie du temps a compiler quand je programme en C++, alors qu'en C c'est quasi instantane.
- le C++ a tendance a pousser les gens vers la perfection. Et c'est pas toujours un bien. On se dit "Ah oui je pourrais peut-etre faire un truc conceptuellement plus beau en faisant ceci ou en faisant cela...". Et du coup on passe son temps a remodeler des trucs qui marchaient deja. En C je trouve que les criteres d'appreciation du code sont plus simples: ca fait ce qu'on veut, ca plante pas -> OK c'est bon.
- le C++ est AMHA beaucoup moins lisible/facile a comprendre que le C. En effet, le language aide le programmeur donc le programmeur n'hesite pas a mettre en place des mecanismes assez complexes. Pour prendre l'exemple de ClanLib, le code est assez dur a comprendre. Tu as des classes qui font Provider de ceci ou de cela, des trucs qui heritent de partout, du masquage de donnees, des concepts a tout va, des connecteurs en veux-tu en voila. Au final, c'est tres joli, mais beaucoup plus dur a comprendre qu'un code qui ferait la meme chose en C. Enfin c'est mon avis.
- en parlant de maintenabilite du C++, je rappelle que ClanLib, qui est en C++, a une API extremement instable qui bouge tout le temps, et est bien loin derriere SDL et Allegro ( http://www.talula.demon.co.uk/allegro/(...) ) en terme de stabilite (je parle ici de la stabilite au sens "ne pas faire de core dump"). Typiquement, les developpeurs de ClanLib ne cessent de faire du "redesign" de l'API parce que "ca sera plus beau comme ca", et la bibliotheque est pas mal victime de bugs lies au C++ (destructeurs appeles 2 fois, fuites memoire...). Prenons un exemple, la gestion des fichiers "a la .wad" a savoir stocker des donnees dans un seul fichier, et y acceder par mot-cle. Les developpeurs d'Allegro ont fait un truc super basique. Tu peux grosso-modo stocker les types "de base" de la lib (font, bitmap, sample...) et pour tes donnees "a toi" on t'offre la possibilite de manipuler le type de donnees "raw data" et tu recupere un pointeur "void *" sur tes donnees. Ca permet de tout faire. Mais c'est pas beau. Avec ClanLib en C++, c'est boOOOO! Par contre l'API a deja change au moins une fois en 2 ans (5 ans sans aucun changement pour Allegro). Tu dispose de supers classes de la mort pour enregistrer toi-meme ton propre type de donnees etc. Genial, mais en quoi cela fait-il gagner du temps? Moi je ne vois pas. Avec le bon vieux "void *" on en faisait autant... De plus, le C++ ne permet absolument pas de s'affranchir des problemes de faute memoire. Par contre, c'est vrai, c'est plus joli. Maintenant faut savoir si on veut faire du code joli ou du code qui marche.
Pour finir avec cette reflexion, je tiens a preciser que les developpeurs de ClanLib font un *excellent* boulot, sont tres competents, et mon propos n'est absolument pas de dire que leur projet est mediocre. Au contraire. Mais je ne vois pas en quoi C++ leur fait gagner du temps...
[^] # Re: Le C c'est mal
Posté par ufoot . En réponse à la dépêche Le livre "Programming Linux Games" disponible en pdf. Évalué à 1.
Mouaif, bof. Developper en Python/Perl/Ruby je veux bien que ce soit plus rapide qu'en C standard. Mais concernant le C++, je suis pas sur.
J'ai personnellement developpe 2 projets de complexite equivalente, l'un en C, l'autre en C++. Celui en C est paradoxalement plus facile a maintenir; paradoxalement car il est vrai que tout le monde (ou presque) semble s'accorder pour dire que le C++ est plus maintenable.
Le probleme du C++, c'est que:
- il est moins standardise. Concretement, tu peux avoir des problemes de format de binaire (gcc 2.x vs gcc 3.x). Certains toolkits super utiles comme STL marchent bizarrement sur certaines plates-formes (Visual C++ pour ne pas le citer...), et d'une maniere generale il est plus facile de trouver un plus petit denominateur commun en C qu'en C++.
- les temps de compilation en C++ sont redhibitoires. Avec mon projet C++, je suis monte a 45 minutes de compilation sur un P200. Maintenant sur un Athlon 1.4GHz ca va un peu mieux, mais par rapport a du C c'est je jour et la nuit. Donc concretement, je passe la moitie du temps a compiler quand je programme en C++, alors qu'en C c'est quasi instantane.
- le C++ a tendance a pousser les gens vers la perfection. Et c'est pas toujours un bien. On se dit "Ah oui je pourrais peut-etre faire un truc conceptuellement plus beau en faisant ceci ou en faisant cela...". Et du coup on passe son temps a remodeler des trucs qui marchaient deja. En C je trouve que les criteres d'appreciation du code sont plus simples: ca fait ce qu'on veut, ca plante pas -> OK c'est bon.
- le C++ est AMHA beaucoup moins lisible/facile a comprendre que le C. En effet, le language aide le programmeur donc le programmeur n'hesite pas a mettre en place des mecanismes assez complexes. Pour prendre l'exemple de ClanLib, le code est assez dur a comprendre. Tu as des classes qui font Provider de ceci ou de cela, des trucs qui heritent de partout, du masquage de donnees, des concepts a tout va, des connecteurs en veux-tu en voila. Au final, c'est tres joli, mais beaucoup plus dur a comprendre qu'un code qui ferait la meme chose en C. Enfin c'est mon avis.
- en parlant de maintenabilite du C++, je rappelle que ClanLib, qui est en C++, a une API extremement instable qui bouge tout le temps, et est bien loin derriere SDL et Allegro ( http://www.talula.demon.co.uk/allegro/(...) ) en terme de stabilite (je parle ici de la stabilite au sens "ne pas faire de core dump"). Typiquement, les developpeurs de ClanLib ne cessent de faire du "redesign" de l'API parce que "ca sera plus beau comme ca", et la bibliotheque est pas mal victime de bugs lies au C++ (destructeurs appeles 2 fois, fuites memoire...). Prenons un exemple, la gestion des fichiers "a la .wad" a savoir stocker des donnees dans un seul fichier, et y acceder par mot-cle. Les developpeurs d'Allegro ont fait un truc super basique. Tu peux grosso-modo stocker les types "de base" de la lib (font, bitmap, sample...) et pour tes donnees "a toi" on t'offre la possibilite de manipuler le type de donnees "raw data" et tu recupere un pointeur "void *" sur tes donnees. Ca permet de tout faire. Mais c'est pas beau. Avec ClanLib en C++, c'est boOOOO! Par contre l'API a deja change au moins une fois en 2 ans (5 ans sans aucun changement pour Allegro). Tu dispose de supers classes de la mort pour enregistrer toi-meme ton propre type de donnees etc. Genial, mais en quoi cela fait-il gagner du temps? Moi je ne vois pas. Avec le bon vieux "void *" on en faisait autant... De plus, le C++ ne permet absolument pas de s'affranchir des problemes de faute memoire. Par contre, c'est vrai, c'est plus joli. Maintenant faut savoir si on veut faire du code joli ou du code qui marche.
Pour finir avec cette reflexion, je tiens a preciser que les developpeurs de ClanLib font un *excellent* boulot, sont tres competents, et mon propos n'est absolument pas de dire que leur projet est mediocre. Au contraire. Mais je ne vois pas en quoi C++ leur fait gagner du temps...
Sur ce, bonne fin de week-end.