Quels sont les coins dangereux de Qt? [fermé]

Il n'y a rien de parfait sous le soleil. Qt ne fait pas exception, et il a des limitations: nous ne pouvons pas utiliser des pixmaps dans un thread autre que l'interface graphique, nous ne pouvons pas utiliser QImage avec un format d'image 16 bits par canal, etc.

Quelles situations vous ont forcé à gâcher la conception en raison des limites de Qt?
Quelles sont les bizarreries les plus détestées?
Quelles décisions de conception doit-on éviter en utilisant Qt dans ses projets?

Ironiquement, je dirais que la puissance de Qt est également l'un des inconvénients. Il y a tellement de constructions et d'extensions puissantes que le code que vous écrivez dans Qt devient facilement fortement ancré de la "manière Qt". Essayer d'extraire des fonctionnalités dans une autre langue ne signifie pas seulement une réécriture, vous devez connaître beaucoup de technologies spécifiques à Qt.

L'étendue de Qt signifie que l'embauche de programmeurs signifie soit s'engager auprès de quelqu'un ayant une expérience Qt, soit une formation pour cette expertise. Obtenir un sous-traitant et le mettre à jour est plus difficile que vanilla C ++.

Lorsque Qt est passé de 3.x à 4.x, notre équipe a mis près de 9 mois à faire le portage, période pendant laquelle peu de nouvelles fonctionnalités ont été ajoutées. Vous espérez compenser ce coût de mise à niveau majeur en une efficacité de développement accrue le reste du temps. (Remarque, j'ai omis les avantages de Qt, dont il existe également de nombreux)

Qt n'utilise pas la bibliothèque C ++ standard , mais possède ses propres QString, QVector, QMap, ...

Cela signifie que vous devez prendre une décision de conception importante: quelles parties de l'application utiliseront QString et quelles parties utiliseront std :: string?

L'utilisation de std :: string dans certaines parties et de QString dans d'autres parties, signifie que vous devrez convertir entre QString et std :: string sur les limites.

Pour éviter ce surcoût, on pourrait décider d'utiliser QString partout dans votre application. Mais cela rend beaucoup plus difficile l'utilisation de bibliothèques tierces qui ne sont pas basées sur Qt, par exemple boost.

(Notez que la même chose s'applique à std :: map vs QMap, std :: vector vs QVector, etc.)

Décider quelles pièces utilisent les types de Qt et quelles pièces utilisent la STL est une décision de conception majeure, avec des implications majeures. Et seulement parce que Qt refuse d'utiliser la bibliothèque C ++ standard.

À mon humble avis, cette décision pourrait aller dans les deux sens, selon le projet. Je ne peux donc pas répondre à votre question laquelle éviter.

Cela ne répond pas directement à la question, mais je pense qu'il convient de le mentionner: peut-être que l'aspect le plus `` dangereux '' de Qt est que Nokia s'est couché avec MSoft ...

Récemment, j'ai découvert qu'un QChar, malgré son nom, ne correspond pas réellement à un caractère mais à une unité de code UTF-16. Ainsi, lorsque vous souhaitez analyser un texte arbitraire Unicode caractère par caractère, vous devez ajouter des algorithmes pour traiter les substituts hauts et bas, en combinant les caractères et similaires.