Journal Sortie de exxEditor - version 0.9

Posté par .
Tags : aucun
24
17
août
2010
Bonjour,

J'ai développé un logiciel, et je pense qu'il pourrait être utile à certains.

Historique
Je travaille dans une équipe de recherche qui développe un simulateur de croissance de plantes: digiplante. Ce simulateur pour fonctionner à besoin de paramètres complexes en entrée. La liste et le type des paramètres sont amenés à être modifiés assez fréquemment (au cours des développements et des travaux de recherche). Nos paramètres sont stockés dans un fichier XML, or comme tout le monde le sait XML c'est pas très pratique à éditer à la main (particulièrement lorsque on s'adresse à des non-informaticiens). Il nous fallait donc une solution souple permettant de saisir les paramètres et donc de créer le fichier XML.

Le logiciel exxEditor
Pour résoudre se problème, nous avons développé exxEditor, un "éditeur" XML, qui génère une interface en lisant un fichier XML Schema. On a ainsi une interface qui affiche l'arbre des paramètres, et permet de les modifier. Bien entendu, exxEditor fait en sorte que l'utilisateur ne puisse pas entrer des valeurs non valides. Pour ce rendre compte de quoi il s'agit, rien de mieux qu'une copie d'écran.
Vous pouvez télécharger exxEditor sur le site du projet.
La gestion du projet ce fait sur la Gforge INRIA.

Licence
exxEditor est sous licence CeCILL-C (type LGPL).

Technique
exxEditor est développé en C++ avec Xerces pour la "décomposition analytique" XML, Qt pour l'interface et Boost pour un peu tout le reste. On utilise CMake comme système de configuration. ExxEditor est multi-plateforme (Linux - Windows - MacOs).
ExxEditor est conçu de manière à pouvoir s'intégrer facilement dans une application Qt.

Avancement et version
exxEditor est maintenant en version 0.9 (comprendre en Beta), et lorsqu'il sera un peu mieux testé et débogué, il passera en version 1.0. Bien que le logiciel ne soit pas capable d'interpréter l'ensemble de la norme XML Schema, je ne compte pas ajouter de nouvelles fonctionnalités avant la version 1.0. En effet, il répond déjà parfaitement à mes besoins, et presque toutes les fonctionnalités basiques de XML Schema sont supportées.

