sur des cas particuliers, C++ peut être plus rapide que C
Me semble avoir vu un papier sur l'utilisation de la fonction C sort, contre je ne sais plus quel algo générique C++ ou le C++ était effectivement supérieur. Mais supérieur à mon avis uniquement à l'implémentation standard C.
Le troisième niveau, le "vrai" niveau,
Je vois. Arguments intéressants, en effet, l'usage des fonctionnalités supplémentaires du C++ risque d'alourdir le programme en terme de performances. La RTTI, les exceptions (quoique, dans ce cas précis, je me demande quel est le plus lourd dans le chemin non-exceptionnel, entre un programme C++ et un programme C qui vérifie tout) et surtout, surtout les méthodes virtuelles... tout ça coûte cher.
Appeler du code sans en faire exprès est également simple. Trop simple même, et c'est probablement pour ce genre de raisons que Bjarne Stroustrup à dit «C++ has indeed become too "expert friendly"».
Pour la STL, à fonctionnalité égale, c'est à dire avec une struct C et son ensemble de fonctions accompagnatrices, je suis déjà plus mitigé. Pour vector et array, je ne vois pas de raison (je pense que c'est égal), pour std::list par contre oui, parce que c'est une implem de liste chaînée non intrusive. Bien qu'on puisse la réimplémenter en intrusif, je doute que ce soit la première étape que prendra un développeur C++. Dans le cas de map et set, je n'en sais rien du tout.
une sorte de langage indéterminé qui mélange les idiomes des deux langages.
Je vois. Donc pour toi, mêler les deux langages résulte dans un code bâtard. Personnellement, je considère qu'il s'agit de C++ pur, parce qu'un des axes de C++ c'est de ne payer que pour ce que l'on utilise (que ce soit les classes, les algo standards, la RTTI, les exceptions... un code C qui n'utiliserait que std::array et les casts plus sûrs de C++ deviendrait à mes yeux du C++).
il n'existe pas encore de religieux intégristes du C++
Ce serait dommage, compte tenu du fait que le C++ est un langage qui me semble plutôt pragmatique, notamment rien n'empêche l'usage de GC ou de tout objet (ah, si, il faut obligatoirement créer une fonction main pour appeler une méthode statique main de la classe principale... mais à part ça, je vois pas)..
Mais personnellement je trouve que c'est dommage de perdre la sémantique (un std::string n'est pas un std::vector en C++)
C'est vrai. Par contre je me demande s'il y a beaucoup de différences entre les implem des deux.
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
Je ne sais pas si le compilateur est capable de détecter qu'un membre d'une classe n'est jamais accédé (cas d'un string jamais modifié, par exemple, qui pourrait être remplacé par un std::array). D'ailleurs, il ne vaudrait mieux pas: si, au cours d'une modification d'un programme, un string passe en const, le compilo le remplace à la compilation par un array, ça risque de péter l'ABI sans raison.
Et je ne suis pas non plus persuadé que l'efficacité du compilateur soit plus importante quand le code est clair: il peut être clair pour son auteur, mais pas pour le compilateur. Il n'y à rien de plus débile qu'un compilo quand il s'agit de deviner ce qu'un programmeur essaie de faire après tout.
Je me trompe peut-être, mais est-ce qu'on n'en demande pas trop parfois au compilateur? Certes, pour des trucs (un paramètre d'une fonction non nommé et donc jamais utilisé par la fonction ne sera pas mis dans le binaire par exemple) on peut lui faire confiance, mais à un moment faire toujours confiance aux autres pour faire son propre job, me paraît délicat.
Dans le cas du goto que j'ai mis en exemple, il y avait effectivement une meilleure implémentation, celle avec le while. Pas de goto, donc un risque en moins, pas de répétition de code, donc maintenance moins dangereuse, et on évite de coller un if qui sera peut-être, ou pas, optimisé par le compilateur. Qui sera peut-être même bugué d'ailleurs (qui n'à jamais fait de faute d'étourderie dans un if?).
D'ailleurs, ce if, il ne sera pas optimisé par le compilateur en débogage, je me trompe? C'est peut-être une micro optim, c'est vrai, mais est-elle illisible? Et si ce n'est pas le cas, pourquoi ne pas l'utiliser?
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par freem . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 3.
Me semble avoir vu un papier sur l'utilisation de la fonction C sort, contre je ne sais plus quel algo générique C++ ou le C++ était effectivement supérieur. Mais supérieur à mon avis uniquement à l'implémentation standard C.
Je vois. Arguments intéressants, en effet, l'usage des fonctionnalités supplémentaires du C++ risque d'alourdir le programme en terme de performances. La RTTI, les exceptions (quoique, dans ce cas précis, je me demande quel est le plus lourd dans le chemin non-exceptionnel, entre un programme C++ et un programme C qui vérifie tout) et surtout, surtout les méthodes virtuelles... tout ça coûte cher.
Appeler du code sans en faire exprès est également simple. Trop simple même, et c'est probablement pour ce genre de raisons que Bjarne Stroustrup à dit «C++ has indeed become too "expert friendly"».
Pour la STL, à fonctionnalité égale, c'est à dire avec une struct C et son ensemble de fonctions accompagnatrices, je suis déjà plus mitigé. Pour vector et array, je ne vois pas de raison (je pense que c'est égal), pour std::list par contre oui, parce que c'est une implem de liste chaînée non intrusive. Bien qu'on puisse la réimplémenter en intrusif, je doute que ce soit la première étape que prendra un développeur C++. Dans le cas de map et set, je n'en sais rien du tout.
Je vois. Donc pour toi, mêler les deux langages résulte dans un code bâtard. Personnellement, je considère qu'il s'agit de C++ pur, parce qu'un des axes de C++ c'est de ne payer que pour ce que l'on utilise (que ce soit les classes, les algo standards, la RTTI, les exceptions... un code C qui n'utiliserait que std::array et les casts plus sûrs de C++ deviendrait à mes yeux du C++).
Ce serait dommage, compte tenu du fait que le C++ est un langage qui me semble plutôt pragmatique, notamment rien n'empêche l'usage de GC ou de tout objet (ah, si, il faut obligatoirement créer une fonction main pour appeler une méthode statique main de la classe principale... mais à part ça, je vois pas)..
C'est vrai. Par contre je me demande s'il y a beaucoup de différences entre les implem des deux.
Je ne sais pas si le compilateur est capable de détecter qu'un membre d'une classe n'est jamais accédé (cas d'un string jamais modifié, par exemple, qui pourrait être remplacé par un std::array). D'ailleurs, il ne vaudrait mieux pas: si, au cours d'une modification d'un programme, un string passe en const, le compilo le remplace à la compilation par un array, ça risque de péter l'ABI sans raison.
Et je ne suis pas non plus persuadé que l'efficacité du compilateur soit plus importante quand le code est clair: il peut être clair pour son auteur, mais pas pour le compilateur. Il n'y à rien de plus débile qu'un compilo quand il s'agit de deviner ce qu'un programmeur essaie de faire après tout.
Je me trompe peut-être, mais est-ce qu'on n'en demande pas trop parfois au compilateur? Certes, pour des trucs (un paramètre d'une fonction non nommé et donc jamais utilisé par la fonction ne sera pas mis dans le binaire par exemple) on peut lui faire confiance, mais à un moment faire toujours confiance aux autres pour faire son propre job, me paraît délicat.
Dans le cas du goto que j'ai mis en exemple, il y avait effectivement une meilleure implémentation, celle avec le while. Pas de goto, donc un risque en moins, pas de répétition de code, donc maintenance moins dangereuse, et on évite de coller un if qui sera peut-être, ou pas, optimisé par le compilateur. Qui sera peut-être même bugué d'ailleurs (qui n'à jamais fait de faute d'étourderie dans un if?).
D'ailleurs, ce if, il ne sera pas optimisé par le compilateur en débogage, je me trompe? C'est peut-être une micro optim, c'est vrai, mais est-elle illisible? Et si ce n'est pas le cas, pourquoi ne pas l'utiliser?