Version imprimable
J'aimerais savoir qui utilise vraiment les signals/slots de Boost ou de libsigc++ ? j'ai recemment decider de les tester serieusement et de les comparer avec Qt ... c'est super lourd a utiliser comparé a Qt, alors peut-etre je les utilise mal ...
Quelqu'un aurait de l'experience la autour ?
a+
Tu peux regarder sur ce lien que j'ai vu passer sur la mailing list de Qt : http://www.scottcollins.net/articles...and-slots.html
Merci pour le lien il est tres clair et tres explicite, il exprime bien les differences. Cependant je voulais avoir des avis de gens qui utilisent souvent et/ou dans le cadre professionnel les signals de boost et/ou libsigc++, ce qu'ils en pensaient et si ils pouvaient donner leurs avis par rapport a Qt si ils pouvaient.
merci a+
J'ai utilisé Qt. J'ai utilisé et utilise boost:signal. Instinctivement, je n'ai jamais eu envie d'utiliser les signaux Qt pour autre chose que de l'IHM. En fait, ils m'apparaissent bien lourds par rapport aux signaux boost :
- Nécessité d'un pré-processeur spécifique à passer sur de code
- Limitations quant à ce qui peut capter un signal, comparé à la souplesse apportée par boost::bind.
Ils sont peut-être moins simples à apprendre, mais je n'ai pas eu de problèmes pour les utiliser.
Je suis dans le même cas que JolyLoic.
Les signaux de Qt sont bien dans le cadre d'IHM. C'est lourd pour quelque chose qui sort du cadre de l'IHM. boost::signal suffit amplement et n'est pas vraiment lourd en plus.
boost.signal et libsigc++ sont en fait très similaires.
Tu peux voir libsigc++ en usage dans GTKmm.
Pourquoi les signaux de Qt conviennent bien pour l'IHM mais pas pour d'autre cas ? pourquoi specialement pour l'IHM ?
Extrait de la doc Qt :
All classes that contain signals or slots must mention Q_OBJECT at the top of their declaration. They must also derive (directly or indirectly) from QObject.
Je n'ai aucune envie de rempire ces conditions pour des classes qui n'ont pas de rapport avec l'IHM de mon application.
c'est philosophique alors ;)Citation:
Envoyé par JolyLoic
mais ca serait homogene par contre ...
je ne critique pas, je m'etais dis la meme chose, mais a la fin je me demande... le faire avec une autre lib n'ameliore pas les choses quand on change de plateforme....
un grand atout des signaux de Qt je trouve est la deconnexion automatique lorsque l'objet se detruit, pas automatic dans boost (il faut heriter trackable) et ne marche pas dans tous les cas ... pas encore du moins mais ca fait deja un bout de temps.
Je separe bien sur mon code metier du code IHM et je voulais aussi le rendre independant de Qt mais il y a pas mal de classes utiles qui me manqueraient sinon et qui faudrait que je refasse.....
Alors j'hesite, j'utilise Qt du bout des doigts ou je fusionne completement avec et je ne me pose plus de question.....
Quelqu'un a / avait le meme probleme ?
a+
heu ?
bon bah apparement je dois etre le seul a me poser des questions ....
Au niveau non-IHM, je ne vois ce que tu devrais refaire qui n'est pas proposé par des bibliothèques classiques genre Boost :koi:
C'est pas vraiment que les slots de Qt ne sont bons que pour l'IHM, c'est juste qu'ils ne sont bons que quand tu utilises Qt.
En partie, mais pratique aussi... Question de licenses, de taille des classes (le fait d'avoir du virtuel ajoute un overhead), le fait de devoir pré-processer le code qui m'a déjà posé problème avec Qt.Citation:
Envoyé par epsilon68
Je n'ai jamais encore utilisé ces déconnections automatique, mais dire que pour l'avoir dans boost, on est obligé d'hériter d'une classe, je trouve ça peu convainquant comme témoin à charge de boost::signal dans une discussion boost::signal/Qt, étant donné que dans Qt, on doit toujours dériver d'une classe, qui plus est avec des fonctions virtuelles.Citation:
Envoyé par epsilon68
Le fait que ça ne marche pas avec boost::function me semble bien plus gênant. Même si là aussi, les cas où on utilise boost::function sont souvent des cas où on n'aurait pas pu faire avec Qt. Le principal pour moi est que ça marche avec boost::bind, sans ça, effectivement, ça perdrait son intérêt.
je ne sais quoi repondre ....
vous avez certainement raison...
mais j'ai l'impression qu'il vaudrait tout de meme utiliser Qt au maximum si on fait une IHM avec... Ca rendrait le tout plus homogene et moins de dependance vers d'autres libs...
en ce qui concerne les classes utiles sont les Threads/mutexes, les streams (unification des File* et des iostream), QString pour l'unicode, les sockets...
les signaux sont aussi thread safe .....
Reste quand meme la licence :(