Version imprimable
Il ne faut pas réver : ils ne vont pas se mettre à supporter les exceptions (et savoir signaler qu'il n'y a plus de mémoire) ou à abandonner le COW pour autant. Pour le premier, ce n'est pas dans leur philo de vieux C++ qu'ils assument, pour le second, il y aurait trop de modif à faire pour continuer à tourner pendant les 10 années à venir sur les compilo 98/03.Citation:
Envoyé par zelegolas2
Sauf que je n'ai pas parlé de Microsoft spécifiquement, mais des raisons qui poussent (pas que Microsoft) à fournir JavaScript comme l'un des languages possibles pour faire des applications natives. Peut importe si Microsoft foire son implémentation, la boite de Pandore c'est d'éffacer la différence de connaissances entre devs d'applications non-web et devs d'applicaitons web pour enrichir les deux cotés.Citation:
Envoyé par zelegolas2
Pour du C++ qui vivais à l'époque ou la STL n'étais pas dispo et où les compilateurs n'implémentaient pas le standard oui.Citation:
Personnellement je trouve leur approche plutôt bien pensé.
Aujourd'hui, c'est juste archaique. On sent qu'il y a eu de l'historique et heuresement qu'ils sont allé dans cette direction au début, mais depuis 10 ans au moins on a de quoi faire du C++ MODERNE et ça visiblement ils vont s'en occuper que dans les versions du future lointain.
Je n'ai pas dit que Qt était archaique par rapport a C++11, il l'est par rapport à C++03. Aujourd'hui, dans GCC 4.4 (on en est à 4.6 comme version stable) on peut faire des smart pointers, du RAII et tout ce qui est idiomatique du C++ sans problème. Ca fait en fait longtemps qu'on peu mais Qt n'en profite à aucun moment. Au contaire, ils encouragent la création de pointeurs bruts qu'on leurs fournis sans être certains du moment où les objets vont être détruits.Citation:
J'ai pas eu de pb avec. C++11 à des features intéressantes, c'est certain, mais il faut aussi savoir les utiliser quand elles sont réellement nécessaires. J'ai trop vue de projets où les gas se mettaient à fumer la moquette en voulant absolument intégrer le dernier truc à la mode alors que c'était pas nécessaire... Je ne parle même pas des "recettes de cuisine" comme les Design Pattern qui la plus part du temps sont employés à tord et à travers. C'est pas parce que certains connaissent par coeur le livre de cuisine qu'ils font de bons cuisiniers !!! 8-)
Actuellement j'utilise pas mal std::unique_ptr qui est dans C++11 mais avant j'utilisais boost::scoped_ptr qui a des similarités et qui combiné avec std::shared_ptr (qui est dans le TR1 de C++03, pas seulement dans C++11), on sait immediatement la durée de vie (logique) d'un objet, en regardant le type de smart pointers. Mais une fois passé a Qt, ben faut attendre un crash pour réaliser que tel objet qt prends l'ownership des objets qu'on lui passe. Mais attention, c'est pas tous les objets qui marchent pareil, donc faut pas se tromper!!!
Ce n'est qu'un exemple d'archaisme de Qt.
C'est juste propice à l'erreur. Mais c'est excusable par l'historique et puis ça reste bien utile, evidemment.
Je ne connaissais pas mais j'avoue que ça ne m'apparait pas comme une solution aussi "générique" que carrément embarquer Chrome dans son application. (voir http://awesomium.com et http://berkelium.com )Citation:
Tu devrais regarder du coté de MoSync ils proposent justement de faire les interfaces en HTML5, javascript. Le code Javascript pouvant accéder à des fonctions compilées en C++. Tu peux aussi regarder du coté de QML si tu reste en Qt.
Mais par contre évidemment sur mobile c'est une autre histoire. Je prends note en tout cas, merci! :ccool:
Pourquoi n'utilise tu pas QtWebKit ? C'est sans doute moins lourd que d'embarquer Chrome dans ton application, non ? Comme c'est aussi basé sur WebKit ça devrait faire la même job que d'embarquer Chrome.Citation:
Envoyé par Klaim
Sinon j'ai mis la main sur un projet fort intéressant si on veut intégrer non pas une client Web mais un petit serveur Web : QtWebApp. Attention on ne parle pas d'intégrer Apache dans son application ! Mais c'est très pratique surtout dans le cas de solutions embarquées. Ça permet avec un simple browser de piloter ces solutions.
Je connais bien QtWebkit et les autres alternatives. Les raisons sont les suivantes :
1. QtWebkit est dépendant de Qt. Je n'ai qu'un unique projet sous Qt. Tous les autres projets nécessitent un rendu sur texture pour être rendu dans un context 3D (OpenGL/DirectX). QtWebkit est juste utile dans le cas où on fait un gui sous Qt, et encore, voir les autres points.
2. QtWebkit ne permet pas (pour l'instant) d'injecter du JavaScript à partir du C++, ni d'enregistrer des callback C++ pour être appelées par le JavaScript. Pour moi, c'est un manque énorme.
3. QtWebkit ne fournis pas tout un tas de features que permet Chromium et qui me sont utiles. Cela étant dis, juste l'affichage web c'est pas mal, mais c'est vraiment peut comparé à ce qu'on peut faire quand on embarque un browser complet (et customisé pour l'application).
Awesomium et Berkelium sont :
1. Agnostiques : ils ne fournissent qu'un buffer graphique et de quoi injecter des informations/entrées à destination du "browser". J'ai embarqué Awesomium dans un jeu, Berkelium dans une application sous Gtk.
2. Permettent d'injecter du javascript depuis le C++ et d'enregistrer des callaback C++ appelées dans le JavaScript - essayez de faire un éditeur de jeu in-game avec ce genre de truc, c'est la fête du slip tellement ça simplifie la vie.
3. Je peu désactiver à mon gréé ce qui n'est pas utile pour une de mes applications.
En échange, Awesomium et Berkelium sont effectivement plus couteux en mémoire et en taille de binaire, mais par contre le rendu est impressionnant de rapidité. Aweomsium est plus "professionnel" que Berkelium mais il faut payer une licence pour avoir accès au source. Il y a des lilcences gratuites pour les petites entreprises/indies et amateurs.
Enfin bref, ce sont des outils plus génériques, tout simplement. Tout dépends des besoins, évidemment.
Là où je me pose une question sur l'intérêt de faire de l'IHM web pour une application qui n'est pas intrinsèquement web, c'est que j'ai l'impression que faire une IHM web est intrinsèquement plus complexe que faire une IHM classique.
Déjà par le nombre de technos différentes à empiler, ensuite par le manque de bibliothèques / la profusion de bibliothèques non adaptées pour tous les contrôles qui sont plus évolués qu'un bouton (des arbres avec support du drag&drop et de l'édition inline, des boîtes de dialogue...), le fait de devoir passer par de la génération de code HTML plus que par de la manipulation directe d'objets pour tout dynamisme dans l'application, les difficultés à accéder aux IHM standard fournies pas la plateforme (dialoguefile/open...).
Je suppose que l'aspect stateless du web n'est pas vraiment un frein dans ce cas là et qu'on devient statefull par l'intermédiaire des callbacks vers notre code.
Je suis globalement ignorant sur le sujet, donc les critiques que je fais sont plus l'expression d'un sentiment diffus qu'une véritable opinion, et je suis tout prêt à les voire démonter les unes après les autres.
Tu n'as pas tord mais dans le cas d'une application il y a différents avantages qui au final simplifient l'ensemble :Citation:
Envoyé par JolyLoic
1. décrire la vue se fait en html uniquement, et ça c'est simple (c'est juste des déclarations de blocs d'elements)
2. le css est le language pour définir comment visuellement tout apparaitrat (le "thème graphique") et ça du coup ça peut être totalement délégué à un graphiste qui saura souvent déjà faire du css
3. tous les éléments dans ta page web sont des objets accessible javascripts (donc là je pense que ce n'est pas très clair pour toi, mais dis toi que le html est une liste de déclarations d'objets accessible en javascript)
4. C++ a boost, JavaScript a JQuery. JQuery est omniprésent sur les sites modernes, et permet de manipuler la page web d'une façon tellement simple que je suis encore souvent impressionné.
5. JQuery a une extension qui fournit du GUI : JQueryUI. Du coup quitte a faire un choix, autant commencer par là.
6. TRES IMPORTANT : le feedback des modifications du développeur est immédiat; tuchanges un fichier, tu recharges, c'est visible. C'est plus dur a faire dans les autres contextes de GUI parceque ça suppose un language de script ET un moyen de tout réinterpréter "à la volée" - et c'est ce que tente de faire Qt avec QML, intégration JavaScript et autres à ce que j'ai compris.
Donc en fait une fois le système mis en place, ça coute pas plus cher que d'avoir un système de script spécifique au comportement visuel.
Cela étant dis, je ne pense pas qu'une IHM totalement web soit utile pour tout. Par exemple dans mon jeu je l'utilise pour tout ce qui est interractinos complexes, ce qui nécessite rééllement du "gui". Comme je suis en 3D, ça m'arrange de ne pas avoir a ajouter un plugin spécifique pour le GUI qu'un graphiste aura du mal a comprendre parceque presque personne ne l'utilise. CSS a l'avantage d'être bien connu des graphistes.
En revanche pour beaucoup d'éléments d'interface du jeu je n'utilise pas ce genre de trucs parceque c'est trop lourd pour ce dont j'ai besoni (ce qu'on appelle le Heads Up Display).
J'ai aussi besoin d'afficher de vrai pages webs online donc dans l'ensemble je suis bien content que ça fasse le travail à ma place.
Sinon l'autre chose c'est que si tu t'en tiens exclusivement au comportement graphique coté web (puisque c'est l'équivalent de la partie "client" d'une application web normale) alors l'essentiel de ce qui est important reste dans ton code d'application, et la séparation est très bien délimitée.
C'est exact sauf que depuis des années on utilise AJAX (en gros on demande des infos aux serveurs en javascript et on les utilise dans la page client sans recharger quoi que ce soit) et du coup ça reviens au même que dire qu'on peut faire des applications stateful en web. Remplace le serveur par le C++ de ton application et tu as la même chose (mais via des callbacks au lieu d'AJAX).Citation:
Je suppose que l'aspect stateless du web n'est pas vraiment un frein dans ce cas là et qu'on devient statefull par l'intermédiaire des callbacks vers notre code.
Heu, tu peux appeler une fonction JS depuis C++ via Qt. C'est d'ailleurs assez pratique pour balancer de la donnée à une fonction qui attend du JSON.Citation:
Envoyé par Klaim
Et surtout, tu as l'inverse que je n'ai pas vu dans Awesomium. Tu peux appeler les QObject depuis JS ce qui peut être pas mal pour des plugins écrits en JS.
Du coup, tu ne dois pas avoir trop de mal à faire un objet de type callback en C++ pour du JS.
Note que pour l'appel JS => C++ on touche à l'absence de réflexion/introspection en C++ et sans MOC (ou langage en surcouche type C++/CLI), je doute qu'on échappe à un fastidieux enregistrement manuel bien plus lourdingue qu'un héritage et deux macros...
S'il manque un truc à C++, ce n'est pas un GC, mais cette réflexion/introspection sur les classes de haut niveau.
Elle permettrait de monter facilement des systèmes de serialization/deserialization en présence de polymorphisme (où au passage, on a alors besoin d'un Object en classe mère pour ne pas renvoyer un any à la lecture...), des langages de script et du RPC capable d'attaquer du C++ sans exposer 20.000 fonctions et classes manuellement, etc...
Pour awesomium voir : http://awesomium.com/docs/1_6_3/cpp_...327aad855ab911Citation:
Envoyé par bretus
Alier les QObject avec le javascript c'est bien gentil mais ça m'apparait un dépassement de bornes entre la vue et le reste.
Pour moi c'est un défaut de design.
Notemment, j'ai vu beaucoup de bibliothèques de réplication (via réseau) fournir ce genre de feature et au final ceux qui les ont utilisés sont tous revenu en arrière dans de nouveaux projets. Parceque c'est passer des messages qui peu marcher, pas répliquer les objets.
Je ne suis pas d'accord du tout avec ça. Dans toutes les utilisations que j'ai fait au final la communication entre les différents modules (au sens le plus abstrait du terme) se fait par "message", autrement dit dans le cas dde javascript <=>C++ il a été carrément plus simple de définir des fonctions simples a appeler dans les deux cas et laisser chaque coté agire à sa guise.Citation:
Note que pour l'appel JS => C++ on touche à l'absence de réflexion/introspection en C++ et sans MOC (ou langage en surcouche type C++/CLI), je doute qu'on échappe à un fastidieux enregistrement manuel bien plus lourdingue qu'un héritage et deux macros...
Faire de la reflexion à ce niveau là c'est du couplage "trop" fort.
Sur le long terme, c'est malsain.
Personellement c'est le moindre de mes soucis concernant ce dont le C++ a besoin, mais c'est un autre sujet.Citation:
S'il manque un truc à C++, ce n'est pas un GC, mais cette réflexion/introspection sur les classes de haut niveau.
Tout dépend de la nature des scripts qui manipulent tes objets C++. Si ce sont des vues, alors, oui, tu peux estimer qu'il y a un couplage fort (en opposition à un couplage faible où la vue n'accède pas "aux modèles")Citation:
Envoyé par Klaim
En revanche, si tes scripts sont des extensions de ton application, c'est tout simplement une fonctionnalité où tu offres une API dans le langage de script pour le développement de module complémentaire sans passer par C++ et les joies de la compilation de plugin.
En exposant une batterie de fonction simples, tu te retrouves ni plus ni moins à exposer une interface C-like non? Tes messages, ils n'encoderaient pas des objets par hasard?Citation:
Je ne suis pas d'accord du tout avec ça. Dans toutes les utilisations que j'ai fait au final la communication entre les différents modules (au sens le plus abstrait du terme) se fait par "message", autrement dit dans le cas dde javascript <=>C++ il a été carrément plus simple de définir des fonctions simples a appeler dans les deux cas et laisser chaque coté agire à sa guise.
Non parcequ'un "message" est tout simplement un arbre de string, entiers, flottants et d'autres arbres, rien d'autre. Une fois le message reçu on peut reconstituer un objet d'un coté ou de l'autre.
Personnellement pour aller plus vite je passe des données en json, parfois à l'aide de boost::property_tree.
Cela étant dis, cela suppose que ce sont des messages "dynamiques" contrairement aux messages "statiques" qu'on peut mettre en place comme dans boost::statechart ou boost::msm. Le truc c'est que pour s'interfaçer avec une vue, même de c++ à c++, mieu vaut que ces messages ne soient pas des types statiques parceque souvent ça mène à des problèmes de couplage et à une maintenance ralentie.
Je n'utilise jamais les widgets webs ou autres browsers embarqués qu'autrement que comme des vues totalement séparées du reste de l'application, parcequ'autrement ça ne peut pas fonctionner à long terme :aie: (en supposant qu'un projet évolue).
EDIT : au fait je ne vois pas dans la doc de l'api les fonctions dont tu parlais concernant QtWebkit pour les communications avec JavaSCript, tu peux me les indiquer stp?
Bonsoir,
Donc c'est un objet sérialisé... Je t'avoue que je suis encore assez fan.Citation:
Envoyé par Klaim
En même temps, quand les modèles échangés sont modifiés, il n'y a pas de magie en terme de maintenance...Citation:
Envoyé par Klaim
Appel JS d'une page :Citation:
Envoyé par Klaim
Ajout QObject en temps qu'objet JS scriptable :Code:
2
http://doc.trolltech.com/4.6-snapsho...ptWindowObject
On a plus de possibilités avec le moteur ECMAScript (QScriptEngine) seul :
http://doc.qt.nokia.com/latest/scripting.html
http://doc.qt.nokia.com/latest/scrip...en-in-qtscript
Bye
C'est un peu l'hopital qui se fout de la charité. :mrgreen:Citation:
Envoyé par bretus
C'est un message, peu importe sa structure, ce n'est pas un objet coté C++. Par exemple, tu peux représenter le message en objet sérialisé si tu n'as que ça a faire, en property_tree ou encore en texte brute ou enfin si tes infos sont à plat tu peux tout simplement appeler une fonction avec de sparamettres.
Perso je n'ai jamais eu besoin de faire de la sérialisation, j'interprete le message dans une fonction et c'est tout.
Dans le cas de Qt cela fait un couplage direct avec un QObject. C'est juste malsain sur le long terme parceque ça fait un couplage fort, mais j'imagine que ça ne se comprends qu'avec de gros projets.
Une meta-note/remarque sur ce que tu as dis précédemment concernant le "c-like" :
- il n'y a rien de mal à n'utiliser que des fonctions dans un language qui le permet et même l'encourage quand les autres abstractions sont juste inutiles, comme par exemple, en C++. Eh oui le C++ ce n'est pas juste de l'objet, c'est procédural, objet, template, programmation générique/meta-prog, un poil de fonctionel (à la compilation), etc. Le fait est que la programmation orienté-objet est très utile pour régler une catégorie de problemes et les autres paradigmes sont très utiles pour régler d'autres catégories de problèmes et comme la plupart des systèmes que nous mettons en place sont en réalité des problèmes complexes constitués de sous-problemes simples, ces problèmes simples peuvent être résolus par divers solutions AUTRE QUE L'OBJET. Voilà où mène l'abus de Qt, à une vision uniquement objet en C++.
- utiliser quasimment que des fonctions en C++ n'est pas forcément "C-like" : si tu utilises les algorithms STL, si tu utilises des objets que tu n'as pas déclaré dans ton projet comme les conteneurs STL mais que ton projet peut être simplement structuré en quelques sets de fonctions parceque c'est du traitement brute sans vraiment d'états, ce n'est pas du C, et ça reste des fonctions. Souvent on mélange fonctions, objets, etc, comme je disais au dessus parcequ'on arrive a combiner les meilleurs solutions aux différents problèmes. Le "C-like" c'est complètement différent, c'est plutot utiliser les tableaux natifs, tout manipuler par pointeurs brutes, etc.
Ce n'est pas ce que je sous-entendais et je suis d'accord. Non c'est la manière dont les données sont traitées qui change et qui est elle dynamique et peut s'adapter aux cas généraux, notemment si le protocole de communication permet quelque chose d'équivalent au duck-typing. En C++ le duck-typing est possible uniquement au niveau de la compilation donc ça limite fortement l'interet.Citation:
En même temps, quand les modèles échangés sont modifiés, il n'y a pas de magie en terme de maintenance...
Donc c'est juste "mieu" que des messages statiques, simplement parcequ'un environnement visuel dynamique a besoin d'être "volatile" dans son execution et sa communication.
Merci pour les infos sur QtWebkit. :ccool: