Le C est tellement proche de l'implémentation machine qu'il sera toujours plus performant.
Faux, l'assembleur est le plus proche.
Blague à part, un superbe example que c'est faux, c'est la différence de performance entre qsort et std::sort. Impossible également de retrouver le lien précis, mais il y a quelques années, GCC à commencé à autoriser le C++, pour se débarrasser du garbage collector qu'ils avaient dû implémenter à cause du manque de RAII en C.
J'ai regardé rapidement (j'ai du taf, je voulais juste me distraire vite fait) un des examples de code en C++, et un autre en C. Celui en C++ utilise std::cout, celui en C utilise printf.
Rien n'empêche d'utiliser std::printf en C++ (personnellement, c'est ce que je fais, même si je m'emmerde pas avec le namespace) qui est plus lisible (à mes yeux, en tout cas, parce que je trouve les doubles chevrons imbuvables) et si ma mémoire est bonne plus rapide, surtout si l'on fait l'erreur d'utiliser std::endl (toujours de mémoire, c'est super lent comparé à '\n'). Le fait qu'il soit plus léger en mémoire reste à prouver, mais j'en suis persuadé (!= convaincu) du fait qu'il me semble que ça puisse lancer des exceptions (le code est p'tet mort, mais il est là quand même).
À noter que printf n'est spécialement un truc léger non plus, d'ailleurs.
Perso, je dirais que C++ est plus performant que C sur de gros projets, si on se limite à un certain nombre de fonctionnalités, ce que devraient faire à mon avis tous les projets, et je ne suis pas le seul à penser qu'il faut sélection un jeu de fonctionnalités et s'y tenir. Certains bannissent les exceptions, d'autres les templates, d'autres l'héritage multiple, d'autres les méthodes virtuelles...
La raison pour laquelle C++ serait plus efficace que C sur de gros projets est qu'il ne nécessite pas de gérer les ressources (la mémoire, les accès fichiers, les entités opengl, les accès aux bases de données, etc) à la main, ce qui fait que les ressources sont libérées dès qu'il n'y en a plus besoin.
Le gain en performance pour moi de ce côté est: moins de bugs, moins de mémoire consommée à instant T.
Les templates eux permettent, comme pour std::sort vs qsort, un gain de vitesse lié à la réduction des callbacks.
Par contre, mal utiliser des fonctionnalités de C++ peut être très punitif en matière de performance: utiliser std::map, std::set ou std::list pour stocker des petits objets (de taille inférieure à un pointeur, par exemple), utiliser std::vector sans réserver la mémoire avant de faire une boucle de push_back est aussi une erreur que je vois régulièrement et qui est potentiellement très punitive.
De manière générale, je trouve la STL difficile à utiliser efficacement, en fait, et je trouve qu'elle déroge quand même pas mal au fameux "you pay for what you use" de C++: après tout, dès lors que l'on utilise la STL, on est obligé d'utiliser les exceptions, qui ne sont pas vraiment légères en terme de code (certes qui n'est exécuté qu'exceptionnellement, mais il est bien présent dans le binaire, ce qui compte parfois).
D'ailleurs, sur ce sujet, EA games avait implémenté la sienne notamment parce que gérer la mémoire avec la STL n'est pas vraiment simple.
[^] # Re: Quid sur de gros programmes ?
Posté par freem . En réponse au lien Faites du C pour sauver la planète!. Évalué à 4.
Faux, l'assembleur est le plus proche.
Blague à part, un superbe example que c'est faux, c'est la différence de performance entre qsort et std::sort. Impossible également de retrouver le lien précis, mais il y a quelques années, GCC à commencé à autoriser le C++, pour se débarrasser du garbage collector qu'ils avaient dû implémenter à cause du manque de RAII en C.
J'ai regardé rapidement (j'ai du taf, je voulais juste me distraire vite fait) un des examples de code en C++, et un autre en C. Celui en C++ utilise std::cout, celui en C utilise printf.
Rien n'empêche d'utiliser std::printf en C++ (personnellement, c'est ce que je fais, même si je m'emmerde pas avec le namespace) qui est plus lisible (à mes yeux, en tout cas, parce que je trouve les doubles chevrons imbuvables) et si ma mémoire est bonne plus rapide, surtout si l'on fait l'erreur d'utiliser std::endl (toujours de mémoire, c'est super lent comparé à '\n'). Le fait qu'il soit plus léger en mémoire reste à prouver, mais j'en suis persuadé (!= convaincu) du fait qu'il me semble que ça puisse lancer des exceptions (le code est p'tet mort, mais il est là quand même).
À noter que printf n'est spécialement un truc léger non plus, d'ailleurs.
Perso, je dirais que C++ est plus performant que C sur de gros projets, si on se limite à un certain nombre de fonctionnalités, ce que devraient faire à mon avis tous les projets, et je ne suis pas le seul à penser qu'il faut sélection un jeu de fonctionnalités et s'y tenir. Certains bannissent les exceptions, d'autres les templates, d'autres l'héritage multiple, d'autres les méthodes virtuelles...
La raison pour laquelle C++ serait plus efficace que C sur de gros projets est qu'il ne nécessite pas de gérer les ressources (la mémoire, les accès fichiers, les entités opengl, les accès aux bases de données, etc) à la main, ce qui fait que les ressources sont libérées dès qu'il n'y en a plus besoin.
Le gain en performance pour moi de ce côté est: moins de bugs, moins de mémoire consommée à instant T.
Les templates eux permettent, comme pour std::sort vs qsort, un gain de vitesse lié à la réduction des callbacks.
Par contre, mal utiliser des fonctionnalités de C++ peut être très punitif en matière de performance: utiliser std::map, std::set ou std::list pour stocker des petits objets (de taille inférieure à un pointeur, par exemple), utiliser std::vector sans réserver la mémoire avant de faire une boucle de push_back est aussi une erreur que je vois régulièrement et qui est potentiellement très punitive.
De manière générale, je trouve la STL difficile à utiliser efficacement, en fait, et je trouve qu'elle déroge quand même pas mal au fameux "you pay for what you use" de C++: après tout, dès lors que l'on utilise la STL, on est obligé d'utiliser les exceptions, qui ne sont pas vraiment légères en terme de code (certes qui n'est exécuté qu'exceptionnellement, mais il est bien présent dans le binaire, ce qui compte parfois).
D'ailleurs, sur ce sujet, EA games avait implémenté la sienne notamment parce que gérer la mémoire avec la STL n'est pas vraiment simple.