Le C a l'avantage principal de vous permettre de voir ce qui se passe réellement lorsque vous regardez un morceau de code (oui, le préprocesseur : compilez avec -E et vous le verrez). Quelque chose qui est bien trop souvent faux lorsque vous regardez du code C++. Il y a des constructeurs et des destructeurs qui sont appelés implicitement en fonction de la portée ou à cause des affectations, il y a la surcharge des opérateurs qui peut avoir un comportement surprenant même si elle n'est pas mal utilisée. J'admets que je suis un maniaque du contrôle, mais je suis arrivé à la conclusion que ce n'est pas une si mauvaise habitude pour un développeur de logiciels qui veut écrire des logiciels fiables. Je veux juste avoir une chance équitable de dire que mon logiciel fait exactement ce qu'il est censé faire et ne pas avoir une mauvaise sensation dans l'estomac en même temps parce que je sais qu'il pourrait encore y avoir tellement de bogues dans ce logiciel que je ne remarquerais même pas en regardant le code qui les cause.
Le C++ dispose également de modèles. Je les déteste et les aime, mais si quelqu'un dit qu'il ou elle les comprend parfaitement, je le traite de menteur ! Cela inclut les auteurs de compilateurs ainsi que les personnes impliquées dans la définition de la norme (ce qui devient évident lorsque vous essayez de la lire). Il y a tellement de cas particuliers absurdement trompeurs qu'il n'est tout simplement pas possible de les prendre tous en compte lorsque vous écrivez du code. J'aime les templates C++ pour leur puissance pure. C'est vraiment incroyable ce que l'on peut faire avec eux, mais ils peuvent également conduire aux erreurs les plus étranges et les plus difficiles à trouver que l'on peut (ne pas) imaginer. Et ces erreurs se produisent réellement, et même rarement. La lecture des règles impliquées dans la résolution des templates dans l'ARM C++ me fait presque exploser la tête. Et cela me donne le sentiment désagréable d'avoir perdu du temps à lire des messages d'erreur du compilateur qui font plusieurs milliers de caractères et pour lesquels il me faut déjà 10 minutes ou plus pour comprendre ce que le compilateur attend réellement de moi. Dans le code C++ typique (bibliothèque), on trouve aussi souvent beaucoup de code dans les fichiers d'en-tête pour rendre certains templates possibles, ce qui rend les cycles de compilation/exécution douloureusement lents, même sur des machines rapides, et nécessite la recompilation de grandes parties du code lorsque l'on y change quelque chose.
Le C++ dispose également de la trappe const. Soit vous évitez les constantes pour tous les cas d'utilisation, sauf les plus triviaux, soit vous devrez tôt ou tard les rejeter ou remanier de grandes parties du code de base lorsqu'il évolue, en particulier lorsque vous êtes sur le point de développer une conception OO agréable et flexible.
Le C++ possède un typage plus fort que le C, ce qui est formidable, mais j'ai parfois l'impression de nourrir un Tamagotchi lorsque j'essaie de compiler du code C++. Une grande partie des avertissements et des erreurs que je reçois habituellement ne sont pas vraiment dus au fait que je fais quelque chose qui ne fonctionnerait pas, mais simplement à des choses que le compilateur n'aime pas que je fasse de telle ou telle façon sans faire de casting ou sans mettre quelques mots-clés supplémentaires ici et là.
Ce ne sont là que quelques-unes des raisons pour lesquelles je n'aime pas le C++ pour les logiciels que j'écris seul en utilisant uniquement des bibliothèques externes prétendument robustes. La véritable horreur commence lorsque vous écrivez du code en équipe avec d'autres personnes. Qu'il s'agisse de hackers C++ très intelligents ou de débutants naïfs n'a pratiquement aucune importance. Tout le monde fait des erreurs, mais le C++ rend délibérément difficile de les trouver et encore plus difficile de les repérer avant qu'elles ne se produisent.
Avec le C++, vous êtes tout simplement perdu sans l'utilisation permanente d'un débogueur, mais j'aime pouvoir vérifier l'exactitude de mon code dans ma tête et ne pas avoir à compter sur un débogueur pour découvrir que mon code s'exécute sur des chemins que je n'aurais jamais prévus. En fait, j'essaie d'exécuter tout mon code dans ma tête et de prendre toutes les branches qu'il a, même dans les sous-routines, etc. et de n'utiliser un débogueur qu'occasionnellement, juste pour voir à quel point il fonctionne bien dans tous les endroits confortables que j'ai préparés pour lui. Il est tout simplement impossible d'écrire et d'exécuter un si grand nombre de cas de test où tous les chemins de code ont été utilisés dans toutes les combinaisons avec toutes sortes de données d'entrée étranges. Vous ne connaissez peut-être pas les bogues des programmes C++, mais cela ne veut pas dire qu'ils n'existent pas. Plus un projet C++ est important, moins je suis sûr qu'il ne comportera pas de nombreux bogues non détectés, même s'il fonctionne parfaitement avec toutes les données de test dont nous disposons. Finalement, je le mets à la poubelle et je recommence avec un autre langage ou une combinaison d'autres langages.
Je pourrais continuer, mais je pense que j'ai été clair maintenant. Tout cela m'a donné l'impression d'être improductif lorsque je programme en C++ et m'a fait perdre confiance dans l'exactitude de mon propre code, ce qui signifie que je ne l'utiliserai plus, alors que j'utilise toujours du code C que j'ai écrit il y a plus de 20 ans. Peut-être est-ce simplement parce que je ne suis pas un bon programmeur C++, ou peut-être que le fait d'être assez bon en C et dans d'autres langages me permet de reconnaître à quel point je suis nul en ce qui concerne le C++, et que je ne serai jamais capable de le comprendre complètement.
La vie est courte...
