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.