Une façon d’utiliser QSignalMapper efficacement

Posted on mars 29, 2009 by admin.
Categories: Eclipse, Koro, Programmation, Qt, je suis hot..

Bon, je ne m’en cacherai pas, je suis un addict de la programmation. J’adore programmer, j’en mange, j’en rêve (ou presque), etc… Et je travaille aussi présentement (avec Cyphermox pour ne nommer que celui-là) sur un projet personnel qui ne décolle pas encore, mais qui a du potentiel… Enfin bref. L’une de mes décisions de conception est d’utiliser un système de fonctionnalités par greffons (plugins), de façon à plus ou moins forcer une bonne division encapsulée des fonctions par objet. Cette approche a le mérite d’économiser un peu sur la mémoire et de ne pas avoir à rechanger le programme au complet parce que y’a un programmeur naze qui a mal compilé la dernière version de la librairie et que ça envoie un password en texte clair sur paypal. Cette décision m’a permis de développer une expertise côté chargement de greffons avec Qt… Mais qu’en est-il du déchargement de greffons? Y a-t-il un moyen de décharger des greffons de la mémoire tout en gardant le greffon dans la totale ignorance de son parent? … Eh bien oui! J’ai utilisé une fonctionnalité de Qt appelée QSignalMapper pour réussir à assigner une fonction de déchargement unique à chaque greffon chargé en mémoire. Fun times, mais ce n’est pas de tout repos.

Tout premièrement, sachez que QSignalMapper est awesome.

Deuxièmement, mon approche pour utiliser QSignalMapper a été de faire un objet d’ »attribution de signaux ». Il possède un constructeur qui prend en entrée un pointeur vers l’objet de « cleanup »; un pointeur char* vers la fonction à appeler pour se débarasser des objets qui lui seront attribués; et le classique pointeur vers le parent, présent dans tout QObject. Après, pour la destruction des objets en tant que tel, il y a une fonction qui prend en entrée une Action (de menu ou de bouton, tant que le signal « triggered() » est lancé) et un pointeur QObject vers l’objet à détruire. Cette-dite fonction créera un AUTRE objet, que j’ai appelé « ActionPluginBridge », et qui est là pour les besoins de « pureté » et de mémoire des signaux à attribuer. De cette façon, je peux « nettoyer » le QSignalMapper au complet à chaque nouvelle attribution. En faisant ça, c’est autrement plus facile d’être sûr que c’est bien attribué et à toutes fins pratiques stable (vive les foreach, soi dit en passant).

Vous avez maintenant ci-haut la structure que j’ai utilisée pour utiliser une même fonction plusieurs fois en gardant l’encapsulation intacte et en ne me faisant pas c…à écrire du code superflu. Là faut juste que je réussisse à faire déguerpir les objets sans crahser… ;)

Code available on request. Évidemment sous GPL, bande de capitalissssssss.

Commentaires spéciaux:

Patrick K. Gauthier: C’est peut-être « impur » comme approche mais je suis comme tu le sais obsédé par le platform-neutre, donc chut. Et ça va compiler sur Linux, Darwin et Windows, donc DOUBLE-chut.

no comments yet.

Leave a comment

Names and email addresses are required (email addresses aren't displayed), url's are optional.

Comments may contain the following xhtml tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>