Bonjour à tous !
Jouant depuis un bon moment maintenant avec
SFML, il m’ait venu à l'esprit d'essayer d’implémenter le pattern signal/slot à la gestion d'évenement de
SFML avec ma libraire perso de signal/slot.
Pour la petite histoire ... Cela fait un moment que j'ai découvert la puissance du pattern signa/slot avec la libraire Qt. Et j'ai eu l'idée de l'utiliser dans des projets non-reliés à Qt, j'ai donc commencé ma petite recherche de librairie reprenant le principe.
Il y évidement Boost qui integre ce systeme, mais je prefere ne l'utiliser quand dernier recours, préférant de petite libraire à un mastodonte comme Boost ( qui reste quand même une mine d'or pour le C++ ).
Je me suis donc renseigné sur de plus petites librairies, et il y en a un bon paquet ! xD
Hélàs la plupart ( et les plus récentes ) utilisent un principe de
Delegate qui bien qu’extrêmement rapide, possède un problème que je trouve dérangeant :
un signal n'a aucun moyen de savoir quand un objet avec un slot qui lui est connecté est detruit ...En d'autre terme : il est parfaitement possible qu'un signal appel une fonction membre d'un objet , alors que celui si est detruit !
Retrouvant ce problème dans de nombreuses librairies de signal/slot, je me suis donc rendu à l’évidence : je devais essayer d'en coder une moi même...
La naissance de SISL Apres de loooooong mois de sueur et d'optimisation, j'ai enfin terminé la première version de SISL ( pour SIgnal SLot ).
Une libraire que j'ai voulu rapide , facile à maintenir , relativement simple d'utilisation , standard ( C++11 ) , et surtout qui ne possède pas le même problème de "non détection de la destruction des objets" que la plupart des autres librairies de signal/slot ont.
Pour ce faire, j'ai du opter pour une solution radicale : ne pas connecter une fonction ( ou une fonction membre) directement au signal , mais passer par un objet qui encapsule la fonction de manière unique , et qui lui, pourra etre connecté à un signal ( tout en etant detruit en meme temps que l'objet contenant le slot, ainsi, il est impossible qu'un signal appel un slot relié à une fonction dont l'objet n'existe plus ).
SFML + SISL ? Quelques développeurs et moi même avons donc commencé à utiliser SISL dans plusieurs de nos projets, et nous sommes arrivés à la même conclusion : pourquoi ne pas essayer d’intégrer SISL à SFML dans une sorte de fork ? juste pour tester ?
Ainsi, je me suis donc lancé dans l'idée de tenter cette fusion dans mon coin, voir si cela est réalisable et surtout utile.
Je me permet donc de poster cette idée sur le forum SFML, pour voir si certaines personnes seraient intéressées par un tel systeme, et surtout pour avoir des retours extérieurs sur ma librairie ( des optimisations à faire que je n'aurais pas vu ? des bugs ? des ajouts ? )
Je vous donne donc en annexe le github de sisl, ainsi que la première version de test d’intégration de SISL à SFML .
En vous remerciant d'avance pour le temps accordé à mon gros pavé ! xD
Annexes : github sisl :
https://github.com/Asphox/SISLgithub SFML+SISL :
https://github.com/Asphox/SFML-SISLUpdate : voila j'ai terminé la premiere version et ça fonctionne ! ( avec tout les events sauf ceux en rapprot avec les joysticks )
je vous laisse check sur le github en essayant par vous même si cela vous intéresse ( il y a un petit readme pour expliquer les bases ).
Prochainement : prise en compte des events joystick ...
Voir les contributions
).
