lorsque l'on utilise des std::thread (C++11), le système de signaux ne peut pas savoir qu'il doit transférer le signal vers un autre thread et il y a toutes les chances qu'en cascade l'interface soit touchée par le mauvais thread. Si on veut utiliser des std::thread, on doit renoncer aux signaux.
Tu as essayé ? Je viens d'essayer et ça marche très bien. Qt s'intègre parfaitement avec std::thread et pas de problème pour faire passer des signaux et slots entre en std::thread et un QThread. Si lo'bject est créé dans le std::thread, ses slots seront executé dans ce thread là.
Un QObject n'est pas copiable/déplaçable,
Oui, un QObject ne peux pas être copié car il est supposé être hérité. En général, ces classes ne sont pas copiable. Tu peux toujours avoir un constructeur de copie dans ta classe héritière, mais je ne pense pas que ça ait du sens.
pointeurs sont préférés à des références, comme pour la création d'un QVariant,
Ah bon? QVariant::fromValue n'a pas besoin de pointeur. Tu n'es pas sensé le constructeur interne qui prends un pointeur.
Il y a clairement une duplication de fonctionnalités au niveau des conteneurs, je ne vois pas ce qu'apportent les QList et semblables.
Oui c'est vrai. L'apport est une API unifiée et plus utilisable pour les utilisateur de Qt. Mais c'est vrai que c'est dupliqué.
Aussi, Qt ne veux pas avoir de type de la STL dans son ABI car Qt conserve une ABI binarie qui est mieux que celle de la standard library. Ainsi, Qt compilé avec libc++ de clang est compatible binaire avec une application qui utilise libstdcpp de gcc, et inversément.
Un QString ne peut pas être affiché sur la sortie standard avec std::cout << monQString;
Il faut écrire l'opérateur soit même. C'est vrai que Qt devrait supporter ça. Tu peux toujours envoyer un patch :-)
[^] # Re: Des exemples !
Posté par Gof (site web personnel) . En réponse au journal Squarez, le retour. Évalué à 3.
Tu as essayé ? Je viens d'essayer et ça marche très bien. Qt s'intègre parfaitement avec
std::threadet pas de problème pour faire passer des signaux et slots entre en std::thread et un QThread. Si lo'bject est créé dans le std::thread, ses slots seront executé dans ce thread là.Oui, un QObject ne peux pas être copié car il est supposé être hérité. En général, ces classes ne sont pas copiable. Tu peux toujours avoir un constructeur de copie dans ta classe héritière, mais je ne pense pas que ça ait du sens.
Ah bon? QVariant::fromValue n'a pas besoin de pointeur. Tu n'es pas sensé le constructeur interne qui prends un pointeur.
Oui c'est vrai. L'apport est une API unifiée et plus utilisable pour les utilisateur de Qt. Mais c'est vrai que c'est dupliqué.
Aussi, Qt ne veux pas avoir de type de la STL dans son ABI car Qt conserve une ABI binarie qui est mieux que celle de la standard library. Ainsi, Qt compilé avec libc++ de clang est compatible binaire avec une application qui utilise libstdcpp de gcc, et inversément.
Il faut écrire l'opérateur soit même. C'est vrai que Qt devrait supporter ça. Tu peux toujours envoyer un patch :-)