Bonjour,
J'aimerais savoir pourquoi les signaux de boost ne sont pas thread safe?
ne peut-on vraiment pas les utiliser si on protege nos fonctions slots?
Merci beaucoup d'avance.
Bonjour,
J'aimerais savoir pourquoi les signaux de boost ne sont pas thread safe?
ne peut-on vraiment pas les utiliser si on protege nos fonctions slots?
Merci beaucoup d'avance.
Pourquoi : Parce que c'est plus compliqué, ya un cout, que sais-je encore...
Perso, je les ai utilisé quand même, et ça marche en ajoutant le code qui va bien. De mémoire (ça va faire 1,5 ans de ça), ce qui posait le plus de problème, c'était l'ajout/suppression de slot pendant que l'on parcours la liste des slots (pas pendant que le slot est en cours d'exécution).
Donc j'ai mis en place un mutex lors de l'ajout/suppression de slots, ainsi qu'au déclenchement d'un slot, et je wrap chaque slot de telle façon que pendant l'exécution du slot, ce mutex est libéré (l'inverse du RAII en sorte...), ce qui me permet de manipuler la liste des slots pendant l'exécution d'un slot, ce dont j'avais besoin.
Maintenant, je ne sais pas si mon pattern d'utilisation couvre tous les cas d'ennuis possibles.
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Une version thread-safe est en cours de préparation, je ne sais pas ce que ça donne...
Si ca t'interresse,
Qt fournie dans le même styles, des connections thread-safe
... en fait je m'éloigne de Qt,
J'utilise le plus possible boost. Je ne veux plus aucune dependance à Qt.
Si j'utilise Qt, ce sera strictement pour l'interface!!!
Je cherche en fait une bonne alternative d'ailleurs.
si quelqu'un a de l'experience sur une autre lib qui soit multi-plateforme Linux/Macosx/Windows, je suis tout à son écoute.
Je ne veux plus de Qt dans la partie métier, je ne veux plus de dépendance avec elle. Le rachat de Qt est pour beaucoup dans ma decision, mais c'est aussi une bonne habitude de completement séparer le code métier de l'interface graphique.
ca a l'air bien la version thread safe...
aucun changement a part l'include, c'est plutot cool.
en fait ma phrase était mal formulée, je sais que Qt fait plus que du GUI, j'ai été vraiment fan de Qt, mais ce rachat m'a fait froid dans le dos et finalement maintenant je préfère les projets vraiment libres et bien séparer mon code métier avec des composants libres de toutes libs de type Qt.
... excuse si je peux paraitre negatif, je suis juste un utilisateur tres decu.
epsilon68 > Qt fait très bien tout ça.
Le rachat ?
J'en sais trop rien. Naïvement, je dirais qu'il n'y aucun risque. En réalité, je ne sais pas.
Toutefois, tous les déveppeurs de chez Trolltech en discutent entre eux, et tous disent que Nokia ne changera pas le système de double-license de Qt et la façon de penser de Qt.
Et puis, penses-tu qu'avec KDE + tant d'autres projets, Qt a un avenir en péril ?
Enfin on a un débat pour ça dans le forum Qt, je t'y réinvite
Mon blog anglais - Mes articles et critiques de livres - FAQ C++0x, avec liste des nouveautés - Conseils sur le C++ - La meilleure FAQ du monde - Avant de créer des classes que vous réutiliserez, regardez si ça n'existe pas déjà - Le site du comité de normalisation du C++
Le guide pour bien débuter en C++ - Cours et tutoriels pour apprendre C++
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager