Salut,
 
je suis en train un arbre binaire mais je ne suis pas sûr que je m'y prend bien.
 
Mon noeud le plus haut, A, contient un string et 2 pointeurs. Ces pointeurs peuvent être des A* ou des B*.
 
Pour l'instant je partais sur une union avec chaque classe qui possède un type, mais je me demande si c'est vraiment intelligent. Les 2 classes n'ont rien en rapport à part que A peut avoir un pointeur sur B donc l'héritage me parait inutile mais je peux me tromper.
 
En gros pour l'instant j'ai
 
Class A
{
public:
....
 
private:
MonType _type
union{
A* _a;
B* _b
} child1;
union{
A* _a;
B* _b
} child2;
string _toto
};
 
ca parait super lourd comme cela... surtout qu'après faudra tester le _type pour savoir sur quoi je tappe et tout mais je ne sais pas trop comment m'en sortir sinon.
 
Si ca vous parle    
 
Merci

Contenir des A ou des B : boost::variant
http://boost.org/doc/html/variant/tutorial.html

Ensuite, t'as aussi le droit de faire hériter A et B d'une même classe abstraite, de stocker des poinetrus vers cette classe mére et de te servir du polymorphisme de classe
L'héritage ici n'est PAS inutile. A et B ont quelquchose en commun : être des fils de ton arbre binaire.

Dis toi que si tu commences à devoir avoir une variable qui indique le type d'une classe, tu es sur la mauvaise voie car tu réinvente la roue

Oui je pensais à hériter d'une classe C, mais je me vois toujours obliger après de savoir sur quoi je tappe non?
Car je ne chercherai pas les mêmes données (en gros dans B j'ai les données, et dans A je chercherai B, remarque je peux mettre une fonction eval en virtuel).
 
Si tu as plus d'idées je prends
 
Merci

punaise, dynamic_cast quoi c'est la base du polymorphisme.
 
Tu herite de C, tu transtype ton C* en A* avec dynamic_cast, si le cast renvoie pas NULL, c'ets bon, sinon c'est que c'est un B*

ooh je ne connaissais pas ce truc.

c'ets quoi le smiely [/QUOTED] deja

aucune idée désolé

J'ai regardé un peu ca a l'air pas mal en effet. Faudrait que je comprenne les 4 types de cast de ce genre

Sinon mon ami Joel, une autre question stupide pour toi. Quand je parcours mon arbre je peux avoir envie de garder en mémoire le noeud parent (ou le parent du parent si le parent ne m'interesse pas). Une solution est d'avoir une variable _current dans ma classe parser que je met à jour quand ca m'interesse. Les autres solutions sont l'envoie de variable à chaque fonction qui évalue les noeuds, ou bien traiter les données au niveau parent en récupérant les infos du noeud enfant par un retour.

Donc qu'est ce qui vaut mieux?
- _current
- void evalNode(Node* iParent)
- Node* evalNode()

J'aime bien le _current, je m'en sers souvent mais je ne sais pas si c'est intelligent. Le retour de donnée me fait probablement faire plus de travail mais à vérifier.

Il est de bon ton de découpler SDD et algo de parcours.
Je t'invite à te renseigner sur le Design Pattern 'Visitor'

J'ai regardé un peu mais je ne comprend pas le principe.
J'ai lu le lien http://en.wikipedia.org/wiki/Visitor_pattern
 
Le truc c'est que je ne vois pas à quoi servent les fonctions accept et visit.
En effet, le visiteur est envoyé à la donnée qui appelle le visiteur. Pourquoi le visiteur ne travaille pas sur la donnée directement? Je ne vois pas l'intéret (qui doit exister quelque part).
 
 
Merci

Ca permet de découpler les données des algo qui travaillent dessus.
Et découpler c'est comme s'accoupler, c'est que du bon
 

 
A méditer

Euh oui mais je ne comprend toujours pas  
 
Je veux dire je vois ce scénario:
- maclasse.accept(monvisiteur)
- monvisteur.visit(&this)
 
Je ne vois pas l'interet face à
monvisiteur.visit(&maclasse)

En fait, il faut voir le Visiteur comme un foncteur que tu applique sur une classe. Semantiquement ca veut dire que tu créer une instance de ton visiteur que tu passe à ta classe Visitable. EN gros tu emules du Double Dsipatching, et ca, conceptuellement c'est gros.

Autre truc : comment veut tu que visitor sache comment visité des visitable composites ? Soit tu delegue au visité (classe) soit tu doit faire X version du visiteur (pas classe)

Pas compris la remarque là

regarde l'exempel avec la voiture composé de roue etc et essaye d'ecrire un visiteur avec ton interface qui reste générique

ok je tenterai cela toute à l'heure
J'imagine que je posterai ma réponse pendant que tu dormiras par contre

Bon je n'ai pas encore eu le temps de regarder cela.
Par contre pas de dynamic_cast sur un smartPointer ca fait mal

bah faut utiliser un smart_ptr qui va bien

mouem.
 
Sinon la difference de dynamic entre pointer et réference spa drôle je trouve

Salut !
 
je vais ptêtre dire une connerie, mais il y a les boost::dynamic_pointer_cast pour faire des cast sur les smart pointer. Mais par contre il faut utiliser les smart pointer de boost...

ce qui est pas une mauvaise idée en soi
Merci pr le reminder

oui j'utilise les smart pointers de boost, et j'ai regardé vite fait le dynamic_pointer_cast ca avait l'air ok.
 
En fait un truc pas drôle avec les smart pointers boost c'est le cote ".get()->" ca ralourdit le code d'une force je trouve En fait il nous faudrait des smart references

sauf que par définition une référence est forcement smart

Aaah et comment je fais pour associer un objet dynamique à une référence?
 
bon je peux faire
Object& ref = *ptr;
 
mais bon c'est laid non?

sinon j'ai un vecteur de smart pointers là.
Pour remplacer un élément je peux simplement utiliser le []? ca détruira tout de même le smart pointer et son objet?

 
oui, surtout que une référence se comporte comme un pointeur vis à vis du polymorphisme
 
Fille f;
Mere& m = f;
 
marche farpaitement

Oh je ne savais pas pour le polymorphisme c'est pratique. Mais en fait je parle dans le cas suivant :

A* a = new A();

Je ne peux pas utiliser un B& en tant que "smart reference" (ie que l'objet meurt en même temps que la dernière référence) non?

apres c'est à voir. J'ai pas les ref sous la main mais y avait un bon papier de Sutter sur les object lifetime qui resumait les bonnes pratiques