striiiiiiiiiiiiiiing - Page 40

Brunni (./1170) :
Mais ça a un impact négligeable sur les perfs, considère plutôt que le fait qu'une méthode soit virtuelle ou non a un rapport avec la conception, pas les perfs ;-)

GoldenCrystal (./1171) :
Mais oui, après on est d'accord, il ne faut pas se priver des méthodes virtuelles pour une bête raison de performance.

Folco (./1150) :
Oui, il est où le problème du nombre de classe ? La consommation mémoire et cpu ? (mécanismes à mettre en place pour chaque classe toussa)
Pour moi, c'est qu'une question de place dans l'IDE à mes yeux hein

Folco (./1156) :
squalyl -> J'espère que le mécanisme de typage dynamique n'est mis en place que quand nécessaire, sinon boujour les perfs ^^

Kevin Kofler (./1173) :
C'est surtout que je trouve ça crade. L'icône Ouvrir d'une application est une icône, pas une "icône ouvrir, sous-classe de icône". Question performances, ça ne change pas grand chose. Ça risque juste de prendre de la place dans l'exécutable (table de symboles etc.). Mon objection est liée à la conception, pas à la performance.

Donc la pénalité que tu te tapes, ce sont 2 lectures de pointeurs en mémoire (le pointeur sur la vtable et l'entrée dans la vtable) par appel de fonction virtuelle, mais ça s'arrête là.

Thepro (./1158) :

aze (./1155) :
(j'ai édité une 50aines de fois, je sais pas si tu as eu la dernière version )

Peut-être que tu devais éditer encore pour corriger ce genre de chose :

a.f(); // b::f
a.g(); // a::f

Kevin Kofler (./1173) :
Les méthodes virtuelles ne fonctionnent pas à travers un mécanisme de typage dynamique, mais à travers un simple pointeur dans la classe de base qui pointe sur une table des fonctions virtuelles (vtable). Donc la pénalité que tu te tapes, ce sont 2 lectures de pointeurs en mémoire (le pointeur sur la vtable et l'entrée dans la vtable) par appel de fonction virtuelle, mais ça s'arrête là.

Thepro (./1182) :
(Il faut éditer encore, tu as fait cette erreur deux fois )

Folco (./1180) :
Donc on a un cast de entry[ID_truc].ptr en "Receive", puis la méthode est appelée.

aze (./1184) :

Thepro (./1182) :
(Il faut éditer encore, tu as fait cette erreur deux fois )

je vais locker ce putain de post

aze (./1152) :
b->g(); // a::f car b de type A*

Folco (./1180) :
Oui non mais en C++ pur, ya pas de signaux et de [slots], donc je vais dériver.

Sinon, pour palier aux manques de signaux et slots du C++, j'ai pensé à ça :
- Ma "première classe" dans l'ordre des créations instancie un objet "communication" dont tous les objets "parlants" du programme recevront un pointeur.
- Chaque objet "parlant" héritent d'une classe "Receive" qui implémente receiveMsg(int n)
- Chaque objet s'enregistre dès sa construction : Communication->register(this, MyID)
- Objet X qui parle à objet ID_truc : Communication->SendMsg(ID_truc, int x)
- Comm qui répercute à ID_truc : entry[ID_truc].ptr->receiveMsg(x)
Donc on a un cast de entry[ID_truc].ptr en "Receive", puis la méthode est appelée.

Sasume (./1185) :
Et oui, ça marcherait très bien. Tu peux même faire de ta classe Communication un singleton, ça t’évitera d’avoir à faire ta bidouille en début d’exécution.

Kevin Kofler (./1188) :

Folco (./1180) :
Oui non mais en C++ pur, ya pas de signaux et de [slots], donc je vais dériver.

Le C++ sans signaux et slots (et sans Qt en général) n'a aucun intérêt.

Et voilà, tu viens de réinventer un système de signaux et de slots (en moins bien ).

Ou tout simplement un .cpp avec des variables/fonction static pour ce qui est privé et déclarées dans le .h pour ce qui est public, comme en C. Les singletons, ça sert moyennement en C++, grâce à la compatibilité avec le procédural.

GoldenCrystal (./1191) :
Donc le C++ n'a aucun intérêt ? (Bon je suis limite d'accord sur ce point) Donc le C n'a aucun intérêt. (Soit)

GoldenCrystal (./1190) :
Alors pourquoi avoir codé Qt en C++ dans ce cas ?

Pen^2 (./1187) :
J'ai lu en diagonale, mais ceci me semble suspect :

aze (./1152) :
b->g(); // a::f car b de type A*

j'ai du revérifier deux fois

Kevin Kofler (./1192) :
Le C++ est incomplet, Qt lui rajoute tout ce qui lui manque.

aze (./1194) :

Pen^2 (./1187) :
J'ai lu en diagonale, mais ceci me semble suspect :

aze (./1152) :
b->g(); // a::f car b de type A*

non ça c'est correct par contre j'ai du revérifier deux fois
(heureusement c'est l'exemple le plus important )

aze (./1152) :
b->g(); // a::f car b de type A*