C++ question de débutant ^^ - Page 4

En java il n'y a pas de mot-clé virtual
Mais le fait de mettre virtual devant une fonction membre d'une classe produit le même comportement qu'en java

Sasume :
En java il n'y a pas de mot-clé virtual
Mais le fait de mettre virtual devant une fonction membre d'une classe produit le même comportement qu'en java

oui, mais y a la même idée, non ? (ça fait plus de 2 ans que j'ai pas touché à du java, faut pas trop m'en demander )

Oui

Par contre attention avec l'utilisation de l'héritage. Cette relation représente la relation "ceci *est un* cela".
class A hérite de class B signifie "A est un B"
Dans ton exemple, tu dis "approx est un scheduler".

Si ce n'est pas cette relation que tu représentes, tu ne dois pas utiliser l'héritage. Par exemple si tu voulais dire "approx utilise un scheduler" tu peux lui mettre un scheduler en tant que membre.
Si tu voulais dire "approx est une tâche ordonnançable", alors il te faut 3 classes : une classe Schedulable, une classe approx qui dérive de Schedulable ("approx est un schedulable") et la classe scheduler.

nan, t'inquiète pas, c'est bien la bonne relation (vu qu'approx est une approximation d'ordonnanceur et scheduler une classe pour offrir un certain nombre de fonctions utiles)

Zephyr :
Bah la fonction ne peut pas retourner 0 si elle est templatée par un type non pointeur et non initialisable avec un entier, comme le compilo peut décider à la compilation si il accepte ou non un "templatage", il peut très bien déterminer laquelle choisir entre deux implémentations; je n'ai pas la réponse mais ça ne me semble pas tellement différent de n'importe quelle spécialisation de template ?

(accessoirement on m'a demandé de le faire, donc je pense que c'est faisable ^^)

T'as fait comment finalement ?

