Le qml ne peut pas afficher des std::string, il faut utiliser des QString.
L'interface graphique doit être mise à jour dans le thread principal, 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.
Un QObject n'est pas copiable/déplaçable, si on veut avoir un membre qui soit un QObject on en revient souvent à avoir des (auto-)pointeurs vers le QObject. C'est peut-être un mauvais usage de ma part, je n'ai pas cherché beaucoup plus loin.
À quelques endroits les pointeurs sont préférés à des références, comme pour la création d'un QVariant, nécessaire pour exposer un modèle via un QAbstractListModel par exemple.
Il y a clairement une duplication de fonctionnalités au niveau des conteneurs, je ne vois pas ce qu'apportent les QList et semblables.
Peu d'objets sont utilisables dans un stream, ou alors il faut utiliser un header que je ne connais pas. Un QString ne peut pas être affiché sur la sortie standard avec std::cout << monQString;
L'intégration qui existe permet la création de QString à partir de std::string et inversement, l'utilisation de lambdas, std::function et pointeurs sur méthode pour la connexion de signaux, et tous les problèmes que je n'ai pas eu parce qu'ils ont été corrigés !
[^] # Re: Des exemples !
Posté par Patrick Nicolas . En réponse au journal Squarez, le retour. Évalué à 4.
Les cas que j'ai eu le temps de voir:
Le qml ne peut pas afficher des std::string, il faut utiliser des QString.
L'interface graphique doit être mise à jour dans le thread principal, 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.
Un QObject n'est pas copiable/déplaçable, si on veut avoir un membre qui soit un QObject on en revient souvent à avoir des (auto-)pointeurs vers le QObject. C'est peut-être un mauvais usage de ma part, je n'ai pas cherché beaucoup plus loin.
À quelques endroits les pointeurs sont préférés à des références, comme pour la création d'un QVariant, nécessaire pour exposer un modèle via un QAbstractListModel par exemple.
Il y a clairement une duplication de fonctionnalités au niveau des conteneurs, je ne vois pas ce qu'apportent les QList et semblables.
Peu d'objets sont utilisables dans un stream, ou alors il faut utiliser un header que je ne connais pas. Un QString ne peut pas être affiché sur la sortie standard avec std::cout << monQString;
L'intégration qui existe permet la création de QString à partir de std::string et inversement, l'utilisation de lambdas, std::function et pointeurs sur méthode pour la connexion de signaux, et tous les problèmes que je n'ai pas eu parce qu'ils ont été corrigés !