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

10

Dans l'état actuel des choses, cette question ne convient pas à notre format de questions / réponses. Nous nous attendons à ce que les réponses soient étayées par des faits, des références ou une expertise, mais cette question suscitera probablement un débat, des arguments, des sondages ou une discussion approfondie. Si vous pensez que cette question peut être améliorée et éventuellement rouverte, visitez le centre d'aide pour obtenir des conseils.

Fermé il y a 8 ans .

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?

qt design-decisions

— vignes
source

Pouvez-vous dire le Qt? Si vous le développez en "Q Toolkit", vous pouvez ajouter un "le" devant, mais est-ce correct / de bonne pratique de dire le Qt? Juste curieux.

— Anto

@Anto: Je suppose que thec'est lié cornersici, non Qt, mais ce n'est que ma sensation intuitive, puisque je suis russe :)

— vignes

Une courbe dangereuse possible est que le projet peut être en difficulté financière. Nokia a récemment signé un accord avec Microsoft (pour utiliser Win7 sur leurs téléphones) qui met l'avenir de Qt sur un terrain instable.

— Peter Rowell

je suis très intéressé à connaître cette réponse parce que je suis un noob à la programmation visuelle C ++: D

— Shaheer

@Vines: Que diriez-vous de "Quels sont les coins dangereux du QT?"?

— Chris

12

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)

— James Creasy
source

2

Le port Qt3 à Qt4 était difficile pour la plupart des gens que je connais. Ce QML et les choses similaires qui ont été introduites dans les versions les plus récentes m'inquiètent, car cela peut signifier à nouveau l'arrivée d'un port compliqué.

— Vitor Py

10

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.

— Sjoerd
source

1

Je suis d'accord, mais je voudrais sortir sur le bord et dire que le QString (etc etc) est également l'un des points forts car il est si agréable de travailler avec eux.

— Johan

1

De plus, il n'est pas si difficile d'utiliser une bibliothèque qui n'utilise pas QString. Il existe une méthode simple pour convertir une chaîne QString en chaîne std :: et vice versa. Pas grand chose.

@Glenn Nelson: Oui, de nos jours il existe des fonctions de conversion pour QString; très utile et pratique! Mais en particulier pour QVector et QMap, il y aura des frais généraux dans la conversion (et les solutions simples ne fonctionneront pas, par exemple pour QVector <QString>); Cette surcharge doit être prise en compte lors de la conception pour éviter des problèmes de performances sur toute la ligne.

— Sjoerd

3

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 ...

— Vecteur
source

2

Mais ils ont abandonné Qt pour le faire.

— Martin Beckett

1

Par souci d'exhaustivité - La partie commerciale de Qt appartient désormais à Digia, tandis que Qt est passé à un système de «gouvernance ouverte» où d'autres peuvent facilement contribuer. Il existe également la fondation KDE Free Qt qui protège Qt contre les sources fermées.

— Vishesh Handa

2

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.

— Sebastian Negraszus
source