Faire du réseau de manière portable en C++, ça va devenir une réalité ! Le travail se fait dans une spécification technique (TS), c'est-à-dire dans une bibliothèque annexe qui sera figée pour C++17 et mise dans un namespace explicite : std::experimental.
Concrètement, la proposition qui en est à sa troisième révision, est largement fondée sur Boost.Asio qui, comme son nom ne l'indique pas, permet de faire à la fois du synchrone et de l'asynchrone. Elle me semble pour l'instant assez complète et permet de traiter tout un tas de cas d'usages.
Ce qu'on peut dire, c'est qu'il était temps d'avoir cette bibliothèque dans C++. Et toi, journal, tu en penses quoi ?
# Boule de cristal
Posté par Dring . Évalué à 10.
2017: une première version officielle est disponible dans GCC.
2020: tous les compilateurs majeurs proposent des versions plus ou moins compatibles. Microsoft a rajouté 2/3 options et supporte mal la création d'un socket. LLVM est en train d'expérimenter une implémentation de ipot.
2028: tous les compilateurs sont compatibles. Une nouvelle TS a vu le jour pour améliorer la première. Mais peu de personnes ont changé leurs habitudes ; Qt utilise toujours son implémentation maison car les libs standards ne supportent pas bien les architectures 128 bits.
2053: Décès de Bjarne Stroustrup à l'âge de 103 ans. Le C++ est abandonné.
[^] # Re: Boule de cristal
Posté par barmic . Évalué à 9.
Il y a quelque chose d'assez marrant. C'est que les nouveautés viennent souvent/régulièrement de boost et jamais de Qt alors que cette dernière est massivement utilisée et qu'elle est multiplateforme.
Je présume que c'est parce que ceux qui font boost sont dans le comité de standardisation et/ou en sont proche, mais il n'y a vraiment aucune discussion avec Digia pour un rapprochement ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Boule de cristal
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 24 novembre 2014 à 10:25.
Boost suit de manière très forte le style de la STL (la bibliothèque standard), et ce depuis le début : ce n'est pas parce que Boost est copain avec le comité que les idées de Boost sont acceptées mais parce que le comité a son boulot prémaché par Boost, bref l'un s'est adapté à l'autre pour être accepté.
L'esprit de Qt est à l'opposé, avec peu d'utilisation de la STL. Pas spécialement parce qu'ils ne veulent pas, mais plutôt parce que d'une la STL était pauvre quand Qt a commencé (poids de l'histoire) et que Qt est axé GUI qui est loin d'avoir autant d'unaminité que des classes non GUI (tu noteras que Boost ne touche pas aux GUIs) surtout que les GUI bougent beaucoup plus (un réseau, c'est assez stable comme interface, une UI ça bouge vite, très vite…).
A noter aussi que commercialement c'est dangereux d'être standardisé (rappel : Qt est sous LGPL et parfois non libre, Boost est sous copyfree), on est "dilué" au niveau de la marque, donc pas forcément de motivation pour.
PS : ça doit faire 15 ans que je lis que le C++ va prochainement mourir, rien de nouveau dans les "blagues" et C++ ou C sont toujours la dès qu'on a besoin de code qui passe partout et n'est pas à jeter à chaque changement de mode…
[^] # Re: Boule de cristal
Posté par devnewton 🍺 (site web personnel) . Évalué à -8.
Et c'est bien dommage! Une lib de qualité pour les UIs, ça manque!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Boule de cristal
Posté par fearan . Évalué à 5.
je dirai que Qt réponds très bien aux besoins d'UIs ;)
Le seul truc c'est que quand on code avec Qt, on a tendance à laisser la stl de coté…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Boule de cristal
Posté par reynum (site web personnel) . Évalué à 2. Dernière modification le 25 novembre 2014 à 15:54.
C'est pas l'idée du patern MVC ?
faire V avec QT et faire C avec la stl ? (et puis M avec un SGBD existant ou des fichiers texte comme XML)
kentoc'h mervel eget bezan saotred
[^] # Re: Boule de cristal
Posté par fearan . Évalué à 3.
l'énorme intérêt de Qt, c'est ne pas changer de paradigme d'un bout à l'autre; Quiconque a joué avec Xercesc/Xalan avec les traduction de XmlCh* (qu'il faut penser à libérer ou pas), comprends qu'avoir un ensemble homogène est un grand plus.
Si je joue avec des QString (avec split, QRegExp, arg) c'est la Même QString d'un bout à l'autre, pour les map tu as QMap, pour les set QSet…
avec les fonctions qui vont bien (intersect, substract, contains(QSet)…
Bref à partir du moment où Qt est dans la place, c'est ballot de pas l'utiliser.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Boule de cristal
Posté par reynum (site web personnel) . Évalué à 3.
Je ne vois pas ce que le paradigme vient faire là dedans ?
Que ce soit avec QT ou avec la STL ou même avec Boost on fait presque que de l'impératif et de l'objet.
MVC est un design pattern (Patron de conception) qui sont précisément utilisés pour avoir des ensembles homogènes
kentoc'h mervel eget bezan saotred
[^] # Re: Boule de cristal
Posté par fearan . Évalué à 4.
Justement quand tu joues avec Qt, tu utilises QString, QList, QMap, QSet, QRegEx, QStringList, QVector… la stl s'applique moins facilement, et surtout est généralement déjà couverte, par ailleurs tous les conteneur Qt implémentent la copy-on-write.
Quand je parle de paradigme, il ne faut pas comprendre objet/fonctionel/impératif ou autre, mais de philosophie sous-jacente. J'ajouterai que la QMap à un operator const, qui manque cruellement à la std::map (non find ne répond pas au besoin), et si y a besoin de filer le truc à un bibliothèque externe, ou même à la stl on a toujours le toStdMap.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Boule de cristal
Posté par neil . Évalué à 2. Dernière modification le 26 novembre 2014 à 20:12.
J’imagine que tu parles de
operator[] constdans Qt, qui peut retourner une valeur par défaut (pour certains types seulement!), alors que la STL est basée sur des itérateurs, avecfindouequal_rangequi en retournent (même s’il existeatqui lance une exception). L’un des avantages de la STL est de s’appuyer sur une théorie des itérateurs validée par la pratique et bien définie, décrite par exemple dans les travaux de Stepanov, notamment son Elements of Programming.Si vraiment on veut faire du C-style, C++ permet de définir cet opérateur en une petite ligne de code, et rien n’empêche soumettre une proposition rajoutant ce manque « cruel » au comité C++, le développement actuel du langage étant relativement ouvert.
[^] # Re: Boule de cristal
Posté par rewind (Mastodon) . Évalué à 9.
Il y a un groupe de travail nommé SG13, dont le but est de travailler à avoir du graphique dans la bibliothèque standard. Certes, ça n'ira sans doute pas jusqu'à une GUI, mais c'est un début. Les spécifications techniques sont issues de ces groupes de travail.
Bon, pour l'instant, je dois dire que je suis assez déçu par les travaux engagés. Ils sont partis sur définir une API de dessin à partir de cairo. Mais du coup, on ne sait pas à quoi s'applique cette API : écran, fichier ? Et malgré toutes les interventions sur la liste disant que ce n'est pas la bonne direction ni la bonne méthode, ils persistent. Certains avaient même bien fait l'état des lieu : ce qui est difficile actuellement, c'est d'obtenir une fenêtre (et c'est pas là dessus qu'un système se différencie de nos jours, c'est un peu la base), pouvoir ensuite y créer un contexte de dessin (que ce soit pour OpenGL, DirectX ou cairo, peu importe), et pouvoir récupérer les événements sur cette fenêtre.
[^] # Re: Boule de cristal
Posté par chubinou . Évalué à 3.
Le comité de standardisation du C++ avait commencé à étudier la possibilité d'intégrer une bibliothèque graphique dans son standard. Je ne sais pas trop où cela en est à l'heure actuelle. lien vers la proposition
C'est basé sur l'API de cairo et est donc beaucoup plus bas niveau qu'un Qt Gtk ou autre.
[^] # Re: Boule de cristal
Posté par neil . Évalué à 2. Dernière modification le 24 novembre 2014 à 19:28.
Proposition remplacée par la N4073, avec toujours la même implémentation. On peut noter les dépendances insolites à Gtk+ pour la version Linux, alors que la proposition se limite au rendu graphique (laissant le fenêtrage et les interactions à d’autres groupes de travail).
[^] # Re: Boule de cristal
Posté par barmic . Évalué à 6.
C'est une histoire de poule et d'oeuf. Je ne pensais pas à une question de passe droit.
Ouai s'il ne faut plus considérer la STL comme elle l'était il y a 15 ans, il faut en faire de même avec Qt qui est découpé et qui possède les bibliothèques qui n'ont rien avoir avec l'UI. Ici je pense en particulier à QtNetwork.
Standardisé probablement pas (Qt ne respecte même pas les conventions de nommage qu'on trouve dans std), mais plus d'avoir des discussions pour qu'au lieu de se contenter de porter une lib boost, on discute avec la communauté pour savoir si ça couvre leur besoin. L'idée serait de vider QtNetwork de sont contenu pour qu'il ne devienne qu'une glue entre l'API Qt et le standard. Donc il n'est ni question de reprendre du code, ni de copier les API, mais plus de comment est-ce que les gens qui font l'un des frameworks C++ les plus utilisés ne communiquent apparemment pas avec le comité de standardisation ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Boule de cristal
Posté par Philippe F (site web personnel) . Évalué à 10.
Qt dépend très très fortement de son coeur en Qt (avec du QObject, un préprocesseur maison et une boucle d'évènement à la Qt). Ceci le rend très peu généralisable.
Pour donner un exemple concret, une string en Qt, c'est une suite de caractère avec un encodage connu, que tu peux convertir dans d'autre encodages (latin1, utf8, …). En STL, une string, c'est un tableau de caractère dont l'encodage est inconnu et varie d'un système à l'autre, et varie aussi suivant les options du compilateur. Il est donc a priori impossible de convertir une string STL en string Qt (sans apport d'information extérieur).
Dans la couche réseau de Qt, tu trouveras tout un tas d'autres limitations, lié en général au fait que Qt fait des choix explicites alors que la STL a une approche "ouverte" dans laquelle tu peux plugger le choix que tu veux.
Ca ne veut pas dire qu'il n'y a pas d'échange de bon procédés. Quand tu vois des blog de développeurs Qt, tu constates qu'ils passent à la loupe la STL avant de faire leur choix en terme de techno, d'implémentation, etc etc. Et dans l'autre sens, certaines idées intéressante de Qt ont été reprises dans boost sous une forme plus STL: je pense au célèbre mécanisme signal/slot de Qt, qui dépend du préprocésseur de Qt, et était donc inutilisable en contexte boost/STL. L'idée a quand même plu puisque quelques années après la croissance en popularité de Qt, une implémentation en style boost/STL est apparue (template à mort, pas de préprocesseur): http://www.boost.org/doc/libs/1_57_0/doc/html/signals.html .
[^] # Re: Boule de cristal
Posté par Tit . Évalué à 0.
Ton PS répond à quoi? Dring FirebirdVsMySql pronostique l'abandon du C++ en 2053, c'est que tu entends par "prochainement"
[^] # Re: Boule de cristal
Posté par rewind (Mastodon) . Évalué à 7.
Tu a oublié une date.
2014 : une implémentation de référence pour les principales plateformes et avec une licence qui va bien (Boost). Alors bon, il faudrait vraiment le faire exprès pour ne pas avoir une implémentation dans les principaux compilateurs d'ici 2017.
# c'est bien
Posté par maboiteaspam . Évalué à 1.
Que ce soit standardisé. C'est une brique importante, et tellement omniprésente.
Cela devrait permettre au développement open source de mieux pénétrer les environnements windows.
Espérons que cette réussite soit reproduite aussi souvent que possible.
En ce qui me concerne, j'espère que cela améliorera les bindings bas niveaux que j'utilise avec nodejs : D
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.