: "ouais, Electron bouffe plein de RAM et de CPU, mais ça coûte moins cher en dév et les futures machines seront plus puissantes, donc on s'en fout."
C'est l'apologie de l'usine à gaz. 
Uther (./416) :C'était juste l'IHM au début ?
il contient beaucoup trop de chose à mon gout qui vont bien au delà de l'IHM.
Zerosquare (./414) :Merci
coucou Zeph
(je trouve que c'est ce qui amène le plus de discussions et donc qui fait la différence entre yN et un newsfeed ^^)
Uther (./420) :
Ceci dit, Ils auraient quand même pu faire un effort pour intégrer proprement ce qui est standard.
Par pitié, non! L'implémentation Qt est généralement beaucoup plus simple à utiliser que l'implémentation STL: partage implicit (copie à l'écriture), noms de méthodes plus clairs, API plus complète (la STL est souvent minimaliste, il n'y a souvent pas de méthode pour les opérations en O(n) ou plus, mais il arrive qu'on ait besoin de les utiliser et que changer de conteneur n'est pas la bonne solution pour une raison ou pour une autre, et il manque aussi souvent des surcharges simplifiées comme un std::sort sur le conteneur entier, sans devoir passer les itérateurs begin et end à chaque fois) etc.
Ils ont aussi déprécié Q_FOREACH, le foreach optimisé pour les conteneurs Qt, en faveur du ranged-for C++11, qui 1. ne copie pas le conteneur dans une variable const (comme le fait Q_FOREACH) et 2. n'utilise pas les méthodes Qt constBegin et constEnd, donc les conteneurs Qt voient ça comme une écriture et détachent pour rien (le comportement en 1. est fait pour ne pas recopier les conteneurs non-partagés de la STL, mais il est contreproductif pour les conteneurs partagés de Qt) et à cause de 1., ça foire aussi (les itérateurs deviennent invalides) si le code dans la boucle modifie le conteneur (alors qu'avec Q_FOREACH, dans ce cas, le conteneur détache et la boucle continue à énumérer le conteneur d'origine). Il existe un workaround, qAsConst, pour le détachement inutile, mais là aussi, ça fait du code moche à copier-coller. Et qAsConst ne gère pas les rvalues parce que le futur std::as_const sous discussion ne les gèrera pas et les mêmes développeurs qui remplacent les fonctionnalités Qt par ces horreurs STL sont passés à volontairement limiter les fonctionnalités de Qt pour ne pas dépasser la STL limitée. 
Godzil (./417) :T'es pas obligé de l'utiliser hein, ni de distribuer la lib ave tes projets en fait, non non
Oui genre support du bus CAN
Uther (./416) :
Dans les faits, Qt est aussi un peu une usine a gaz, certes un niveau en dessous de Electron, mais il contient beaucoup trop de chose à mon gout qui vont bien au delà de l'IHM.
Godzil (./428) :Sauf que Qt se veut multi-plateforme et ne peut pas préjuger des interfaces accessibles via le kernel.
tu as deja pletore de lib et d'interface via le kernel qui fontionnent a merveille pour ca
Kevin Kofler (./431) :Heu si justement pour moi tout le problème de Qt est QtCore. QtCore pose tout le cadre qui fait que Qt n'est pas une simple bibliothèque mais une vrai framework avec notamment ses QObject qui se présentent presque comme une modification du langage même.
Et Qt 5 est modulaire, CAN est évidemment un module optionnel à part, mais même QtNetwork est distinct de QtWidgets, seul QtCore est la base minimale que tous les utilisateurs de Qt doivent utiliser, et il n'y a rien de ce que vous critiquez dans QtCore.
Kevin Kofler (./431) :Je l'apprécie aussi beaucoup, dans certaines conditions.
Et personnellement, j'apprécie bien avoir une bibliothèque de classes comparable à celle du Java
Warpten (./20) :Trier à l'insertion n'est pas forcément le plus efficace. Asymptotiquement, c'est au moins en O(log(n)) par insertion, donc au total, on retrouve le O(n log(n)) du tri séparé. Et si on utilise une fonction sort, c'est généralement parce qu'on a utilisé une API externe qui retourne des résultats non triés, ou triés différemment de l'ordre dont on a besoin dans l'application. L'insérer dans un conteneur qui trie à l'insertion veut dire recopier tout le contenu du conteneur, donc au final on recode un sort manuellement, et probablement en moins efficace.
Entre devoir trier un conteneur et passer a un conteneur qui trie a l'insertion, le choix ne se fait pas.
Quand aux foreach...Je suis bien au courant. Mais comme déjà écrit, son fonctionnement est optimisé pour les conteneurs STL et n'est pas pratique pour les conteneurs Qt.
for (auto const& value : container
Et si tu te plains de l'absence de copie, l'idee c'est qu'en C++ on evite les macros, on n'est pas en C ou on peut se permettre de cacher le fonctionnement d'une macro derriere des directives absolument immondes. Il reste des cas ou c'est necessaire pour eviter de copier-coller comme un malade, mais dans l'ensemble, je prefere copier moi-meme et savoir POURQUOI je copie plutot qu'utiliser des macros qui ne disent pas explicitement le detail de ce qu'elles font et me retrouver avec une utilisation de memoire de cingle parce qu'une macro au nom assez innocent fait un truc que je ne veux pas.Mais justement, la "copie" d'un conteneur Qt est une shallow copy qui ne recopie pas les données, c'est ça la génialité de QtCore! Et c'est au contraire l'utilisation directe de container, sans le copier dans une variable const ni même utiliser une référence const, qui risque de recopier les données (appel de la version non-const de la méthode begin()).
Et si t'as besoin d'une copie, auto containerCopy(container) et tu peux iterer dessus...Il faut au moins const auto pour que ça fasse ce que je veux, et qAsConst(container) ou même static_cast<const auto &>(container) sont plus pratiques comme workarounds. Mais ça reste pourri.
Pour les vecteurs, si tu veux les trier... std::set<T>. Tu perds les valeurs en double, mais des valeurs en double n'ont aucun sens dans un contexte de tri.Vive QMultiMap…
Uther (./21) :Pour moi, QtCore est la partie la plus intéressante de Qt, même avant QtWidgets, j'ai déjà fait des projets non-graphiques en C++/QtCore.
Heu si justement pour moi tout le problème de Qt est QtCore. S'il y a avait des libs d'IHM, Réseau, BDD, ... bien séparées, ça serait parfait.
QtCore pose tout le cadre qui fait que Qt n'est pas une simple bibliothèque mais une vrai framework avec notamment ses QObject qui se présentent presque comme une modification du langage même.
Rien que QString est une aberration a mon sens. Certes, y a l'unicode, mais on a aussi std::wstring, ou encore std::u(16|32)string, exotiques mais bien definis (Ce ne sont que des specialisations de std::basic_string<...>. Meme sices types n'ont aucune notion d'encodage, mais c'est voulu, puisque le C/C++ ne voit les chaines de caracteres que comme des tableaux de bytes...
Zerosquare (./26) :Si on a besoin d'un environnement complet à la Java, et que l'on veux bien se plier au fonctionnement du Framework, en effet c'est très bien.
./24 : Mais quel serait l'intérêt d'avoir un framework si les modules ne pouvaient pas s'appuyer sur une base, et devaient donc réimplémenter la roue chacun de leur côté ?
Zerosquare (./28) :Pour l'époque, bien sur que non.
Mais Qt date de 1995, on ne peut pas lui reprocher de ne pas utiliser des choses qui n'existaient pas à l'époque.
Uther (./29) :Alors Qt n'est pas l'outil qu'il te faut, tout simplement. Dans l'absolu c'est dommage (tout comme c'est rageant de tomber sur LE truc qu'il nous faut en .NET quand on n'utilise pas .NET), mais ça ne me semble pas raisonnable de demander à un framework d'être modulaire à 100%.
Le problème c'est que je voudrais parfois faire de l'IHM, ou autre sans avoir a subir le framework et les contraintes qui vont avec.
Uther (./29) :C'est quand même un gros chantier, avec des risques de régressions. Est-ce qu'il y a une vraie demande des utilisateurs de Qt ?
Mais il y a eu plusieurs version de Qt entre temps dont des majeures qui brisaient la compatibilité, ils auraient pu en profiter pour s'intégrer mieux au C++.
)