Folco (./1180) :
entry[ID_truc].ptr

Sasume (./1185) :
Hm, pourquoi y aurait-il un cast ? entry peut être une liste de Receive *, non ?

Exact, j'avais pensé à en faire une liste de mes objets considérés en tant que tels (ie dérivant de Receive et d'une autre classe genre icone ou sprite). MAis le polymorphisme me permet d'enregistrer l'adresse d'un objet de type Receive "pur", t'as raison.

Sasume (./1185) :
Et oui, ça marcherait très bien. Tu peux même faire de ta classe Communication un singleton, ça t’évitera d’avoir à faire ta bidouille en début d’exécution.

Je vais regarder pour le singleton, j'ai vu ça passer dans mon bouquin (une combine avec une variable static empêchant la recréation de l'objet si je me souviens bien)
Tu parles de quelle bidouille au fait ? Le fait d'instancier une première fois un objet Communication ?

GoldenCrystal (./1186) :
Sinon Folco, est-ce que tu as vraiment besoin d'un mécanisme si sophistiqué dans ton projet ? Tu as vraiment des messages susceptibles d'être traités par plus d'un objet par émission ?

J'en sais rien Mais c'est le seul truc intelligent que j'ai trouvé pour tous les problèmes de mon jeu qui me sont passés par la tête.

GoldenCrystal (./1186) :
Tu as des exemples des messages que tu voudrais transmettre, à titre d'info ?

Voilà. Je peux vouloir dire : "ajoute cette unité (n° tant) à cette armée" + "déduis le prix de l'unité du portefeuille du joueur" + "mets à jour la liste d'icones des unités dans le menu".
Tout ça suite à un seul clic. Le problème, c'est qu'un tel message s'adresse à plusieurs objets... : objet Module pour rajouter une icone à la liste du module, objet Joueur->Portefeuille pour le fric, objet Joueur->Armée etc...
Donc 3 messages à propager, sachant que je ne gérais pas une pile de message mais un seul message (j'ai pensé à faire une pile, mais c'est très couteux de parcourir une pile pour chaque objet, surtout que sur l'ensemble, très peu auront un message à leur intention). Et mon Message était fortement typé : transmission de deux int + 1 pointeur. Génial, mais c'est hyper limitatif.
Là, l'avantage est que je peux faire une sorte de protocole (je sais pas comment appeler ça) :
- je vais t'envoyer deux pointeurs sur des objets dont tu sais quoi faire
- ok (je prépare ma liste)
- en v'là un
- et voilà, fini

Et il me suffit de surcharger sendMessage() et receiveMessage() dans la classe dérivée pour envoyer tous les types que je veux (chaque objet devant implémenter ses versions spécialisées dont il sait qu'il aura besoin).

Vu de loin, ça me parait souple, performant et surtout simple à utiliser : juste des sendMessage() à écrire pour les émetteurs, et des receiveMessage() pour les récepteurs. Il y a probablement mieux pour mon cas, mais c'est la seule idée de ce genre qui me soit venue.

GoldenCrystal (./1186) :
(Et oui, c'est un bon modèle, je me demande juste si c'est adapté à ce que tu veux faire)

(alors là, je suis content, je comprends l'utilité de l'héritage multiple par besoin, j'aime apprendre comme ça (ben oui, j'en avais jamais fait encore ))

Kevin Kofler (./1188) :
Et voilà, tu viens de réinventer un système de signaux et de slots (en moins bien ).

Je sais très bien que Qt propose ça, mais je m'en fous, j'ai voulu trouver un système bien fait. Et tu sais très bien que je le sais, ce n'est pas ton premier post à ce sujet
Ce qui aurait été intéressant, c'est de savoir ce que fait Qt de mieux et qui serait susceptible de m'intéresser, là oui je suis preneur