Posté le 23/08/2017 à 13:57 Membre depuis le 27/10/2001, 493 messages
Zeph a souhaité poursuivre une discussion dérivée dans un nouveau sujet. La discussion initiale a eu lieu dans le sujet topics/185087-mais-le-developpement-front-end-est-un-bordel-sans-nom/15#post-433 tandis que la discussion dérivée continue dans le sujet topics/188375-c-stl-vs-qt où les messages en rapport ont été copiés.
avatarBen, bouh, quoi :D
Posté le 22/08/2017 à 13:57 Membre depuis le 27/04/2006, 59488 messages
https://dev.to/bitario/in-defense-of-electron
TL;DR coucou Zeph tongue : "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."
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Posté le 22/08/2017 à 14:39 Membre depuis le 10/06/2001, 40014 messages
sick C'est l'apologie de l'usine à gaz. bang

Et son argument de portabilité ignore l'existance de C++/Qt qui permet de développer pour toutes les plateformes desktop qu'il vise, y compris iOS et Android qui sont à part, ça ferait 2 versions (web et desktop) au lieu de 3.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Posté le 22/08/2017 à 14:46 Membre depuis le 10/06/2001, 8784 messages
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.
avatar
Posté le 22/08/2017 à 14:47 Membre depuis le 30/06/2001, 70810 messages
Oui genre support du bus CAN trifus
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 22/08/2017 à 14:51Edité par Kevin Kofler le 22/08/2017 à 15:13 Membre depuis le 10/06/2001, 40014 messages
Dans les commentaires, il dit que Qt est trop cher, alors qu'il existe la version LGPL gratuite et parfaitement utilisable dans des applications propriétaires commerciales. J'ai posté un commentaire à ce sujet.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Posté le 22/08/2017 à 15:01 Membre depuis le 10/06/2001, 44321 messages
Uther (./416) :
il contient beaucoup trop de chose à mon gout qui vont bien au delà de l'IHM.
C'était juste l'IHM au début ?
Je trouve que l'IHM est un élément comme un autre, tout le reste est justement une bonne chose, la STL c'est bien gentil mais c'est vraiment vide — et pas intuitif à utiliser.
Posté le 22/08/2017 à 15:29 Membre depuis le 10/06/2001, 8784 messages
Non en effet il prend en charge beaucoup de choses qui manquaient à la STL a une époque. Ceci dit, Ils auraient quand même pu faire un effort pour intégrer proprement ce qui est standard.
avatar
Posté le 22/08/2017 à 17:44 Membre depuis le 13/06/2002, 42484 messages
Zerosquare (./414) :
coucou Zeph tongue
Merci love (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 ^^)
avatarAll right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)
Posté le 23/08/2017 à 02:56 Membre depuis le 10/06/2001, 40014 messages
Uther (./420) :
Ceci dit, Ils auraient quand même pu faire un effort pour intégrer proprement ce qui est standard.
sick 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.

Qt a déjà déprécié certaines choses au profit de la version STL et à chaque fois, ça a empiré les choses. Par exemple, la plupart du header QtAlgorithms a été déprécié, et du coup, à la place de qSort(foo), il faut écrire std::sort(foo.begin(), foo.end()). mur 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. mur

Bref, à mort la STL et non au remplacement de Qt par ses horreurs illisibles! vtff
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Posté le 23/08/2017 à 06:34 Membre depuis le 18/06/2001, -26239 message
Godzil (./417) :
Oui genre support du bus CAN trifus
T'es pas obligé de l'utiliser hein, ni de distribuer la lib ave tes projets en fait, non non grin
Ils développent de ce côté parce qu'ils entrent dans le marché de l'embarqué. Par exemple au boulot, on a des automates dont les interfaces sont en Qt. Et d'ailleurs, ça change des interfaces 1990 façon Schneider ou Siemens sick
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 23/08/2017 à 10:13 Membre depuis le 30/06/2001, 70810 messages
Mais c'est un truc super low level qui a a foutre dans le kernel pas dans une lib GUI!
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 23/08/2017 à 10:54 Membre depuis le 13/06/2001, 72568 messages
Mais justement, Qt n'est pas (plus) qu'une lib GUI. C'est un framework qui propose des widgets, des API réseau, bases de données, etc.
avatar
Posté le 23/08/2017 à 11:36 Membre depuis le 10/06/2001, 8784 messages
CQFD :
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.
avatar
Posté le 23/08/2017 à 11:42 Membre depuis le 13/06/2001, 72568 messages
Ce qui est normal vu que ce n'est pas (plus) une lib d'IHM !

(goto 0 cheeky )
avatar
Posté le 23/08/2017 à 11:43 Membre depuis le 30/06/2001, 70810 messages
BDD la raison est simple, tu as tout un set de widget (un widget est un element de la GUI) qui sont dedié BDD, ca me parais logique qu'il y ai un support, meme basique, d'ailleurs ca fait partit des widgets les plus anciens sur l'environement Windows (on en trouve des Windows 3)

API reseau est discutable, tres discutable, mais au moins le TCP/IP est standard. le bus CAN si le Phy est standard, ce qu'on y discute la ne l'est pas, chacun fait a sa sauce, donc une lib a ce niveau n'a aucun interet, tu as deja pletore de lib et d'interface via le kernel qui fontionnent a merveille pour ca
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 23/08/2017 à 11:45 Membre depuis le 13/06/2001, 72568 messages
Godzil (./428) :
tu as deja pletore de lib et d'interface via le kernel qui fontionnent a merveille pour ca
Sauf que Qt se veut multi-plateforme et ne peut pas préjuger des interfaces accessibles via le kernel.
avatar
Posté le 23/08/2017 à 12:02 Membre depuis le 30/06/2001, 70810 messages
Sauf que le bus CAN ne fonctionnera pas en mode utilisateur donc une lib universelle tu peux oublier smile
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Posté le 23/08/2017 à 12:48 Membre depuis le 10/06/2001, 40014 messages
C'est une couche d'abstraction qui utilise les interfaces natives en dessous.

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.

Et personnellement, j'apprécie bien avoir une bibliothèque de classes comparable à celle du Java (même plus puissante par endroits, Qt fait certaines choses pour lesquelles il faut des JARs externes en Java) en C++, la STL est beaucoup trop limitée.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Posté le 23/08/2017 à 13:48Edité par Warpten le 23/08/2017 à 13:59 Membre depuis le 24/04/2009, 2514 messages
Entre devoir trier un conteneur et passer a un conteneur qui trie a l'insertion, le choix ne se fait pas.

Quand aux foreach...

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.

Et si t'as besoin d'une copie, auto containerCopy(container) et tu peux iterer dessus...

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.
Eti si tu as simplement besoin de valeurs uniques sans tri, std::unordered_set<T>
Posté le 23/08/2017 à 13:50Edité par Uther le 23/08/2017 à 14:24 Membre depuis le 10/06/2001, 8784 messages
Kevin Kofler (./431) :
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.
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.
Alors que parfois je veux juste une lib d'IHM, Réseau, BDD, ... sans que ça ait d'impact sur le fonctionnement du projet.

Kevin Kofler (./431) :
Et personnellement, j'apprécie bien avoir une bibliothèque de classes comparable à celle du Java
Je l'apprécie aussi beaucoup, dans certaines conditions.
Le problème de Qt c'est que c'est construit comme framework qui apporte donc une certaine lourdeur, un peu comme Électron en fait (en un peu moins grave quand même).
avatar
Posté le 23/08/2017 à 14:16 Membre depuis le 10/06/2001, 40014 messages
Warpten (./20) :
Entre devoir trier un conteneur et passer a un conteneur qui trie a l'insertion, le choix ne se fait pas.
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.

Quand aux foreach...

for (auto const& value : container
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.

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 QMultiMaptongue
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Posté le 23/08/2017 à 14:17 Membre depuis le 10/06/2001, 40014 messages
Uther (./21) :
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.
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.

J'aime bien le C++ en tant que langage, même s'il n'est pas parfait (mais tous les autres langages objet que je connais sont pire), mais je déteste la STL.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Posté le 23/08/2017 à 16:05 Membre depuis le 10/06/2001, 8784 messages
Je ne dis pas que QtCore ne peut pas avoir d’intérêt, il y a des choses intéressantes dedans, je trouve juste dommage qu'elle soit la base de tout Qt et qu'on se trouve obligé de la subir même si on fait quelque chose qui pourrait très bien s'en passer.
avatar
Posté le 23/08/2017 à 16:15Edité par Warpten le 23/08/2017 à 16:19 Membre depuis le 24/04/2009, 2514 messages
QMultiMap -> (unordered_)?multimap
Les conteneurs tries de la STL sont, pour autant que je sache, quasiment tous des hash map, des arbres binaires ou des listes liees (ou se comportent comme tels), donc y a rien a bouger en mémoire, juste des pointeurs a changer.

./24 pencil 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...

Et WTF? f8fhNbk.png

Je suis en revanche d'accord pour dire que <iostream> et les differentes versions de <fstream> ne sont que des horreurs. Pour avoir essaye d'ecrire mes propres facet, c'est absolument inutilisable.
Posté le 23/08/2017 à 16:17 Membre depuis le 27/04/2006, 59488 messages
./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é ? confus
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Posté le 23/08/2017 à 16:20 Membre depuis le 24/04/2009, 2514 messages
Ben, la base serait la STL, non?
Posté le 23/08/2017 à 16:25 Membre depuis le 27/04/2006, 59488 messages
Mais Qt date de 1995, on ne peut pas lui reprocher de ne pas utiliser des choses qui n'existaient pas à l'époque.
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Posté le 23/08/2017 à 16:29 Membre depuis le 10/06/2001, 8784 messages
Zerosquare (./26) :
./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é ? confus
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.
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.

Zerosquare (./28) :
Mais Qt date de 1995, on ne peut pas lui reprocher de ne pas utiliser des choses qui n'existaient pas à l'époque.
Pour l'époque, bien sur que non.
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++.
avatar
Posté le 23/08/2017 à 17:01 Membre depuis le 27/04/2006, 59488 messages
Uther (./29) :
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.
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%.

Uther (./29) :
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++.
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 ?
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo