problème d'accès dans une classe dérivée!

les fonctions ou je fais le dynamic_cast sont:

pour recuperer le pointeur de type PATSection

Code:

---

1 2 3 4 5 6

PATSection* Payload::GetSectionPAT() { return dynamic_cast<PATSection*>(Section); }

---

pour recuperer le pointeur de type PMTSection

Code:

---

1 2 3 4 5 6

PMTSection* Payload::GetSectionPMT() { return dynamic_cast<PMTSection*>(Section); }

---

j'espère que j'ai bien compris cette fois...

C'est la structure du code qui appelle Payload::GetSectionPAT() qui est intéressante.

ok ok,il s'agissait de l'instruction d'accès que j'avais mis au départ du genre:
rappel:

Code:

---

1 2 3

SequenceTS[0]->payload->Section->SetSection_number(0xAA);

---

le code pour la partie principal qui va utiliser l'accès a mes methode GetPATSectio.........
n'est encore developper car je fais test du genre d'instruction que je vais devoir utiliser. Instruction du type comme ci-dessus.

Ceci pour une raison simple, c'est que je developpe d'abord la partie traitement de mon projet.
Puis par la suite, je desire avoir accès aux différentes sections, via le GUI(qui n'est pas encore developper donc), pour modifier des champs par exemple.
Donc lorsque un champs sera modifier une section données devra être accéder avec le genre d'instruction que j'ai écris la haut.
D'ailleurs rien que pour afficher il faudra également accéder au champs par ce moyen...

J'espère que c'est bon now!

Merci de ta patience

Citation:

---

Envoyé par Jean-Marc.Bourguet

Un mécanisme de double dispatch me semble toujours être ce qu'il te faut, peut-être un visiteur sur la classe qui contient les Payload.

---

Je connais ces mecansimes de double dispatch c'est quoi?? et aussi la conception orientié visiteur c'est quoi ???

Citation:

---

Envoyé par chrono23

Je connais ces mecansimes de double dispatch c'est quoi??

---

Tu connais ou pas? ;)

Le mécanisme des fonctions virtuelles permet de choisir au moment de l'appel le code qui sera exécuté en fonction du type dynamique d'un paramètre. Avec un double dispatch, on fait le choix en fonction du type de deux paramètres. Ce n'est pas disponible directement en C++ mais il y a moyen de s'en sortir avec une technique qui a été popularisée par la présentation du DP visiteur dans le bouquin de Gamma et al.

Citation:

---

et aussi la conception orientié visiteur c'est quoi ???

---

Parler de conception orientée visiteur me semble un abus de langage. Les visiteurs, c'est une technique qu'on peut utiliser en concevant quelque chose. Ce n'est pas un principe sur lequel on peut baser toute une conception.

C'est un peu long à expliquer... http://home.earthlink.net/~huston2/dp/visitor.html
ne me semble pas une mauvaise explication.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Parler de conception orientée visiteur me semble un abus de langage.

---

J'avoue qu'en me relisant ça fait un peu bizarre :lol: Mais sur le coup je ne trouvais pas de meilleurs mots :aie:
J'essaierai de poster un petit exemple demain si tu veux chrono23 ;)
C'est un design assez sympa à utiliser dans certain cas et pas très compliqué à mettre en place...

Bonne soirée à tous ;)

Bonjours à tous,

Je n'ai pas pris le temps de tout lire dans les détails. C’est pour cela que je propose juste une approche "visiteur". Je ne critique pas les approches citées ici, je ne sais même pas si cette méthode est applicable pour ton problème...
Je donne quand même très rapidement 2 ou 3 explications au cas où ça t’intéresserai ;)

Le "design pattern" dit visiteur est une technique de génie logiciel répandue qui permet de résoudre de manière élégante le problème des multi-méthodes. C'est une manière aussi de séparer un algorithme de la structure d'un objet

Concrètement, chaque classe pouvant être "visiter" met à disposition une méthode public "accepter" prenant un "visiteur" en paramètre.
La fonction "accepter" appel la fonction "visiter" du "visiteur" avec pour argument l'objet visité lui même.
Ainsi, et tout simplement, un "visiteur" connaît l'objet visité et peut appeler ses méthodes publiques pour obtenir les données nécessaires au traitement.

Un avantage pour toi : le type est donc implicitement déduis (pas besoin de "Switch" de "cast" ou autre...)
Désavantages : dépendance des hiérarchies...

Un petit exemple super simple de codage :

On a une hiérarchie de classe (acceptant des visiteurs) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

... #include "MyVisitor.h" ... class A { public : A() {}; virtual ~A() {};   virtual void accept(MyVisitor &v) { v.visit(this); };   ... };   class B : public A { public : B() {}; virtual ~B() {};   virtual void accept(MyVisitor &v) { v.visit(this); };   ... };   ...

---

On a une classe de visiteur associé à cette hiérarchie :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

... #include "A.h" #include "B.h" // On peut éviter ces includes mais je préfère simplifier l'exemple ... class MyVisitor { public : MyVisitor () {}; virtual ~MyVisitor () {};   // methodes permettant d'appliquer le pattern visiteur // il faut ajouter une methode virtuelle pour chaque nouvel objet // virtuelle pur pour forcer, par exemple, l'utilisateur à prendre en compte tous les visiteurs. virtual void visit( A * pObj ) = 0 ; virtual void visit( B * pObj ) = 0 ; ... };

---

On définit une classe pour un ou plusieurs traitements spécifiques (Générer un rapport, effectuer des calculs, etc.)

Code:

---

1 2 3 4 5 6 7 8 9 10 11

... #include "MyVisitor.h" #include "A.h" #include "B.h" // On peut éviter ces includes mais je préfère simplifier l'exemple ... class MyVisitorProcessTruc : public MyVisitor { public : // Traitements virtual void visit( A * pObj ) { ... }; // On a directement accés à l'objet souhaité. virtual void visit( B * pObj ) { ... }; };

---

Utilisation :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

int main() { ... MyVisitorProcessTruc processTruc; ... A* ptr1 = new A(); A* ptr2 = new B(); // Je prefererai mettre des scoped_ptr mais bon... simplifions ;) ... ptr1->accept(processTruc); // Accede directement au traitement processTruc pour les objets de type A ptr2->accept(processTruc); // Accede directement au traitement processTruc pour les objets de type B ... }

---

Merci de ta réponse je vois enfin ce que c'est que ces visiteurs, mais c'est pas vraiement ce qu'il me faut.

Désolé pour le temps de réponse mais je me suis focaliser sur un autre souci du projet...

En revanche je viens de tester un truc qui fonctionne bien et qui résout mon problème.

j'explique :

Ma classe mere MpegSection contient un champ TableID ce dernier permet d'identifier le type de section , PAT, PMT, CAT,....

donc l'idée est simplement de tester ce TableID puis en focntion du résultats on saura comment le pointeur de section a été modéliser. et donc qu'elle comment je vais acceder les champs specifique de chaque sections.