QT-C ++ vs Generic C ++ et STL [fermé]

J'ai récemment révisé mon C ++, sur Ubuntu QQ. J'adore le cadre Qt pour tout, en particulier la création d'interfaces graphiques. Je me suis familiarisé avec lui lors de l'utilisation de PyQt au cours des dernières années.

Lors de l'utilisation de PyQt, j'ai eu quelques problèmes qui sont maintenant plus prononcés lors de l'utilisation de C ++ avec Qt: Qt a de nombreuses extensions à C ++ qui sont spécifiques à Qt - QString n'est qu'un exemple courant, sans parler de la collecte automatisée des ordures. Il est possible d'écrire des applications Qt en C ++ sans en savoir grand-chose sur C ++ et la STL.

Je devrais peut-être bientôt revenir sur le marché du travail et j'aimerais pouvoir envisager des postes en C ++ - mais je crains de trop me lier à Qt limitera mes capacités à travailler avec du C ++ générique, qui était autrefois assez formidable mais sont maintenant longtemps dormants et rouillés.

Dois-je éviter Qt? Serais-je mieux d'utiliser WxWidgets ou GTK ++ pour créer des interfaces graphiques?

Quel est le meilleur framework GUI à utiliser qui permet / nécessite la plus grande utilisation du C ++ générique et de la STL? Comment puis-je me rendre le plus commercialisable en tant que programmeur C ++ en ce qui concerne les frameworks GUI, etc.?

Je ne m'abstiendrais pas d'utiliser Qt juste pour ces raisons. Vous n'êtes pas obligé d'utiliser toutes les classes d'utilitaires de Qt; pour ceux qui remplacent la STL, vous serez tout au plus obligé d'utiliser QString et, éventuellement, QStringList. En outre, un programme comporte généralement bien plus que l'interface graphique. Vous pouvez toujours utiliser exclusivement du C ++ générique pour le reste de votre programme et utiliser Qt uniquement pour l'interface graphique.

À mon avis, travailler avec STL consiste davantage à comprendre quelles structures de données sous-jacentes sont utilisées et leurs complexités, et par conséquent à quel moment vous devez utiliser chaque conteneur. Et en ce qui concerne la programmation C ++, il s'agit surtout de savoir comment utiliser l'en-tête <algorithm> très essentiel, qui devrait également fonctionner sur les conteneurs de Qt, car ils sont compatibles avec STL.

Je ne vois pas beaucoup de mal à utiliser toutes ces extensions fournies par Qt, tant que vous savez (ou du moins avez une idée générale) de la façon dont elles sont implémentées en interne. Assurez-vous que vous savez que des choses comme Q_OBJECT, SIGNAL (), SLOT (), foreach (), ne sont pas magiques, mais des macros qui se développent en instructions C ++ valides. Par exemple, ce n'est pas si compliqué de comprendre comment les classes implicitement partagées et les relations parent-enfant qui donnent à Qt l'impression d'être plus Java sont implémentées. Vous pouvez toujours essayer de recréer certaines fonctionnalités dans un projet distinct juste pour voir si vous pouvez le faire avec du C ++ générique, et ne vous sentez pas mal de les utiliser dans Qt.

Jetez également un œil aux bibliothèques Boost. Ils fournissent des utilitaires supplémentaires que la bibliothèque C ++ standard ne fournit pas et sont un très bon moyen de se rapprocher un peu du C ++ générique, car ils suivent essentiellement les mêmes conventions que le C ++ générique. Certaines bibliothèques ont des classes modèles assez complexes, et essayer simplement de comprendre comment elles fonctionnent est, en soi, une bonne étude en C ++. Boost possède de nombreux utilitaires introuvables dans Qt, et d'autres qui implémentent des concepts identiques ou similaires à certaines classes de Qt et peuvent être utilisés à leur place.

Si vous entrez sur le marché du travail en travaillant avec C ++, il est probable que vous allez travailler avec Qt ou un autre framework qui, comme lui, aura ses propres classes d'utilitaires qui essaient de simplifier C ++.

Je suis d'accord avec la plupart des éloges de Qt, mais la question était quel est le meilleur cadre GUI à utiliser qui permet / nécessite le plus d'utilisation du C ++ générique et de la STL? À cet égard, Qt est un peu schizophrène: il duplique les conteneurs STL et les algorithmes avec ses propres rebondissements. Il fournit également des conteneurs différents de STL. L'interopérabilité entre Qt et STL n'est pas toujours fluide. Dans certains cas , il faut quelques appels de fonction pour obtenir de std::stringla QStringet le dos.

wxWidgets a une option pour la construction STL, qui utilise exclusivement des conteneurs STL - il n'y a pas d'univers parallèle avec des remplacements maison comme dans le cas de Qt. Il compile également avec un compilateur C ++ standard sans avoir besoin d'extensions non standard. C'est un cadre GUI de qualité qui mérite d'être considéré.

Vous pouvez également consulter un gtkmm, qui est un wrapper C ++ autour de GTK +. C'est plus proche de satisfaire votre première exigence que Qt.

Je ne m'inquiéterais pas trop de ne pas utiliser de bibliothèques STL spécifiques comme std :: string ou std :: iostream ou std :: vector. Les équivalents QT viennent dans une saveur différente mais ils ne sont pas si loin pour poser problème.

La différence la plus idiomatique à mon avis semble être le style de programmation lourd à utiliser newpour l'allocation. Alors que pour un programme QT, cela pourrait être bien pour la partie Gui, la vertu de C ++ et RAII est que vous pouvez réellement garder beaucoup de données sur la pile au lieu du tas. Lorsque vous passez à l'écriture de code non GUI, vous devez vous en souvenir.