Des signaux, des slots, et SFML

[Asphox]

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/SISL
github SFML+SISL : https://github.com/Asphox/SFML-SISL


Update : 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 ...

[Laurent]

J'avoue que je n'ai pas regardé en détail, mais déjà ça sent les complications inutiles avec la macro EXT_SLOT. Normalement pas besoin de macro, C++11 a tout ce qu'il faut pour faire ça proprement et sans fioriture supplémentaire.

[Asphox]

Oui je suis d'accord que les macros sont évitées au maximum en C++11.
mais dans mon cas,  je pensais que cela simplifier pas mal les choses ( ça empêche de créer soit même l'objet slot).

Je vais quand même réfléchir pour supprimer toutes ces macros ^^

Merci pour votre retour en tout cas Laurent 

[Laurent]

Pourquoi créer un objet slot ? La fonction "connect" doit pouvoir accepter directement n'importe quel type de "callable" compatible avec la signature du signal (via un peu de meta-programmation intelligente). Je l'ai fait récemment dans un projet et ça fonctionne parfaitement.

void f(int);
void f2(int, int);

struct C
{
    void f(int);
}
C c;

Signal<int> sig;
sig.connect(&f);
sig.connect(&C::f, c);
sig.connect(std::bind(&f2, std::placeholders::_1, 10));
sig.connect([](int arg){});
 

[Asphox]

Oui, ma librairie fonctionnait comme ça au debut.
Mais ce qui me derange dans cette pratique, c'est que le signal ne peut pas savoir quand l'objet à qui appartient la fonction membre passée en paramètre est detruit ... et donc il peut tres bien l'appeler alors que l'objet n'existe plus ( j'ai testé et c'est ce qu'il se passe ).
Alors que l'objet slot qu'en à lui est detruit en même temps que l'objet qui le possède, il peut donc "avertir" ( via son destructeur ) les signaux connectés à lui et forcer leur deconnection.
Ainsi les signaux n'appelent jamais un fonction membre dont l'objet est detruit.

Apres peut etre que je veux trop "securiser" le principe ... vaudrait il mieu laisser le developpeur faire attention a bien deconnecter les slots "manuelement" quand l'objet est detruit ?

[Laurent]

Ok, je vois pourquoi tu as fait ça maintenant. Ca se vaut comme choix.

[janf]

Pour l'instant je n'ai pas regardé les GitHubs mais je voulais juste dire que je suis enthousiaste face à des projets comme celui-ci. C'est intéressant, il y a toujours des choses à en apprendre, et ça peut même être utile dans des projets. Donc je voulais dire bravo pour le travail accompli, même si je n'ai pas encore regardé je sais qu'il y a eu du temps et de la bonne volonté derrière, c'est déjà ce qui compte pour moi

Je m'en vais shouffer le code.