Les craintes de performances ou de ballonnement ne sont pas une bonne raison de renoncer au C ++. Chaque langue a ses pièges potentiels et ses compromis - les bons programmeurs en apprennent plus sur ces derniers et, le cas échéant, développent des stratégies d'adaptation, les pauvres programmeurs tomberont dans l'erreur et blâmeront la langue.
Le Python interprété est à bien des égards considéré comme un langage «lent», mais pour des tâches non triviales, un programmeur Python expérimenté peut facilement produire du code qui s'exécute plus rapidement que celui d'un développeur C inexpérimenté.
Dans mon secteur, les jeux vidéo, nous écrivons du code haute performance en C ++ en évitant des choses comme le RTTI, les exceptions ou les fonctions virtuelles dans les boucles internes. Ceux-ci peuvent être extrêmement utiles, mais présentent des problèmes de performances ou de ballonnement qu'il est souhaitable d'éviter. Si nous devions aller plus loin et passer entièrement à C, nous gagnerions peu et perdrions les constructions les plus utiles de C ++.
La principale raison pratique de préférer C est que le support est plus répandu que C ++. Il existe de nombreuses plates-formes, en particulier celles intégrées, qui n'ont même pas de compilateurs C ++.
Il y a aussi la question de la compatibilité pour les vendeurs. Alors que C a une ABI (Application Binary Interface) stable et bien définie, C ++ n'en a pas. L'ABI en C ++ est plus compliqué en raison d'éléments tels que les vtables et les constructeurs / destructeurs, il est donc implémenté différemment avec chaque fournisseur, et même les versions d'une chaîne d'outils de fournisseurs.
En termes réels, cela signifie que vous ne pouvez pas prendre une bibliothèque générée par un compilateur et la lier avec du code ou une bibliothèque d'un autre, ce qui crée un cauchemar pour les projets distribués ou les fournisseurs de middleware de bibliothèques binaires.