j'ai tjrs pas fait
(c'est plus moi qui m'occupe du projet où y'avait besoin de ça ^^)

Je recycle ce sujet discrètement:
En c++, quand on a des classes Orange et Violet qui hérite de Couleur, est-ce que quand on fait:
Couleur *couleur = new Orange();
il y a moyen de savoir de quelle classe couleur est une instance, sans passer par une variable initialisée dans les constructeurs de Orange et Violet?

C'est le RTTI de C++.
Utilise la fonction: typeid(*couleur).name() pour avoir la sortie en nom (C++ decore) sinon, tu peux tester avec les typeid(*couleur) == typeif(monObjectOrange)

Parfait .

(tu n'es pas obligé de créer un objet orange bidon juste pour ça, tu peux aussi faire typeid(*couleur) == typeid(Orange) ^^)

malheureusement vérifier l'égalité rigoureuse des typeid t'empêche de faire dériver une classe OrangeFluo en lui faisant hériter de toutes les propriétés de Orange (puisque typeid(OrangeFluo)!=typeid(Orange)) donc ça va vraiment à l'encontre de la philosophie OO ^^ en fait si tu veux que ça marche même pour une classe dérivée de Orange il vaut mieux regarder si dynamic_cast<Orange*>(couleur)!=NULL...

cela dit, je ne sais pas exactement pourquoi tu fais ça, mais il y a de fortes chances que ça soit plus propre de passer par, par exemple, une méthode virtuelle style est_orange() ou même une fonction couleur() qui renvoie un membre d'une enum qui décrit toutes tes couleurs (non seulement ça sera plus propre, mais ça sera aussi plus performant si tu as plusieurs couleurs)

Généralement, pour des couleurs statiques, on utilise plutôt soit une enum, soit des objets statiques (comme en java ou en .Net).
Ensuite, une comparaison avec sémantique de valeur ou d'identité fait le reste. Pour des couleurs, je pendrais une sémantique de valeur (d'autant que pour la sémantique d'identité, il faut faire gaffe si on joue avec des DLL)

Heu en quoi c'est plus propre d'avoir un flag qui simule ton RTTI plutot que de le faire en utilisant type_info ?

Bah parce que le RTTI, c'est moche et ça va à l'encontre de la conception objet. Les alternatives de Pollux sont des conceptions relativement plus propres.

Pollux :
cela dit, je ne sais pas exactement pourquoi tu fais ça

Je voulais faire ça parceque c'était la méthode qui demandait d'écrire le moins de code
Cependant, vu que "ça va à l'encontre de la philosophie OO", je vais pas le faire (dans ce projet là en tout cas)

Link :
Généralement, pour des couleurs statiques, on utilise plutôt soit une enum, soit des objets statiques (comme en java ou en .Net).

Les classes Orange et Violet, c'était juste des exemples.

Sasume :
Bah parce que le RTTI, c'est moche et ça va à l'encontre de la conception objet. Les alternatives de Pollux sont des conceptions relativement plus propres.

Certes, mais c'est exactement la meme chose dans les faits.
Autant utiliser un outil de C++.
Ca me rappelle des debats avec des profs sur le mot cle friend. C'est crade, ca viole... bouh
Mais enfiat, ca fait parti des concepts de C++, stoo. Meme si c'est pas bien pour de l'objet...

Jyaif
:

Pollux :
cela dit, je ne sais pas exactement pourquoi tu fais ça

Je voulais faire ça parceque c'était la méthode qui demandait d'écrire le moins de code

Je voulais dire "pour implémenter quoi dans ton code"

nEUrOO
:

Sasume :
Bah parce que le RTTI, c'est moche et ça va à l'encontre de la conception objet. Les alternatives de Pollux sont des conceptions relativement plus propres.

Certes, mais c'est exactement la meme chose dans les faits.
Autant utiliser un outil de C++.

Ben non, comme je l'ai dit c'est pas du tout la même chose. Si tu veux faire dériver OrangeFluo de Orange, alors ton code qui détectait la classe Orange ne pourra pas détecter OrangeFluo comme un orange... Alors que moralement si tu fais une classe dérivée sans rien redéfinir de nouveau, les objets devraient se comporter exactement pareil que ceux de la classe de base ^^

Ensuite même si tu passes par des dynamic_cast<> pour éviter ces problèmes de dérivation, tu perds qd même en flexibilité par rapport à une fonction virtuelle, parce que la fonction virtuelle peut être redéfinie comme tu veux dans la classe dérivée, alors qu'avec les dynamic_cast<> les classes dérivées d'Orange se comporteront toujours comme Orange lui-même même quand c'est pas ce que tu veux... (enfin ça pour le coup ça dépend des cas, ça peut quand même être plus simple de passer par un dynamic_cast<> dans certain cas)

Oui, sans compter que l'activation des RTTI à la compilation ralentit fortement la manipulation des objets, et augmente de manière significative l'utilisation de la mémoire.

Pollux
:

Jyaif
:

Pollux :
cela dit, je ne sais pas exactement pourquoi tu fais ça

Je voulais faire ça parceque c'était la méthode qui demandait d'écrire le moins de code

Je voulais dire "pour implémenter quoi dans ton code"

J'ai une classe Object. J'ai plusieurs classes qui en héritent comme "MovingObject", "StillObject". J'ai une array "Object *objectList[1000]" contenant des pointeurs vers des MovingObject, StillObject et autre. Je veux parcourir l'array et exécuter une méthode propre aux MovingObject.

spectras :
Oui, sans compter que l'activation des RTTI à la compilation ralentit fortement la manipulation des objets

c'est pas exactement comme une méthode virtuelle supplémentaire ? (donc oui ça prend un peu de place pour chaque classe, mais je vois pas de raison pour que ça ralentisse si on s'en sert pas)


Jyaif> ben dans ce cas-là c'est probablement plus propre d'utiliser une méthode virtuelle is_moving() ^^

Si on s'en sert pas ça fait comme s'il était pas activé, ...enfin en théorie. En pratique, si la plupart des compilateurs permettent de le désactiver tout de même c'est pas par hasard. Sans compter que avec la compilation séparée tu peux avoir de gros problèmes si certaines parties du programmes l'utilisent et d'autres pas.

Après, non c'est pas comme une méthode virtuelle supplémentaire. Regarde la traduction d'un dynamic_cast, c'est une horreur (c'est encore plus joli si tu l'utilises dans des templates).
Surtout sur les plateformes MS, où le dynamic_cast fait une comparaison des noms de classe et non pas des IDs (à cause de la possibilité d'avoir une classe chargée dynamiquement depuis une dll).

Si c'est possible, il vaut mieux avoir ta propre fonction virtuelle indiquant le type. Ou implémenter un pattern Visitor. Et réserver le dynamic_cast aux cas où ce n'est pas possible (son principal avantage étant d'être non intrusif, ce qui est utile quand tu ne peux pas toucher au source de l'arbo des classes).

oui on est bien d'accord, mais ça ne justifie pas ton "l'activation des RTTI à la compilation ralentit fortement la manipulation des objets" : en quoi un bout de code qui n'utilise pas typeid & co serait "fortement plus lent" quand les RTTI sont "activés à la compilation" que quand ils sont désactivés ?

Pas la moindre idée. Je verrais bien ptet un tout petit peu d'overhead lors de l'instanciation et de la destruction des objets, mais rien qui justifie une vraie baisse de vitesse. Et pourtant, c'est quelque chose que j'ai constaté à plusieurs reprises quand je jouais avec (VC++6 sous win98...l'époque avant que je découvre la vérité...que de souvenirs )

ah oui mais VC++6 et le C++, ça fait deux :/

pas le C++, la STL et ce qui va directemetn avec...

Autre problème qui n'a rien à voir:
J'ai une classe Object qui contient (entre autre) une méthode virtuelle "virtual void draw(void)" et les variables "float x", "float y".
Beaucoup de classes héritant de Object implémentent de la même manière la méthode "draw"... mais pas toute.

exemple:

MovingObject1 implémente draw exactement de la même manière que StillObject1.
MovingObject2 et StillObject2 implémentent draw d'une manière complètement différente.

Je pensais faire une classe DrawStandart qui ne ferait qu'implémenter draw, et du coup j'aurais juste à faire hériter MovingObject1 et StillObject1 de DrawStandart.
Le problème (?), c'est que la méthode draw de DrawStandart dépend de x et y, des variables qui sont contenues dans Object.
Excusez moi, je n'ai jamais fais hériter une classe de plusieurs classes, le problème est peut être tout simple.

Je pensais faire une classe DrawStandart qui ne ferait qu'implémenter draw, et du coup j'aurais juste à faire hériter MovingObject1 et StillObject1 de DrawStandart.

Ce serait une grave erreur de conception. L'héritage représente la relation X est un Y. Il ne sert pas à faire de la réutilisation de code.

Je pense que c'est le nom de ma classe qui est mal choisix; Si je renomme "DrawStandart" en "ObjectSimpleAAfficher", ça donne:
"MovingObject1" est un "MovingObject" et un "ObjectSimpleAAfficher"

Ben pourquoi MovingObject1 ne serait pas un DrawStandard ? je ne dis pas que c'est forcément la bonne solution, mais c'est pas absurde, si un DrawStandard est un objet qu'on doit dessiner de telle façon, et qu'un MovingObject1 est un objet (mobile) qu'on doit dessiner de cette façon, alors MovingObject1 est un DrawStandard...

Jyaif > ben il suffit que DrawStandard hérite de Object non ? edit : d'ailleurs ça semble encore plus évident si tu appelles la classe ObjetSimpleAAfficher ^^. Tu fais juste une classe qui hérite et qui implémente ta méthode abstraite...

sinon évidemment tu peux aussi faire une fonction plutôt qu'une classe (enfin je dis évidemment, je connais pas le C++, mais bon je pense qu'on peut ^^)

edit : cross

spectras :
Ce serait une grave erreur de conception. L'héritage représente la relation X est un Y. Il ne sert pas à faire de la réutilisation de code.

Par contre, il peut utiliser DrawStandart comme un foncteur...