Discussion :

[yan]

<WRONG>a ma connaissance ca marche</WRONG>
EDIT: ha non t'as raison, alors on peut utiliser le typeid non? et puis faire un static_cast

Normalement typeid ne devrais pas marcher non plus.

hum je crois que tu n'as pas essayé de faire un model pour un tree, ai-je raison?

non, c'est ce que j'essaie de faire pour vérifier ce que je dit.

la personne à l'origine de ce post a donné sa structure de donnée au début,
et c'est un arbre. c'est facile de parcourir cet arbre, c'est facile de donner des pointers, c'est facile de recuperer les enfants du noeud puisqu'on a toujours le pointer dans le QModelIndex.

Je sais parcourir un arbre, c'est pas le problème. Mais là je suis un peu perdu. Je me suis basé sur l'exemple de Qt.

Comme tu fait pour faire ton arbre? Tu utilise QTreeWidget ou QTreeView?

[epsilon68]

QTreeView, surtout pas l'autre ... on ne peut changer son model, il n'est fait que pour garder une certaine compatibilité avec Qt3

J'ai juste remarqué un probleme, c'est qu'il faudrait connaitre le parent, mais la structure de données est une structure descendante seulement... c'est possible mais je n'ai pas d'idée geniale juste à l'instant.

[TanEk]

De ce que je vois je suis obligé de savoir quel est le type de l'objet. Donc pour cela il faut faire du polymorphisme on en revient au problème de départ. Je pense donc faire ce que j'ai proposé au début cad modifier ma structure HalfEdge et rajouter une interface Node et l'utiliser dans mon modèle d'arbre pour parcourir facilement l'arbre (c'est un peu la classe utilitaire proposée par epsilon68 mais en plus propre je pense :p).

[epsilon68]

... si tu le dis!

moi je pense qu'il faudrait le faire sans modifier ta structure, car la memoire est precieuse, et ne devrait pas etre gaspillé juste pour eviter un static cast ou autre workaround.

comme dit c'est toi qui voit ...

[TanEk]

... si tu le dis!

moi je pense qu'il faudrait le faire sans modifier ta structure, car la memoire est precieuse, et ne devrait pas etre gaspillé juste pour eviter un static cast ou autre workaround.

comme dit c'est toi qui voit ...

Pour faire ta méthode il faut à un moment faire un typeid et pour que ça marche il faut... une méthode virtuelle. Donc autant faire comme j'ai dis au lieu de faire avec un work-around vu que de toute façon on sera obligé d'avoir le polymorphisme... non ?

[yan]

QTreeView, surtout pas l'autre ... on ne peut changer son model, il n'est fait que pour garder une certaine compatibilité avec Qt3

J'ai juste remarqué un probleme, c'est qu'il faudrait connaitre le parent, mais la structure de données est une structure descendante seulement... c'est possible mais je n'ai pas d'idée geniale juste à l'instant.

Donc en faite on parle de la même chose, sauf que l'on ne prend pas les même contrainte.
Je suis partie sur l'idée de class interface par ce que :
- son arbre se parcoure que dans un sens
- un void* ne permet pas de retrouver ce qu'était l'objet
- eviter un ensemble de if else if else if ... pour choisir ce qu'il faut faire

Sinon, je suis tout à fait d'accord que tanEk ne devrais pas modifier ses structures uniquement si c'est pour l'ihm.

[epsilon68]

ok je pensais que typeid permettait de retrouver le type,
je me suis trompé

mais il ne faut pas refaire d'arbre ...

par contre c'est tres problematique l'histoire du parent... qu'il faut absolument pour le treeview

[TanEk]

La Face ne connait pas de parent car elle n'en a pas. L'half-edge connait son parent (la face), le sommet connait son parent (l'half-edge). Ou est le probleme ?

[epsilon68]

ok j'avais mal vu.

[yan]

mais il ne faut pas refaire d'arbre ...

EN faite c'est pas vraiment un arbre sa structure. Le fait de créé un arbre pour l'affichage me choque pas temps que cela du coup, mais c'est vrais que pour la mise à jour cela semble moins évident....

par contre c'est tres problematique l'histoire du parent... qu'il faut absolument pour le treeview

oui surtout qu'il faut que le parent connaisse sa position par rapport à son parent

[yan]

voilà ce que j'ai fait.
J'ai refait trois struc qui forme une sorte de graph (comme les class tanEK)et je les affiches en créant un arbre interne à l'affichage.

Cela permet de faire un affichage. Après pour ajouter les modification je ne sait pas trop. Cela ne me parait pas être si compliqué, mais effectivement y as une mise à jour à faire.

Dsl y as pas de commentaire, mais si il y as des question, aucun problème

[TanEk]

Ok merci je pense pouvoir m'en sortir maintenant .

[epsilon68]

ll y a une solution de faire heriter les triangles et les halfPlane avec une classe qui stoke le type avec un char (avec de la chance ce char sera absorbé par l'alignement) puis ensuite faire un static_cast en fonction du type.

cette class "NodeType" n'aura pas besoin de faire des methodes virtuelles,
juste offrir une class de base (pour le premier cast) pour recuperer le type:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
class NodeType
{
public:
	NodeType( int type ) : _type(type) {}
	short int type() const { return _type; }
 
private:
	char _type;
};
 
class Triangle : public NodeType {
public:
  Triangle() : NodeType(1) { ... }
};
 
class HalfPlane : public NodeType {
public:
  HalfPlane() : NodeType(2) { ... }
};

puis les static_cast

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
NodeType* n = static_cast<NodeType*> (internal_pointer);
if( p->type() == 1 ) {
  Triangle *t = static_cast<Triangle*>(n);
  // bla bla bla
}
else if( p->type() == 2 ) {
  // meme chose
}

[yan]

ll y a une solution de faire heriter les triangles et les halfPlane avec une classe qui stoke le type avec un char (avec de la chance ce char sera absorbé par l'alignement) puis ensuite faire un static_cast en fonction du type.

si ils ont une class mère commune le dynamic_cast suffira

[epsilon68]

bein non puisqu'il faut une methode virtuelle pour que cela marche....

[yan]

bein non puisqu'il faut une methode virtuelle pour que cela marche....

ben non.
Le dynamic_cast ser à caster correctement de la class mère vers une class enfant.
Les methodes virtuels c'est juste pour du polymorphisme.

[edit]
ha non tiens , j'ai dit une connerie
comme quoi on apprend des choses tous les jours

[epsilon68]

moi aussi j'en ai dit des bétises
mais tant qu'on les admet, on progresse :-)

[epsilon68]

... autant faire comme j'ai dis au lieu de faire avec un work-around vu que de toute façon on sera obligé d'avoir le polymorphisme... non ?

non pas obligé