Liens
Captures d'écran [http://dgp-public.gforge.inria.fr/fr/capture_ecran.html].
Téléchargements [http://dgp-public.gforge.inria.fr/fr/telechargement.html].
Site officiel [http://dgp-public.gforge.inria.fr/fr/index.html].
Licence CeCILL-C [http://www.cecill.info/licences/Licence_CeCILL-C_V1-fr.html]
  • # Qt mais pas complètement ?

    Posté par (page perso) . Évalué à 8.

    Bonjour,

    Je n'ai pas encore lu le code de ce logiciel, mais ça m'étonne un tout petit peu de le voir utiliser Qt, ainsi que deux autres dépendances qui ont de beaux modules Qt qui les remplacent.

    Par exemple, QtXml propose un arbre DOM mais aussi une interface en flux. QtXmlPatterns propose tout ce qu'il faut pour gérer les schémas XML. Je ne sais pas quelles parties de Boost sont utilisées, mais les regexp, les signaux et les slots sont proposés par Qt.

    Pour ceux qui disent que Qt est trop lent, c'est son DOM qui est lent (instanciation de QObject en série), pas l'interface par flux, qui est très rapide.

    Ce n'est absolument pas une critique, je suis juste un peu étonné.
    • [^] # Re: Qt mais pas complètement ?

      Posté par . Évalué à 10.

      Il y a principalement 2 raisons pour ne pas avoir utilisé Qt pour l'ensemble du logiciel.

      La première est "historique". Quand j'ai commencé à développé exxEditor, je ne connaissais pas suffisamment Qt et surtout j'ai commencé le développement avant d'avoir choisi quelle bibliothèque j'allais utiliser pour la GUI.

      Ensuite la deuxième raison est une question d'organisation du code. Le code est organisé en packages et je voulais être sûr que les basses couches ne dépendaient pas du toolkit graphique.
      Je reconnais que ça peu être limite comme argument, comparé à avoir 2 dépendances supplémentaires.

      En fait j'utilise Qt comme un toolkit graphique uniquement, et non pas comme une plateforme complète de développement d'application.
      • [^] # Re: Qt mais pas complètement ?

        Posté par (page perso) . Évalué à 2.

        Un petit bug report: Sur les captures d'écran il me semble qu'il faudrait "Ecophysiologie" et pas "Echophisiologie" non ?
      • [^] # Re: Qt mais pas complètement ?

        Posté par (page perso) . Évalué à 4.

        > En fait j'utilise Qt comme un toolkit graphique uniquement, et non pas comme une plateforme complète de développement d'application.

        C'est dommage, d'une part pour les distributions qui ont des dépendances en plus à gérer (ce programme semble très bon, il y a des chances qu'il soit empaqueté au moins par Debian), et pour le développeur, qui a plusieurs bibliothèques à apprendre.

        Je vais me prendre comme exemple : je connais une bonne partie de Qt, et sait me servir de sa doc. Je n'ai jamais utilisé ses flux XML (uniquement le DOM), mais la doc est là et je la comprend. Je serais capable de contribuer à exxEditor. Par contre, je ne connais pas Xerces, ni Boost, donc je ne peux que difficilement aider.

        > toolkit graphique

        Tout à fait d'accord, j'évite absolument d'utiliser des parties de QtGui dans la libpackage de Setup, qui doit servir au client console. Pas de GUI là-bas.

        N'empêche, j'utilise QtCore, QtXml, QtScript et QtSql dans cette bibliothèque. Le gros morceau de Qt est QtGui (et QtWebkit si on le sépare de QtGui). Le reste n'est pas graphique. La plupart des distributions font de bons paquets et séparent les composants de Qt, mais les distributions "en block", comme ArchLinux ou Gentoo, gardent le paquet en un gros morceau, donc je peux comprendre le refus d'utiliser Qt pour une partie console.

        Mais bon, je comprends l'argument historique et vais cesser de chipoter avec Qt. Je n'aime pas qu'on me dise que j'ai utilisé les mauvaises libs, donc je ne le fais pas moi-même (ce message est avant-tout un anti-FUD des GTKistes qui réduisent Qt à une lib graphique lourde et liée à KDE).

        Beau travail en tous cas, ça pourrait me servir un de ces jour si je dois faire éditer des fichiers XML par madame michu.
        • [^] # Re: Qt mais pas complètement ?

          Posté par . Évalué à 3.

          Par contre, je ne connais pas Xerces, ni Boost, donc je ne peux que difficilement aider.

          Entre nous soit dit, c'est un peu de la mauvaise foi car :
          - Xerces est *the* implementation XML/DOM utilisée en C++
          - C++ sans boost, c'est un peu les spagetthis sans la bolognaise ...
          • [^] # Re: Qt mais pas complètement ?

            Posté par (page perso) . Évalué à 7.

            - C++ sans boost, c'est un peu les spagetthis sans la bolognaise ...

            Sauf que je ne vois pas bien l'intérêt de boost quand on utilise Qt.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Qt mais pas complètement ?

              Posté par (page perso) . Évalué à 3.

              >Sauf que je ne vois pas bien l'intérêt de boost quand on utilise Qt.

              Comme il le dit plus haut, il n'était pas certain de garder QT donc il n'allait pas s'emprisonner avec une technologie et devoir recoder tout s'il voulait passer en TCL/TK, GTK etc
              • [^] # Re: Qt mais pas complètement ?

                Posté par (page perso) . Évalué à 6.

                Je ne parlais pas du cas du journal vu qu'il a expliqué qu'il ne voulais pas Qt pour les parties non graphique. Je voulais réagir à C++ sans boost, c'est un peu les spagetthis sans la bolognaise ... , je ne vois pas bien l'intérêt de faire du boost en plus du Qt, quand on fait du Qt bien sûr.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Qt mais pas complètement ?

              Posté par . Évalué à 2.

              Sauf que je ne vois pas bien l'intérêt de boost quand on utilise Qt.

              Je pense qu'il y a plus de dev c++ à connaitre/pratiquer boost que Qt. Donc pour la partie core, je ne trouve pas ça illogique d'utiliser boost, surtout s'il y a une bonne séparation core/gui.
          • [^] # Re: Qt mais pas complètement ?

            Posté par . Évalué à 8.

            C++ avec Qt et boost, c'est comme les spagetthis avec bolognaise ET carbonara...
            • [^] # Re: Qt mais pas complètement ?

              Posté par . Évalué à 2.

              Faut se méfier des mélanges, surtout pour des sauces...

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Qt mais pas complètement ?

            Posté par . Évalué à 2.

            - C++ sans boost, c'est un peu les spagetthis sans la bolognaise ...

            Chacun ses goûts, certains aiment la sauce carbonara...

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Qt mais pas complètement ?

              Posté par . Évalué à 3.

              et d'autres la morue aux fraises
              • [^] # Re: Qt mais pas complètement ?

                Posté par . Évalué à 3.

                Punaise, je me demandais où j'avais déjà vu ça, et heureusement que Google est là : Gaston Lagaffe.

                Merci pour ce moment de nostalgie.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Qt mais pas complètement ?

      Posté par . Évalué à 6.

      Personnellement j'approuve totalement son choix de conception.

      C'est la meilleure solution pour un bon découplage. Si un jour il veut se passer de Qt, ou si Qt évolue et casse son API, ou encore si quelqu'un souhaite faire un front-end s'intégrant mieux à Gnome (avec GTKmm et autres libs C++ de Gnome) ou autre environnement de bureau, il aura beaucoup moins de problèmes.
      Si être à la fois dépendant de Qt et de Boost est considéré comme stupide, alors qu'en serait-il d'une double dépendance Qt/GTKmm…

      Après, c'est peut-être un peu plus personnel, mais je trouve que Qt en fait trop. Non seulement ça fait doublon avec Boost, mais c'est également le cas avec la STL (pour des raisons historiques).
      Un truc qui manque à l'écosystème C++, c'est une bonne lib GUI qui se contente d'être une lib GUI et qui ne cherche pas à faire en prime le café et la mayonnaise. Bref, en d'autres termes, j'aime bien les libs, mais pas les frameworks intrusifs.

      À mon avis, dans l'état actuel des choses, la combinaison [C++, SL, Boost, autres libs métier, lib GUI] est ce qu'il y a de plus propre. Et si en plus c'est buildé avec CMake, c'est juste parfait ;).
      • [^] # Re: Qt mais pas complètement ?

        Posté par (page perso) . Évalué à 9.

        > si Qt évolue et casse son API

        Et si Boost et Xerces cassent leurs API ? cet argument est ridicule. Pour info Qt n'a pas cassé son API source et binaire depuis plus de 5 ans.

        > un front-end s'intégrant mieux à Gnome

        Et ? QtCore, QtXML ect... sont des librairies comme les autres. Rien n'empêche de faire une GUI GTK+ par dessus. QtCore s'intègre parfaitement avec la boucle d'événement de la GLib. L'inverse existe également : le modèle en GLib et la vue en Qt.

        Au passage désormais (depuis 2 ans déjà) l'intérêt de développer une GUI GTK+ par dessus un modèle qui utilise QtCore n'est plus franchement intéressant grâce à l'utilisation de QGtkStyle http://labs.trolltech.com/blogs/2008/09/05/qgtkstyle-now-par(...) qui permet d'avoir une intégration parfaite dans GNOME. QGtkStyle est intégré dans toutes les distribs modernes et fonctionne vraiment très bien.

        > je trouve que Qt en fait trop. Non seulement ça fait doublon avec Boost,
        > mais c'est également le cas avec la STL

        Pour avoir utilisé Boost pendant 3 ans, Qt est bien supérieur en terme de fonctionnalités, de cohérence et de documentation. Pour la STL j'en parle même pas.

        > Un truc qui manque à l'écosystème C++, c'est une bonne lib GUI qui se contente d'être une lib GUI

        Et en quoi QtGui ne répond pas a cette problématique ?
        Pour info ca fait plus de 5 ans que Qt est découpé en modules indépendants simples et cohérents...

        > j'aime bien les libs, mais pas les frameworks intrusifs

        Comment peut on avoir une vision aussi archaïque !
        Vraiment utilise Qt, ou meme C# ou Java et ensuite compare a tes méthodes de développement qui utilisent 15 libs différentes pour afficher hello world.

        > la combinaison [C++, STL, Boost, autres libs métier, lib GUI] est ce qu'il y a de plus propre

        C'est ce que je pensais (il y a très longtemps) et finalement dans la pratique on se rend compte que c'est compliqué pour rien : ça crée des problèmes sans rien apporter de plus.
        • [^] # Re: Qt mais pas complètement ?

          Posté par (page perso) . Évalué à 6.

          Pour avoir utilisé Boost pendant 3 ans, Qt est bien supérieur en terme de fonctionnalités

          Qt n'a pas d'équivalent à bind, multi_index, graph et autres, asio et thread sont bien mieux fait que QtThread et QtNetwork...

          QtCore s'intègre parfaitement avec la boucle d'événement de la GLib.

          Certains composants de Qt dépendent d'une boucle d'évènement et de variables globales (l'instance de QCoreApplication) : c'est pas terrible pour faire une bibliothèque réutilisation hors des applications Qt...

          http://devnewton.bci.im

          • [^] # Re: Qt mais pas complètement ?

            Posté par (page perso) . Évalué à 3.

            Certes, boost a plein de modules non présent dans Qt (et l'inverse est vrai aussi)

            Par contre, je trouve que la programation avec des thread Qt et QtConcurrent très bien. En quoi boost thread est il mieux fait? (peut être plus bas niveau?)

            Je ne connais pas asio, qu'y a t il de mieux dans asio ?

            > Certains composants de Qt dépendent d'une boucle d'évènement
            > et de variables globales


            Oui, et ? Quel est le problème ?
          • [^] # Re: Qt mais pas complètement ?

            Posté par (page perso) . Évalué à 2.

            > Certains composants de Qt dépendent d'une boucle d'évènement et de variables globales

            Effectivement dans certains cas t'es obligé de fournir une fonction init() (et même exec() et close() qui encapsule QApplication::exec()) que l'utilisateur devra appeler avant d'utiliser ta librairie basée sur Qt.
            Ceci n'est pas spécifique à Qt, cURL par exemple fonctionne sur des mécanismes similaires (curl_init(), curl_exec(), curl_close())

            > asio et thread sont bien mieux fait que QtThread et QtNetwork

            Ce que je retiens de Boost c'est son coté API bas niveau comparée à celle de Qt qui est beaucoup plus simple et cohérente.
            • [^] # Re: Qt mais pas complètement ?

              Posté par (page perso) . Évalué à 2.

              Ceci n'est pas spécifique à Qt, cURL par exemple fonctionne sur des mécanismes similaires (curl_init(), curl_exec(), curl_close())

              Mais pas à boost! Par exemple pas besoin de boucle d'évènements pour utiliser faire du réseau ou pour gérer des signals/slots. Tiens à propos de ces derniers, la version boost est plus puissante et plus simple, puisqu'il n'y a besoin d'un précompilateur...

              http://devnewton.bci.im

              • [^] # Re: Qt mais pas complètement ?

                Posté par (page perso) . Évalué à 3.

                Pas besoin de boucle d'événement pour les signaux et slots de Qt, ni pour utiliser le réseau de façon synchrone.

                Par ailleurs, la boucle d'événement de Qt s'intègre très bien dans une autre boucle d'événements d'une autre lib.
                Il suffit d'apellet Q(Core)Application::processEvents() à chaque iterations.

                Et les signaux de boost ne permettent pas de passer d'un thread à l'autre. Ou de mettre en queue des signaux.
                En plus, il est impossible de rajouter des signaux boost a une classe sans casser la compatibilité binaire, alors que c'est pas un probème avec Qt.
                • [^] # Re: Qt mais pas complètement ?

                  Posté par (page perso) . Évalué à 2.

                  Pas besoin de boucle d'événement pour les signaux et slots de Qt

                  Ca ne marche que pour les "direct connections", cad pas entre plusieurs threads...

                  ni pour utiliser le réseau de façon synchrone.

                  Donc encore une fois dans un cas particulier... Le cas général reste intrusif!

                  Et les signaux de boost ne permettent pas de passer d'un thread à l'autre. Ou de mettre en queue des signaux.
                  En plus, il est impossible de rajouter des signaux boost a une classe sans casser la compatibilité binaire, alors que c'est pas un probème avec Qt.


                  Tes connaissances doivent dater de quelques années. Lis la doc de boost, tu verras que tout ça est possible!

                  http://devnewton.bci.im

        • [^] # Re: Qt mais pas complètement ?

          Posté par . Évalué à 1.

          Bon bon, je vais être franc : l'IHM n'est pas vraiment mon domaine de prédilection et j'avoue ma méconnaissance de Qt. Je pense que tu as raison sur la plupart des points ;).

          Je pensais que Qt était un conglomérat de libs interdépendantes, mais si ce n'est pas le cas, tant mieux. J'aime avant tout le C++.

          Par contre, le point qui me rebutera toujours autant, c'est le fait que ça fasse doublon avec la STL (et à moins forte raison avec Boost). C'est regrettable pour l'écosystème C++, qui aurait l'air beaucoup plus cohérent et cohésif si la hiérarchie S(T)L -> Boost -> Qt était respectée.
          Bon, encore pour Boost… après tout ils se font pas partie du standard (bien que certaines libs de Boost y aient été incluses, mais passons sur ce détail). Mais vraiment, le doublon avec la STL, je trouve que ça fait tache.

          Pour finir, la raison pour laquelle je n'aime pas les frameworks (dans leur aspect bloc monolithique, ce que Qt n'est pas si j'en crois ton argumentaire) s'explique par mon attachement au principe KISS d'Unix : chaque entité fait une chose et une seule, et le fait bien.
          J'ai eu l'occasion de travailler avec Java, et vraiment non merci. Je m'en sors bien mieux avec mon C++ et les multitudes de dépendances qui peuvent en découler.
          • [^] # Re: Qt mais pas complètement ?

            Posté par (page perso) . Évalué à 4.

            Qt fait "doublon" avec la STL dans le sens que certaines fonctions sont dupliquées. Mais Qt ne fait pas doublon dans le sens que les objectifs sont différents.

            Qt essaye de fournir une API facile d'utilisation, cohérente, multi-platformes, intuitive.
            Alors que la STL est plus bas niveau.

            Par example, les conteneurs de Qt sont "implictly shared" ce qui permet de pouvoir passer des listes ou des chaîne de caractère d'une classe à l'autre de manière performante, très facilement et intuitivement.
            Les conteneur STL ne le sont pas car cela veux dire que le la copie à lieu a des moment non déterministique, ce qui est une horreur pour la programmation temps réel.

            La STL fait un usage important des templates, ce qui la rends plus difficile d'utilisation pour les novice. Un programmeur Qt peut s'en tirer sans connaître cette partie compliquée du C++.

            Exemple, les conteneur STL permettent d'avoir un "allocateur" personalisé. Mais qui a vraiment besoin de ça ? Et ce n'est pas transparent pour l'utilisateur si on ne les utilise pas (les messages d'erreurs sont imbitables, ça apparaît dans l'auto-completion, impossible de forward-déclarer certaine classes, ...)
            • [^] # Re: Qt mais pas complètement ?

              Posté par . Évalué à 1.

              Qt essaye de fournir une API facile d'utilisation, cohérente, multi-platformes, intuitive.
              Alors que la STL est plus bas niveau.

              Hum… cette phrase sonne très « Qt, c'est le plus beau et le plus fort et pis c'est tout » !
              Dire que la STL n'est ni intuitive, ni facile d'utilisation, c'est très subjectif… Personnellement, je ne vois pas ce qu'elle a de contre-intuitive ou de difficile d'accès.
              La STL pas cohérente ? Tu peux développer ?
              La STL pas multi-plateforme… euh faut peut-être pas déconner, là !

              Par example, les conteneurs de Qt sont "implictly shared" ce qui permet de pouvoir passer des listes ou des chaîne de caractère d'une classe à l'autre de manière performante, très facilement et intuitivement.
              Un peu comme un vector de shared_ptr, c'est ça ?
              Si oui, quel avantage sur ce dernier ?

              Les conteneur STL ne le sont pas car cela veux dire que le la copie à lieu a des moment non déterministique, ce qui est une horreur pour la programmation temps réel.
              En quoi la copie des conteneurs de la STL n'est pas déterministe ?

              La STL fait un usage important des templates, ce qui la rends plus difficile d'utilisation pour les novice. Un programmeur Qt peut s'en tirer sans connaître cette partie compliquée du C++.
              Ben, c'est du C++, quoi…
              Se passer des templates, je trouve ça idiot. Franchement.
              Mais bon, admettons que ce soit trop compliqué… Si un template est peut-être compliqué à coder, je ne vois pas en quoi il l'est à l'utilisation.
              On crée un std::vector, on met des ints dedans… bon… c'est pas bien sorcier, si ?

              Exemple, les conteneur STL permettent d'avoir un "allocateur" personalisé. Mais qui a vraiment besoin de ça ? Et ce n'est pas transparent pour l'utilisateur si on ne les utilise pas (les messages d'erreurs sont imbitables, ça apparaît dans l'auto-completion, impossible de forward-déclarer certaine classes, ...)
              Je n'ai jamais codé d'allocateur, mais je n'ai jamais souffert du fait qu'il soit possible d'en utiliser un.
              Les messages d'erreur des templates sont parfois à rallonge, ça je te l'accorde. Mais c'est plus un problème inhérent au couple langage/compilateur. De plus, il existe un outil nommé STLFilt permettant de fournir des messages d'erreur plus clairs que ceux des compilateurs.
              Que ça apparaisse dans l'auto-complétion, je vois pas bien ce que ça a de dramatique.
              Quelle classe souhaites-tu forward-déclarer ? Et pourquoi ? De toute façon il est possible d'écrire des forward declarations pour n'importe quelle classe ou template de classe.
              • [^] # Re: Qt mais pas complètement ?

                Posté par (page perso) . Évalué à 2.

                Qt c'est le plus beau et le plus fort et puis c'est tout ! ;-)
                La STL pas cohérente avec le reste de Qt. (Bon, c'est la faute de Qt)

                > Un peu comme un vector de shared_ptr, c'est ça ?

                c'est plus simple de faire
                QString maString("foo");
                que string_ptr maString(new string("foo"));

                > En quoi la copie des conteneurs de la STL n'est pas déterministe ?

                Tu m'a mal compris. Je disais justement que la STL voulais que ce soit déterministe et que c'est une des raisons pour laquelle rien n'est partagé par défaut.

                > Se passer des templates, je trouve ça idiot. Franchement.

                Qt ne se passe pas des template, ils sont juste utilisé modérément. std::vector ça va.
            • [^] # Re: Qt mais pas complètement ?

              Posté par (page perso) . Évalué à 4.

              La STL fait un usage important des templates, ce qui la rends plus difficile d'utilisation pour les novice.

              Les devs qui ont peur des templates n'ont rien à faire en C++ :-)

              http://devnewton.bci.im

              • [^] # Re: Qt mais pas complètement ?

                Posté par . Évalué à 2.

                Hum. Je suppose que c'est un peu une blague, mais au cas où : tu as lu des bouquins genre « Effective C++ » (et son petit frère « More effective C++ ») ?

                Le problème de C++ ce n'est pas les templates, ni la partie objet, ni le C, ni la STL. Le problème, c'est que c'est comme le C mais en pire : c'est un langage multi-paradigmes pour gens qui savent ce qu'ils font. Qu'on soit bien d'accord, j'adore le C. Je code quasiment uniquement dans ce langage (je fais des trucs assez bas-niveau).

                Ce que je veux dire, c'est que

                - faire du « C en C++ » en profitant de la STL mais sans écrire de templates, c'est bien;
                - faire du « C avec classes » pour faire de la POO, c'est bien;
                - faire des templates de fonctions pour obtenir de meilleures perfs, et faire du C tout court, c'est bien;
                - faire du « C avec classes » et utiliser des templates de fonctions, c'est bien;
                - faire du « C avec classes » et utiliser la STL, c'est bien;
                ...

                Par contre, à partir du moment où tu commences à sérieusement mélanger tout ça (et je te parle pas des templates de classes), que tu rajoutes la surcharge d'opérateurs (et de tous les pièges induits, genre quand et où faut-il mettre des const...), etc., oui là j'ai tendance à y aller à reculons...

                Du coup je comprends les réticences de certaines personnes vis-à-vis du C++ et des templates quand on voit certaines horreurs qui sont commises. Et on peut parfaitement faire du C++ sans templates (par contre, sans un truc type STL ou assimilé, c'est un peu se faire mal pour rien).
                • [^] # Re: Qt mais pas complètement ?

                  Posté par (page perso) . Évalué à 2.

                  Hum. Je suppose que c'est un peu une blague, mais au cas où : tu as lu des bouquins genre « Effective C++ » (et son petit frère « More effective C++ ») ?

                  Non, pourquoi? Il y a écrit "les templates sai pas lol, qt sa roxe" dedans?

                  http://devnewton.bci.im

                • [^] # Re: Qt mais pas complètement ?

                  Posté par (page perso) . Évalué à 2.

                  Moi ce que je trouve moche, c'est quand on code en C en piochant deux trois trucs du C++.

                  Envoyé depuis mon lapin.

                  • [^] # Re: Qt mais pas complètement ?

                    Posté par . Évalué à 2.

                    Ben je sais pas en fait. Si je fais du C + surcharge d'opérateurs, parce que (par exemple hein) je fais du calcul intensif et que du coup je veux pouvoir facilement faire des opérations vectorielles/matricielles/etc., ben pourquoi pas ? J'ai pas besoin de classes à proprement parler (des struct suffisent car tout est public), juste de quoi facilement représenter mes calculs (et ensuite je peux appeler des fonctions déjà méga-optimisées depuis operator*(), etc.)
                • [^] # Re: Qt mais pas complètement ?

                  Posté par (page perso) . Évalué à 2.

                  Il faut toujours déclarer les fonctions membres const, sauf quand elles modifient les données. Il n'y a pas de piège.

                  Le problème de C++, c'est que pour y faire quelque chose de correct, il faut lire, beaucoup (Stroustrup, Sutter, Herbs, Meyers, etc).
                  • [^] # Re: Qt mais pas complètement ?

                    Posté par . Évalué à 3.

                    Le problème de C++, c'est que pour y faire quelque chose de correct, il faut lire, beaucoup (Stroustrup, Sutter, Herbs, Meyers, etc).

                    ... et Alexandrescu alors ? /o/
        • [^] # Re: Qt mais pas complètement ?

          Posté par . Évalué à 2.

          Ah et j'oubliais : le moc (préprocesseur custom pour Qt), en voilà un, de truc intrusif contraignant.
          D'accord, ça facilite probablement la tâche du programmeur en rendant le code plus concis… mais ces « public signals: » non-standards, y'a rien à faire, ça me sort par les yeux.
          Je développe une lib d'analyse de code source C++ et j'aime pas trop l'idée d'avoir à faire du dev spécifique pour supporter les excentricités de tous les frameworks qui peuvent exister, même si l'un d'eux s'appelle Qt.
          • [^] # Re: Qt mais pas complètement ?

            Posté par (page perso) . Évalué à 2.

            Les "additions" sont des macros tout ce qu'il y a de plus standards. Les analyseurs de code n'ont en général pas de problème à parser ça, sans modifications.
            • [^] # Re: Qt mais pas complètement ?

              Posté par . Évalué à 1.

              Si tu dis vrai, ça me rassure ;).

              Par contre, ne le prends pas mal mais je reste dubitatif…
              Selon ce bout de code :

              class Foo : public QObject
              {
              Q_OBJECT
              public:
              Foo();
              int value() const { return val; }
              public slots:
              void setValue( int );
              signals:
              void valueChanged( int );
              private:
              int val;
              };

              … on aurait donc une macro « slots » et une autre « signals » ?
              Par quoi peut bien être remplacé « slots », si ce n'est du vide, pour que le code soit standard ?
              • [^] # Re: Qt mais pas complètement ?

                Posté par . Évalué à 1.

                Si je ne me trompe pas c'est bien remplacé par du vide. Ils ne sont là que pour indiquer la position des signaux/slots à l'utilitaire moc.

                Pour être plus précis voila ce qu'on trouve dans le code Qt
                #define slots
                #define signals protected
                • [^] # Re: Qt mais pas complètement ?

                  Posté par . Évalué à 1.

                  Mmh, je vois…
                  Et donc moc va rajouter des variables et fonctions membres à la classe en question, avant de passer le code à la chaine de compilation standard (préprocesseur compris) ?

                  Bon bah c'est chouette, ça reste bon pour mes affaire ;).
                • [^] # Re: Qt mais pas complètement ?

                  Posté par . Évalué à 0.

                  Le code qu'il faut analyser c'est plus celui-ci : moc_toto.cpp

                  Ce fichier est généré par le MOC pour chaque classe ayant la macro Q_OBJECT.

                  Le MOC, c'est juste un préprocesseur fournissant des trucs très cool comme les signaux/slots (façon compréhensible par un jeune développeur C++ et non façon boost), l'instrospection et quelques mots clés (toujours via des macros).
                  • [^] # Re: Qt mais pas complètement ?

                    Posté par (page perso) . Évalué à 2.

                    Le MOC, c'est juste un préprocesseur fournissant des trucs très cool comme les signaux/slots

                    C'était très cool au millénaire dernier. Aujourd'hui, personne ne ferait un framework sérieux avec une bouse pareille.

                    http://devnewton.bci.im

                    • [^] # Re: Qt mais pas complètement ?

                      Posté par . Évalué à 2.

                      Regarde un peu autour de toi le nombre de projets qui utilisent Qt. Regarde dans quels domaines ils sont. Et demande toi un petit peu s'il n'y a pas une (au moins une) bonne raison pour laquelle on utilise Qt. Comme la simplicité, la rapidité de développement et la maintenabilité des projets.

                      Je ne te demande pas d'aimer Qt (c'est très personnel ce genre de truc). Juste de comprendre comment ça fonctionne et d'essayer de voir pourquoi certains développeurs trouvent cela bien.
      • [^] # Re: Qt mais pas complètement ?

        Posté par (page perso) . Évalué à 1.

        Il y a ce qu'il faut dans l'écosystème C++ http://www.fltk.org/
  • # grrr, et la dépêche ? ;)

    Posté par . Évalué à 2.

    Pourquoi ne pas avoir fait une dépêche ? Le sujet s'y prête bien. Je n'ai pas testé (pas vraiment l'utilité pour moi), mais ça semble un beau projet.

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: grrr, et la dépêche ? ;)

      Posté par . Évalué à 8.

      Bas c'est mon premier journal ... C'est impressionnant une dépêche.
      • [^] # Re: grrr, et la dépêche ? ;)

        Posté par (page perso) . Évalué à 7.

        C'est impressionnant une dépêche.

        Moins qu'un journal, vu que les éventuelles fôte peuvent être corrigées.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: grrr, et la dépêche ? ;)

      Posté par . Évalué à 3.

      Pour résoudre se problème
      Il faudra corriger cette vilaine faute avant d'en faire une dépêche.

      Sinon, bravo pour ta contribution communautaire qui comble un vide en la matière.
  • # juste ce qu'il me fallait ...

    Posté par . Évalué à 3.

    ... au boulot !
    Je dois (devoir moral diront nous) coder un petit soft de lecture pour un fichier xml généré par une appli métier avant la fin de la semaine prochaine, que je n'ai bien évidemment pas commencé puisque je n'ai pas fini le reste de mon travail.
    Ca tombe donc à pic. Merci beaucoup :-)

    Je n'en dit pas plus... les corporations ont des oreilles !
    • [^] # Re: juste ce qu'il me fallait ...

      Posté par (page perso) . Évalué à 4.

      Je disais justement hier en réunion qu'on pourrait peut être remplacer le fichier de conf .ini de notre appli par un fichier de conf xml. Tout ce qu'il nous faudrait c'est un petit éditeur sympa :).

      Bon par contre j'ai essayé de compiler l'appli tout à l'heure au boulot et ça n'a pas marché. Je n'ai pas insisté, je vais réessayer là pour voir si ça marche mieux.
      • [^] # Re: juste ce qu'il me fallait ...

        Posté par (page perso) . Évalué à 4.

        Je disais justement hier en réunion qu'on pourrait peut être remplacer le fichier de conf .ini de notre appli par un fichier de conf xml. Tout ce qu'il nous faudrait c'est un petit éditeur sympa :).

        Il est pas bien votre fichier de conf éditable avec n'importe quel éditeur ?
        • [^] # Re: juste ce qu'il me fallait ...

          Posté par . Évalué à 3.

          Probablement l'envi de déléguer le parsing.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: juste ce qu'il me fallait ...

          Posté par (page perso) . Évalué à 2.

          Bof, on doit créer une liste d'éléments qui ont plusieurs propriétés et du coup ça fait un peu genre :
          element1_propriete_a = 42
          element1_propriete_b = "bla"
          element1_propriete_c = 4
          element2_propriete_a = 2
          element2_propriete_b = "ooops"
          element2_propriete_c = 8

          etc.

          En plus d'être un peu lourd à écrire (au risque de faire une faute en plus), quand tu veux supprimer l'un des éléments, t'es obligé de tout renuméroter.

          (enfin, je suppose un peu car ce n'est ni moi moi qui l'utilise ou le code mais lors de la réunion ils ont évoqué rapidement le problème)
          • [^] # Re: juste ce qu'il me fallait ...

            Posté par (page perso) . Évalué à 3.

            En effet, le côté numérotation est plutôt bof.

            Pour un problème similaire, j'avais utilisé qq chose du genre (en utilisant les sections):

            [global]
            les_elements=x,y

            [proprietes x]
            a = 42
            b = "bla"
            c = 4

            [proprietes y]
            a = 2
            b = "ooops"
            c = 8


            Tu conserves un ordre si besoin dans les_elements (y'a qu'à découper sur la virgule), et tu fais une association simple élément/propriétés via les sections.

            Sinon, Yaml (toujours éditable avec un simple éditeur) ?

            Bon, c'est juste que je trouve moyen les fichiers de conf en XML - sauf s'il y a un éditeur dans l'application et que l'on n'a pas à voir l'XML. Ça oblige avoir un éditeur spécifique pour ce format (exxEditor par exemple :-).
            XML permet de rattraper des choses à la main, d'éditer rapidement un petit contenu pour démarrer... mais ça reste un format d'échange entre applications, on ne devrais quasiment pas avoir à le lire/l'écrire nous même, c'est pas "human friendly" même si c'est "human usable".
            • [^] # Re: juste ce qu'il me fallait ...

              Posté par (page perso) . Évalué à 4.

              C'est peut-être parce que j'ai fait pas mal de développement web mais je ne trouve pas que l'édition d'un fichier de conf en XML soit vraiment non-"human friendly". Je trouve ça au contraire clair et structuré.

              <element a="42" b="bla" c="4"/>
              <element a="2" b="ooops" c="8"/>

              En tout cas, merci pour l'exemple, c'est intéressant. Par contre je ne sais pas comment ils ont géré la lecture de fichier ini, je ne sais pas si les sections sont prises en compte.
              • [^] # Re: juste ce qu'il me fallait ...

                Posté par . Évalué à 1.

                Heu, au contraire, un fichier en xml est en général complètement illisible.

                Pourquoi ne pas utiliser quelque chose de plus simple comme le yaml ?
              • [^] # Re: juste ce qu'il me fallait ...

                Posté par (page perso) . Évalué à 4.

                Moi aussi j'aime bien la syntaxe du xml.

                C'est beaucoup plus facile de faire du xml lisible que du json lisible.

                Je n'accroche pas du tout au yaml, surtout quand il y a une erreur de syntaxe.

                Envoyé depuis mon lapin.

  • # Concurrence

    Posté par . Évalué à 1.

    Ça a l'air sympa, mais je n'arrive pas à croire que cela n'existe pas déjà. Y a-t-il des concurrents sérieux ? Qu'est-ce qui vous a poussé à développer votre propre application ? Ce n'est qu'une partie de votre application maison ? Quelle fonctionnalité vous manquait ? Ou alors les solutions existantes sont trop complètes et complexes ?
    • [^] # Re: Concurrence

      Posté par (page perso) . Évalué à 1.

      Je dirais que Mlview est un concurrent même si j'avoue ne pas avoir regarder plus loin exxEditor.
    • [^] # Re: Concurrence

      Posté par . Évalué à 2.

      Ben à vrai dire, après avoir utilisé XMLSpy (sous Win) dans ma boîte, j'ai cherché un truc qui pourrait s'en rapprocher et je n'ai pas trouvé.

      Ici, on a la partie éditer un XML selon un schéma.

      Il ne me manque que l'édition du schéma.
    • [^] # Re: Concurrence

      Posté par . Évalué à 2.

      Je n'ai pas trouvé de concurrent qui correspondait vraiment à mes besoins. Mon objectif est de complètement cacher le XML à l'utilisateur.
      Techniquement, c'est un éditeur XML, mais pour l'utilisateur c'est juste une application qui permet de rentrer des paramètres pour ensuite lancer son application.

      Je n'ai pas trouvé de logiciel qui fasse ça "correctement". J'ai bien vu une application java (je ne me rappelle plus le nom) qui fonctionne sous le même principe, mais qui n'est pas utilisable dès lors que le XML fait plus de quelques lignes.
    • [^] # Re: Concurrence

      Posté par . Évalué à 1.

      Bonjour

      il y a Serna Editor qui est passé en libre dernièrement qui a des fonctionnalités ressemblantes

      http://www.syntext.com/downloads/serna-free/

      Il y a une version free et une version commerciale

      les fonctionnalités sont exprimées ici

      http://www.syntext.com/products/serna-feature-matrix/

      Vala.
  • # Pourquoi pas Jaxe?

    Posté par . Évalué à 1.

    Bonjour!

    Pourquoi ne pas avoir utilisé Jaxe?

    cc

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.