Bonjour,
Soit un objet A avec une fonction membre fcta
Soit B derivant de A avec une fonction fctb, de meme signature que fcta
Par exemple :
class A { public: void fcta(int); }
class B : public A { public: void fctb(int); }
Pour declarer un pointeur sur fonction membre :
typedef void(A::*pfa_t)(int);
typedef void(B::*pfb_t)(int);
pfa_t pfa = &A::fcta;
pfa_t pfb = &B::fctb;
Si j'instancie un A : A *pa = new A;
Et que je veuille appeler fcta : (pa->*pfa)(1);
Maintenant, mes problemes.
-Comment faire pour stocker dans un même conteneur des pfa_t et des pfb_t ?
En fait, il s'agit d'un conteneur associant un A* à un pfx_t (un map par exemple).
Donc pour chaque élement, je *sais* si le pf se rapporte a un A ou a un B.
(evidement, je ne cherche pas a appeler fctb sur un A !)
Pour l'instant, je triche en castant par reinterpret_cast les pfb en pfa_t. Ca marche...
Mais y a t il mieux ?
-dans le cas suivant : A*pb = new B;
Je recupere pfb via mon tableau associatif (en fait un pfb casté en pfa_t)
Comment appeler pfb ? Je ne peux pas caster pb en B* car je n'ai pas acces a ce moment au
type B.
(et un include est hors de question)
En trichant en castant pfb en un pfa_t via reinterpret_cast, ca marche parfaitement, mais
ya t il un risque ?
(autre qu'appeler pfb sur un vrai A, ce qui ne devrait pas arriver vu la facon dont je
construit le map)
Ben, tu vois bien qu'elles n'ont pas la même signature.
Ca je le sais qu'elles n'ont *pas* au sens stricte la même sitgnature ! :-) (tu pinailleras en me disant que seul le sens stricte compte... je le sais...) Ce que je voulais dire, c'est que : elles ont le même objet de retour, les mêmes arguments, et B hérite publiquement de A. Elles sont donc en rapport. Mais je concede que le terme signature etait usurpé.
-Comment faire pour stocker dans un même conteneur des pfa_t et des pfb_t ?
On ne le fait pas. En fait, tu essaies de faire un sale bricolage, rendu totalement inutile par le système des fonctions virtuelles.
Disons plutot que je me retrouve a jouer les bricolos au bout de 24h de jeu avec les templates, les virtuals, a relire Meyers et Alexandrescu ("Attention, l'abus de c++ nuit gravement à la santé") Tu l'auras compris, ce pb est en lien direct avec mon post precedent (Hierarchie de message et de target). J'acheve juste de chercher une solution. Merci de m'aider ;-) J'espère juste avoir survolé qlq chose dans mes bouquins, et qu'une ame charitable mettra le doigt dessus.
Fabien LE LEZ wrote:
On Sun, 02 Nov 2003 22:31:11 GMT, "amerio" <amerio@hotmail.com> wrote:
Bonjour,
Soit un objet A avec une fonction membre fcta
[...]
Le code suivant répondra sans doute à quelques-unes de tes questions :
[...]
Oui, ce code me montre ce que je savais deja. La difference entre virtuel et non...
Soit B derivant de A avec une fonction fctb, de meme signature que fcta
Ben, tu vois bien qu'elles n'ont pas la même signature.
Ca je le sais qu'elles n'ont *pas* au sens stricte la même sitgnature ! :-)
(tu pinailleras en me disant que seul le sens stricte compte... je le sais...)
Ce que je voulais dire, c'est que : elles ont le même objet de retour, les mêmes
arguments, et B hérite publiquement de A.
Elles sont donc en rapport. Mais je concede que le terme signature etait usurpé.
-Comment faire pour stocker dans un même conteneur des pfa_t et des pfb_t ?
On ne le fait pas.
En fait, tu essaies de faire un sale bricolage, rendu totalement
inutile par le système des fonctions virtuelles.
Disons plutot que je me retrouve a jouer les bricolos au bout de 24h de jeu avec les
templates, les virtuals, a relire Meyers et Alexandrescu ("Attention, l'abus de c++ nuit
gravement à la santé")
Tu l'auras compris, ce pb est en lien direct avec mon post precedent (Hierarchie de
message et de target).
J'acheve juste de chercher une solution.
Merci de m'aider ;-)
J'espère juste avoir survolé qlq chose dans mes bouquins, et qu'une ame charitable mettra
le doigt dessus.
Ben, tu vois bien qu'elles n'ont pas la même signature.
Ca je le sais qu'elles n'ont *pas* au sens stricte la même sitgnature ! :-) (tu pinailleras en me disant que seul le sens stricte compte... je le sais...) Ce que je voulais dire, c'est que : elles ont le même objet de retour, les mêmes arguments, et B hérite publiquement de A. Elles sont donc en rapport. Mais je concede que le terme signature etait usurpé.
-Comment faire pour stocker dans un même conteneur des pfa_t et des pfb_t ?
On ne le fait pas. En fait, tu essaies de faire un sale bricolage, rendu totalement inutile par le système des fonctions virtuelles.
Disons plutot que je me retrouve a jouer les bricolos au bout de 24h de jeu avec les templates, les virtuals, a relire Meyers et Alexandrescu ("Attention, l'abus de c++ nuit gravement à la santé") Tu l'auras compris, ce pb est en lien direct avec mon post precedent (Hierarchie de message et de target). J'acheve juste de chercher une solution. Merci de m'aider ;-) J'espère juste avoir survolé qlq chose dans mes bouquins, et qu'une ame charitable mettra le doigt dessus.
Fabien LE LEZ
On Mon, 03 Nov 2003 07:30:22 GMT, "amerio" wrote:
Oui, ce code me montre ce que je savais deja. La difference entre virtuel et non...
Disons que ce que tu essaies de faire est tellement compliqué à bricoler soi-même et tellement proche des capacités des fonctions virtuelles que j'ai cru que tu ne connaissais pas ce mécanisme.
Ce que je voulais dire, c'est que : elles ont le même objet de retour, les mêmes arguments,
Non : une fonction membre a une argument caché, qui est un pointeur (éventuellement const) vers l'objet (en gros, "this"). Donc elles ont deux signatures aussi différentes que
void fA (A*, int); et void fB (B*, int);
Je crois que faire croire au compilo que fB a le même prototype que fA peut marcher en pratique, car un B* a la même taille, et est convertible en, un A*, mais je ne me hasarderais pas à le faire, ni même à essayer de prévoir ce que ça peut donner avec un compilo donné.
-- ;-)
On Mon, 03 Nov 2003 07:30:22 GMT, "amerio" <amerio@hotmail.com> wrote:
Oui, ce code me montre ce que je savais deja. La difference entre virtuel et non...
Disons que ce que tu essaies de faire est tellement compliqué à
bricoler soi-même et tellement proche des capacités des fonctions
virtuelles que j'ai cru que tu ne connaissais pas ce mécanisme.
Ce que je voulais dire, c'est que : elles ont le même objet de retour, les mêmes
arguments,
Non : une fonction membre a une argument caché, qui est un pointeur
(éventuellement const) vers l'objet (en gros, "this"). Donc elles ont
deux signatures aussi différentes que
void fA (A*, int);
et
void fB (B*, int);
Je crois que faire croire au compilo que fB a le même prototype que fA
peut marcher en pratique, car un B* a la même taille, et est
convertible en, un A*, mais je ne me hasarderais pas à le faire, ni
même à essayer de prévoir ce que ça peut donner avec un compilo donné.
Oui, ce code me montre ce que je savais deja. La difference entre virtuel et non...
Disons que ce que tu essaies de faire est tellement compliqué à bricoler soi-même et tellement proche des capacités des fonctions virtuelles que j'ai cru que tu ne connaissais pas ce mécanisme.
Ce que je voulais dire, c'est que : elles ont le même objet de retour, les mêmes arguments,
Non : une fonction membre a une argument caché, qui est un pointeur (éventuellement const) vers l'objet (en gros, "this"). Donc elles ont deux signatures aussi différentes que
void fA (A*, int); et void fB (B*, int);
Je crois que faire croire au compilo que fB a le même prototype que fA peut marcher en pratique, car un B* a la même taille, et est convertible en, un A*, mais je ne me hasarderais pas à le faire, ni même à essayer de prévoir ce que ça peut donner avec un compilo donné.
-- ;-)
amerio
Disons que ce que tu essaies de faire est tellement compliqué à bricoler soi-même et tellement proche des capacités des fonctions virtuelles que j'ai cru que tu ne connaissais pas ce mécanisme.
Hem... D'un autre coté, Meyer en parle comme d'une vtable "à la mano" (au passage, si je peux lire Meyer dans le texte, et le comprendre, je pense que ca veut dire que je sais un minimum de chose en c++. Que je l'applique mal, ptet..., ou que je veux tordre les régles à mon avantage ;-> )
Ce que je voulais dire, c'est que : elles ont le même objet de retour, les mêmes arguments,
Non : une fonction membre a une argument caché, qui est un pointeur (éventuellement const) vers l'objet (en gros, "this"). Donc elles ont deux signatures aussi différentes que
void fA (A*, int); et void fB (B*, int);
Oui, ca aussi, je sais.... ;-) ("non, je sais pas tout !") Rhaaa, et dire que j'ai mis "même sig" en me disant que au moins tt le monde comprendrait (que je simplifiais à outrance)
Je crois que faire croire au compilo que fB a le même prototype que fA peut marcher en pratique, car un B* a la même taille, et est convertible en, un A*, mais je ne me hasarderais pas à le faire, ni même à essayer de prévoir ce que ça peut donner avec un compilo donné.
Ben en fait, ca marche (testé sur vs6, vc7.1, gcc v3.??, cw v??) Mais comme ce n'est pas parceque ca marche *dans qlq cas* que ca marche *tj*, je voulais qu'on me montre des risques (je sais deja qu'avec de l'heritage virtuel ou avec plusieurs racines, ca posera pb, mais je n'aurais jamais ces deux cas) A defaut, je veux bien aussi qu'on me dise : "tu joues a bricolo-bricolette font du code", mais alors, qu'on me montre comment faire proprement... (voir mon autre post : ne pas oublier qu'en fait là je sais que je tord les règles pour resoudre un autre pb !) Voilà.... Merci de tes efforts !
Disons que ce que tu essaies de faire est tellement compliqué à
bricoler soi-même et tellement proche des capacités des fonctions
virtuelles que j'ai cru que tu ne connaissais pas ce mécanisme.
Hem... D'un autre coté, Meyer en parle comme d'une vtable "à la mano"
(au passage, si je peux lire Meyer dans le texte, et le comprendre, je pense que ca veut
dire que je sais un minimum de chose en c++. Que je l'applique mal, ptet..., ou que je
veux tordre les régles à mon avantage ;-> )
Ce que je voulais dire, c'est que : elles ont le même objet de retour, les
mêmes arguments,
Non : une fonction membre a une argument caché, qui est un pointeur
(éventuellement const) vers l'objet (en gros, "this"). Donc elles ont
deux signatures aussi différentes que
void fA (A*, int);
et
void fB (B*, int);
Oui, ca aussi, je sais.... ;-) ("non, je sais pas tout !")
Rhaaa, et dire que j'ai mis "même sig" en me disant que au moins tt le monde comprendrait
(que je simplifiais à outrance)
Je crois que faire croire au compilo que fB a le même prototype que fA
peut marcher en pratique, car un B* a la même taille, et est
convertible en, un A*, mais je ne me hasarderais pas à le faire, ni
même à essayer de prévoir ce que ça peut donner avec un compilo donné.
Ben en fait, ca marche (testé sur vs6, vc7.1, gcc v3.??, cw v??)
Mais comme ce n'est pas parceque ca marche *dans qlq cas* que ca marche *tj*, je voulais
qu'on me montre des risques
(je sais deja qu'avec de l'heritage virtuel ou avec plusieurs racines, ca posera pb, mais
je n'aurais jamais ces deux cas)
A defaut, je veux bien aussi qu'on me dise : "tu joues a bricolo-bricolette font du code",
mais alors, qu'on me montre comment faire proprement... (voir mon autre post : ne pas
oublier qu'en fait là je sais que je tord les règles pour resoudre un autre pb !)
Voilà.... Merci de tes efforts !
Disons que ce que tu essaies de faire est tellement compliqué à bricoler soi-même et tellement proche des capacités des fonctions virtuelles que j'ai cru que tu ne connaissais pas ce mécanisme.
Hem... D'un autre coté, Meyer en parle comme d'une vtable "à la mano" (au passage, si je peux lire Meyer dans le texte, et le comprendre, je pense que ca veut dire que je sais un minimum de chose en c++. Que je l'applique mal, ptet..., ou que je veux tordre les régles à mon avantage ;-> )
Ce que je voulais dire, c'est que : elles ont le même objet de retour, les mêmes arguments,
Non : une fonction membre a une argument caché, qui est un pointeur (éventuellement const) vers l'objet (en gros, "this"). Donc elles ont deux signatures aussi différentes que
void fA (A*, int); et void fB (B*, int);
Oui, ca aussi, je sais.... ;-) ("non, je sais pas tout !") Rhaaa, et dire que j'ai mis "même sig" en me disant que au moins tt le monde comprendrait (que je simplifiais à outrance)
Je crois que faire croire au compilo que fB a le même prototype que fA peut marcher en pratique, car un B* a la même taille, et est convertible en, un A*, mais je ne me hasarderais pas à le faire, ni même à essayer de prévoir ce que ça peut donner avec un compilo donné.
Ben en fait, ca marche (testé sur vs6, vc7.1, gcc v3.??, cw v??) Mais comme ce n'est pas parceque ca marche *dans qlq cas* que ca marche *tj*, je voulais qu'on me montre des risques (je sais deja qu'avec de l'heritage virtuel ou avec plusieurs racines, ca posera pb, mais je n'aurais jamais ces deux cas) A defaut, je veux bien aussi qu'on me dise : "tu joues a bricolo-bricolette font du code", mais alors, qu'on me montre comment faire proprement... (voir mon autre post : ne pas oublier qu'en fait là je sais que je tord les règles pour resoudre un autre pb !) Voilà.... Merci de tes efforts !
Fabien LE LEZ
On Sun, 02 Nov 2003 22:31:11 GMT, "amerio" wrote:
Si j'instancie un A : A *pa = new A; Et que je veuille appeler fcta : (pa->*pfa)(1);
Maintenant, mes problemes. -Comment faire pour stocker dans un même conteneur des pfa_t et des pfb_t ?
Tu peux pas remplacer tes pointeurs de fonctions par des foncteurs ? Du style :
Et tu peux alors créer un tableau de "BaseFoncteur*" sans problème.
-- ;-)
Christophe Lephay
amerio wrote:
Disons que ce que tu essaies de faire est tellement compliqué à bricoler soi-même et tellement proche des capacités des fonctions virtuelles que j'ai cru que tu ne connaissais pas ce mécanisme.
Hem... D'un autre coté, Meyer en parle comme d'une vtable "à la mano" (au passage, si je peux lire Meyer dans le texte, et le comprendre, je pense que ca veut dire que je sais un minimum de chose en c++. Que je l'applique mal, ptet..., ou que je veux tordre les régles à mon avantage ;-> )
D'un autre coté, je me souviens encore des déclarations style DECLARE_RESPONSE_TABLE dans l'ancien framework de borland ! Le problème ne me semble pas seulement trouver une solution qui marche, mais aussi qui soit pas trop lourde à utiliser :)
Chris
amerio wrote:
Disons que ce que tu essaies de faire est tellement compliqué à
bricoler soi-même et tellement proche des capacités des fonctions
virtuelles que j'ai cru que tu ne connaissais pas ce mécanisme.
Hem... D'un autre coté, Meyer en parle comme d'une vtable "à la mano"
(au passage, si je peux lire Meyer dans le texte, et le comprendre,
je pense que ca veut dire que je sais un minimum de chose en c++. Que
je l'applique mal, ptet..., ou que je veux tordre les régles à mon
avantage ;-> )
D'un autre coté, je me souviens encore des déclarations style
DECLARE_RESPONSE_TABLE dans l'ancien framework de borland ! Le problème ne
me semble pas seulement trouver une solution qui marche, mais aussi qui soit
pas trop lourde à utiliser :)
Disons que ce que tu essaies de faire est tellement compliqué à bricoler soi-même et tellement proche des capacités des fonctions virtuelles que j'ai cru que tu ne connaissais pas ce mécanisme.
Hem... D'un autre coté, Meyer en parle comme d'une vtable "à la mano" (au passage, si je peux lire Meyer dans le texte, et le comprendre, je pense que ca veut dire que je sais un minimum de chose en c++. Que je l'applique mal, ptet..., ou que je veux tordre les régles à mon avantage ;-> )
D'un autre coté, je me souviens encore des déclarations style DECLARE_RESPONSE_TABLE dans l'ancien framework de borland ! Le problème ne me semble pas seulement trouver une solution qui marche, mais aussi qui soit pas trop lourde à utiliser :)
Chris
Christophe Lephay
amerio wrote:
Hem... D'un autre coté, Meyer en parle comme d'une vtable "à la mano" (au passage, si je peux lire Meyer dans le texte, et le comprendre, je pense que ca veut dire que je sais un minimum de chose en c++. Que je l'applique mal, ptet..., ou que je veux tordre les régles à mon avantage ;-> )
Je ne sais pas. La difficulté de ton cas, c'est que tu veux une solution qui te permette d'ajouter facilement à la fois des nouveaux types de Target et des nouveaux types de Messages, ce que ne permet pas de faire le modèle Visitor (ou en tout cas pas sans avoir à modifier des classes de base)...
Chris
amerio wrote:
Hem... D'un autre coté, Meyer en parle comme d'une vtable "à la mano"
(au passage, si je peux lire Meyer dans le texte, et le comprendre,
je pense que ca veut dire que je sais un minimum de chose en c++. Que
je l'applique mal, ptet..., ou que je veux tordre les régles à mon
avantage ;-> )
Je ne sais pas. La difficulté de ton cas, c'est que tu veux une solution qui
te permette d'ajouter facilement à la fois des nouveaux types de Target et
des nouveaux types de Messages, ce que ne permet pas de faire le modèle
Visitor (ou en tout cas pas sans avoir à modifier des classes de base)...
Hem... D'un autre coté, Meyer en parle comme d'une vtable "à la mano" (au passage, si je peux lire Meyer dans le texte, et le comprendre, je pense que ca veut dire que je sais un minimum de chose en c++. Que je l'applique mal, ptet..., ou que je veux tordre les régles à mon avantage ;-> )
Je ne sais pas. La difficulté de ton cas, c'est que tu veux une solution qui te permette d'ajouter facilement à la fois des nouveaux types de Target et des nouveaux types de Messages, ce que ne permet pas de faire le modèle Visitor (ou en tout cas pas sans avoir à modifier des classes de base)...
Chris
amerio
Christophe Lephay wrote:
amerio wrote:
Hem... D'un autre coté, Meyer en parle comme d'une vtable "à la mano" (au passage, si je peux lire Meyer dans le texte, et le comprendre, je pense que ca veut dire que je sais un minimum de chose en c++. Que je l'applique mal, ptet..., ou que je veux tordre les régles à mon avantage ;-> )
Je ne sais pas. La difficulté de ton cas, c'est que tu veux une solution qui te permette d'ajouter facilement à la fois des nouveaux types de Target et des nouveaux types de Messages, ce que ne permet pas de faire le modèle Visitor (ou en tout cas pas sans avoir à modifier des classes de base)...
Oui, c'est vrai, tant qu'a faire, autant tout avoir ;-)
[Bon, là, je mixe les deux threads de dicussions] Plus sérieusement, je me doute que certaines concession devront être faite. Typiquement : le pattern DoubleDispatch avec map de message de Meyer a comme inconvenient de ne pas supporter l'heritage dans les messages.D'un autre coté, le pattern Visitor impose que la classe de base connaisse tous les type de message possible (ce qui est hors de question). J'ai effectivement des contraintes contradictoires : - Je dois ajouter *tres* facilement de nouveaux types de messages (mais ajouter une map à la Meyer ne pose pas de soucis, ce qui me gene est l'abscence de support de l'heritage, et que les handlers doivent tous prendre un Message&, et pas le vrai type). Ceci aurait tendance a me diriger vers la surcharge, ce qui etait mon 1er choix. - Mais tous les messages doivent passer par une unique interface Target::OnMessage(Message&).
J'ai bien sur essayer le double dispatch sans map (avec reflexivité par le Message), mais cela ne marche QUE si la classe de base Target surcharge HandleMessage pour TOUS les types de messages. Et c'est hors de question.
Au pire, effectivement, je me rabattrais vers une solution type Meyer. Mais je cherche mieux.
Christophe Lephay wrote:
amerio wrote:
Hem... D'un autre coté, Meyer en parle comme d'une vtable "à la mano"
(au passage, si je peux lire Meyer dans le texte, et le comprendre,
je pense que ca veut dire que je sais un minimum de chose en c++. Que
je l'applique mal, ptet..., ou que je veux tordre les régles à mon
avantage ;-> )
Je ne sais pas. La difficulté de ton cas, c'est que tu veux une solution qui
te permette d'ajouter facilement à la fois des nouveaux types de Target et
des nouveaux types de Messages, ce que ne permet pas de faire le modèle
Visitor (ou en tout cas pas sans avoir à modifier des classes de base)...
Oui, c'est vrai, tant qu'a faire, autant tout avoir ;-)
[Bon, là, je mixe les deux threads de dicussions]
Plus sérieusement, je me doute que certaines concession devront être faite.
Typiquement : le pattern DoubleDispatch avec map de message de Meyer a comme inconvenient
de ne pas supporter l'heritage dans les messages.D'un autre coté, le pattern Visitor
impose que la classe de base connaisse tous les type de message possible (ce qui est hors
de question).
J'ai effectivement des contraintes contradictoires :
- Je dois ajouter *tres* facilement de nouveaux types de messages (mais ajouter une map à
la Meyer ne pose pas de soucis, ce qui me gene est l'abscence de support de l'heritage, et
que les handlers doivent tous prendre un Message&, et pas le vrai type). Ceci aurait
tendance a me diriger vers la surcharge, ce qui etait mon 1er choix.
- Mais tous les messages doivent passer par une unique interface
Target::OnMessage(Message&).
J'ai bien sur essayer le double dispatch sans map (avec reflexivité par le Message), mais
cela ne marche QUE si la classe de base Target surcharge HandleMessage pour TOUS les types
de messages. Et c'est hors de question.
Au pire, effectivement, je me rabattrais vers une solution type Meyer. Mais je cherche
mieux.
Hem... D'un autre coté, Meyer en parle comme d'une vtable "à la mano" (au passage, si je peux lire Meyer dans le texte, et le comprendre, je pense que ca veut dire que je sais un minimum de chose en c++. Que je l'applique mal, ptet..., ou que je veux tordre les régles à mon avantage ;-> )
Je ne sais pas. La difficulté de ton cas, c'est que tu veux une solution qui te permette d'ajouter facilement à la fois des nouveaux types de Target et des nouveaux types de Messages, ce que ne permet pas de faire le modèle Visitor (ou en tout cas pas sans avoir à modifier des classes de base)...
Oui, c'est vrai, tant qu'a faire, autant tout avoir ;-)
[Bon, là, je mixe les deux threads de dicussions] Plus sérieusement, je me doute que certaines concession devront être faite. Typiquement : le pattern DoubleDispatch avec map de message de Meyer a comme inconvenient de ne pas supporter l'heritage dans les messages.D'un autre coté, le pattern Visitor impose que la classe de base connaisse tous les type de message possible (ce qui est hors de question). J'ai effectivement des contraintes contradictoires : - Je dois ajouter *tres* facilement de nouveaux types de messages (mais ajouter une map à la Meyer ne pose pas de soucis, ce qui me gene est l'abscence de support de l'heritage, et que les handlers doivent tous prendre un Message&, et pas le vrai type). Ceci aurait tendance a me diriger vers la surcharge, ce qui etait mon 1er choix. - Mais tous les messages doivent passer par une unique interface Target::OnMessage(Message&).
J'ai bien sur essayer le double dispatch sans map (avec reflexivité par le Message), mais cela ne marche QUE si la classe de base Target surcharge HandleMessage pour TOUS les types de messages. Et c'est hors de question.
Au pire, effectivement, je me rabattrais vers une solution type Meyer. Mais je cherche mieux.
Thomas Labourdette
Bonjour,
J'ai effectivement des contraintes contradictoires : - Je dois ajouter *tres* facilement de nouveaux types de messages (mais ajouter une map à la Meyer ne pose pas de soucis, ce qui me gene est l'abscence de support de l'heritage, et que les handlers doivent tous prendre un Message&, et pas le vrai type). Ceci aurait tendance a me diriger vers la surcharge, ce qui etait mon 1er choix. - Mais tous les messages doivent passer par une unique interface Target::OnMessage(Message&).
Je n'ai peut-être pas compris tout le problème, mais pourquoi ne pas ajouter un identifiant par type de message ?
Les Target déclarent auprès du gestionnaire être en mesure de traiter les messages d'un certains type.
@+ -- Thomas Labourdette Il est faux de penser que les femmes ne savent pas garder un secret.. Seulement, comme c'est difficile, elles s'y mettent à plusieurs...
Bonjour,
J'ai effectivement des contraintes contradictoires :
- Je dois ajouter *tres* facilement de nouveaux types de messages
(mais ajouter une map à la Meyer ne pose pas de soucis, ce qui me
gene est l'abscence de support de l'heritage, et que les handlers
doivent tous prendre un Message&, et pas le vrai type). Ceci aurait
tendance a me diriger vers la surcharge, ce qui etait mon 1er choix.
- Mais tous les messages doivent passer par une unique interface
Target::OnMessage(Message&).
Je n'ai peut-être pas compris tout le problème, mais pourquoi ne pas
ajouter un identifiant par type de message ?
Les Target déclarent auprès du gestionnaire être en mesure de traiter
les messages d'un certains type.
@+
--
Thomas Labourdette
Il est faux de penser que les femmes ne savent pas garder un secret..
Seulement, comme c'est difficile, elles s'y mettent à plusieurs...
J'ai effectivement des contraintes contradictoires : - Je dois ajouter *tres* facilement de nouveaux types de messages (mais ajouter une map à la Meyer ne pose pas de soucis, ce qui me gene est l'abscence de support de l'heritage, et que les handlers doivent tous prendre un Message&, et pas le vrai type). Ceci aurait tendance a me diriger vers la surcharge, ce qui etait mon 1er choix. - Mais tous les messages doivent passer par une unique interface Target::OnMessage(Message&).
Je n'ai peut-être pas compris tout le problème, mais pourquoi ne pas ajouter un identifiant par type de message ?
Les Target déclarent auprès du gestionnaire être en mesure de traiter les messages d'un certains type.
@+ -- Thomas Labourdette Il est faux de penser que les femmes ne savent pas garder un secret.. Seulement, comme c'est difficile, elles s'y mettent à plusieurs...
amerio
J'ai effectivement des contraintes contradictoires : - Je dois ajouter *tres* facilement de nouveaux types de messages (mais ajouter une map à la Meyer ne pose pas de soucis, ce qui me gene est l'abscence de support de l'heritage, et que les handlers doivent tous prendre un Message&, et pas le vrai type). Ceci aurait tendance a me diriger vers la surcharge, ce qui etait mon 1er choix. - Mais tous les messages doivent passer par une unique interface Target::OnMessage(Message&).
Je n'ai peut-être pas compris tout le problème, mais pourquoi ne pas ajouter un identifiant par type de message ?
Les Target déclarent auprès du gestionnaire être en mesure de traiter les messages d'un certains type.
L'identifiant, c'est le type du message. A tout prendre, je preferais un typage fort. C'est pour cà que je n'aimais pas trop la solution de Meyer qui consitait a caster un Message& en le bon type dans l'appelé (et non dans l'appelant). Quand à décalré un support dans le gestionnaire, oui, aucun pb de ce coté là. Il est evident que je *ne veux pas* d'un truc genre : if (msg.id()==0x1234) { Message1234& = static_cast<Message1234>(msg); .... }
J'ai effectivement des contraintes contradictoires :
- Je dois ajouter *tres* facilement de nouveaux types de messages
(mais ajouter une map à la Meyer ne pose pas de soucis, ce qui me
gene est l'abscence de support de l'heritage, et que les handlers
doivent tous prendre un Message&, et pas le vrai type). Ceci aurait
tendance a me diriger vers la surcharge, ce qui etait mon 1er choix.
- Mais tous les messages doivent passer par une unique interface
Target::OnMessage(Message&).
Je n'ai peut-être pas compris tout le problème, mais pourquoi ne pas
ajouter un identifiant par type de message ?
Les Target déclarent auprès du gestionnaire être en mesure de traiter
les messages d'un certains type.
L'identifiant, c'est le type du message.
A tout prendre, je preferais un typage fort. C'est pour cà que je n'aimais pas trop la
solution de Meyer qui consitait a caster un Message& en le bon type dans l'appelé (et non
dans l'appelant).
Quand à décalré un support dans le gestionnaire, oui, aucun pb de ce coté là.
Il est evident que je *ne veux pas* d'un truc genre :
if (msg.id()==0x1234)
{
Message1234& = static_cast<Message1234>(msg);
....
}
J'ai effectivement des contraintes contradictoires : - Je dois ajouter *tres* facilement de nouveaux types de messages (mais ajouter une map à la Meyer ne pose pas de soucis, ce qui me gene est l'abscence de support de l'heritage, et que les handlers doivent tous prendre un Message&, et pas le vrai type). Ceci aurait tendance a me diriger vers la surcharge, ce qui etait mon 1er choix. - Mais tous les messages doivent passer par une unique interface Target::OnMessage(Message&).
Je n'ai peut-être pas compris tout le problème, mais pourquoi ne pas ajouter un identifiant par type de message ?
Les Target déclarent auprès du gestionnaire être en mesure de traiter les messages d'un certains type.
L'identifiant, c'est le type du message. A tout prendre, je preferais un typage fort. C'est pour cà que je n'aimais pas trop la solution de Meyer qui consitait a caster un Message& en le bon type dans l'appelé (et non dans l'appelant). Quand à décalré un support dans le gestionnaire, oui, aucun pb de ce coté là. Il est evident que je *ne veux pas* d'un truc genre : if (msg.id()==0x1234) { Message1234& = static_cast<Message1234>(msg); .... }
