(Note: je ne fais plus que du PyQt depuis longtemps, j'ai perdu de vue Qt/C++ depuis la version 3).
De fait, utiliser Qt fonctionne bien avec une cohérence globale au niveau de ses types, de ses conteneurs et autres. Il arrive bien à échanger des données avec des conteneurs et types externes mais c'est plus une notion d'import/export que d'interopérabilité. Ca ne m'étonne pas que le mélange profond des deux au sein d'un même programme se passe pas bien.
Donc ça force un style particuliers de programmation, avec des QThread, des QString, des QObject et des QList. Quand j'ai commencé, j'ai trouvé que ce style "forcé" était de bonne qualité et donc ça m'a plutôt plu. Mais je conçois que ça puisse poser des problèmes.
Lorsque Qt est arrivé en 1994, c'était vraiment une révolution. On était même pas sur de trouver une STL fonctionnelle sur toutes les plate-formes, et à côté, on avait Qt qui fournissait bien plus que la STL, avec une meilleure documentation et une interface plus abordable.
Depuis, la STL a rattrapé une partie de son retard et devient relativement utilisable (bien qu'un peu lourdingue à mon goût), surtout avec du boost.
Donc Qt peut être vu comme une solution non standard. Je râlais de la même façon quand je faisais des MFC et que je n'arrivais pas à faire marcher mes std::string et que Microsoft m'obligeais à utiliser des CString (les string en MFC). J'aurai jamais pensé que l'argument se retournerai contre mon toolkit adoré un jour.
std::cout << monQString;
Je pense qu'il y a de bonnes raisons à ça. Au hasard, je dirai que comme la STL ne spécifie pas réellement d'encoding par défaut, suivant les options de compilations que tu passes à ton programme, il faut que les chaînes soit encodées en UTF8, UTF16 ou UTF32, voire même latin1.
Donc Qt t'oblige à faire le choix toi-même, en convertissant soit en UTF8 avec tu toUtf8(), soit en en encoding "locale" avec toLocal8bit().
Et si tu veux afficher cette même chaîne sur un terminal, l'encoding final à choisir est assez complexe : sous Windows, il faut probablement la convertir un cp1252 ou en UTF8 suivant la version de Windows et de la console, sous Linux UTF8 a l'air de s'en sortir pas trop mal. Je doute honnètement que cout gère ce genre de subtilité, donc au final, ton code sera probablement pas portable.
Demande à Victor Stinner le cauchemar que c'est de faire marcher l'unicode correctement sous Python.
[^] # Re: Des exemples !
Posté par Philippe F (site web personnel) . En réponse au journal Squarez, le retour. Évalué à 3.
C'est intéressant.
(Note: je ne fais plus que du PyQt depuis longtemps, j'ai perdu de vue Qt/C++ depuis la version 3).
De fait, utiliser Qt fonctionne bien avec une cohérence globale au niveau de ses types, de ses conteneurs et autres. Il arrive bien à échanger des données avec des conteneurs et types externes mais c'est plus une notion d'import/export que d'interopérabilité. Ca ne m'étonne pas que le mélange profond des deux au sein d'un même programme se passe pas bien.
Donc ça force un style particuliers de programmation, avec des QThread, des QString, des QObject et des QList. Quand j'ai commencé, j'ai trouvé que ce style "forcé" était de bonne qualité et donc ça m'a plutôt plu. Mais je conçois que ça puisse poser des problèmes.
Lorsque Qt est arrivé en 1994, c'était vraiment une révolution. On était même pas sur de trouver une STL fonctionnelle sur toutes les plate-formes, et à côté, on avait Qt qui fournissait bien plus que la STL, avec une meilleure documentation et une interface plus abordable.
Depuis, la STL a rattrapé une partie de son retard et devient relativement utilisable (bien qu'un peu lourdingue à mon goût), surtout avec du boost.
Donc Qt peut être vu comme une solution non standard. Je râlais de la même façon quand je faisais des MFC et que je n'arrivais pas à faire marcher mes std::string et que Microsoft m'obligeais à utiliser des CString (les string en MFC). J'aurai jamais pensé que l'argument se retournerai contre mon toolkit adoré un jour.
Je pense qu'il y a de bonnes raisons à ça. Au hasard, je dirai que comme la STL ne spécifie pas réellement d'encoding par défaut, suivant les options de compilations que tu passes à ton programme, il faut que les chaînes soit encodées en UTF8, UTF16 ou UTF32, voire même latin1.
Donc Qt t'oblige à faire le choix toi-même, en convertissant soit en UTF8 avec tu toUtf8(), soit en en encoding "locale" avec toLocal8bit().
Et si tu veux afficher cette même chaîne sur un terminal, l'encoding final à choisir est assez complexe : sous Windows, il faut probablement la convertir un cp1252 ou en UTF8 suivant la version de Windows et de la console, sous Linux UTF8 a l'air de s'en sortir pas trop mal. Je doute honnètement que cout gère ce genre de subtilité, donc au final, ton code sera probablement pas portable.
Demande à Victor Stinner le cauchemar que c'est de faire marcher l'unicode correctement sous Python.