Pourquoi la surchage a-t-elle si mauvaise réputation ?

Pourquoi la surchage a-t-elle si mauvaise réputation ? - C++ - Programmation

Marsh Posté le 10-10-2004 à 01:43:57    

Bonsoir bonsoir.
 
Bin alors je lis partout: le C++ peut être quasi aussi rapide que du C si on évite la ligature dynamique, telle lib dit: on a pas utilisé l'héritage virtuel pour éviter la chute de perfs, etc...
Alors moi je me suis posé la question: pourquoi c'est réputé si lent ?
Test:
 

Code :
  1. class Parent
  2. {
  3. public:
  4. virtual int getValue(int a) { return a+a; }
  5. virtual int getSecondValue(int a) { return 2*a-a; }
  6. };
  8. class Fils : public Parent
  9. {
  10. public:
  11. virtual int getValue(int a) { return a*a; }
  12. virtual int getSecondValue(int a) { return 4*a-a; }
  13. };
  15. int main()
  16. {
  17. Parent* p;
  18. Fils f;
  19. p = &f;
  20. p->getValue(3);
  21. p->getSecondValue(3);
  22. }


 
(je sais y'a pas de return dans main mais c pas la question)
Après compilation avec les 4 virtual, sous vc7.1 en mode debug sans optimisations, on obtient pour main:
 

Code :
  1. _main PROC NEAR
  3. ; 16   : {
  5. push ebp
  6. mov ebp, esp
  7. sub esp, 8
  9. ; 17   :  Parent* p;
  10. ; 18   :  Fils f;
  12. lea ecx, DWORD PTR _f$[ebp]
  13. call ??0Fils@@QAE@XZ
  15. ; 19   :  p = &f;
  17. lea eax, DWORD PTR _f$[ebp]
  18. mov DWORD PTR _p$[ebp], eax
  20. ; 20   :  p->getValue(3);
  22. push 3
  23. mov ecx, DWORD PTR _p$[ebp]
  24. mov edx, DWORD PTR [ecx]
  25. mov ecx, DWORD PTR _p$[ebp]
  26. call DWORD PTR [edx]
  28. ; 21   :  p->getSecondValue(3);
  30. push 3
  31. mov eax, DWORD PTR _p$[ebp]
  32. mov edx, DWORD PTR [eax]
  33. mov ecx, DWORD PTR _p$[ebp]
  34. call DWORD PTR [edx+4]
  36. ; 22   : }
  38. xor eax, eax
  39. mov esp, ebp
  40. pop ebp
  41. ret 0
  42. _main ENDP


 
En virant les 4 virtual:
 

Code :
  1. _main PROC NEAR
  3. ; 16   : {
  5. push ebp
  6. mov ebp, esp
  7. sub esp, 8
  9. ; 17   :  Parent* p;
  10. ; 18   :  Fils f;
  11. ; 19   :  p = &f;
  13. lea eax, DWORD PTR _f$[ebp]
  14. mov DWORD PTR _p$[ebp], eax
  16. ; 20   :  p->getValue(3);
  18. push 3
  19. mov ecx, DWORD PTR _p$[ebp]
  20. call ?getValue@Parent@@QAEHH@Z  ; Parent::getValue
  22. ; 21   :  p->getSecondValue(3);
  24. push 3
  25. mov ecx, DWORD PTR _p$[ebp]
  26. call ?getSecondValue@Parent@@QAEHH@Z  ; Parent::getSecondValue
  28. ; 22   : }
  30. xor eax, eax
  31. mov esp, ebp
  32. pop ebp
  33. ret 0
  34. _main ENDP


 
Moi les différences que je vois sont:
 - appel d'un constructeur de Fils, qui appelle un constructeur de Parent en virtual, ce qui n'est pas fait en non virtual. Vlà le code du constructeur de Fils au cas où on me le demande:

Code :
  1. ??0Fils@@QAE@XZ PROC NEAR    ; Fils::Fils, COMDAT
  2. ; _this$ = ecx
  3. push ebp
  4. mov ebp, esp
  5. push ecx
  6. mov DWORD PTR _this$[ebp], ecx
  7. mov ecx, DWORD PTR _this$[ebp]
  8. call ??0Parent@@QAE@XZ
  9. mov eax, DWORD PTR _this$[ebp]
  10. mov DWORD PTR [eax], OFFSET FLAT:??_7Fils@@6B@
  11. mov eax, DWORD PTR _this$[ebp]
  12. mov esp, ebp
  13. pop ebp
  14. ret 0
  15. ??0Fils@@QAE@XZ ENDP     ; Fils::Fils


 
 - un appel des fonctions via un offset depuis this, et une écriture d'ecx 2 fois pareil... donc une inutile.
 
Soit au coût de l'appel, 2 mov en plus et un call indirect, ce qui devrait pas faire plus de 3-4 cycles en plus par appel, ce que je trouve super négligeable comparé au temps d'exécution d'une fonction normalement longue/complexe... Je vois pas trop la différence avec utiliser un pointeur de fonction en C, qui serait le moyen que j'utiliserais normalement pour remplacer ces virtual.
 
Quelqu'un peut m'expliquer pourquoi on dit que c'est lent alors ?
Merci !

Reply

Marsh Posté le 10-10-2004 à 01:43:57   

Reply

Marsh Posté le 10-10-2004 à 01:59:21    

ben y a que les cons qui disent ça. Y a toujours des cons pour pas comprendre. Les gens familiers du C++ comprennent bien que la virtualité implique un traitement supplémentaire. Mais y aura toujours des abrutis qui font de la branlette intellectuelle.
 
 
Cela dit : si tu vires les virtual, magique, le compilateur génère un return 0 est rien d'autres :D

Reply

Marsh Posté le 10-10-2004 à 09:38:11    

Taz a écrit :

ben y a que les cons qui disent ça. Y a toujours des cons pour pas comprendre. Les gens familiers du C++ comprennent bien que la virtualité implique un traitement supplémentaire. Mais y aura toujours des abrutis qui font de la branlette intellectuelle.


 
Ces cons la si on les ecoutés, faudriat faire du C avec des cout et basta :|
 
le virtual comme le template c'ets bien quand on en sert correctement point.
 
Les onanistes du bulbe sont peut-etre juste un gros tas de mauvais codeur.

Reply

Marsh Posté le 10-10-2004 à 09:43:47    

Citation :

Ces cons la si on les ecoutés, faudriat faire du C avec des cout et basta :|


les cout c'est pas du C :/


---------------
I mean, true, a cancer will probably destroy its host organism. But what about the cells whose mutations allow them to think outside the box by throwing away the limits imposed by overbearing genetic regulations? Isn't that a good thing?
Reply

Marsh Posté le 10-10-2004 à 10:31:26    

Masklinn a écrit :

Citation :

Ces cons la si on les ecoutés, faudriat faire du C avec des cout et basta :|


les cout c'est pas du C :/


 
il veut dire que ces cons en question font du c avec des cout en guise de c++

Reply

Marsh Posté le 10-10-2004 à 11:03:19    

cris56 a écrit :

il veut dire que ces cons en question font du c avec des cout en guise de c++


Ah oui, du C++ avec des malloc quoi :love:


---------------
I mean, true, a cancer will probably destroy its host organism. But what about the cells whose mutations allow them to think outside the box by throwing away the limits imposed by overbearing genetic regulations? Isn't that a good thing?
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed