• [^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..

    Posté par . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 5.

    Je ne vois pas vraiment de raison pour que le C++ soit plus lent que le C.

    Il y a plusieurs niveaux de réponse. Le premier niveau, évidemment, c'est que le C est (à peu près) valide en C++, et qu'il suffit de coder en C pour avoir les mêmes performances. Le deuxième niveau est que ça dépend ; en théorie, on peut faire plus de choses au C++ au moment de la compilation, et que sur des cas particuliers, C++ peut être plus rapide que C (il y a des exemples d'algorithmes qui peuvent même être résolus au moment de la compilation en C++ via des templates ou des constructions un peu complexes). Le troisième niveau, le "vrai" niveau, consiste à admettre que la richesse du C++, la programmation objet, la STL, etc, ont des contraintes qui ajoutent un coût significatif—et là, on est bien d'accord, on n'est pas à fonctionalités égales. Les fonctions virtuelles, ont un coût, par exemple. Par ailleurs, les idiomes du C++ sont plus lourds que le C ; par exemple, on a tendance à faire beaucoup plus de tests pour vérifier l'intégrité des classes ; il est également plus facile en C++ d'appeler du code inutile (constructeur par défaut...) involontairement.

    utiliser des char[] dans l'array, et pas des std::string

    Ce genre de trucs, par exemple, me semblent relever du fameux C/C++, une sorte de langage indéterminé qui mélange les idiomes des deux langages. Après, chacun fait ce qu'il veut, et il n'existe pas encore de religieux intégristes du C++. Mais personnellement je trouve que c'est dommage de perdre la sémantique (un std::string n'est pas un std::vector en C++) pour gagner un micropouillème hypothétique au moment de l'exécution (sans compter qu'il n'est pas impossible que le compilo détecte les concaténation de chaines constantes, et que plus le code est clair, plus le compilo est efficace).