Discussion :

[Michel_57]

salut à tous.

j'ai un problème conceptuel, je vous explique ce que je veux faire :

J'ai une classe P (qui contient diverses variables)

Ensuite je définis des classes A B et C dérivées de P dans lesquelles j'ai :

static const int IdType=1 dans A
static const int IdType=2 dans B
static const int IdType=3 dans C

je crée des instances de A B et C que je place dans un tableau de P*
ceci est possible car mes instances de A B et C sont dérivées de P. j'utilise cette technique pour mettre des instances de classes différentes dans une même structure. je trouvais ça astucieux mais je rencontre un problème par la suite, quand j'accès à mon tableau de P*, je ne parviens pas à récupérer la valeur de IdType pour savoir de quelle classe est l'élément. en effet mon élément est vu en tant que P (qui n'a pas d'attribut IdType).

Ma question est donc : comment récupérer mes éléments du tableau sous leur vrai type ?

je ne sais pas si j'ai été clair dans mes explications, j'espère que vous pourrez m'aider, merci :

[zais_ethael]

Hum, déclarer IdType dans P? Et pas en static tant qu'on y est...

[Michel_57]

Tout d'abord, merci pour ta réponse. Oui sans le static ça marcherait, mais dans mon cas je dois le laisser. Explication :

Mon programme fera des milliers d'instanciations de A B et C, des constructions et destructions à tout bout de champ, un truc qui mouline beaucoup, et je dois économiser au maximum :
- l'espace dans la ram
- la rapidité

Si j'enlève static, IdType sera recréé à chaque construction et détruit à chaque destruction, ça ralentit le programme ET prend davantage de mémoire.

Voilà le static est indispensable dans mon cas. Il doit bien y avoir un moyen de m'en sortir pour créer 3 variables plutôt que des centaines de milliers (je n'exagère pas du tout).

[bountykiler]

Une autre solution consiterait à utiliser une fonction getType qui permettrai de récuperer la valaur correspondant au type. Le problème, c'est que pour que cela marche, il faudrait que cette fonction soit virtuelle, ce qui est susceptible de poser problème en ce qui concerne la vitesse d'exécution de ton code.

La seule autre solution que je vois, c'est d'utiliser l'operateur typeid.

[kacedda]

Le problème, c'est que pour que cela marche, il faudrait que cette fonction soit virtuelle, ce qui est susceptible de poser problème en ce qui concerne la vitesse d'exécution de ton code.

Excusez moi de vous demander pardon, mais juste en passant. Ca ralentit enormement le code? je ne comprend pas pourquoi ca doit ralentir l'execution?
Ca prend quoi de plus? un test + un appel?
En fait c'est juste que j'en utilise et je voudrais savoir si ca ralentit beaucoup ou pas, genre si y a un ratio?
Merci

[buzzkaido]

Pour ce que j'en sais, pour les fonctions virtuelles, ça marche comme ça :

- pour chaque classe définissant des fonctions virtuelles, une "VTable" contenant les adresses des implémentations propre à cette classe des fonctions virtuelles est crée

- si une classe hérite d'une autre, elle hérite aussi de sa VTable au cas où des fonctions ne seraient pas re-définie dans la classe fille

- lors de la création d'un objet, l'adresse de sa VTable est stockée avec lui

Ainsi, lors de l'appel à une fonction virtuelle, le programme va lire l'adresse de la bonne implémentation à utiliser dans la VTable de l'objet et l'appeller.

Tout ça, c'est des mécanismes qui dépendent du compilateur, mais je pense que l'esprit général est là.

Du coup, à chaque appel de fonction virtuelle, tu as :
- un déréferencement pour lire la VTable
- un déréferencement pour executer la bonne fonction pointée par la VTable

Ce qui peut être relativement lourd : par exemple, si tu appelle une fonction virtuelle qui ne fait que une addition, le temps de retrouver son adresse peut etre supérieur au temps d'execution de l'addition, ce qui est un peu dommage.


Merci de me corriger si je me trompe...

[koala01]

Salut,

Early optimisation is the root of all evil

Je suis d'accord qu'il peut sembler important de gagner du temps et de l'espace mémoire partout où c'est possible, mais, quand même...

Une énumération ne prend "que" la place d'un int, et, au pire, il y aurait même moyen de s'organiser pour faire tenir trois valeurs dans un char...

Je suis d'accord que, pour plusieurs (centaines de) millier, cela *peut* finir par faire beaucoup, mais, selon moi, il y a surement bien d'autres endroits où les optimisations peuvent être bien plus nécessaires

Dés lors, pourquoi ne pas "tout simplement" envisager de mettre un membre du type enum protégé dans l'interface

[Michel_57]

Une énumération ne prend "que" la place d'un int, et, au pire, il y aurait même moyen de s'organiser pour faire tenir trois valeurs dans un char...

oui, bon, j'ai juste mis IdType pour expliquer le problème. mais il n'y a pas que ça, il y a plein de valeurs et même un tableau de vecteurs, je ne peux pas me permettre de les recopier dans chaque instance.

je vais me documenter sur les fonctions virtuelles comme me l'a suggéré bountykiller. si ça ralentit juste un peu ce sera quand même mieux que de recopier autant de variables inutilement

[koala01]

Mais, de deux choses l'une:

• Soit, les différentes valeurs (ou tableau de valeurs) sont uniques pour chaque instance de ta classe, et, à ce moment là, tu n'auras pas le choix: il faudra que ces différentes valeurs apparaissent dans ta classe,
• Soit ces différentes valeurs (ou tableau de valeurs) sont gérés de manière externe à ta classe, et à ce moment là, il y a sans doute intérêt à envisager une autre classe qui les gérera (quitte à en transmettre l'instance dans les différentes méthodes )

La question à se poser est donc "Ma classe peut-elle se contenter d'obtenir les valeurs en cas de besoin, ou faut il qu'elle en dispose de manière "inconditionnelle" "