Discussion :

[Luc Hermitte]

Je suis d'accord que ce débat est un faux débat. Mais aussi pour d'autres raison. Ta phrase me rappelle le débat sur le coût révé de la virtualité, que l'on a peut-être déjà abordé ici d'ailleurs. Le truc est que l'on paye pour les fonctionnalités que l'on utilise. Après, il faut voir de quelles fonctionalités on a besoin.

Juste une précision supplémentaire. Objet ne veut pas dire polymorphisme d'inclusion à tous les coins de rue. On n'est pas obligé d'hériter et d'introduire la liaison tardive parce que l'on veut écrire des objets. Cf ce qui dérive directement de la STL (j'écarte donc les flux propres à la SL). 0 héritage, 0 polymorphisme d'inclusion. Et pourtant 100% C++, 0% C.

Concernant les biblios mathématiques, la référence initale, ce sont les BLAS du Fortran. On trouve des adaptations C qui vont avoir de bonnes perfs, mais une interface de manipulation peu pratique. Et on trouve des biblios C++ qui rajoutent une expressivité "mathématique" tout en maintenant d'excellentes perfs. Dans le passé, on avait Blitz++ qui réalisait une utilisation intensive de méta-programmation template pour éliminer les temporaires, ... Visiblement, blitz++ ne semble pas se préoccuper des problèmes de pipeline aussi efficacement que d'autres biblios. Qu'à cela ne tienne, on a des alternatives construites sur la même philo que blitz++ qui savent encapsuler des biblios C à la BLAS.
En fait, pour le côté mathématique, la sémantique de valeur inhérente aux objets mathématique fait que l'on evite naturellement tout ce qui concerne le polymorphisme d'inclusion.

[mchk0123]

En effet (et par exemple) la création et la destruction d'objets plus ou moins polymorphes impliquent les appels respectifs à tous les constructeurs et destructeurs de tous les parents de l'objet en question mais aussi à ses propres méthodes de construction et de destruction...

Surement moins d'impact que tu ne le penses sur la différence C/C++.
Tu perd en temps d'appel entre les différents const./dest. mais c'est mineur sur les CPU d'aujourd'hui (bien moins qu'un branch misprediction).

Ce qui est sur c'est que si tu est accroc aux méthodes virtuelles, aux constructeurs de copies et que tu ne pratique jamais le passage d'objets par référence, ... aie aie aie ... Ca peut faire mal.

Donc je serais tenté de dire que plus tu utilises un langage abstrait, plus tu à de décisions (correctes) d'implémentation à prendre car tu auras toujours plus de combinatoire pour faire la même chose que si tu utilises un langage plus proche du bit code.

[zais_ethael]

Bon, je crois qu'on a tous compris que le C++ n'est pas lent en lui même et qu'un code C compilé avec un compilo C++ produira exactement le même résultat.
Je vais prendre un petit exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
int vecc[N];
vector<int> veccpp(N);
 
for(int i=0;i<N;i++)
   vecc[i]++;
for(int i=0;i<N;i++)
   veccpp.at(i)++;

A priori ces deux codes sont similaires, sauf que la fonction at() de vector vérifie systématiquement si la taille de vecteur et renvoie une exception si elle est dépassée. Donc si N=10 000, cela fera 10 000 vérifications inutiles puisque on sait très bien qu'on ne dépassera pas la taille de ce vecteur (oui, les gourous de la stl me diront qu'on peut utiliser l'opérateur [] qui ne fait pas cette vérification ou encore des itérateurs, mais c'est pour illustrer et j'avais pas d'autre exemple en tête ).
C'est inévitablement plus lent, c'est une des conséquences quand on fait des classes "super-safes, où tout est toujours libéré correctement, où rien ne peut jamais se retrouver dans un état incohérent à quelque instant que ce soit". Pour généraliser on pourrait même énoncer une loi du style: toute abstraction entraine une perte d'optimisation.
Ce n'est pas forcément lié au C++, pour reprendre notre exemple il existe aussi des biblios pour faire des tableaux plus sécurisés en C. Le C++ se distingue juste parceque cela est plus facile, plus naturel.

[mchk0123]

Donc je serais tenté de dire que plus tu utilises un langage abstrait, plus tu à de décisions (correctes) d'implémentation à prendre car tu auras toujours plus de combinatoire pour faire la même chose que si tu utilises un langage plus proche du bit code.

Je précise ce que j'ai dit :

Plus un langage à une puissance d'expression etendue (ce qui le cas de C++ par rapport à C, car il ajoute des concepts sans en enlever), plus il y à de combinaisons possible pour implémenter un processus donnant le même résultat.
Du coup on à plus de décisions correctes à prendre ...

... Donc plus de probabilitée d'écrire du code peu optimisé si on y fait pas attention.