Journal Retour aux sources

Posté par (page perso) . Licence CC by-sa
26
26
sept.
2014

Amour, gloire et cpp

Bonjour Nal,

Si tu suis régulièrement mes aventures, tu sais que depuis quelques années je n'utilise plus qu'une seule plateforme de développement pour tous mes projets: Java.

Portable, performant et surtout productif, ce mariage de raison n'a pas empêché quelques aventures avec Python ou Javascript, mais est resté assez solide.

Toutefois je n'ai jamais complètement pu oublier mon premier amour pour le C++, celui-ce ne cessant de se rappeler à mon bon souvenir, me promettant qu'il n'était plus le même, qu'il avait changé.

J'ai fini par craquer et convenu d'un rendez-vous autour d'un prototype de jeu de sport dont je te reparlerais bientôt j'espère, bien que je ne sache pas si j'irais jusqu'au bout. En effet, la mise en place du projet n'a pas été un retour aux sources chaudes, mais plutôt une douche glacée façon ice bucket challenge avec un seau oublié pendant 3 mois dans un congélateur industriel.

Le choix des larmes

Le panel de choix de l'outillage a été très décevant.

J'ai essayé quelques IDE, avant de me rendre compte que Eclipse ou Netbeans sont les seuls à proposer une bonne complétion, du refactoring qui marche et à ne pas planter lamentablement (kdevelop, c'est de toi que je parle). Les meilleurs IDE C++ sont donc en Java…

Pour le gestionnaire de projet, c'est bien simple, ça n'existe pas. Je n'ai trouvé aucun outil qui semble seulement s'approcher du centième de ce que fait un maven hors de la boite. Il faut donc utiliser une sorte script de compilation et gérer ses dépendances à la main comme à la préhistoire de l'informatique. J'ai pris cmake, car tout le monde semble l'utiliser de nos jours, mais mes yeux saignent en voyant le genre d'horreurs qu'il faut écrire:

    if (${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU" OR ${CMAKE_CXX_COMPILER_ID} STREQUAL "Clang")
       set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -pedantic -std=c++11")
       set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS} -g")
       set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS} -O2")
    endif()

J'ai aussi regardé comment faire de la cross compilation, créer des packages ou des binaires portables: là aussi il n'y a rien de bien au point, juste des tutoriaux ou des recommandations au détour d'un blog ou d'un forum.

Le vent du changement c'est maintenant

Une fois passée la douloureuse mise en place du projet, j'ai quand même été content de voir que C++ a bien changé. Fini les functors, vive les lambdas! Enfin vous voilà, smart pointers dans la STL! Oh et boost qui s'est bonifié avec le temps!

Je peux enfin écrire sans honte de belles lignes de code comme celles ci-dessous sans recourir à 150000 lignes de templates, de macros et de libs externes:

    boost::property_tree::read_json(path, pt_nanim);
    boost::filesystem::path parent_path = boost::filesystem::path(path).parent_path();
    auto collec = std::make_shared<nanim::collection>();
    for (auto& pt_animation : pt_nanim.get_child("animations")) {
        auto anim = std::make_shared<nanim::animation>();
    for (auto& pt_frame_child : pt_animation.second.get_child("frames")) {
        auto pt_frame = pt_frame_child.second;
        ...

Si le langage a bien évolué sur des points qui me faisaient mordre mon clavier tous les jours à l'époque, je constate qu'il n'a pas bougé d'un poil sur des sujets fondamentaux:

  • l'absence de système de modules: des entêtes avec #ifndef … #endf en 2014, c'est très moche.
  • j'ai une dizaine de classes et la compilation se fait déjà longuette.
  • toujours pas de stacktrace lors d'une exception.

Si tu reviens, je compile tout

Ah Nal! Tu l'auras compris, retrouver une ancienne amour, c'est souvent se rendre compte que tout a changé pour que rien ne change.

A ton avis, dois-je continuer cette aventure risquée ou revenir à la Raison?

  • # Yahou peut être enfin des jeux qui marchent !

    Posté par . Évalué à 10.

    Toutefois je n'ai jamais complètement pu oublier mon premier amour pour le C++
    J'ai fini par craquer et convenu d'un rendez-vous

    En voila une idée quelle est bonne, si Newton adventure ou Ned et les maki sont réécrit en C++ je vais peut être enfin pouvoir y jouer (sans mettre mon CPU à 400% et lagger comme un fou) ?

    J'ai essayé quelques IDE, avant de me rendre compte que Eclipse ou Netbeans sont les seuls à proposer une bonne complétion

    Même QtCreator ou Code::Blocks n'ont pas réussit à te satisfaire ?

    Les meilleurs IDE C++ sont donc en Java…

    Je soupçonne un parti pris ôO

    des entêtes avec #ifndef … #endf en 2014, c'est très moche.

    Pourquoi changer un équipe qui gagne ? ;-)

    A ton avis, dois-je continuer cette aventure risquée ou revenir à la Raison?

    A mon avis tu aurais raison de continuer l'aventure.

    kentoc'h mervel eget bezan saotred

    • [^] # Re: Yahou peut être enfin des jeux qui marchent !

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

      A mon avis tu aurais raison de continuer l'aventure.

      L'intérêt pour moi, c'est de ne pas perdre la main en C++. Mais à part ça?

      http://devnewton.bci.im

    • [^] # Re: Yahou peut être enfin des jeux qui marchent !

      Posté par (page perso) . Évalué à 10. Dernière modification le 26/09/14 à 12:06.

      J'hesite entre classé ton poste en troll ou en démonstration flagrante d'ignorance d'un dev Java.

      J'ai essayé quelques IDE, avant de me rendre compte que Eclipse ou Netbeans sont les seuls à proposer une bonne complétion, du refactoring qui marche et à ne pas planter lamentablement (kdevelop, c'est de toi que je parle). Les meilleurs IDE C++ sont donc en Java…

      ça dépend de ta définition d'IDE. Si par IDE tu entends bloatware qui prends 4G de ta ram toute en réduisant dramatiquement ta productivité par sa lenteur. Effectivement Eclipse est un bon candidat.

      Si tu cherches quelques chose de rapide, qui a l'auto complétion, la gestion des projets, des SCM, gestion des plugins, et qui plus est, est bien intégré à CMake.
      ça s'appelle QtCreator.

      if ({CMAKE_CXX_COMPILER_ID} STREQUAL "GNU" OR{CMAKE_CXX_COMPILER_ID} STREQUAL "Clang")
      set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -pedantic -std=c++11")
      set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS} -g")
      set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS} -O2")
      endif()

      Ne reproche pas le fait que tu ne sais pas utiliser cmake à cmake en fait.

      Tout ce que tu as fait précédent existe déja en modules, tu aurais pu le faire en une ligne:
      include(blabla REQUIRED)

      J'ai aussi regardé comment faire de la cross compilation, créer des packages ou des binaires portables: là aussi il n'y a rien de bien au point, juste des tutoriaux ou des recommandations au détour d'un blog ou d'un forum.

      Tu veux dire ça en fait ?
      include(CPack)

      l'absence de système de modules: des entêtes avec #ifndef … #endf en 2014, c'est très moche.

      mmh
      #pragma once.
      De rien.

      toujours pas de stacktrace lors d'une exception.

      http://cs.baylor.edu/~donahoo/tools/gdb/tutorial.html
      De rien.

      Sinon j'imagine que tu as posté ce troll entre deux compilation maven ?
      Vu qu'elles téléchargent la moitié du web à chaque fois, il est vrai que ça laisse tu temps libre.

      • [^] # Re: Yahou peut être enfin des jeux qui marchent !

        Posté par (page perso) . Évalué à 10. Dernière modification le 26/09/14 à 12:14.

        J'hesite entre classé ton poste en troll ou en démonstration flagrante d'ignorance d'un dev Java.

        J'ai fait du C++ pendant 15 ans, mais 3 ans de pause suffisent à oublier ou à ne plus être au courant des 42000 choses à savoir pour faire un hello world C++ correct :-)

        Ne reproche pas le fait que tu ne sais pas utiliser cmake à cmake en fait.

        Comment remplacerais-tu les lignes que j'ai mise? Sur mon temps libre, j'utilise la technique "fapless coding", cad que je prends le premier truc qui marche sans me prendre la tête, donc oui je n'ai pas pris le temps de lire les centaines de page de Mastering cmake à 59$…

        Sinon j'imagine que tu as posté ce troll entre deux compilation maven ?
        Vu qu'elles téléchargent la moitié du web à chaque fois, il est vrai que ça laisse tu temps libre.

        Tu veux vraiment comparer les temps de compilation java et c++???

        http://devnewton.bci.im

        • [^] # Re: Yahou peut être enfin des jeux qui marchent !

          Posté par . Évalué à -3.

          en même temps tu met IDE et eclipse dans la même phrase, forcément ça coince. Même pour le java j'utilise pas (je lui préfère intelliJ).

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: Yahou peut être enfin des jeux qui marchent !

          Posté par . Évalué à 5. Dernière modification le 26/09/14 à 12:57.

          je n'ai pas pris le temps de lire les centaines de page de Mastering cmake

          Ne perd pas ton temps avec… malheureusement il ne sert pas a grand chose ce bouquin. Tres decevant.

          CMake c'est super bien mais c'est un peu … bugge. Par exemple il arrive parfois qu'il n'arrive pas a faire le lien avec un bibliotheque qu'il a pourtant trouve. La raison c'est que le chemin n'as pas ete mis a la creation du Makefile enfin c'est ce que j'ai cru comprendre. Je dois avouer que j'ai fait simple et que j'ai mis la bibliotheque dans un chemin classique (/usr/local/lib) et la ca passe nickel… Je sais c'est porc et il va falloir que je corrige le fichier Find…

        • [^] # Re: Yahou peut être enfin des jeux qui marchent !

          Posté par (page perso) . Évalué à 0. Dernière modification le 26/09/14 à 13:12.

          J'ai fait du C++ pendant 15 ans, mais 3 ans de pause suffisent à oublier ou à ne plus être au courant des 42000 choses à savoir pour faire un hello world C++ correct :-)

          echo -e '#include \n int main(int argc, char** argv){ std::cout << "Hello World" << std::endl; }' | g++ -x c++ -o /tmp/test -
          /tmp/test

          Tu me fais le même en Java ? je veux rire un peu.

          Comment remplacerais-tu les lignes que j'ai mise? Sur mon temps libre, j'utilise la technique "fapless coding", cad que je prends le premier truc qui marche sans me prendre la tête, donc oui je n'ai pas pris le temps de lire les centaines de page de Mastering cmake à 59$…

          curl http://pastebin.com/raw.php?i=ywnLKdJu -o cmake/modules/ReleaseDebugFlags.cmake
          include(ReleaseDebugFlags REQUIRED);

          Tu veux vraiment comparer les temps de compilation java et c++???

          Oui si on considère les 2 min de compilation JIT, de chargement JVM et d'optimization "server" à chaque exécution du bloat.

          • [^] # Re: Yahou peut être enfin des jeux qui marchent !

            Posté par . Évalué à 10.

            echo -e 'class Hello {\n public static void main(String[] args) {\n System.out.println("Hello Troll");\n }\n}' > Hello.java && javac Hello.java && java Hello

          • [^] # Re: Yahou peut être enfin des jeux qui marchent !

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

            Tu veux vraiment comparer les temps de compilation java et c++???

            Oui si on considère les 2 min de compilation JIT, de chargement JVM et d'optimization "server" à chaque exécution du bloat.

            Mouhahaha ! Même en comptant tout ça, la compilation C++ est à des années-lumières derrière…

            • [^] # Re: Yahou peut être enfin des jeux qui marchent !

              Posté par . Évalué à 10.

              Mouhahaha ! Même en comptant tout ça, la compilation C++ est à des années-lumières derrière…

              C'est pour mieux te pulvériser avec le binaire mon enfant. :-D

              kentoc'h mervel eget bezan saotred

              • [^] # Re: Yahou peut être enfin des jeux qui marchent !

                Posté par . Évalué à 8.

                Purée, j'ose pas imaginer ce que donnerait un KDE entièrement en Java…

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

                • [^] # Re: Yahou peut être enfin des jeux qui marchent !

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

                  http://sourceforge.net/projects/jdx/ ?

                  http://devnewton.bci.im

                  • [^] # Re: Yahou peut être enfin des jeux qui marchent !

                    Posté par (page perso) . Évalué à 10. Dernière modification le 26/09/14 à 15:59.

                    Définitivement un projet qui va révolutionner le monde: Étendre la laideur, la lenteur et l'over-engineering de SWING à un environnement bureau complet, j'en salive déja rien qu'a l'idée.

                    Ça ferait presque passé Xorg et Motif pour des environnements modernes et respectables en fait.

                    Allez juste pour le troll final, je copie colle ça depuis la dernière news du projet:

                    "New feature includes hot key support and many bug fixes. However, Swing's single thread model has been known to cause performance problems in this release when running multiple Java applications.."

                    Sounds awesome

            • [^] # Re: Yahou peut être enfin des jeux qui marchent !

              Posté par . Évalué à 2.

              Moui. Si on exécute le programme qu'une fois, c'est possible. Si, maintenant, on le lance, disons, une fois par jour… c'est moins certain, beaucoup moins.

          • [^] # Re: Yahou peut être enfin des jeux qui marchent !

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

            curl http://pastebin.com/raw.php?i=ywnLKdJu -o cmake/modules/ReleaseDebugFlags.cmake
            include(ReleaseDebugFlags REQUIRED);

            C'est pas très différent je trouve :-)

            http://devnewton.bci.im

          • [^] # Re: Yahou peut être enfin des jeux qui marchent !

            Posté par . Évalué à 10.

            echo -e '#include \n int main(int argc, char** argv){ std::cout << "Hello World" << std::endl; }' | g++ -x c++ -o /tmp/test -
            /tmp/test

            clair qu'écrire du code a coup de echo et de pipe, c'est super pertinent et vachement courant, cette possibilité se place tres tres haut sur la liste des trucs importants qui font vraiment une difference.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: Yahou peut être enfin des jeux qui marchent !

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

              Bof mon objectif n'était pas de lancer un concours de qui peut faire le plus de choses inutiles à coup de pipe initialement :D

              Plutôt de souligner la stupidité de l'affirmation

              des 42000 choses à savoir pour faire un hello world C++ correct :-)

              Tout en défendant un langage à la verbosité légendaire où tu as besoin de créer une classe pour faire un "Hello world".
              ```

              • [^] # Re: Yahou peut être enfin des jeux qui marchent !

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

                man hyperbole

                http://devnewton.bci.im

              • [^] # Re: Yahou peut être enfin des jeux qui marchent !

                Posté par . Évalué à -7.

                Si ton C++ te permet de te passer des classes pour un programme simple, c'est qu'il n'est pas vraiment objet. Ca reste du C auquel on a rajouté des classes en pourrissant la syntaxe déjà un peu crade d'origine.

                • [^] # Re: Yahou peut être enfin des jeux qui marchent !

                  Posté par . Évalué à 4.

                  Rien à voir.

                  Déjà il y a deux familles de langages orienté objet (au moins) : ceux basés sur des classes (C#, Java, …), et ceux basés sur le passage de messages (Ruby par exemple).

                  Et Ruby permet aussi de se passer de classes. On peut pas dire pour autant qu'il n'est pas vraiment objet, loin de là !

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Re: Yahou peut être enfin des jeux qui marchent !

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

                    Même si sur le fond il n'a pas tort (le C++ est du C avec une couche objet), ce n'est pas parce qu'on peut se passer de classes qu'il n'est pas objet.

                    On pourrait dire que Python est bien plus objet que Java, vu que tout est objet (y compris les classes, les méthodes, les fonctions, les entiers, …). Pourtant, on peut s'en servir sans faire de classe.

                    • [^] # Re: Yahou peut être enfin des jeux qui marchent !

                      Posté par . Évalué à 10.

                      Quand on parle de paradigme de programmation il y a souvent confusion entre :

                      • le modèle : par exemple le fait de tout voir comme des objets
                      • ce que prévoit le langage : par exemple en C, c'est pas du tout pensé pour ça, mais on peut programmer des objets très naturellement.

                      Après, il y a clairement des langages plus ou moins « orienté objet » mais savoir qui de python ou java est le plus objet est aussi intéressant que de savoir si quelqu'un dont les deux parents sont juifs est plus juifs que quelqu'un dont le père est catholique.

                      Je ne peux m'empêcher de penser que le paradigme objet a beaucoup d'une escroquerie intellectuelle. C'est pas un paradigme de programmation… Tout au plus c'est une vague idée de génie logiciel élevée au rang de doctrine. Parce qu'au fond, c'est rarement autre chose que de la programmation impératives.

                      La programmation logique, ça c'est VRAI paradigme. On exprime notre problème sous forme logique, et l’exécution du programme est en fait la recherche d'une preuve de la solution. Et il n'y a pas à ergoter pour savoir si tel ou tel langage est plus ou moins « orienté logique ». Soit le langage permet de prendre en entrée un ensemble de formule logique et de sortir une solution au problème, soit il ne le peut pas.

                      Bref, savoir si tel langage est plus ou moins orienté que tel autre c'est comme savoir si un livre est plus ou moins un livre de coloriage qu'un autre parce qu'il y a plus de traits à ne pas dépasser.

                      Please do not feed the trolls

                      • [^] # Re: Yahou peut être enfin des jeux qui marchent !

                        Posté par . Évalué à 4.

                        Je ne suis pas complètement d'accord (mais en grande partie quand même).

                        La POO est un vrai paradigme, dans le sens ou le raisonnement est différent de la programmation modulaire plus classique du C (par exemple).
                        Maintenant, je ne crois pas avoir vu un seul langage réellement OO, et ce, ne serait-ce que parce que de prime abord, l'OS appelle une fonction, et lui passe une liste de chaînes de caractères.
                        En Java, par exemple, ils utilisent une classe avec une méthode statique pour ça. Pas très pur objet, pas vrai? Si on voulait qu'un langage puisse être réellement pur objet (mais quel intérêt, sérieux?) il faudrait que lors de l'appel du programme on ait une API prédéfinie, genre une classe (et pas une méthode) main, que l'OS instancie en appelant le constructeur, puis dont il appelle une méthode précise (et pas une fonction, comme c'est le cas en Java, parce qu'une méthode statique, c'est bien plus proche d'une fonction dans un namespace, que d'une méthode), et qu'enfin l'OS dés-instancie en passant par le destructeur.
                        Mais franchement, quel intérêt ça aurait? Les langages "pur objet" me font bien rire, et la façon de faire du C++ (et de bien d'autres langages "bâtards" je pense) est à mon avis la bonne: exposer un certain nombre de façon de programmer, et laisser l'utilisateur faire son truc comme il le veut, en fonction de la situation.

                        Perso, rien jusqu'a présent n'a réussi à me convaincre que respecter un seul paradigme dans un programme est la meilleure chose à faire pour que le programme soit clair et efficace. C'est même le contraire.

                • [^] # Re: Yahou peut être enfin des jeux qui marchent !

                  Posté par (page perso) . Évalué à 9. Dernière modification le 27/09/14 à 12:52.

                  Si ton C++ te permet de te passer des classes pour un programme simple, c'est qu'il n'est pas vraiment objet. Ca reste du C auquel on a rajouté des classes en pourrissant la syntaxe déjà un peu crade d'origine.

                  Si j'avais envie de troller encore un peu je dirai:

                  • C++ n'a jamais prétendu être entièrement objet et c'est tant mieux: il est multi-paradigme.
                  • Java n'est pas entièrement orienté Objet aussi. Un programmeur Smalltralk ou Ruby peut facilement te faire un speech de 1h sur le sujet.

                  Une personne en 2014 qui ne prêche que le 100% pure-objet à l'heure du multi-core et la programmation concurrente devrait sincèrement internée.

          • [^] # Re: Yahou peut être enfin des jeux qui marchent !

            Posté par . Évalué à 1. Dernière modification le 27/09/14 à 12:06.

            edit: mauvais endroit en fait

      • [^] # Re: Yahou peut être enfin des jeux qui marchent !

        Posté par . Évalué à 8.

        Sinon j'imagine que tu as posté ce troll entre deux compilation maven ?
        Vu qu'elles téléchargent la moitié du web à chaque fois, il est vrai que ça laisse tu temps libre.

        Bel exemple de mauvaise foi crasse. Maven ne télécharge les artefacts (plugins et dépendances) que lorsqu'ils ne sont pas déjà présents dans le repository local.
        La 1ère compilation d'un projet peut effectivement demander pas mal de téléchargements, mais sur les compilations suivantes il n'y aura plus nécessiter de télécharger quoi que ce soit.

      • [^] # Re: Yahou peut être enfin des jeux qui marchent !

        Posté par . Évalué à 6.

        Ne reproche pas le fait que tu ne sais pas utiliser cmake à cmake en fait.
        Tout ce que tu as fait précédent existe déja en modules, tu aurais pu le faire en une ligne:

        include(blabla REQUIRED)
        

        Ah wep ok et donc les ptites recettes magiques, les modules qu'y faut utiliser et tout, on les découvre comment ? Pasque la doc de CMake est plutôt sèche (c'est une doc de référence, ya pas de "comment y faut faire pour bien faire") et les ressources en lignes se résument à un wiki chelou et des mailing lists, et tu te retrouve fatalement à faire ce qu'il fait : du gros copier coller.

      • [^] # Re: Yahou peut être enfin des jeux qui marchent !

        Posté par (page perso) . Évalué à 1. Dernière modification le 28/09/14 à 02:15.

        mmh
        #pragma once.
        De rien.

        Non, c’est pas standard.

        Edit: Ah bon ça a déjà été discuté à côté.

  • # Question

    Posté par . Évalué à 4.

    Dans tes includes tu utilises plutôt des directives #include pour déclarer les classes où tu utilise class Plop; ?

    Dans le premier cas regardes du coté des precompiled header ou tente de passer au maximum par le second  ;)

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # ...

    Posté par . Évalué à 5.

    j'ai une dizaine de classes et la compilation se fait déjà longuette.

    Un .h peut maintenant se compiler comme les .c. Cela permet de gagner du temps.

    toujours pas de stacktrace lors d'une exception.

    Non, mais il existe des bout de code qui permet de le faire, en récupérant les exceptions.

    "La première sécurité est la liberté"

    • [^] # Re: ...

      Posté par (page perso) . Évalué à 4. Dernière modification le 26/09/14 à 10:25.

      Un .h peut maintenant se compiler comme les .c. Cela permet de gagner du temps.
      Non, mais il existe des bout de code qui permet de le faire, en récupérant les exceptions.

      Il y a des trucs portables qui marchent facilement pour faire tout ça?

      http://devnewton.bci.im

      • [^] # Re: ...

        Posté par (page perso) . Évalué à 5. Dernière modification le 26/09/14 à 10:46.

        Question #1 : avec gcc, tout simplement.

        
        $ gcc lua_commun.h
        $ ls -lh
        -rw-r--r-- 1 jseb jseb 1,7K 22 avril 09:39 lua_commun.h
        -rw-r--r-- 1 jseb jseb 2,1M 26 sept. 10:45 lua_commun.h.gch
        
        

        Lors des compilations suivantes, gcc détectera le .gch et l'utilisera.

        • [^] # Re: ...

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

          Comment faire ça avec cmake?

          http://devnewton.bci.im

          • [^] # Re: ...

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

            Il n'y a toujours pas de support officiel pour les entêtes précompilés dans cmake (mais il y'a plein de pistes dans le bug associé
            http://www.cmake.org/Bug/print_bug_page.php?bug_id=1260).

          • [^] # Re: ...

            Posté par . Évalué à 8.

            Est-ce que cmake t'apporte un vrai gain ? Il est pas mal pour la gestion des dépendance (qu'il est le seul à gérer avec les autotools), mais si ça ne t'arrange pas il y a un paquet d'outils de build qui te ferront du café torréfié sous l'aisselle, font revenir l'être aimé et rende le poil plus soyeux, les plus avancés soignent les phobies administratives.

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

            • [^] # Re: ...

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

              Une gestion des dépendances dans cmake? Où ça?

              J'ai pris celui là pour faire comme tous les développeurs modernes. Les autres outils de build ont l'air préhistoriques ou morts.

              http://devnewton.bci.im

              • [^] # Re: ...

                Posté par . Évalué à 3.

                moi j'aime bien "gcc -MM" avec make.

                Mais c'est pour des trucs simple.

                "La première sécurité est la liberté"

              • [^] # Re: ...

                Posté par . Évalué à 3.

                Comme ide sympa avec CMake, qtcreator est bien, en plus on peut faire du vim comme à la maison :)
                Pour les temps de compilation, en effet les forward declarations c'est ce qu'il y a de mieux. Si tu cherches néanmoins du côté des precompiled headers je te conseilles d'éviter les includes guards (#ifndef au début du .h) et de préférer les #pragma once. En effet si ton include est inclus par d'autres headers, il sera lu à chaque fois avec différentes variables de préprocesseur (et donc recompilé). Concernant la portabilité du pragma once, marche avec gcc, clang et visual donc ça me suffit :)
                A propos de clang, j'ai de bien meilleurs temps de compilation avec (surtout avec du boost).

                Pour les stacks trace, j'ai pas mieux que lancer dans gdb (ou activer les fichier core pour du post-mortem)

                • [^] # Re: ...

                  Posté par . Évalué à 2.

                  ou a l'init signal(11, fonction());

                  et dans la fonction faire tout ce qu'il faut pour la stacktrace, attention cependant :
                  pas d'allocation dynamique dans une fonction appelé via un signal (théoriquement que du signal safe)

                  typiquement

                  void printStackTrace()
                  {
                    void *stack[20]; 
                    backtrace_symbols_fd(stack, backtrace(stack, 20), 2);
                  }

                  et hop magie (bon c'est dun GNU ) ;)

                  Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                • [^] # Re: ...

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

                  Les compilateurs modernes reconnaissent les include guards et effectuent la même optimisation que pour #pragma once.

                  (mais je ne veux pas dissuader l'utilisation de #prama once qui est bien moins sujet à l'erreur)

                  • [^] # Re: ...

                    Posté par . Évalué à 1.

                    Le compilateur reconnaît oui, mais il n'empêche que le fichier n'est pas compilé avec les même définitions, donc dans le cas d'en-têtes pré-compilées, elles seront re-compilées. Je parle ici d'un A.h qu'on veut pré-compiler, s'il est inclus par B.h et C.h, il sera pré-compilé avec INCLUDEGUARD_A_H, puis pré-compilé avec INCLUDEGUARD_B_H.

      • [^] # Re: ...

        Posté par . Évalué à 3.

        pour le 1), c'est gcc (et sans doute aussi visual studio).

        pour le 2), c'est du linux, il me semble.

        "La première sécurité est la liberté"

      • [^] # Re: ...

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

        Ne pas oublier non plus :
        - ccache (assez trivial à mettre en place)
        - distcc (si tu as d'autres bécanes sous la main)
        - éviter le couplage fort entre les sources en utilisant le PIMPL idiom
        - …

      • [^] # Re: ...

        Posté par . Évalué à 4.

        Faire tourner dans gdb (et un on IDE qui wrapper bien autour de gdb) est assez efficace pour trapper les exceptions.

        Sinon dans l'idée c'est de réactiver la génération des fichiers core en cas de crash, et du coup pareil, avec ton fichier core (pas strippé par contre) et un bon IDE tu peux retrouver l'endroit du plantage

  • # Cross-compilation

    Posté par (page perso) . Évalué à 10. Dernière modification le 26/09/14 à 11:13.

    Salut,

    Pour la cross-compilation, j'ai découvert depuis mon projet crossroad que c'est vraiment pas un problème du moment que tu fais du code ok et des Makefiles normaux (que ce soit autotools ou cmake), puis tu testes une cross-compilation régulièrement (avec crossroad, qui prend en charge justement autotools et cmake!) pour t'assurer que ça cross-compiles bien et corriger les éventuels accrocs.

    Il m'est déjà arrivé de corriger des projets en un mini-patch qui n'avaient jamais même pensé que leur projet marcherait avec win32. C'est le cas par exemple de la bibliothèque GExiv2 (quand on s'est mis à utiliser Exiv2 et son wrapper GExiv2 pour GIMP, il fallait bien sûr que cela fonctionne sous Windows aussi). Ils utilisaient à l'époque un Makefile fait à la main, à l'ancienne. Je l'ai transposé en un Makefile.am + configure.ac tout à fait classiques. Je cross-compile. Pof! Ça marche! En un temps record, GExiv2 fut porté sous Windows (je pense même pas avoir eu à toucher une seule ligne de code). Les développeurs de cette bibliothèque m'ont dit qu'ils n'avaient jamais développé cette lib sur Windows, n'avaient jamais tenté de la compiler pour cette plateforme et ne s'étaient même pas dit que ce serait possible (puisqu'ils ne s'en préoccupaient pas depuis le début). C'est la magie des chaînes de compilation standards sous Linux (en tous cas, pour les 2 les plus répandus, autotools et cmake. Je n'ai jamais eu l'occasion d'en essayer d'autre dans un contexte de crossbuild).
    Franchement, la cross-compilation, c'est pas un gros problème. :-)

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: Cross-compilation

      Posté par . Évalué à 2.

      Ha tiens, il faudra que je réessaie pour mon jeu. Il y a eu des mises à jour de Mingw-W64, ça va peut-être corriger le bug que j'ai eu la dernière fois.

      • [^] # Re: Cross-compilation

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

        N'hésite pas à me tenir au courant sur comment ça se passe.

        Aussi j'ai déjà plusieurs évolutions sur ma copie locale. Dès que j'aurai un peu tout mis au propre et bien testé sur mes crossbuilds locaux, faudra que je sorte une v0.6 qui commencera à bien s'approcher d'un outil que je pense vraiment indispensable pour enfin se débarrasser de tous les scripts sales et non portables "par projet" que chacun fait dans son coin pour chaque cross-compilation.

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

  • # IDE

    Posté par . Évalué à 8.

    J'ai essayé quelques IDE, avant de me rendre compte que Eclipse ou Netbeans sont les seuls à proposer une bonne complétion, du refactoring qui marche et à ne pas planter lamentablement (kdevelop, c'est de toi que je parle). Les meilleurs IDE C++ sont donc en Java…

    Pour aussi bosser en Java (mais c'est pareil pour les développeurs C#), c'est vraiment des manières de travailler différentes. Un intellij est capable de faire de l'autocomplétion intelligente, de faire des refactoring sophistiqués (tu utilise un identifiant qui n'existe pas, il te propose d'ajouter un paramètre à ta fonction avec un type cohérent (que tu peut changer), et de lui donner une valeur par défaut (partout où la méthode sera appelée il ajoutera cette valeur dans les paramètre) ou d'ajouter une donnée membre à ta classe etc).

    Bien sûr les IDE c'est mal quand on apprend, il faut comprendre ce qu'on fait, etc, etc. Mais personnellement j'ai plus à apprendre les bases du langage dans le quel je travail, maintenant je l'utilise et j'essaie de produire du code de qualité. Plus important, je relis mes diff avant de commiter/pusher. Au lieux de perdre 2h à faire des refacto à la main (à coup de Ctrl+c/Ctrl+v, pas très enrichissant1) voir à coup de grep/sed (pour ceux qui utilisent cette dernière méthode j'ose espérer qu'ils relisent en détail les diff parce que c'est nettement plus casse gueule que ce que fait un IDE), je passe 10-15 minutes à relire mes diff. Le gain est réel.


    Aucun rapport mais pour l'édition du code, moi qui utilise vim à longueur de temps j'ai commencé à jouer avec les multi-curseur. C'est vachement bien ça ! Il va vraiment falloir que ce soit ajouté dans vim ou au pire emacs.


    1. les macro vim peuvent aider, intellij a une fonctionnalité pas mal aussi avec SSR

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

  • # Jeux de mots tard

    Posté par . Évalué à 10.

    Ah Nal! Tu l'auras compris, retrouver une ancienne amour, c'est souvent se rendre compte que tout a changé pour que rien ne change.

    Tu racontes tes amours à Nal ?

    Ben bravo, c'est du propre !

    • [^] # Re: Jeux de mots tard

      Posté par . Évalué à 5. Dernière modification le 26/09/14 à 15:29.

      Mouai, jeu de mots laid pour gens bêtes ;-) mais très bon au demeurant

      kentoc'h mervel eget bezan saotred

      • [^] # Re: Jeux de mots tard

        Posté par . Évalué à 5.

        Mouais, jeu de mots laid pour gens bêtes ;-)

        Pour les moinsseurs pressés, il s'agit d'une référence à l'excellentissime Bobby Lapointe.

        Très bonne référence \o/

  • # plop

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

    J'ai essayé quelques IDE, avant de me rendre compte que Eclipse ou Netbeans sont les seuls à proposer une bonne complétion, du refactoring qui marche et à ne pas planter lamentablement

    Il y a aussi CLion. Je le teste depuis quelques temps et à part une mauvaise gestion des macros du type __LINE__ (il ne l'utilise pas bien et affiche des erreurs dans le code alors qu'il n'y en a pas, par exemple sur des macros qui créent des identifiants uniques) ça marche plutôt pas mal.

    l'absence de système de modules: des entêtes avec #ifndef … #endf en 2014, c'est très moche.

    Hein ? Nan mais ça fait un moment qu'on est plus obligé d'utiliser ce genre de truc pour gérer les .h

    #pragma once

    Franchement je sais pas pour quelle foutu raison les gens ne se sortent pas les doigts pour l'utiliser. Certes, si on lit wikipedia il parait que c'est pas standard et non supporté par tout le monde, mais bon quand on regarde la liste on a tout de suite 'achement moins peur. Donc #pragma once.

    • [^] # Re: plop

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

      Il n'y a pas une option pour avoir l'effet de #pragma once pour tous les .h? Je ne me souviens pas une seule fois d'avoir eu un .h à inclure plusieurs fois…

      http://devnewton.bci.im

      • [^] # Re: plop

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

        J'ai déjà vu ce cas se produire une fois chez un collègue dans une histoire de modules/plugins sous windows.
        Il me semble bien que tout le code est parti à la poubelle quelques mois plus tard.

      • [^] # Re: plop

        Posté par . Évalué à 2.

        Tu n'as jamais de class utilitaire définit dans un fichier util.h que tu utilises un peu partout ?

        "La première sécurité est la liberté"

        • [^] # Re: plop

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

          nan mais au final tu ne l'inclus qu'une seule fois.

          Je pense que ce qu'il veut dire c'est un .h que tu inclus réellement plusieurs fois (donc sans #ifndef)

          • [^] # Re: plop

            Posté par . Évalué à 2.

            Bah, les .h(pp) sont inclus plusieurs fois, si tu utilises plusieurs fichiers c(pp) qui l'incluent, ton header sera inclus plusieurs fois (pour un projet donné), et c'est d'ailleurs la principale cause des lenteurs de compilation C++.

            • [^] # Re: plop

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

              Heu, oui mais non.
              Certes il sera inclus, mais comme il va rencontrer (là deuxième fois et les suiantes) un #findef BLABLA_H qui sera défini, il ne va rien inclure du tout.
              Donc le code de ton .h sera bel est bien inclus une seule fois (sauf cas très particuliers)

        • [^] # Re: plop

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

          Il fallait comprendre "plusieurs fois avec le besoin que le contenu soit répété et non gardé par un ifndef/pragma".

          http://devnewton.bci.im

          • [^] # Re: plop

            Posté par . Évalué à 2.

            A part dans des cas tordu, je ne crois pas.

            https://en.wikipedia.org/wiki/X_Macro

            "La première sécurité est la liberté"

            • [^] # Re: plop

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

              Exactement. Exemple:

              enum MySuperEnum {
              #define X(NAME, VALUE, ACTION)  SuperEnum_##NAME = VALUE,
              #include "super_values.def"
              #undef X
              };
              
              /* ... Plus loin  ...   */
              
              vod MyClass::maFunction(MySuperEnum foo) {
                switch (foo) {
              #define X(NAME, VALUE, ACTION) case SuperEnum_##NAME : ACTION; break; 
              #include "super_values.def"
              #undef X
               }
              }

              Le premier bout de code est dans un header mais le tout fini dans la même translation unit

              Le fichier super_value.def ressemble à ça:

              X(Addition, 13,  Val0 = Val1 + Val2)
              X(Division, 21,  Val0 = Val1 / Val2)
              X(SelfAddition, 42,  Val0 += Val1)
              // ...

              (possiblement auto-généré)

    • [^] # Re: plop

      Posté par (page perso) . Évalué à -5.

      Hein ? Nan mais ça fait un moment qu'on est plus obligé d'utiliser ce genre de truc pour gérer les .h…
      pragma once

      http://en.wikipedia.org/wiki/Pragma_once
      In the C and C++ programming languages, #pragma once is a non-standard but widely supported preprocessor directive (…)

      Programmer en non standard, ce n'est pas terrible (sympa pour les compilos qui se conforment au standard mais n'ont pas ce truc). A utiliser que si on n'a pas pour but de diffuser son code plus que ça.

      • [^] # Re: plop

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

        Bien.

        Maintenant tu peux relire mon message jusqu'au bout :

        Certes, si on lit wikipedia il parait que c'est pas standard et non supporté par tout le monde, mais bon quand on regarde la liste on a tout de suite 'achement moins peur. Donc #pragma once.

        Ho tiens, c'est le même lien et la même information…

        A utiliser que si on n'a pas pour but de diffuser son code plus que ça.

        Ha oué ? Et tu peux m'expliquer dans quel cas normal ça ne passerait pas ? Parce que justement si on suit le lien on a :

        Portability

        Compiler #pragma once
        Clang Supported
        Comeau C/C++ Supported
        C++Builder XE3 Supported
        Digital Mars C++ Supported
        GCC Supported (since 3.4)
        Intel C++ Compiler Supported
        Microsoft Visual C++ Supported
        Pelles C Supported
        ARM DS-5 Supported
        IAR C/C++ Supported
        • [^] # Re: plop

          Posté par . Évalué à 3. Dernière modification le 26/09/14 à 14:22.

          Pas sûr que ça soit supporté par TCC ? (cela dit ce dernier ne gère que ISOC99 et pas C++, donc hors-sujet pour Devnewton)

      • [^] # Re: plop

        Posté par (page perso) . Évalué à 5. Dernière modification le 26/09/14 à 12:41.

        Est-ce qu’il existe un autre compilateur que Clang, Comeau C/C++, C++Builder XE3, Digital Mars C++, GCC, Intel C++ Compiler, Microsoft Visual C++, Pelles C, ARM DS-5 et IAR C/C++ qui sera susceptible de compiler le nouveau jeu de devnewton< ? C’est la vraie question en fait.

        cf. https://en.wikipedia.org/wiki/Pragma_once#Portability

        [Edit: arg, grillé par CrEv :D]

        ce commentaire est sous licence cc by 4 et précédentes

        • [^] # Re: plop

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

          Si c'est pour un jeu, faut voir quels compilos sont utilisés (ou utilisables) pour les "homebrew" sur consoles de jeux (Pandora, PSP, DS…), ça pourrait être un frein à la portabilité pour le jeu.

    • [^] # Re: plop

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

      Alors, peut-on avoir un retex sur CLion, à part ce problème de macros ? Bon, il est encore en beta à ma connaissance, c'est normal qu'il ne soit pas encore parfait.
      Je commence à bien connaître PyCharm (qui m'a fait totalement oublier un VIM configuré avec amour), et un peu IntelliJ (qui m'a fait mettre rapidement Eclipse à la poubelle, comme tous ceux que je connais et qui ont essayé IntelliJ ou PHPStorm), et du coup j'attendais avec impatience qu'ils fassent un IDE C/C++. Maintenant, plus qu'à trouver un projet à faire en C++ :D

      Pour ceux qui ne connaissent pas, contrairement à Eclipse qui est multilangage, Jetbrains publie un IDE par langage (IntelliJ pour le Java/Scala, PyCharm pour le Python, PHPStorm pour le PHP, RubyMine pour le Ruby), avec parfois des plugins pour une prise en charge limitée d'autres langages.

      • [^] # Re: plop

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

        Pour le moment j'ai aucun problème avec, l'auto reload de cmake fonctionne plutôt bien, la complétion aussi.
        Ça prend un peu de ram quand même… mais sinon c'est sympa, il y a des symboles pour passer du prototype à l'implémentation d'une méthode facilement, l'intégration aux gestionnaires de sources est bonne, etc.

        Le problème des macros est quand même assez spécifique, genre si on utiliser __LINE__ ou __COUNTER__ pour créer des variables uniques, les deux macros ne sont pas bien interprétées et sont à 0. Résultat les variables uniques ne le sont plus pour l'IDE et il affiche en rouge.

        Ex :

        #define UNIQUE_2(name, line) name##line
        #define UNIQUE_1(name, line) UNIQUE_2(name, line)
        #define UNIQUE(name) UNIQUE_1(name, __LINE__)
        
        int UNIQUE(plop);
        int UNIQUE(plop);

        Le résultat devrait être

        int plop5;
        int plop6;

        pour CLion le résultat est

        int plop0;
        int plop0;

        Et donc forcément ça ne passe pas. Bon c'est génant mais pas ultra horrible. Le problème c'est que c'est souvent utilisé dans les framework de tests unitaires.

        D'ailleurs question bonus, si quelqu'un sait comment faire une macro pour avoir un nom de variable unique sans __LINE__ ni __COUNTER__ ça m'intéresse vraiment ;-)

        • [^] # Re: plop

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

          Effectivement, c'est un peu dommage :(

          Au passage, que donne le debuggueur ? Si j'ai bien compris, il est encore basé sur gdb.
          N'y a-t-il pas de debuggueir plus récent ? Comme lldb ?

  • # KDevelop

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

    planter lamentablement (kdevelop, c'est de toi que je parle).

    Chez moi ça marche très bien.
    Quelle version de KDevelop as tu utilisé ? Pourquoi plantait-il ?

    • [^] # Re: KDevelop

      Posté par . Évalué à 3.

      Idem ici. Si c'est une version récente, est ce que tu as rapporté les backtraces du crash sur le bugzilla ?

      • [^] # Re: KDevelop

        Posté par . Évalué à 1.

        Idem. J'ai bien connu le crash lamentable, c'était de kdevelop 4.0 à 4.4.
        J'ai compilé la version de développement (4.6 à l'époque) et maintenant tout fonctionne parfaitement.
        Ça vaut le coup de (re)tenter les toutes dernières versions.

  • # smart pointer

    Posté par . Évalué à 2.

    Enfin vous voilà, smart pointers dans la STL!

    Je veux pas être méchant, mais tu es mauvaise langue.
    Ceci dit, l'actuel unique_ptr est effectivement nettement mieux.

    Je passerais outre le fait que tu dises n'avoir trouvé qu'eclipse comme IDE digne de ce nom, genre il plante pas. J'ai vécu l'enfer avec cet outil, pour coder en Java. J'ai un net souvenir d'une auto-complétion hyper longue, qui se déclenchait toute seule (et pas moyen de l'en empêcher, j'ai cherché partout, sauf au bon endroit je suppose) et qui faisait planter la bête si j'osais utiliser mon clavier tant qu'elle avait pas fini.

    Bref, comparé à ce bon vieux code::blocks par exemple, que je n'ai que rarement vu planter et ce, probablement parce que j'utilisais la version de nightly, je ne pense pas qu'eclipse vaille la peine. À la rigueur, tu aurais dis netbeans, je t'aurais accordé le bénéfice du doute.
    Mais perso, je suis passé à cmake+vim+cgdb, ça marche très bien, c'est léger, réactif, stable et ça n'a pas besoin de serveur graphique (sisi, parfois c'est utile).

    Sinon, continue si tu le souhaites, de toute façon la plupart des problèmes de performances ne sont pas dus aux langages, mais aux dev. Après… c'est une évidence pour moi, quand on enlève une couche dans un SI, ça va plus vite et bouffe moins de RAM, si les choses sont faites proprement. Chacun ses goûts et opinions.

    PS: vrai que c'est lent ta compilation. Mais ça doit être lié aux lib boost qui sont à base de template. À voir si il n'y à pas moyen d'améliorer ça… en-tête précompilés par exemple?
    PPS: ça compile pas ici, je verrai plus tard pour fixer.
    Commit: aaa9cbb9c70e

    /home/****/superpaflaballe/src/assets.cpp:59:31: note: in instantiation of function template specialization
          'boost::property_tree::json_parser::read_json<boost::property_tree::basic_ptree<std::basic_string<char>,
          std::basic_string<char>, std::less<std::basic_string<char> > > >' requested here
            boost::property_tree::read_json(path, pt_nanim);
                                  ^
    
    • [^] # Re: smart pointer

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

      ça compile pas ici, je verrai plus tard pour fixer

      Peut être la version de boost? Pour l'instant je ne garantis la compilation que sous Ubuntu 14 LTS :-)

      http://devnewton.bci.im

      • [^] # Re: smart pointer

        Posté par . Évalué à 2.

        Probable en effet: 1.49 ici.

        Je te suggère donc un patch, si tu dépends d'une version particulière de boost: find_package(Boost $BOOST_VERSION COMPONENTS $BOOST_COMPONENTS REQUIRED) ;)

    • [^] # Re: smart pointer

      Posté par . Évalué à 0.

      Mais perso, je suis passé à cmake+vim+cgdb, ça marche très bien, c'est léger, réactif, stable et ça n'a pas besoin de serveur graphique (sisi, parfois c'est utile).

      Et c'est totalement imbitable pour voir des structures imbriquees, genre STL.

      Pour avoir passe l'annee derniere a developper sur Linux apres des siecles dans Visual Studio, j'ai vraiment l'impression d'etre passe du 21eme siecle a la prehistoire niveau debuggage, c'est incroyable a quel point c'est douloureux et non-productif. J'ai du mal a comprendre qu'une communaute tellement portee sur le developpement n'ait pas resolu ce point la.

      • [^] # Re: smart pointer

        Posté par . Évalué à 3.

        Tu sais, dans l’industrie, j’ai des clients qui nous demande encore visual 6… alors tu sais…

        Pour ton information, kdevelop, qtcreator, emacs sont très bien, font de la très bonne complétion. Kdev te propose même les inclusions. Visual a aussi pas mal progressé que ce soit au niveau du compilateur comme de l’IDE… mais personnellement, pour faire des remplacements, compilation… je préfère une ligne de commande. C’est juste une question de gout et d’habitude.

        • [^] # Re: smart pointer

          Posté par . Évalué à 4.

          Je parles de debuggage

          Ni KDevelop, ni Emacs, ni Eclipse (que j'ai tous essaye) ne sont foutus de permettre de proprement debugger un programme sans y passer des heures. Car ils se basent tous sur gdb qui est un homme des cavernes de ce cote la (et je n'oses meme pas en parler quand tu ajoutes openmp dans le mix…), et leur capacite a interpreter proprement les containers STL par exemple est proche de zero.

          • [^] # Re: smart pointer

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

            Pour avoir passé ces quelques derniers mois du temps sous visual, en effet un debugger qui invente parfois des breakpoints de toutes pièces c'est à la limite de skynet en effet !
            Et que dire de l'environnement qui freeze 4fois par jour parce que j'ai eu la drôle d'idée d'appuyer sur F7 …
            Ou encore d'intellisense qui met 5 minutes à chercher la définition d'un truc placé honteusement 15 lignes plus haut dans le même fichier.
            Que penser aussi de la boite de dialogue de configuration des entrées du linker qui date au moins des ergonomistes de windows 3.11
            Et bien sur je ne parle pas des compils qui s'arrêtent sur une erreur inattendue de visual (certaines sont attendues au fait ?)
            C'est con de payer une licence aussi chère pour se taper l'achat en parallèle d'un truc genre visual Assist pour enfin avoir une complétion honnête et du refactoring pas trop con.
            paye paye paye …

            • [^] # Re: smart pointer

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

              Sans oublier que MSVC, le compilateur C++ de Microsoft, est l'équivalent de IE en ce qui concerne le support des standard.
              C++11 est normalisé depuis 3 ans. MSVC est terriblement en retard comparer aux équivalent libre (clang et GCC). Même la dernière version ne supporte pas encore tout.

            • [^] # Re: smart pointer

              Posté par . Évalué à 1.

              Chacun ses gouts. Je me contentes de constater qu'il m'est bcp, bcp, plus rapide de developper un soft sous Windows avec VStudio, eliminer un max de bugs grace a un debugger qui fonctionne proprement, et faire alors le portage sous Linux que faire le codage principalement sous Linux avec Eclipse/Emacs/KDevelop et gdb.

              C'est quand meme con de devoir utiliser un Windows pour accelerer le developpement d'un soft Linux…

              • [^] # Re: smart pointer

                Posté par . Évalué à 2.

                C' est fou tu es en train de dire que tu as tes habitudes et que tu n'aimes pas en changer. Comme c' est curieux tu es bien le premier humain comme cela…

                • [^] # Re: smart pointer

                  Posté par . Évalué à 2.

                  Tu remarqueras que j'ai liste un probleme tres precis : l'impossibilite du debugger utilise a afficher des conteneurs STL.

                  Quand ton soft est totalement base sur STL, vecteurs, maps, string, smart pointers, … on va dire que c'est un probleme sacrement dur a vivre avec.

                  • [^] # Re: smart pointer

                    Posté par . Évalué à 2.

                    Je sais pas pour les autres conteneurs STL mais Qt Creator s'en sort très bien avec les std::vector et les std::string, probablement parce qu'il inclut de base des scripts gdb pour bien les gérer.

                  • [^] # Re: smart pointer

                    Posté par . Évalué à 5.

                    Chez moi ça marche.
                    Source:

                    #include <vector>
                    int main()
                    {
                            std::vector<int> foo;
                           for(int i=0;i<100;++i)
                                    foo.push_back(i);
                    }

                    Sortie de gdb (enfin, cgdb, mais c'est juste un frontend):

                    (gdb) p foo
                    $1 = std::vector of length 15, capacity 16 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11,
                    12, 13, 14}

                    Bien entendu, je n'ai exécuté en pas à pas que quelques itérations, pour l'exemple. Donc, problème résolu?

                    À noter tout de même pour l'honnêteté intellectuelle, il me semblait qu'il fallait faire appel à des trucs plus retors (à l'époque ou j'utilisais C::B, il me semble qu'il y avait besoin de faire appel à du python. Je n'ai jamais creusé la question ceci dit…), il y à quelques mois. J'imagine que ça ne fonctionne que sur des versions un minimum récentes de gdb donc.

              • [^] # Re: smart pointer

                Posté par . Évalué à 2.

                Est-ce que c'est aussi vrai pour debugger des programmes multithreadés ? (c'est une vraie question, mon expérience sous unix est que de toute manière comme j'écris mes propres bibliothèques de threads au-dessus des PThreads, je me retrouve à avoir des outils pour faire des traces, et je n'utilise que rarement la capacité de gdb à suivre les PThreads…)

                • [^] # Re: smart pointer

                  Posté par . Évalué à 0.

                  J'ai un layer d'abstraction pour la creation de threads/lock/unlock/… et ca n'a donc pas vraiment d'effet pour moi. Mais pour avoir utilise OpenMP, gdb pourrit totalement le debuggage avec ca(du moins c'est l'experience que j'en ai eue a travers Eclipse)

                  • [^] # Re: smart pointer

                    Posté par . Évalué à 2.

                    OpenMP c'est différent : ils utilisent un système de user threads au-dessus des pthreads. Du coup à moins de patcher gdb pour avoir les bons hooks vers les threads omp, tu pourras pas faire grand chose. Un de mes collègues au CEA avait pris un stagiaire juste pour rajouter les bons outils de debug dans gdb pour sa bibliothèque de threads mixtes (pthreads+user threads). Ça marchait très bien ensuite.

                    • [^] # Re: smart pointer

                      Posté par . Évalué à 0.

                      Pour moi peu importe la raison… OpenMP est dans gcc depuis un moment, mais du fait de l'impossibilite de debugger ce code car tous les IDEs utilisent gdb, c'est inutilisable sur Linux. J'ai du me resoudre a faire ca sous Visual Studio et ensuite porter la chose. On va dire que c'est vraiment pas ideal comme experience pour un developpeur.

                      • [^] # Re: smart pointer

                        Posté par . Évalué à 2.

                        Moui enfin, OpenMP est dans MVC++ mais seulement en v2.0, alors qu'on est passé à v2.5 puis 3.0, puis 3.1. Et tous les compilos — Intel cc, gcc, Sun cc, etc., implémentent le standard1. Est-ce que MSVC++ permet de débugger les threads OpenMP ? (là encore, vraie question)


                        1. Bon par contre OpenMP 4.0 sortie l'an dernier rajoute le support des GPU et du coup à part Intel qui propose une implémentation partielle, y'a pas grand chose de mise en œuvre pour cette version-ci. 

                        • [^] # Re: smart pointer

                          Posté par . Évalué à 0.

                          Est-ce que MSVC++ permet de débugger les threads OpenMP ? (là encore, vraie question)

                          Ben oui, c'est justement comme ca que je l'ai fait… Codage / debuggage sous Windows autant que possible et portage aussi tard que possible.

                          C'est bien sympa que gcc soit a la pointe avec openmp, mais si c'est impossible a utiliser car impossible a debugger, ca sert a rien… :/

                          • [^] # Re: smart pointer

                            Posté par . Évalué à 3.

                            C'est bien sympa que gcc soit a la pointe avec openmp, mais si c'est impossible a utiliser car impossible a debugger, ca sert a rien… :/

                            En même temps, à ma connaissance, le compilo d'Intel ne fait pas mieux, et idem pour la plupart des concurrents Quelque part j'ai envie de dire « C'est bien beau de fournir un env. de debugging pour OpenMP 2.0, mais on n'est plus en 2004. » :-P

                            De plus, les gens qui bossent sur des applis avec plusieurs centaines ou milliers de threads OpenMP n'utilisent pas de debuggers parce que trop compliqué (à moins de te faire pousser quelques dizaines d'yeux, comment tu fais pour surveiller les cas chiants du type data race ?). Du coup la plupart des gens qui bossent sur des applis massivement multithreadées passent par des trucs du genre omp barrier ou omp taskwait + printf. En règle générale, dans le monde du HPC, il y a peu voire pas de vraie solution de debug pour le parallélisme massif. Et la réponse des gens à ce problème est en gros « utilise un langage qui limite les possibilités de data race, genre DSL, langages fonctionnels, ou quasi-fonctionnels (i.e. multi-paradigmes) ».

                            Pour ce genre d'applications (HPC), le debugger « idéal » serait sans doute un truc qui permet d'enregistrer une trace sur N cycles ou secondes, puis qui permette de « rejouer » la séquence et d'analyser les valeurs. Le problème est la taille de la trace résultante, et surtout les heisenbugs : même comme ça tu risques d'avoir des soucis pour trouver le bug en question.

                            Note que j'aime beaucoup le debugger de MSVC++, juste que le manque de fonctionnalités du compilo en fait quelque chose de pas très intéressant pour faire du dév OpenMP un peu poussé (il y a tout un tas d'applis de simulation numériques qui tirent fortement partie des tasks OpenMP pour la traversées de structures de graphe ou tableaux « creux »).

                            • [^] # Re: smart pointer

                              Posté par . Évalué à 0.

                              Notes bien que je ne blames pas le compilo hein, c'est gdb et les IDEs qui l'utilisent qui sont le probleme de mon point de vue.

                              Mon utilisation d'openmp n'est pas du tout pour du HPC, c'est simplement pour tres facilement parralleliser des boucles qui s'y pretent bien (quasiment rien a locker dedans, juste besoin d'un join a la fin de la boucle).

                              • [^] # Re: smart pointer

                                Posté par . Évalué à 2.

                                Notes bien que je ne blames pas le compilo hein, c'est gdb et les IDEs qui l'utilisent qui sont le probleme de mon point de vue.

                                Je comprends bien. Apparemment, le compilo d'Intel (idb) ne fait rien pour OpenMP. Celui de SunOracle permet d'insérer un break point à l'entrée d'une région parallèle, mais sans réellement permettre de décider quel thread on veut surveiller (le premier thread arrivé est celui qu'on surveille), du coup je trouve ça assez limité aussi… Du coup le manuel propose plutôt d'utiliser les stack traces (voir ici par ex). XL/C (le compilo d'IBM) ne semble pas avoir de support du tout, etc.

          • [^] # Re: smart pointer

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

            J'ai travaillé plusieurs années sous VisualStudio 2008 sur un très gros projet — appli industrielle de gestion de risque financier — en C++ et je dois dire que le débogueur visuel est excellent — à ceci près que notre version n'incluait pas de fonction trace, mais les fonctions offertes sont très bonnes. Il a toujours fonctionné de façon à peu près correcte — ce qui sur une codebase pré-STL de plus de 30 ans, qui sert accessoirement de vitrine à toutes les mauvaises pratiques de programmation imaginables, est un succès non-négligeable.

            Le problème de la boîte est qu'il était utilisé en guise de documentation technique — c'est à dire, pour comprendre l'organisation du code, la seule ressource était de faire du pas à pas! :)

          • [^] # Re: smart pointer

            Posté par . Évalué à 2.

            Moi j’ai eu des cas, ou tu as du matériel de test pendant 4h. Tu trouves un premier bug, mais si on le corrige, il y a 5h de recompilation… donc, pouvoir scripter un test, ajouter un breakpoint, modifier une variable avancer de 5 instructions, remodifier une variable, pour enfin être prêt à trouver un deuxième bug… et bien je suis content que gdb soit en ligne de commande, qu’on puisse lui passer des scripts, etc.

            Après, pour des softs avec IHM, un débogueur en IHM aussi peut suffire.

            • [^] # Re: smart pointer

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

              pouvoir scripter un test, ajouter un breakpoint, modifier une variable avancer de 5 instructions, remodifier une variable, pour enfin être prêt à trouver un deuxième bug… et bien je suis content que gdb soit en ligne de commande, qu’on puisse lui passer des scripts, etc.

              Après, pour des softs avec IHM, un débogueur en IHM aussi peut suffire.

              Je ne suis pas sûr de bien comprendre, donc je vais éviter de m'énerver, parce que mon incompréhension vient peut-être simplement du fait que tu ne sais pas t'exprimer de manière construite, mais… si je lis ce que j'ai cité, j'en déduis que tu crois qu'on ne peut

              • ni ajouter de breakpoint à la volée
              • ni modifier de variable à la volée
              • ni faire du pas-à-pas

              avec un debugger "sale" (pour un langage "sale" genre Java dans un outil "sale" donc graphique) ?

              Dans quel monde tu vis ?

              Du coup je vais jouer au même jeu du "ma feature basique est inimaginable pour les autres" et poser des questions basées sur mon usage basique du debugger d'IntelliJ IDEA dans mon code Groovy.

              • Est-ce qu'avec ton gdb tu peux exprimer une condition pour activer ou non un breakpoint (genre "arrête-toi ici seulement si ceci et cela" en ayant accès à toute l'expressivité de groovy et même ta logique métier) ?
              • Est-ce que tu peux sélectionner une ligne de ton programme et cliquer/taper le raccourci clavier "j'ai pas mis de breakpoint mais relance le flot d'exécution jusqu'à cette ligne peu importe ce qu'il se passe" ?
              • Est-ce que tu peux abandonner le contexte courant ("drop frame" dans IntelliJ, désolé flemme de chercher mieux) en revenant au début de ta méthode et en remettant tout le contexte (variables, paramètres, etc.) dans l'état où il était au début histoire de revoir ce qu'il se passe ?
              • [^] # Re: smart pointer

                Posté par . Évalué à 5.

                Je ne suis pas sûr de bien comprendre, donc je vais éviter de m'énerver, parce que mon incompréhension vient peut-être simplement du fait que tu ne sais pas t'exprimer de manière construite, mais… si je lis ce que j'ai cité, j'en déduis que tu crois qu'on ne peut
                * ni ajouter de breakpoint à la volée
                * ni modifier de variable à la volée
                * ni faire du pas-à-pas

                Non, ce n'est ni ce que j'ai dit, ni ce que je crois.

                Dans quel monde tu vis ?

                Dans un monde où les bancs industriels coûte cher, ils sont donc partagés. Donc quand tu as une après midi sur le banc pour faire tes tests, tu y restes coûte que coûte. Si tu trouves un bug rapidement à 14h30. Tu as deux choix, soit tu corrigse et recompiles, mais le temps de recompilation (4h) me donnera un nouvel essai dans, heu ben demain en fait. Sauf que le lendemain, je n'ai pas de créneau avant 16h.
                Pour optimiser mon temps sur le banc, je recommence en « corrigeant » le bug dans le débugger. A ce point, j'ai deux choix, soit je contourne le bug à chaque fois manuellement (avec une interface graphique), avec gdb, je peux scripter cette partie et gagner du temps.

                Il est possible qu'une bonne interface graphique de debug permette de scripter, mais je n'en connais pas.

                Est-ce qu'avec ton gdb tu peux exprimer une condition pour activer ou non un breakpoint (genre "arrête-toi ici seulement si ceci et cela" en ayant accès à toute l'expressivité de groovy et même ta logique métier) ?

                Oui.

                Est-ce que tu peux sélectionner une ligne de ton programme et cliquer/taper le raccourci clavier "j'ai pas mis de breakpoint mais relance le flot d'exécution jusqu'à cette ligne peu importe ce qu'il se passe" ?

                Je ne suis pas sûr de comprendre le « peu importe ce qu'il se passe ».

                Est-ce que tu peux abandonner le contexte courant ("drop frame" dans IntelliJ, désolé flemme de chercher mieux) en revenant au début de ta méthode et en remettant tout le contexte (variables, paramètres, etc.) dans l'état où il était au début histoire de revoir ce qu'il se passe ?

                Je ne sais pas le faire, mais il me semble que gdb sait faire depuis quelques versions.

      • [^] # Re: smart pointer

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

        Vous n'utilisez pas d'IDE ?

        Mais c'est vrai que je n'ai toujours pas compris comment on peut être content à ce point de gdb (enfin non pas de l'outil en lui même mais de son "utilisabilité")

        • [^] # Re: smart pointer

          Posté par . Évalué à 1.

          Moi si, mais tous les IDEs Linux se basent sur gdb, et aucun n'est foutu d'afficher correctement le contenu d'objets en C++ donc bon, ca ne resoud rien…

        • [^] # Re: smart pointer

          Posté par . Évalué à 4. Dernière modification le 29/09/14 à 12:13.

          Euh, et sinon, je me permets de rappeler que j'ai écrit cgdb. C'est, franchement, un peu moins inconfortable que gdb, surtout quand on ne connaît ce dernier que de nom. Maintenant, je pourrai m'en sortir un peu, et cgdb reste primitif, mais bon, on fait avec ce qu'on à.

          Il existe aussi ddd, plus complet, plus gros, graphique, mais à mon goût dur à prendre en main. Aucun d'eux ne vaut visual studio, qui lui-même n'égale pas vraiment ollydbg (qui, de mémoire, peut afficher le source). Je pourrais également citer quelques ancêtres mais ce serait abusé: windasm, et dans une autre catégorie, softice. Mais ces ancêtres n'ont pas vraiment une IHM des plus modernes…

          À mon avis, si linux possède moins d'IHM sympa pour les débuggueurs, c'est pour une raison simple: moins de programmes à reverser (que ce soit pour une raison légale ou pas n'est pas la question) du fait que bien souvent, on à les sources ou ils n'ont pas de prix.

          PS: si, j'ai un IDE, c'est mon DE ;)

      • [^] # Re: smart pointer

        Posté par . Évalué à 0.

        J'ai du mal a comprendre qu'une communaute tellement portee sur le developpement n'ait pas resolu ce point la.

        Parce que c'est une communaute qui met un point d'honneur a utiliser les outils les plus pourris possibles pour prouver a quel point ils sont l33t et plus malin que les autres.
        Syndromes du "nan mais j'ai pas besoin de ca moi, je suis plus malin que le compilo".

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: smart pointer

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

          Peut etre aussi qu'au fond les debuggers c'est un peu de la merde, ça passe son temps à perdre les symboles de debug ou à afficher de la merde parce que le niveau d'optim est trop fort, et que ce n'est pas si indispensable que ça.

          • [^] # Re: smart pointer

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

            Je debug quasi uniquement à l'aide de printf qDebug()

            • [^] # Re: smart pointer

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

              Si encore quelqu'un expliquait qu'il ne debug pas mais fait tout par des tests (unitaires et autres) je comprendrais, mais là ça devient vraiment triste :-(

              • [^] # Re: smart pointer

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

                qu'est-ce qui est triste exactement ?

                • [^] # Re: smart pointer

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

                  les gens qui "debug" à coup de printf/qDebug/etc

                  • [^] # Re: smart pointer

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

                    oh vraiment ? et tu peux prouver que tu es plus efficace avec ton gros debuggeur lourdingue ? J'en doute. Moi je ne sors le debugger que pour les bugs triviaux (genre ca segfault). Le reste du temps, les bugs un peu plus vicieux et compliqués , c'est au printf + affichage de stack trace. Je ne vois pas ce qu'un debuggeur apporte de plus a part de la lourdeur et de la fragilité.

                    • [^] # Re: smart pointer

                      Posté par . Évalué à 7.

                      oh vraiment ? et tu peux prouver que tu es plus efficace avec ton gros debuggeur lourdingue ?

                      Moi je peux… C'est juste que tu ne sais pas te servir d'un debuggeur.

                      Ton debug flow c'est :

                      1. essayer d'imaginer ce qu'il peut se passer
                      2. truffer ton programme de printf
                      3. recompiler
                      4. relancer
                      5. executer
                      6. espérer trouver quelque chose qui va pas dans la sortie monstrueuse
                      7. goto 1

                      Avec un debuggeur, tu pourrait faire exactement la même chose, en plus efficace :

                      1. essayer d'imaginer ce qui peut se passer
                      2. trouver les variables à surveiller
                      3. dire à ton debugger quelle valeur elle sont supposée prendre
                      4. lui demander d'arrêter le programme sinon
                      5. le laisser faire le boulot chiant

                      T'économise le temps qu'il faut pour écrire plein de printf, tu ne pourri pas ton code source, tu n'a pas à faire des grep avec les yeux, tu n'a pas à recompiler 15000 fois juste pour trouver le bug…

                      En plus ! Tu peux programmer le debuggeur pour amener directement le programme au bug par exemple, ou pour afficher joliment une structure compliquée… Tu peux suivre chaque thread séparément, sauter de l'un à l'autre,… bref, avec tu peux vraiment entrer dans l’exécution du programme, avec des printf on ne fait que lui faire semer des petits cailloux.

                      Please do not feed the trolls

                      • [^] # Re: smart pointer

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

                        Tu as raisons. (Puisque tu peux simuler facilement des printf avec un bon débugger, utiliser les printf est un sous ensemble d'utiliser un débugger)

                        Cependant, je pense que la tache qui prends le plus de temps et d'effort est le point 1. (essayer d'imaginer ce qui peut se passer).
                        L'art de débugger consiste à déterminer l'endroit ou mettre les printf / breakpoint: pauser des hypothèses et les vérifier. Ne pas trop so focaliser sur les symptomes mais essayer de trouver la cause d'un problème. Et bien comprendre le problème.

                        Considérant ça, printf ou un débugger c'est un peu pareil. L'avantage de printf est que c'est écrit dans le même langage que le produit et que tu à accès à toute les bibliothèques pour afficher les valeurs que tu veux. L'inconvénient c'est qu'il faut recompiler et relancer. (Ce que tu devras quand même faire si tu cherche à corriger le problème)

                        • [^] # Re: smart pointer

                          Posté par . Évalué à 3.

                          Considérant ça, printf ou un débugger c'est un peu pareil. L'avantage de printf est que c'est écrit dans le même langage que le produit et que tu à accès à toute les bibliothèques pour afficher les valeurs que tu veux.

                          Pour ça et déboguer en même temps, il y a les "espions" dans Visual Studio. Je peux y mettre une variable existante pour savoir sa valeur actuelle ou un appel/expression, et autant que je veux. Nul besoin d'arrêter, coder des appels à prinf/echo/au log managaer, et de relancer. Vu le temps gagné, adieu printf !

                          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                        • [^] # Re: smart pointer

                          Posté par . Évalué à 3. Dernière modification le 29/09/14 à 12:16.

                          Considérant ça, printf ou un débugger c'est un peu pareil.

                          Non, un débogueur ne te force pas à recompiler. C'est important quand tu utilises des libs assez lourdes. Et un printf ne te permets pas de lister l'ensemble de l'état de ton programme, et encore moins de revenir en arrière. Choses qu'un dbg te permets.

                          Mais ça, qu'il soit en ligne de commande (gdb), en ncurses (cgdb), ou graphique (visual, ddd, ollydbg…) ils peuvent tous le faire.

                    • [^] # Re: smart pointer

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

                      et tu peux prouver que tu es plus efficace avec ton gros debuggeur lourdingue ? J'en doute.

                      Ok, tu en doutes. Et tu peux prouver que tu es plus efficace avec ton printf limité ? Genre comment tu affiches une structure un peu complexe sans y passer plein de temps ? Comment tu affiches une donnée que tu ne pensais pas initialement nécessaire (je veux dire sans modifier ton code, recompiler, réexécuter ?)

                      Et bon, un debuggeur ça ne se limite pas qu'à du printf/stacktrace. Si c'était le cas peut-être qu'on pourrait comparer un peu, mais ce n'est pas le cas du tout.
                      Comment tu fais pour que ton programme s'arrête à un état donné (un breakpoint conditionnel) ? Tu écris du code avec un while(true) ?
                      Et comment tu sautes à une instruction avec ton printf ?

                      Alors c'est sur que gdb et la pauvreté des interfaces dans le monde linux ça ne donne pas du tout envie de debugger quoi que ce soit, ça c'est vrai. Mais dire qu'on en a pas besoin moi ça me fait penser à tous ceux qui disent que les IDE ça ne sert à rien puisqu'il y a grep/sed/awk. Mais va faire un refactoring correct simplement avec ça…

                    • [^] # Re: smart pointer

                      Posté par . Évalué à 3.

                      Moi oui je peux.

                      Au hasard :

                      Tu peux mettre un breakpoint et voir les variables du systeme, incluant la stack, incluant la valeur des variables dans chaque frame, incluant les valeurs sur lesquelles les pointeurs pointent … n'importe ou a chaud.

                      Tu peux changer de breakpoint, l'enlever, … a chaud, n'importe quand. En 3 secondes.

                      Tu peux modifier le code a la volee, continuer l'execution

                      Tu peux bouger le registre d'instruction et le remettre au debut d'un bout de code pour revoir son execution sans devoir tout relancer

                      Tu peux voir ton buffer en memoire a chaud, pas a pas, y inclus les qqe bytes suivant / precedant le buffer, et t'assurer que le probleme n'est pas du a un ecrasement d'une autre variable par exemple.

                      etc…

                      Un debugger et printf, c'est aussi different qu'une BMW et une Trabant. Les 2 permettent de rouler, mais un des deux est bcp plus rapide, plus agreable et plus fiable.

              • [^] # Re: smart pointer

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

                Un test unitaire te dis que ça ne passe pas, vers où ça ne passe pas, mais il t'indique rarement directement la correction à faire et où. Ou alors y'a eu de forts progrès dans le domaine de l'ingénierie du développement de logiciels.

                Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

                • [^] # Re: smart pointer

                  Posté par . Évalué à 4.

                  Si à la simple vue du nom du test qui échoue, tu n'es pas capable d'identifier le code fautif, c'est que ton test est pourri.

                  • [^] # Re: smart pointer

                    Posté par . Évalué à 2.

                    Je bosse dans un milieu où on fait tout un tas de tests (unitaires ou non) et franchement, même en test unitaire ce n'est pas toujours facile de comprendre d'où vient un bug. (ou alors parfois c'est évident mais on se dit quand même que le programmeur ne peut pas s'être planté 3 fois dans l'implémentation du calcul d'une médiane, mais c'est un autre problème)

                    Dernièrement j'ai eu pas mal de mes tests unitaires qui passaient sur ma machine, sur d'autres PC, mais pas une fois compilés pour la plateforme cible. Du coup si je n'avais fait que le test sur la plateforme cible, j'aurais eu du mal à dire ce qui était fautif dans le code juste à la vue du nom, vu que ce n'était pas dans le code.

                    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                • [^] # Re: smart pointer

                  Posté par . Évalué à 6.

                  Ton test unitaire va te donner LA fonction dans laquelle il ya un bug et LE cas dans lequel ca bug.
                  En clair, dans l'immense majorite des cas, ca va faire 70% du boulot, a savoir identifier le bug et te pointer vers une 20aine de ligne qui sont fautives dans un cas tres precis.

                  Si ton test ne fait pas ca, reecrit les (ou arrete d'en ecrire, tu perds ton temps).
                  Le probleme en general, c'est plutot d'avoir un test qui choppe le probleme, mais si t'as un test qui passe pas, la correction devient tres simple.

                  Apres, si tu veux tester une UI, les test unitaires vont pas t'aider des masses. Ya des outils pour ca, mais ca reste douloureux en general.

                  Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                  • [^] # Re: smart pointer

                    Posté par . Évalué à 2.

                    Ton test unitaire va te donner LA fonction dans laquelle il ya un bug et LE cas dans lequel ca bug.

                    Oui… Dans le cas où le test unitaire test un cas qui reproduit le bug. Dans la majorité des cas, on définit des tests plutôt simples. Et les bugs sont rarement détectés par ce moyen.

                    Par contre, les tests unitaires peuvent très bien déceler certaines régressions.

                    • [^] # Re: smart pointer

                      Posté par . Évalué à 4.

                      Dans le cas où le test unitaire test un cas qui reproduit le bug

                      Bah dans ce cas tu rajoutes du code dans ton test qui reproduit le bug. Sinon, ça n'a pas beaucoup d'intérêt d'avoir des tests.

                      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Re: smart pointer

                        Posté par . Évalué à 2.

                        Bah dans ce cas tu rajoutes du code dans ton test qui reproduit le bug.

                        Cela implique de connaître le bug à l'avance, dans ce cas autant écrire un code sans bug. Ou alors, que le bug a été découvert par un autre moyen et cela permet d'adapter les tests.

                        Sauf à utiliser du fuzzing, un test unitaire va rarement te découvrir un bug.

                        • [^] # Re: smart pointer

                          Posté par . Évalué à 4.

                          Euh, je parlais de rajouter un test/modifier un test pour reproduire le comportement qui à mis à jour le bug, une fois le bug corrigé. Pour éviter de l'introduire à nouveau dans le futur.

                          Je vois pas le rapport avec de de la divination ou être parfait

                          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: smart pointer

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

        texitoi@vaio:~/dev/tests$ cat test.cpp
        #include <iostream>
        #include <vector>
        
        int main() {
          std::vector<int> v {0,1,2,3};
          for (int i: v) std::cout << i << " ";
          std::cout << std::endl;
          return 0;
        }
        texitoi@vaio:~/dev/tests$ clang++ -g -std=c++11 -Weverything -Wno-c++98-compat test.cpp -o test
        texitoi@vaio:~/dev/tests$ gdb -q ./test 
        Reading symbols from ./test...done.
        (gdb) b test.cpp:6
        Breakpoint 1 at 0x400d25: file test.cpp, line 6.
        (gdb) r
        Starting program: /home/texitoi/dev/tests/test 
        
        Breakpoint 1, main () at test.cpp:6
        6     for (int i: v) std::cout << i << " ";
        (gdb) p v
        $1 = std::vector of length 4, capacity 4 = {0, 1, 2, 3}
        (gdb) 
        

        Mais c'est vrai que ça fait pas longtemps que Debian configure correctement gdb par défaut.

        • [^] # Re: smart pointer

          Posté par . Évalué à 2.

          Oui, depuis GDB 7.0 y'a des pretty-printer en Python pour la STL (et tu peux ajouter les tiens pour tes propres types).

      • [^] # Re: smart pointer

        Posté par . Évalué à 4. Dernière modification le 29/09/14 à 12:05.

        Mouai. En fait, non, c'est pas imbitable. Je sais, mon argument est aussi puissant que le tiens, mais sincèrement, j'ai l'habitude de faire de petites (et nombreuses) classes, et d'être strict avec les contrats des méthodes/fonctions: si un param d'entrée me va pas, je lance une exception avec un message d'erreur. Vu que je ne rattrape que rarement mes exceptions (et pas toutes, en plus, histoire que ça crash bien comme il faut) quand j'ai un bug je sais très très vite d'où ça viens, même sans débuggueur. Ça m'évite la plus grosse part des douleurs.

        Et pour ce qui est des structures imbriquées, j'utilise un outil nommé: typedef. Comme ça, c'est tout de suite 1) plus simple à lire et 2) plus court à taper.

        Et pour l'auto-complétion, vim s'en sort pas trop mal, excepté c'est vrai, quand j'utilise un framework lourd que je ne connait pas assez. Mais c'est assez rare, et en plus isolé dans une seule "couche" de l'application.

        Bon, ça à aussi des avantages niveau ergonomie, si je combine mes terminaux avec un tiling window manager. En fait, sans cet outil, je ne supporterai pas ce mode de fonctionnement et j'utiliserai effectivement un IDE. Mais grâce aux twm, l'IDE c'est mon bureau, et je ne connais pas mieux qu'un twm pour gérer du multi-screen ou pour se passer de la souris, qui est, selon moi, un véritable instrument de torture: c'est lent, peu précis, ça sert à pointer des interfaces qui risquent de changer à la moindre MaJ, et ça nécessite de lâcher le clavier (et les claviers modernes ayant ce foutu pavé numérique, le mouvement de bras n'est pas court).

        Perso, c'est quand je passe sur un IDE que je me sens handicapé. Ou avec un gestionnaire de fenêtres classique. Et pourtant, je ne qualifie pas les gens qui s'en servent au quotidien de rétrogrades et non-productifs: j'accepte qu'ils aient une façon de faire différente de la mienne, sûrement plus efficace sur certains points (c'est clair, pour construire une boîte de dialogue, je suis assez emmerdé… par contre, pour switcher entre git, mon source, pondre un script rapide pour tester un truc ou deux, et autres, je pense que ma façon de faire n'est pas mauvaise.

        [edit]
        Ceci étant dit, il faut admettre que visual à un debugguer qui gère un max.

        • [^] # Re: smart pointer

          Posté par . Évalué à 3.

          Mouai. En fait, non, c'est pas imbitable. Je sais, mon argument est aussi puissant que le tiens, mais sincèrement, j'ai l'habitude de faire de petites (et nombreuses) classes, et d'être strict avec les contrats des méthodes/fonctions: si un param d'entrée me va pas, je lance une exception avec un message d'erreur. Vu que je ne rattrape que rarement mes exceptions (et pas toutes, en plus, histoire que ça crash bien comme il faut) quand j'ai un bug je sais très très vite d'où ça viens, même sans débuggueur. Ça m'évite la plus grosse part des douleurs.

          Et ça marcherait pas aussi bien avec un assert ? Personnellement, j'en mets des tonnes partout où je peux. et quand ça crache via un assert, ça me crée un fichier core et je peux connaître la stack trace via gdb (c'est d'ailleurs ma seule utilisation de cet outil).

          • [^] # Re: smart pointer

            Posté par . Évalué à 2.

            Je vois 3 différences avec l'assert:

            • l'assert est dégagé quand on livre. Contrairement aux exceptions, qui me permettent de logguer avant de crasher fermer violemment en désallouant les éventuelles ressources. Dans certains cas (les std::logic_error et ses filles) ce n'est pas très pertinent, mais quand il s'agit de se fermer après constat d'une erreur dans l'environnement (un fichier vital non trouvé, une entrée "utilisateur" --soyons d'accord: l'utilisateur n'est pas toujours humain…-- foireuse, ce genre de trucs) je trouve plus clair de juste lancer une exception avec un message potable (pour la logguer, c'est assez simple, il suffit de dériver une classe de std::exception, qui loggue automatiquement) que de faire un appel à une fonction pour logguer puis un autre à exit.
            • le message d'erreur d'une exception est à la possibilité d'être plus parlant. Bon, j'imagine qu'on peut aussi écrire une fonction avec le nom super long et qui renvoie true/false, pour l'emploi dans un assert, mais ça me semble un poil plus pénible.
            • on peut éventuellement récupérer d'une exception (c'est dégueu, selon moi, mais on me demande parfois de faire de la programmation défensive… à mon corps défendant :/)

            Entendons nous bien, encore une fois: quand je lance une exception, ce n'est pas pour que mon programme survive, je ne m'en sers pas comme d'un switch dégueu. Je ne me sers des exceptions que signaler que le programme ne peux plus continuer, et sauver ce qui peut l'être le cas échéant.
            Par exemple, imagines un IDE qui, pour une raison ou une autre, à un bug. Si, plutôt qu'utiliser des assert qui imposeront à l'utilisateur d'utiliser un outil en mode déboguage, et donc lent, afin d'avoir des messages d'erreur et qui en plus impliqueront la perte de toutes les données, le développeur utilises des exceptions, alors l'utilisateur peut utiliser une version non débug (plus rapide, moins lourde), avoir un message d'erreur, et en plus récupérer son travail dans l'état juste avant l'anomalie. Ça (peut) évite(r) des sauvegardes automatiques toutes les N minutes, qui seront plus coûteuses.

            Après, je t'avoue, je ne maîtrise pas gdb, loin de là (ça ne fait pas longtemps que j'ai abandonné les IDEs) donc c'est possible que ce soit plus intéressant. Mais je viens de faire un test basique, et je ne vois aucun fichier core généré. Tu utilises quoi comme options de compilation (outre le -g, évidemment)?

            • [^] # Re: smart pointer

              Posté par . Évalué à 3.

              Aucune option particulière, mais j'autorise les fichiers core (avec ulimit -c unlimited), c'est peut-être ça ton souci. Ensuite, je lance gdb avec le nom de l'exécutable et le fichier core et je tape la commande magique bt (comme backtrace) et là, il m'affiche la pile d'appel avec toutes les lignes dans les fichiers qui vont bien.

              • [^] # Re: smart pointer

                Posté par . Évalué à 2.

                Je connaissais bt, c'est juste le fichier core que je ne sais (savais? je verrai ça dans l'aprem) générer. Merci bien!

            • [^] # Re: smart pointer

              Posté par . Évalué à 3.

              Pour les asserts qui doivent toujours échouer, tu ne peux pas bêtement faire ça ?

              void une_fonction(...) {
                assert("MON MESSAGE D'ERREUR" && 0);
                /* Reste du code si besoin */
              }
              • [^] # Re: smart pointer

                Posté par . Évalué à 2.

                Tu veux dire pour le manque de message d'erreur… C'est une bonne idée en effet.

        • [^] # Re: smart pointer

          Posté par . Évalué à 2. Dernière modification le 03/10/14 à 15:11.

          et [la souris] nécessite de lâcher le clavier (et les claviers modernes ayant ce foutu pavé numérique, le mouvement de bras n'est pas court).

          C’est la revanche des gauchers. MOUHAHAHA !

  • # Trop gros, passera pas.

    Posté par . Évalué à 0.

    Portable, performant et surtout productif

    Je sais qu'on est vendredi , mais quand même !

  • # J'aurais dû faire un journal qui troll pour qu'on réponde à mes questions, moi aussi

    Posté par . Évalué à 7.

    Tu es trop balèze, devnewton. Tu as rameuté tout plein de dev C++ qui montrent la puissance du C++ par rapport au Java (alors qu'il y a pas vraiment de comparaison à faire).

    La prochaine fois, je ferai aussi un journal pour poser des questions sur des IDE, et tout et tout, concernant le C++ :

    http://linuxfr.org/forums/programmation-c/posts/autocompletion-dans-qtcreator-comme-dans-eclipse (petite pub pour mon topic, siouplait :))

    Il faut croire qu'il n'y a pas grand monde qui aime les forum mais quand il y a un journal qui écorche la techno préférée de quelques-un, wahou, c'est la fête :D

  • # Projet perso = ce qui te fait plaisir !

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

    C'est pour un projet perso, et les deux langages te permettront de faire la même chose -> utilise celui qui t'éclate le plus (ou qui te prend le moins la tête) ;)

    • [^] # Re: Projet perso = ce qui te fait plaisir !

      Posté par (page perso) . Évalué à 6. Dernière modification le 26/09/14 à 20:56.

      Ce qui m'éclate c'est de faire des jeux, le langage importe peu. Pour le premier, j'ai pris Java pour me former. Pour le second, il fallait aller vite, j'ai repris Java, car j'avais tout le code prêt à copier coller. Cette fois je prends C++ pour ne pas perdre la main.

      Dans la vie quand on a un marteau, les problèmes ressemblent tous à des clous.

      En IT, c'est la même chose, mais on prends un tournevis.

      http://devnewton.bci.im

      • [^] # Re: Projet perso = ce qui te fait plaisir !

        Posté par . Évalué à 10.

        Dans la vie quand on a un marteau, les problèmes ressemblent tous à des clous.

        pour terminer le proverbe, "et quand ton marteau, c'est C++, tout ressemble à un doigt" ! :D

  • # Gestionnaire de projets

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

    Ça fait un moment que je n'ai pas eu à programmer en C ou C++, donc je ne suis plus trop au fait des derniers outils de build modernes. Quand je fais du C ou C++, j'utilise encore make.

    Toutefois, en Ada (oui j'ai cette chance de développer en Ada au boulot), il y a depuis quelques années maintenant, un langage de haut niveau pour décrire les projets qui est élégant, simple à utiliser et assez complet. La syntaxe est proche du langage Ada, ce qui fait que c'est facilement lisible par des humains. C'est d'ailleurs devenu le standard dans le monde Ada pour décrire un projet.

    Ces fichiers projet sont compris par tout plein d'outils de développement Ada : IDE, chaîne de compilation, analyse de code, etc. Parmi ces outils, il ya GPRbuild qui sait également compiler d'autres langages que Ada (genre le C++). On peut également mixer assez aisément plusieurs langages. Bref c'est vraiment du bonheur ce truc. Bon le seul bémol, c'est que ça fait partie des chaînes de compilation Ada. C'est pas forcément une dépendance couramment installée chez tous les développeurs. Et c'est quand même un peu orienté Ada ;-)

    Un exemple tout simple pour illustrer quand même :

    with "xmlada.gpr"; -- Exemple de dépendance à une lib
    
    project MonProjet is
      for Source_Dirs use ("src");
      for Object_Dir  use "obj";
      for Exec_Dir    use "bin";
      for Main        use ("main.adb");
    end MonProjet;
    

    Je rêve de voir un truc similaire s'imposer (i.e., devenir quasiment un standard) pour le C et le C++.

    Un peu de doc pour ceux que ça intéresse : http://docs.adacore.com/gprbuild-docs/html/gprbuild_ug.html

    • [^] # Re: Gestionnaire de projets

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

      L'idéal pour moi, c'est un outil qui impose une organisation (les sources dans src, les binaires générés dans build… peu importe les noms), utilise un simple fichier de configuration (basé sur un format très connu comme json ou xml) pour renseigner les quelques propriétés nécessaires (nom du projet et liste des dépendances) et prends entièrement en charge le téléchargement des dépendances, la (cross)compilation et la génération des installeurs/packages.

      Bref, je n'ai pas envie d'un nième maker basé sur un langage de script pour faire tout et n'importe, mais d'un outil qui me fait gagner du temps.

      http://devnewton.bci.im

      • [^] # Re: Gestionnaire de projets

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

        asdf.

        De rien.

      • [^] # Re: Gestionnaire de projets

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

        xml

        Tu devrais attendre un trolldi 13 pour ça.

        * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

      • [^] # Re: Gestionnaire de projets

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

        Cargo : http://crates.io/

        Bon, OK, c'est pour Rust et encore un peu limité ;)

      • [^] # Re: Gestionnaire de projets

        Posté par . Évalué à 2.

        utilise un simple fichier de configuration (basé sur un format très connu comme json ou xml)

        On à des définitions différentes pour deux choses.
        1) simple fichier de configuration
        2) idéal

        Désolé, mais, vraiment, pour être idéal un "simple fichier de configuration" doit être facilement lisible et modifiable par un humain. Ce n'est le cas ni du xml, ni du json, à fortiori quand le fichier en question dépasse les 20 lignes.
        Je dirais même plus, les outils basés sur du xml pour la config, me hérissent le poil, et pas juste par principe. J'utilisais un IDE dans le passé. J'en ai même utilisé plus d'un… les uns avec des formats proprios (mais "lisibles" avec un éditeur de texte, les autres avec des formats genre xml/json justement… et force m'est de constater que dès que l'on à plus envie de subir /que l'on ne peut plus utiliser une IHM graphique GTK/Qt/MFC/Whatever, ces choses sont horribles à gérer.
        Je ne parlerai même pas de versionner ou differ ce genre d'horreur…

        Je suppose que mon opinion différente viens du fait que j'aime pouvoir assembler mon écosystème logiciel moi-même, plutôt qu'être obligé de me reposer sur les choix de quelqu'un d'autre et devoir forker (et donc maintenir) une structure complexe dès que je veux changer customiser un truc dans un sens pas prévu par le(s) dev(s) d'origine.
        Ça évite aussi de se taper des bugs très pénibles sans pouvoir changer le composant en un minimum d'efforts, quand ça arrive. Mais c'est vrai que ça nécessite un peu plus de travail pour mettre en place ses outils.

        • [^] # Re: Gestionnaire de projets

          Posté par . Évalué à 3.

          Ce n'est le cas ni du xml, ni du json, à fortiori quand le fichier en question dépasse les 20 lignes.

          Un format qui fait plus q'une liste clef => valeur de facile à modifier pour un humain, personnellement j'en connais pas (mais je suis intéressé si tu as).

          Je ne parlerai même pas de versionner ou differ ce genre d'horreur…

          Ça se fait plutôt bien (le versionnement très bien) le diff un peu moins pour XML.
          JSON s'en sort un peu mieux.
          Mais YAML est le meilleur AMHA pour ça (il est sensible au retour à la ligne).

          Je suppose que mon opinion différente viens du fait que j'aime pouvoir assembler mon écosystème logiciel moi-même, plutôt qu'être obligé de me reposer sur les choix de quelqu'un d'autre et devoir forker (et donc maintenir) une structure complexe dès que je veux changer customiser un truc dans un sens pas prévu par le(s) dev(s) d'origine.

          Je ne vois pas ce que ça change. Que ce soit du protobuf, de l'INI, du YAML ou autre ça ne te change pas grand chose pour ça.

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

          • [^] # Re: Gestionnaire de projets

            Posté par . Évalué à 2.

            Pour yaml, je ne sais pas, j'en ai vu vite fait sur wikipedia, je n'en sais pas plus, mais c'est vrai que ça me plaît vachement plus que les autres.

            Je ne vois pas ce que ça change. Que ce soit du protobuf, de l'INI, du YAML ou autre ça ne te change pas grand chose pour ça.

            Bah, non, franchement.

            Exemple XML réel (code::blocks):

            <?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
            <CodeBlocks_project_file>
                <FileVersion major="1" minor="6" />
                <Project>
                    <Option title="pluma" />
                    <Option pch_mode="2" />
                    <Option compiler="gcc" />
                    <Build>
                        <Target title="Release DLL">
                            <Option output="..\..\lib\pluma" prefix_auto="1" extension_auto="1" />
                            <Option object_output="..\..\ztemp\mingw\release" />
                            <Option type="3" />
                            <Option compiler="gcc" />
                            <Option createStaticLib="1" />
                            <Compiler>
                                <Add option="-O3" />
                            </Compiler>
                            <Linker>
                                <Add option="-s" />
                            </Linker>
                        </Target>
                    </Build>
                    <Compiler>
                        <Add option="-Wall" />
                        <Add option="-DPLUMA_EXPORTS" />
                        <Add directory="..\..\include" />
                        <Add directory="..\..\src" />
                    </Compiler>
                    <Unit filename="..\..\include\Pluma\Config.hpp" />
                    <Unit filename="..\..\include\Pluma\Connector.hpp" />
                    <Unit filename="..\..\include\Pluma\Host.hpp" />
                    <Unit filename="..\..\include\Pluma\PluginManager.hpp" />
                    <Unit filename="..\..\include\Pluma\Pluma.hpp" />
                    <Unit filename="..\..\include\Pluma\Pluma.inl" />
                    <Unit filename="..\..\include\Pluma\Provider.hpp" />
                    <Unit filename="..\..\src\Pluma\DLibrary.cpp" />
                    <Unit filename="..\..\src\Pluma\DLibrary.hpp" />
                    <Unit filename="..\..\src\Pluma\Dir.cpp" />
                    <Unit filename="..\..\src\Pluma\Dir.hpp" />
                    <Unit filename="..\..\src\Pluma\Host.cpp" />
                    <Unit filename="..\..\src\Pluma\PluginManager.cpp" />
                    <Unit filename="..\..\src\Pluma\Provider.cpp" />
                    <Unit filename="..\..\src\Pluma\uce-dirent.h" />
                    <Extensions>
                        <code_completion />
                        <debugger />
                    </Extensions>
                </Project>
            </CodeBlocks_project_file>

            L'équivalent Visual Studio (et il n'y à que le vcxproj, et je n'ai pas viré les sections pour les divers builds comme j'ai fait pour C::B, pour cause de non masochisme):

            <?xml version="1.0" encoding="utf-8"?>
            <Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
              <ItemGroup Label="ProjectConfigurations">
                <ProjectConfiguration Include="Debug DLL|Win32">
                  <Configuration>Debug DLL</Configuration>
                  <Platform>Win32</Platform>
                </ProjectConfiguration>
                <ProjectConfiguration Include="Debug static|Win32">
                  <Configuration>Debug static</Configuration>
                  <Platform>Win32</Platform>
                </ProjectConfiguration>
                <ProjectConfiguration Include="Release DLL|Win32">
                  <Configuration>Release DLL</Configuration>
                  <Platform>Win32</Platform>
                </ProjectConfiguration>
                <ProjectConfiguration Include="Release static|Win32">
                  <Configuration>Release static</Configuration>
                  <Platform>Win32</Platform>
                </ProjectConfiguration>
              </ItemGroup>
              <ItemGroup>
                <ClInclude Include="..\..\include\Pluma\Config.hpp" />
                <ClInclude Include="..\..\include\Pluma\Connector.hpp" />
                <ClInclude Include="..\..\include\Pluma\Host.hpp" />
                <ClInclude Include="..\..\include\Pluma\PluginManager.hpp" />
                <ClInclude Include="..\..\include\Pluma\Pluma.hpp" />
                <ClInclude Include="..\..\include\Pluma\Provider.hpp" />
                <ClInclude Include="..\..\src\Pluma\Dir.hpp" />
                <ClInclude Include="..\..\src\Pluma\DLibrary.hpp" />
                <ClInclude Include="..\..\src\Pluma\uce-dirent.h" />
              </ItemGroup>
              <ItemGroup>
                <None Include="..\..\include\Pluma\Pluma.inl" />
              </ItemGroup>
              <ItemGroup>
                <ClCompile Include="..\..\src\Pluma\Dir.cpp" />
                <ClCompile Include="..\..\src\Pluma\DLibrary.cpp" />
                <ClCompile Include="..\..\src\Pluma\Host.cpp" />
                <ClCompile Include="..\..\src\Pluma\PluginManager.cpp" />
                <ClCompile Include="..\..\src\Pluma\Provider.cpp" />
              </ItemGroup>
              <PropertyGroup Label="Globals">
                <ProjectGuid>{C061A27D-7CA0-4179-9869-672FA04A86A8}</ProjectGuid>
                <RootNamespace>sfml-system</RootNamespace>
                <Keyword>Win32Proj</Keyword>
              </PropertyGroup>
              <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
              <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release static|Win32'" Label="Configuration">
                <ConfigurationType>StaticLibrary</ConfigurationType>
                <CharacterSet>MultiByte</CharacterSet>
                <WholeProgramOptimization>false</WholeProgramOptimization>
              </PropertyGroup>
              <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug static|Win32'" Label="Configuration">
                <ConfigurationType>StaticLibrary</ConfigurationType>
                <CharacterSet>MultiByte</CharacterSet>
              </PropertyGroup>
              <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release DLL|Win32'" Label="Configuration">
                <ConfigurationType>DynamicLibrary</ConfigurationType>
                <CharacterSet>MultiByte</CharacterSet>
                <WholeProgramOptimization>true</WholeProgramOptimization>
              </PropertyGroup>
              <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug DLL|Win32'" Label="Configuration">
                <ConfigurationType>DynamicLibrary</ConfigurationType>
                <CharacterSet>MultiByte</CharacterSet>
              </PropertyGroup>
              <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
              <ImportGroup Label="ExtensionSettings">
              </ImportGroup>
              <ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release static|Win32'" Label="PropertySheets">
                <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
              </ImportGroup>
              <ImportGroup Condition="'$(Configuration)|$(Platform)'=='Debug static|Win32'" Label="PropertySheets">
                <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
              </ImportGroup>
              <ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release DLL|Win32'" Label="PropertySheets">
                <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
              </ImportGroup>
              <ImportGroup Condition="'$(Configuration)|$(Platform)'=='Debug DLL|Win32'" Label="PropertySheets">
                <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
              </ImportGroup>
              <PropertyGroup Label="UserMacros" />
              <PropertyGroup>
                <_ProjectFileVersion>10.0.30319.1</_ProjectFileVersion>
                <OutDir Condition="'$(Configuration)|$(Platform)'=='Debug DLL|Win32'">$(SolutionDir)..\..\lib\</OutDir>
                <IntDir Condition="'$(Configuration)|$(Platform)'=='Debug DLL|Win32'">$(SolutionDir)..\..\ztemp\vc2010\$(ProjectName)\$(Configuration)\</IntDir>
                <LinkIncremental Condition="'$(Configuration)|$(Platform)'=='Debug DLL|Win32'">true</LinkIncremental>
                <OutDir Condition="'$(Configuration)|$(Platform)'=='Release DLL|Win32'">$(SolutionDir)..\..\lib\</OutDir>
                <IntDir Condition="'$(Configuration)|$(Platform)'=='Release DLL|Win32'">$(SolutionDir)..\..\ztemp\vc2010\$(ProjectName)\$(Configuration)\</IntDir>
                <LinkIncremental Condition="'$(Configuration)|$(Platform)'=='Release DLL|Win32'">false</LinkIncremental>
                <OutDir Condition="'$(Configuration)|$(Platform)'=='Debug static|Win32'">$(SolutionDir)..\..\lib\</OutDir>
                <IntDir Condition="'$(Configuration)|$(Platform)'=='Debug static|Win32'">$(SolutionDir)..\..\ztemp\vc2010\$(ProjectName)\$(Configuration)\</IntDir>
                <OutDir Condition="'$(Configuration)|$(Platform)'=='Release static|Win32'">$(SolutionDir)..\..\lib\</OutDir>
                <IntDir Condition="'$(Configuration)|$(Platform)'=='Release static|Win32'">$(SolutionDir)..\..\ztemp\vc2010\$(ProjectName)\$(Configuration)\</IntDir>
                <TargetName Condition="'$(Configuration)|$(Platform)'=='Debug DLL|Win32'">$(ProjectName)-d</TargetName>
                <TargetName Condition="'$(Configuration)|$(Platform)'=='Debug static|Win32'">$(ProjectName)-s-d</TargetName>
                <TargetName Condition="'$(Configuration)|$(Platform)'=='Release DLL|Win32'">$(ProjectName)</TargetName>
                <TargetExt Condition="'$(Configuration)|$(Platform)'=='Debug DLL|Win32'">.dll</TargetExt>
                <TargetExt Condition="'$(Configuration)|$(Platform)'=='Release DLL|Win32'">.dll</TargetExt>
                <TargetName Condition="'$(Configuration)|$(Platform)'=='Release static|Win32'">$(ProjectName)-s</TargetName>
              </PropertyGroup>
              <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug DLL|Win32'">
                <CustomBuildStep>
                  <Message>
                  </Message>
                  <Command>
                  </Command>
                  <Outputs>%(Outputs)</Outputs>
                </CustomBuildStep>
                <ClCompile>
                  <AdditionalOptions>/MP %(AdditionalOptions)</AdditionalOptions>
                  <Optimization>Disabled</Optimization>
                  <AdditionalIncludeDirectories>$(SolutionDir)..\..\src;$(SolutionDir)..\..\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
                  <PreprocessorDefinitions>PLUMA_EXPORTS;%(PreprocessorDefinitions)</PreprocessorDefinitions>
                  <MinimalRebuild>false</MinimalRebuild>
                  <BasicRuntimeChecks>EnableFastChecks</BasicRuntimeChecks>
                  <RuntimeLibrary>MultiThreadedDebugDLL</RuntimeLibrary>
                  <PrecompiledHeader>
                  </PrecompiledHeader>
                  <WarningLevel>Level4</WarningLevel>
                  <DebugInformationFormat>EditAndContinue</DebugInformationFormat>
                </ClCompile>
                <Link>
                  <OutputFile>$(SolutionDir)..\..\lib\$(ProjectName)-d.dll</OutputFile>
                  <AdditionalLibraryDirectories>%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
                  <GenerateDebugInformation>true</GenerateDebugInformation>
                  <ProgramDatabaseFile>$(IntDir)$(TargetName).pdb</ProgramDatabaseFile>
                  <SubSystem>Windows</SubSystem>
                  <RandomizedBaseAddress>false</RandomizedBaseAddress>
                  <DataExecutionPrevention>
                  </DataExecutionPrevention>
                  <TargetMachine>MachineX86</TargetMachine>
                </Link>
                <PostBuildEvent>
                  <Command>
                  </Command>
                </PostBuildEvent>
              </ItemDefinitionGroup>
              <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release DLL|Win32'">
                <CustomBuildStep>
                  <Message>
                  </Message>
                  <Command>
                  </Command>
                  <Outputs>%(Outputs)</Outputs>
                </CustomBuildStep>
                <ClCompile>
                  <AdditionalOptions>/MP %(AdditionalOptions)</AdditionalOptions>
                  <Optimization>Full</Optimization>
                  <InlineFunctionExpansion>AnySuitable</InlineFunctionExpansion>
                  <IntrinsicFunctions>true</IntrinsicFunctions>
                  <FavorSizeOrSpeed>Speed</FavorSizeOrSpeed>
                  <WholeProgramOptimization>false</WholeProgramOptimization>
                  <AdditionalIncludeDirectories>$(SolutionDir)..\..\src;$(SolutionDir)..\..\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
                  <PreprocessorDefinitions>PLUMA_EXPORTS;NDEBUG;WIN32;%(PreprocessorDefinitions)</PreprocessorDefinitions>
                  <StringPooling>true</StringPooling>
                  <RuntimeLibrary>MultiThreadedDLL</RuntimeLibrary>
                  <BufferSecurityCheck>false</BufferSecurityCheck>
                  <EnableEnhancedInstructionSet>NotSet</EnableEnhancedInstructionSet>
                  <FloatingPointModel>Fast</FloatingPointModel>
                  <PrecompiledHeader>
                  </PrecompiledHeader>
                  <WarningLevel>Level4</WarningLevel>
                  <DebugInformationFormat>
                  </DebugInformationFormat>
                </ClCompile>
                <Link>
                  <OutputFile>$(SolutionDir)..\..\lib\$(ProjectName).dll</OutputFile>
                  <AdditionalLibraryDirectories>%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
                  <GenerateDebugInformation>true</GenerateDebugInformation>
                  <ProgramDatabaseFile>$(IntDir)$(TargetName).pdb</ProgramDatabaseFile>
                  <SubSystem>Windows</SubSystem>
                  <OptimizeReferences>true</OptimizeReferences>
                  <EnableCOMDATFolding>true</EnableCOMDATFolding>
                  <LinkTimeCodeGeneration>
                  </LinkTimeCodeGeneration>
                  <RandomizedBaseAddress>false</RandomizedBaseAddress>
                  <DataExecutionPrevention>
                  </DataExecutionPrevention>
                  <TargetMachine>MachineX86</TargetMachine>
                </Link>
              </ItemDefinitionGroup>
              <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug static|Win32'">
                <CustomBuildStep>
                  <Message>
                  </Message>
                  <Command>
                  </Command>
                  <Outputs>%(Outputs)</Outputs>
                </CustomBuildStep>
                <ClCompile>
                  <AdditionalOptions>/MP %(AdditionalOptions)</AdditionalOptions>
                  <Optimization>Disabled</Optimization>
                  <AdditionalIncludeDirectories>$(SolutionDir)..\..\src;$(SolutionDir)..\..\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
                  <PreprocessorDefinitions>PLUMA_EXPORTS;PLUMA_STATIC;_DEBUG;WIN32;%(PreprocessorDefinitions)</PreprocessorDefinitions>
                  <MinimalRebuild>false</MinimalRebuild>
                  <BasicRuntimeChecks>EnableFastChecks</BasicRuntimeChecks>
                  <RuntimeLibrary>MultiThreadedDebugDLL</RuntimeLibrary>
                  <PrecompiledHeader>
                  </PrecompiledHeader>
                  <WarningLevel>Level4</WarningLevel>
                  <DebugInformationFormat>EditAndContinue</DebugInformationFormat>
                </ClCompile>
                <Lib>
                  <OutputFile>$(SolutionDir)..\..\lib\$(ProjectName)-s-d.lib</OutputFile>
                </Lib>
                <PostBuildEvent>
                  <Command>
                  </Command>
                </PostBuildEvent>
              </ItemDefinitionGroup>
              <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release static|Win32'">
                <CustomBuildStep>
                  <Message>
                  </Message>
                  <Command>
                  </Command>
                  <Outputs>%(Outputs)</Outputs>
                </CustomBuildStep>
                <ClCompile>
                  <AdditionalOptions>/MP %(AdditionalOptions)</AdditionalOptions>
                  <Optimization>Full</Optimization>
                  <InlineFunctionExpansion>AnySuitable</InlineFunctionExpansion>
                  <IntrinsicFunctions>true</IntrinsicFunctions>
                  <FavorSizeOrSpeed>Speed</FavorSizeOrSpeed>
                  <WholeProgramOptimization>false</WholeProgramOptimization>
                  <AdditionalIncludeDirectories>$(SolutionDir)..\..\src;$(SolutionDir)..\..\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
                  <PreprocessorDefinitions>PLUMA_EXPORTS;PLUMA_STATIC;NDEBUG;WIN32;%(PreprocessorDefinitions)</PreprocessorDefinitions>
                  <StringPooling>true</StringPooling>
                  <RuntimeLibrary>MultiThreadedDLL</RuntimeLibrary>
                  <BufferSecurityCheck>false</BufferSecurityCheck>
                  <EnableEnhancedInstructionSet>NotSet</EnableEnhancedInstructionSet>
                  <FloatingPointModel>Fast</FloatingPointModel>
                  <PrecompiledHeader>
                  </PrecompiledHeader>
                  <WarningLevel>Level4</WarningLevel>
                  <DebugInformationFormat>
                  </DebugInformationFormat>
                </ClCompile>
                <Lib>
                  <OutputFile>$(SolutionDir)..\..\lib\$(ProjectName)-s.lib</OutputFile>
                </Lib>
              </ItemDefinitionGroup>
              <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
              <ImportGroup Label="ExtensionTargets">
              </ImportGroup>
            </Project>

            Et enfin, cmake:

            cmake_minimum_required ( VERSION 2.8 )
            project( pluma )
            
            set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O3 -s -Wall -DPLUMA_EXPORTS")
            
            file(GLOB_RECURSE sources src/*.cpp )
            
            include_directories( "include" "src" )
            add_library( pluma SHARED ${sources} )
            target_link_libraries( pluma )

            PS: désolé pour le délai avant la réponse, j'ai voulu avoir un truc un peu plus concret…

            • [^] # Re: Gestionnaire de projets

              Posté par . Évalué à 3.

              On doit pouvoir l'écrire en XML ainsi :

              <?xml version="1.0" encoding="utf-8"?>
              <CMake version_minimum="2.8">
                  <project name="pluma">
              
                  <set name="CMAKE_CXX_FLAGS">${CMAKE_CXX_FLAGS} -O3 -s -Wall -DPLUMA_EXPORTS</set>
              
                  <files>
                      <glob name="sources">src/*.cpp</glob>
                  </files>
              
                  <includes>
                     <dir name="include">src</dir>
                  <includes>
              
                  <libraries>
                      <library name="pluma" type="SHARED">${sources}</library>
                  </libraries>
                  <targetLink>
                      <library>pluma</library>
                  </targetLink>
              </project>
              </CMake>

              L'avantage c'est que tu as un format qui est largement supporté. Je peux facilement écrire un truc qui va l'analyser (pour mon intégration continue par exemple).

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

              • [^] # Re: Gestionnaire de projets

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

                Et si l'outil propose de bonnes options par défaut pour 99% des projets (les sources dans src, les options Wall & co…), on pourrait réduire à:

                <?xml version="1.0" encoding="utf-8"?>
                <project xmlns="http://supercmake.lol/project/2.9">
                    <name>pluma</name>
                    <type>library</type>
                </project>

                http://devnewton.bci.im

                • [^] # Re: Gestionnaire de projets

                  Posté par . Évalué à 2.

                  Utiliser -O3 par défaut serait une ânerie, ce niveau d'optim peut déclencher des bugs (je n'ai pas d'exemples précis en tête, cependant, mais une recherche devrait pouvoir te guider rapidement. Du côté du wiki de gentoo, peut-être?).

                  Idem, "-DPLUMA_EXPORTS" n'à rien de standard.

                  Générer des libs shared par défaut serait, encore, de bien mauvais goût, selon la taille, ça peut juste être un coup à générer du méchant bloatware (dans le cas de pluma, comme tout le monde l'aura lu dans le très concis exemple de VS, il y à 4 cibles: debug/release et share/static).

                  Imposer des paths n'est pas non plus une bonne idée, j'ai cru constater que les dev c++ sont loin de tous avoir les mêmes conventions, et ça peut même varier selon le projet: par exemple pour une lib, séparer les include d'interface des include utilisés par le source est fréquent.
                  Je ne parle même pas du cas ou le src contiens des sous-dossiers en fonction de l'interface utilisé… (aptitude est un exemple).

                  D'ailleurs, je pense qu'il est largement faisable de faire ce que tu as fait en autant de lignes avec cmake, si tu as un template à inclure… je ne vois pas pourquoi ça le serait.
                  Un truc genre (syntaxe à l'arrache):

                  include( montemplate.cmake )
                  project( pluma )
                  build_library( pluma )
                  

                  Ne doit pas être infaisable. À ce niveau, je me demande(en tout cas on peut creer des fonctions) si on ne pourrait pas construire un template, ou plutôt une lib, qui permettrait d'écrire:

                  include( montemplate.cmake )
                  build_library( pluma )
                  

                  Alors, ok, c'est pas en standard, mais bon, ça fait bien ce que tu demandes, avec encore moins d'infos "inutiles" que ton xml.

                  • [^] # Re: Gestionnaire de projets

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

                    j'ai cru constater que les dev c++ sont loin de tous avoir les mêmes conventions
                    ok, c'est pas en standard, mais bon, ça fait bien ce que tu demandes, avec encore moins d'infos "inutiles" que ton xml.

                    C'est bien ça le problème: rien n'est standard.

                    Avant de démarrer un projet, il faut choisir des conventions, une organisation, utiliser des scripts compliqués…

                    Vu qu'il faut gérer les dépendances à la main, il faut se taper non seulement sa propre organisation, mais aussi celles de toutes les libs dont on dépends.

                    Ne doit pas être infaisable.

                    Oui tout est faisable, mais on perds un temps infini sur des tâches que les autres langages (java, go, python, ruby…) ont standardisées et automatisées.

                    http://devnewton.bci.im

              • [^] # Re: Gestionnaire de projets

                Posté par . Évalué à 3.

                "On doit", contre des "exemples concrets"…
                Donnes-moi un outil concret qui accepte ton truc et compile?

                Enfin, admettons. Tu trouves ton truc plus lisible pour un humain (enfin, pour un dev, puisque ce sont les dev qui maintiennent les cmakelists.txt en général) que le pendant cmake? Plus maintenable?

                Dans ce cas, vraiment, on à des goûts différents et je doute qu'on puisse se convaincre l'un l'autre.
                Quant au format… je vois ton truc, j'ai peur. Parce que je me dis que si je dois utiliser un outil de manipulation de texte (grep, sed, cut, etc) pour extraire une info précise de ce machin, je suis dans une merde assez profonde. Mais nul doute que ton usine à gaz outil qui interprète ça te fournira tout ce dont tu as besoin je suppose?

                • [^] # Re: Gestionnaire de projets

                  Posté par . Évalué à 1. Dernière modification le 29/09/14 à 19:45.

                  Tu trouves ton truc plus lisible pour un humain (enfin, pour un dev, puisque ce sont les dev qui maintiennent les cmakelists.txt en général) que le pendant cmake? Plus maintenable?

                  Pour un dev, tu peux utiliser à peu près n'importe quoi ça ne poeseras pas de problème, json, cmake, makefile, gpr, xml, script shell ou scons, c'est du détail.

                  La seule chose que je dis c'est que la grammaire XML est simple et elle est connu là où celle de cmake est spécifique.

                  Parce que je me dis que si je dois utiliser un outil de manipulation de texte (grep, sed, cut, etc) pour extraire une info précise de ce machin, je suis dans une merde assez profonde.

                  Ouai si tu commence à utiliser ce genre d'outil pour aller chercher des choses dans ton cmakelits.txt t'es mal. Ça peut marcher pour pleins de cas simples mais tu ne peux pas distribuer tes scripts sans très largement t'emmerder à gérer les instructions multiples et de vérifier les données que tu récupère. Tu va aussi devoir gérer les commentaire par exemple.

                  Pour aller faire des recherches dans du XML de manière fiables tu a les requêtes XPath avec les commandes xpath (fourni avec le module perl XML::XPath) ou xfind.

                  Mais nul doute que ton usine à gaz outil qui interprète ça te fournira tout ce dont tu as besoin je suppose?

                  Ben en fait, il y a un énorme paquets de gens qui fournissent tout ce dont je peux avoir besoin, chaque langage a plusieurs bibliothèques, mais tu as aussi des outils qui sont directement capable de faire du xpath (jenkins a un module pour ça par exemple). L'écosystème autour d'XML est largement plus grand que celui de CMake.

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

                  • [^] # Re: Gestionnaire de projets

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

                    La seule chose que je dis c'est que la grammaire XML est simple et elle est connu là où celle de cmake est spécifique.

                    Oué mais XML c'est bien pour du déclaratif, ce que n'est pas le langage de CMake.
                    Et on voit bien avec Maven que le déclaratif c'est bien sur le papier mais dans le vrai monde on fabrique des plugins en java pour pouvoir passer outre et avoir les comportements attendus.

                    • [^] # Re: Gestionnaire de projets

                      Posté par . Évalué à 5.

                      Exactement, les cas particuliers sont gérés par du code particulier. Et le cas simple de 99% des gens, et bien une simple déclaration suffit. Et c'est tout ce que demande devnewton.

                      • [^] # Re: Gestionnaire de projets

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

                        Et le cas simple de 99% des gens

                        Ajoutons que dans le monde java, l'un des effets bénéfiques de maven a été de faire des builds particuliers de vilains petits canards qu'on évite comme la grippe aviaire.

                        http://devnewton.bci.im

                    • [^] # Re: Gestionnaire de projets

                      Posté par . Évalué à 4.

                      Oué mais XML c'est bien pour du déclaratif, ce que n'est pas le langage de CMake.

                      Ah bon ?

                      Et on voit bien avec Maven que le déclaratif c'est bien sur le papier mais dans le vrai monde on fabrique des plugins en java pour pouvoir passer outre et avoir les comportements attendus.

                      On ne doit pas être dans le même vrai monde. Dans le miens c'est rare qu'on ai à le faire et le faire avec un langage complet comme celui de ton programme est plutôt agréable (la seule fois où j'en ai eu besoin c'était pour manipuler un fichier xls et remplacer la macro qui s'y trouvait (tu fais ça comment avec make ou cmake ?

                      J'apprécie beaucoup gradle et sbt mais c'est pas pour autant que maven est pourri.

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

                    • [^] # Re: Gestionnaire de projets

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

                      Et on voit bien avec Maven que le déclaratif c'est bien sur le papier mais dans le vrai monde on fabrique des plugins en java pour pouvoir passer outre et avoir les comportements attendu

                      Et on configure ses plugins avec du déclaratif. Le système est bien fait.

                      http://devnewton.bci.im

            • [^] # Re: Gestionnaire de projets

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

              On n'est pas obligé de subir le XML des autres.

              Pour ma part, pour chacun de mes logiciels, j'écris un fichier XML, nommons-le 'Project.xml', dont c'est moi qui ai décidé de la signification des balises et attributs qu'il contient. Il y a ainsi quelques balises descriptives (nom du logiciel, numéro de version du logiciel, auteur…), et de nombreuses autres plus techniques (nom et localisation des fichiers sources, options de compilation…). Grâce à un ensemble de scripts et de fichiers XSL que j'ai développés, je génère, à partir de ce 'Project.xml', les fichiers '.vcxproj' et '.vcxproj.filters' qui permettent de compiler le logiciel à l'aide de Visual Studio, ainsi que le Makefile qui permet de compiler le logiciel sous Cygwin avec G++ et MinGW, ainsi que sous GNU/Linux et MacOS.
              Lorsque je veux, par exemple, ajouter/enlever/modifier un option de compilation, je ne passe pas par l'interface de Visual Studio, ni ne modifie le Makefile, mais modifie uniquement 'Project.xml', puis relance les scripts pour régénérer les différents fichiers.
              J'envisage, dans un futur proche, d'offrir la possibilité d'utiliser Clang sous Windows pour compiler les logiciels que je développe. Et bien, pour cela, il suffira que je modifie les scripts et les fichiers XSL, sans toucher aux différents 'Project.xml', pour que les Makefile générés prennent automatiquement en charge Clang. Pas besoin de modifier manuellement tous les Makefile pour cela.

              Je gère ainsi chacun de mes projets à partir d'un seul et unique fichier 'Project.xml', dont j'ai la totale maîtrise du contenu, puisque qu'il n'est destiné à être traité que par des outils que j'ai moi-même développé. Bien entendu, il a fallu développer ces différents scripts et fichiers XSL, ce qui m'a pris au final bien moins de temps que je ne le pensais, ayant l'habitude de travailler avec XML/XSLT, mais depuis que ces dernier sont écrits, je n'ai plus eu à modifier de Makefile ou équivalent, ni à me replonger dans la documentation de Visual Studio, ou de GNU make, ou d'un quelconque autre outil similaire…

              Freelance en ingénierie informatique.

              • [^] # Re: Gestionnaire de projets

                Posté par . Évalué à 3.

                Tu décris un cmake-like au final. Tu n'a pas trop de rupture de compatibilité avec les formats de fichiers projet de VS et C::B ?

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

                • [^] # Re: Gestionnaire de projets

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

                  D'après ce que j'en sais, cmake est similaire, dans son usage, à make, donc utilisé pour la compilation. Or, je ne lance pas mes scripts pour compiler le logiciel, mais pour générer les fichiers permettant cette compilation. La compilation proprement dite se fait à l'aide d'outils traditionnels (Visual Studio, make…). Donc, je ne pense pas que l'on puisse qualifier mes scripts de 'cmake-like'. Ils seraient plutôt, toutes proportions gardées, 'automake-like'.
                  Concernant Visual Studio, la dernière version est capable d'utiliser tel quel ou de convertir les fichiers issus de certaines précédentes versions. Cependant, j'ai modifié mes scripts lorsque j'ai changé de version, et ce ne devait pas être bien compliqué, car la seule chose dont je me souvienne, c'est d'avoir modifié le contenu de l'attribut qui semble correspondre à la version de Visual Studio. En tout cas, après modification de la valeur ce cet attribut ('ToolsVersion'), Visual Studio acceptait le fichier généré par mes scripts tel quel, sans demande de conversion.
                  Je n'ai jamais utilisé C::B…

                  Freelance en ingénierie informatique.

                  • [^] # Re: Gestionnaire de projets

                    Posté par . Évalué à 3.

                    D'après ce que j'en sais, cmake est similaire, dans son usage, à make, donc utilisé pour la compilation.

                    Non justement cmake est un descripteur de projet qui ne sais pas compiler lui même, il sait générer des fichiers/script de build dans différents format.

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

                    • [^] # Re: Gestionnaire de projets

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

                      En fait, j'avais regardé http://fr.wikipedia.org/wiki/CMake et m'était arrêté à : [CMake] est comparable au programme Make… (et cela correspondait à ce que je croyais savoir de CMake). Il est vrai que la description qui en est faite dans la suite de l'article présente de fortes similarités avec ce que réalisent mes scripts.
                      Ceci dit, l'avantage de ma démarche, c'est que je parvenais au résultat désiré juste en utilisant des outils qui n'étaient très familiers, et un fichier dont j'avais la maîtrise totale du contenu (modulo la structure due à l'utilisation de XML) et de sa signification. Mais ce qui est un avantage pour moi, parce que j'ai développé ces scripts, n'en serait pas un pour une tierce personne…

                      Freelance en ingénierie informatique.

                      • [^] # Re: Gestionnaire de projets

                        Posté par . Évalué à 3.

                        Ceci dit, l'avantage de ma démarche

                        Je ne remet pas du tout en cause ton approche, c'est juste une manière de décrire (je me suis bien plus amusé sur certains doom-like que sur doom :) ).

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

                      • [^] # Re: Gestionnaire de projets

                        Posté par . Évalué à 3.

                        Ce n'est pas parce que c'est un *-like, que c'est moins bien ou pas pertinent. Au contraire, surtout que toi, tu utilises une approche radicalement différente (xml au lieu de langage de script).

                        Je ne sais pas si tu publies tes scripts, mais je pense qu'ici plusieurs seraient intéressés, à lire les différentes interventions.

              • [^] # Re: Gestionnaire de projets

                Posté par . Évalué à 3.

                Tu as un exemple de projet.xml et les feuilles XSLT sur un dépôt quelque part ?

        • [^] # Re: Gestionnaire de projets

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

          Que proposes-tu? Parce que un Makefile et des scripts, c'est pas spécialement plus lisible et modifiable par un humain…

          http://devnewton.bci.im

          • [^] # Re: Gestionnaire de projets

            Posté par . Évalué à 2.

            Je trouve effectivement que Makefile, c'est horrible. Par contre, je trouve CMake très accessible, c'est d'ailleurs en corrigeant un CMakeLists.txt de quelques centaines de ligne en moins de 15 minutes pour générer un .deb, sans le connaître au préalable (juste de nom), que je l'ai adopté.

        • [^] # Re: Gestionnaire de projets

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

          Pour moi, un bon fichier de configuration doit également être facilement modifiable de façon automatique, histoire d'être utilisable avec les outils classiques de gestion de conf'.

          • [^] # Re: Gestionnaire de projets

            Posté par . Évalué à 2.

            Ce n'est pas faux. Du coup, tu utilises quels outils classiques pour modifier de la conf xml/json? Parce que sed, grep, cut & co, ça me paraît difficilement adapté?

            • [^] # Re: Gestionnaire de projets

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

              Je ne suis pas admin sys, donc je fais assez peu de gestion de conf' (uniquement à la maison, avec Salt Stack). J'ai codé quelques petites extensions Python quand j'ai eu à le faire (assez rarement).
              Accessoirement, j'ai un peu participé à la lib plistlib Python (elle ne savait pas travailler avec la représentation binaire du plist, uniquement avec la représentation XML).

              Malheureusement, sed/cut/grep et Cie sont en effet assez peu adaptés à la manipulation des fichiers de conf (même textuels), c'est le bon plan pour ajouter des bugs discrètement ($ dans les mots de passe, option répartie sur plusieurs lignes, etc.).

              • [^] # Re: Gestionnaire de projets

                Posté par . Évalué à 2.

                Je ne suis pas admin sys,

                Je suis aussi loin d'être admin, mais j'essaie de me mettre aux scripts shell, parce que c'est vraiment puissant, même à mon très faible niveau.
                Par exemple, quand on doit se taper des comparaisons de fichiers de log qui peuvent différer d'un serveur à un autre, ou d'une date à une autre, pour trouver des infos supplémentaires au sujet d'un bug qu'il faut corriger.
                Ou quand on est dans une petite boîte et qu'il faut modifier une entrée SQL dans 5 bases de données, répliquées sur un autre serveur ( ce qui fait donc 10 fois la même manipulation à faire, à la main… c'est ce que mes collègues faisaient, c'est ce que je refuse de faire. ).
                Pour ces situations, écrire un programme complet serait un peu overkill, quand on peut coder ça en 10-20 lignes de shell.
                En fait, dans ma boîte je fait un peu de tout, sûrement pas du grand art, mais bon, faut bien que quelqu'un le fasse, et j'avoue que ça ne me déplaît pas. Tant qu'on me demandera pas de faire ce genre de trucs sur des serveurs windows du moins :)

                Malheureusement, sed/cut/grep et Cie sont en effet assez peu adaptés à la manipulation des fichiers de conf (même textuels),

                Si, ils sont très efficaces quand il s'agit de gérer des fichiers de type clé=valeur, genre INI ou… en fait la plupart de ce que je trouve dans mes /etc.

            • [^] # Re: Gestionnaire de projets

              Posté par . Évalué à 4.

              Pour json, je ne sais pas.
              Pour xml, tu as les commandes xpath et xfind en ligne de commande.

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

              • [^] # Re: Gestionnaire de projets

                Posté par . Évalué à 2.

                Je trouve bien xpath, mais pas moyen de mettre la main sur un man de xfind. Tu aurais une URI?

                • [^] # Re: Gestionnaire de projets

                  Posté par . Évalué à 3.

                  Le site officiel : http://uucode.com/texts/xfind/index.html

                  Mais ce ne sont que des exemples tu as aussi xqilla pour tout ce qui est xpath et xquery (plus puissant) et qui est souvent packagé.

                  Tout ça pour dire que manipuler du XML ça se fait largement plus facilement (et de manière plus fiable)que de manipuler le format de CMake et surtout pour freem qui pense que le xml oblige à passer par l'outil dédié :

                  • ce n'est pas le cas avec du xml parce qu'il existe des outils en cli fiables pour manipuler du xml et il est possible dans tous les langages de le faire
                  • c'est le cas avec CMake où tu ne peux pas faire grand chose (et surtout pas des choses fiables) dès lors que ce n'est pas prévu par les créateurs de CMake/CTest/CPack

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

  • # C'est plus de boulot, mais ça vaut le coup

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

    Salut!

    J'arrive un peu après la bataille, mais voila néanmoins mon avis.

    Tout d'abord, ayant récemment, et à mon corps défendant, fait pas mal de Java, j'ai pu apprécier l'intégration du langage avec ses outils, la simplicité du build, et la gestion de dépendances façon Maven ou Ivy. Je n'ai pas pu retrouver une intégration aussi bonne avec le C++, je comprends donc ta douleur.

    Je suis passé par de nombreux IDE, mais je n'ai jamais rien trouvé qui me satisfasse complètement. CodeBlocks était probablement un des meilleurs. J'ai entendu beaucoup de bien de QCreator. Mais la solution qui a fonctionné pour moi, c'est ce bon vieux Emacs. En utilisant le modes compilation, qui permettent d'aller à l'erreur via un clic ou via une touche du clavier, et le mode gdb, qui permet, via gdb-many-windows, d'obtenir un très bon environnement de debug, l'on se retrouve avec une solution très intégrée et productive. Pub inside, je détaille mon utilisation d'Emacs dans ma série Coder efficacement avec Emacs (les posts les plus anciens ne sont pas correctement taggés, mais ils ne sont pas difficiles à trouver).

    Pour la solution de build, il n'existe pas de remède miracle. Ton choix semble judicieux, cmake est très utilisé et devient de plus en plus une référence, mais l'outil gagne à être un petit peu étudié, l'utilisation des modules simplifie énormément la vie.

    Le temps de compilation est toujours aussi problématique. J'ai utilisé dans le passé les en-têtes pré-compilées, mais j'en suis revenu, ayant trouvé qu'un peu d'attention dans les #include et qu'une utilisation massive de la forward declaration me donnait de bien meilleurs résultats. Surtout, utiliser Boost le plus parcimonieusement possible, en particulier dans les fichiers d'en-tête, et utiliser plutôt les primitives de la bibliothèque standard, laquelle s'est bien étoffée avec une panoplie de pointeurs intelligents, de primitives pour gérer le parallélisme, la mesure du temps ou même les expressions régulières.

    Au passage le linker "gold" (Goooooold linker!!!!) améliore fortement les performances à l'édition de liens, ce qui est toujours ça de pris.

    Ccache et distcc aident également beaucoup, mais c'est encore du boulot supplémentaire de mettre tout cela en place.

    Je ne peux que t'encourager à investir un peu de temps pour te construire un environnement aux petits oignons, et à tirer meilleur parti du langage. D'excellentes bibliothèques sont disponibles pour programmer des jeux. Nommons en particulier SFML, le couteau suisse de l'interaction avec le matériel (vidéo, audio, contrôleurs), et OpenSceneGraph, qui est un graphe de scène basé sur OpenGL, et dont les capacités sont remarquables.

    Bon courage!

    • [^] # Re: C'est plus de boulot, mais ça vaut le coup

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

      Nommons en particulier SFML, le couteau suisse de l'interaction avec le matériel (vidéo, audio, contrôleurs), et OpenSceneGraph, qui est un graphe de scène basé sur OpenGL, et dont les capacités sont remarquables.

      On a pas mal débattu de la SFML ici et sur #jeuxlibres. Rewind l'utilise pour Akagoria et en est très content. Je suis plus sceptique et je pense que je vais partir sur cette bonne vieille SDL. En fait mon point de vue n'a pas beaucoup changé depuis ce journal :-)

      http://devnewton.bci.im

      • [^] # Re: C'est plus de boulot, mais ça vaut le coup

        Posté par . Évalué à 10.

        En fait, il faut qu'on se cotise pour offrir à devnewton un ordinateur qui gère un truc aussi moderne qu'OpenGl ES 2 pour qu'il arrête de vouloir des bibliothèques qui utilisent encore OpenGL 1 parce que ses cartes graphiques ne gèrent que ça.

  • # Retourne à la raison!

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

    C++ a d'immenses problèmes, qui sont essentiellement liés à la présence dans le langage de technologies ou méthodes concurrentes et à tous les outils de code obfuscation dont il dispose.

    • Le préprocesseur n'a pas été abandonné au profit des templates et const int ce qui rend quasiment impossible l'analyse statique du code et beaucoup de raisonnements élémentaires sur le code source. Résultat: la compilation est très lente dès qu'on sort du cadre d'un projet trivial.

    • Les références font essentiellement double emploi avec les pointeurs, elles enrichissent le lexique d'un langage déjà touffu pour une sémantique (passage de pointeur sans transfert de propriété) essentiellement dupliquée par les smart pointers.

    • Il est très difficile de tirer correctement parti des champs constants. Bien utiliser l'attribut const nécessite de préparer une vraie stratégie de développement.

    • Le langage est tellement compliqué qu'il n'y a pas foule de compilateurs implémentant complètement le langage — la dernière fois que j'ai fait des recherches là-dessus il y en avait exactement un. Et puis les implémentations sont boguées! J'ai appris C++ et exactement 3 mois plus tard j'ai découvert un bogue dans le compilateur!

    J'abrège un peu parce que c'est Samedi: C++ est utilisable si

    • On a une grosse équipe avec deux “seniors” et un architecte compétents pour la diriger.
    • On écrit un compilateur dont le backend est C++.

    Dans tous les autres cas, s'abstenir.

    • [^] # Re: Retourne à la raison!

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

      Comme le disait Bjarne Stroustrup, le créateur de C++: « Il y a deux sorte de languages de programmation: ceux dont on se plaint, et ceux que personne n'utilise »

      Toujours d'après Stroustrup, L'une des caractéristique qui contribue au succès de C++ est la compatibilité avec le C. Le fait que du code écrit il y a plusieurs décénies peux être utiliser avec du C++ moderne.

      Il est tout à fait possible d'utiliser le C++ sans utiliser les fonctionalités rétrogrades.
      Et le C++ moderne n'est pas si horrible.

      Les languages « meilleurs » qui ont retiré la compatibilité n'ont pas eu beaucoup de succès. (Exemple: D.) (Et je suis curieux de voir ce que va devenir Rust.)

    • [^] # Re: Retourne à la raison!

      Posté par . Évalué à 4.

      Le préprocesseur n'a pas été abandonné au profit des templates et const int ce qui rend quasiment impossible l'analyse statique du code et beaucoup de raisonnements élémentaires sur le code source. Résultat: la compilation est très lente dès qu'on sort du cadre d'un projet trivial.

      Les compilateurs modernes (dont Clang) savent remonter une erreur jusqu'à l'instruction préprocesseur fautive.

      Les références font essentiellement double emploi avec les pointeurs, elles enrichissent le lexique d'un langage déjà touffu pour une sémantique (passage de pointeur sans transfert de propriété) essentiellement dupliquée par les smart pointers.

      Les références ne font pas double emploi, au contraire, et elles n'ont pas du tout la sémantique que tu veux leur donner. Et les smart pointers, c'est encore autre chose.

      Il est très difficile de tirer correctement parti des champs constants. Bien utiliser l'attribut const nécessite de préparer une vraie stratégie de développement.

      C'est une blague ? Il n'y a pas besoin de «stratégie», juste d'un peu de bon sens et normalement, tout se passe bien et les const sont au bons endroits.

      Le langage est tellement compliqué qu'il n'y a pas foule de compilateurs implémentant complètement le langage — la dernière fois que j'ai fait des recherches là-dessus il y en avait exactement un. Et puis les implémentations sont boguées! J'ai appris C++ et exactement 3 mois plus tard j'ai découvert un bogue dans le compilateur!

      C'est là qu'on voit que tu n'as sans doute pas pratiqué C++ depuis un moment. Certes pour C++98, seul Comeau C++ implémentait la norme complète et en particulier le mot-clef export. Mais celui-ci a été enlevé de C++11 et depuis, Clang et GCC implémente la norme complètement. Après, si tu connais des compilateurs (peu importe le langage) sans bug, dis le, ça va intéresser plein de gens.

      • [^] # Re: Retourne à la raison!

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

        C'est une blague ? Il n'y a pas besoin de «stratégie», juste d'un peu de bon sens et normalement, tout se passe bien et les const sont au bons endroits.

        Oui c'est exactement comme ça que ça marche. Quand on parle de blague! Au passage, le bon sens c'est la dialectique typique des gens qui n'ont pas d'argument, comme nous l'a rappelé à souhait un de nos précédents gouvernements, c'est donc une expression à éviter invariablement si on veut être pris au sérieux.

        Exemple au hasard: si je décide de mettre une référence constante dans une object, et bien je ne peux plus utiliser le classique clone & swap pour implémenter l'assignement, ce qui oblige à dupliquer une bonne partie du clonage et de l'assignement. Le bon sens ici ne suffit pas.

        Autre exemple: dans la vraie vie on travaille avec des APIs toutes pourries qui ne connaissent pas const et penser une interface vaguement propre ne se fait pas sur un coin de table de bar avec un peu de bon sens.

        Pour avoir travaillé sur une importante base de code C++ développée avec “le bon sens” j'ai une expérience qui dit que ça se passe plutôt mal.

        Les références ne font pas double emploi, au contraire, et elles n'ont pas du tout la sémantique que tu veux leur donner. Et les smart pointers, c'est encore autre chose.

        Si tu as des choses utiles à dire — du type, une affirmation positive — ne t'en prive pas, on est toujours content d'apprendre quelque chose.

        C'est là qu'on voit que tu n'as sans doute pas pratiqué C++ depuis un moment.

        Effectivement. Mais il ne faut pas oublier que dans la vie de beaucoup de développeurs contemporains C++11 c'est de la science-fiction, ne parlons pas de C++14.

        Après, si tu connais des compilateurs (peu importe le langage) sans bug, dis le, ça va intéresser plein de gens.

        Tu t'appuies tes arguments sur le bon sens et ensuite tu exagères les propos de tes contradicteurs pour les contredire par le ridicule. Merci pour tes contributions inestimables à la qualité du débat sur LinuxFR.

        • [^] # Re: Retourne à la raison!

          Posté par . Évalué à 5.

          Référence ou pointeur ?

          Un pointeur indique un emplacement mémoire. Il peut être nul (nullptr). Une référence indique un objet. Elle ne peut pas être nulle.
          Certes, on peut maladroitement produire des références à partir de pointeurs invalides ou nuls, donc dans le fond ce n'est qu'un déguisement.
          Néanmoins l'information est bien là. C'est un peu comme un argument de fonction qui serait un uint et pas un int.
          De plus, cela permet techniquement un maniement un peu plus fin sur les lvalue, rvalue, prvalue du programme, comme avec l'opérateur && (qui n'est pas une référence de référence : quel agréable choix de symbole…) .
          Un pointeur est un outil assez bourrin. Efficace mais peut-être trop direct ?

          Les smart pointers ont un objectif assez différent, plutôt orienté gestion mémoire partagée. Je ne suis pas convaincu qu'on puisse les faire rentrer dans une question autour de la pertinence des références.

          Liberté

          Dans le fond, ce que tu reproches à C++, c'est de ne pas assez restreindre le développeur, c'est ça ?

          Même si des aspects de C++ comme les exceptions ou les templates sont objectivement maladroits, dans le fond, est-ce vraiment grave ?
          On peut toujours s'en passer et coder uniquement avec des codes de retour d'erreur et des pointeurs, s'en tenir à du "C Objet".

          Parce qu'après tout une exception sécurisée est assez peu rentable.
          Et comme on aura toujours moyen de bousiller un programme malgré des références, autant utiliser des pointeurs pour garder un programme simple. Et ce serait pertinent.

          Un développeur maladroit fera toujours de la merde, même avec un langage prison.
          Y aura toujours moyen de corrompre un jeu de données, outrepasser la limite d'un conteneur, faire une division par zéro… Peu importe le langage !

          C++ est une drôle de connerie inutilement compliquée, mais il ne faut pas non plus lui mettre sur le dos l'éventuelle incompétence des programmeurs.

          • [^] # Re: Retourne à la raison!

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

            Un pointeur indique un emplacement mémoire. Il peut être nul (nullptr). Une référence indique un objet. Elle ne peut pas être nulle.

            Mais ce n'est pas du tout la différence entre un pointeur et une référence — en dépit de la litanie lénifiante qu'on peut lire à beaucoup d'endroits. Comme tu le dis plus bas on peut maladroitement — mais de façon complètement anodine — passer un référence nulle. En réalité la seule véritable différence de fonctionnalité entre un pointeur et une référence c'est que le pointeur permet de déconstruire l'objet et pas la référence.

            Autrement dit les références implémentent les pointeurs sans transfert de propriété — le propriétaire est responsable de la libération de mémoire. Et les rapprocher d'un outil de gestion comme les smart pointers n'a rien de farfelu.

            Dans le fond, ce que tu reproches à C++, c'est de ne pas assez restreindre le développeur, c'est ça ?

            Pas du tout. Ce que je reproche à C++ est d'être un langage complètement byzantin, absolument illisible, et où il y a 36 réponses à chaque problème d'organisation qu'on se pose — et aucun des choix de réponse qu'on fait n'est anodin et les interdépendances et incompatibilités entre ces choix n'apparaissent souvent que lorsqu'on a écrit une quantité substantielle de code.

            […]

            Pour en revenir à la discussion, mon message à DevNewton est que les problèmes d'ingénierie logicielle posés par C++ sont plus difficiles que dans beaucoup d'autres langages. Une façon de commencer à les résoudre est de faire, comme tu les suggères, du C with classes mais ce n'est pas forcément la plus intéressante.

            • [^] # Re: Retourne à la raison!

              Posté par . Évalué à 0. Dernière modification le 27/09/14 à 23:42.

              Byzanterie

              Une façon de commencer à les résoudre est de faire, comme tu les suggères, du C with classes mais ce n'est pas forcément la plus intéressante.
              Ce que je reproche à C++ est d'être un langage complètement byzantin, absolument illisible, et où il y a 36 réponses à chaque problème d'organisation

              Complètement d'accord.
              De toute évidence le C++ n'est pas une réussite, et ses nombreux besoins de rétrocompatibilités l'enchaînent encore plus. Trop tard pour lui, dommage.

              Mais est-il vraiment à jeter pour autant ? N'est-ce pas là tout simplement le prix à payer pour avoir à la fois puissance et abstraction ?

              Références et pointeurs

              les références implémentent les pointeurs sans transfert de propriété

              Les pointeurs purs non plus n'ont pas d'information de propriétés, non ?
              Ce sont de simples adresses de mémoire.

              En réalité la seule véritable différence de fonctionnalité entre un pointeur et une référence c'est que le pointeur permet de déconstruire l'objet et pas la référence.

              Euh, j'ai un doute là, du coup. La condition pour faire un delete propre est d'avoir allouer sur le tas avec un new la mémoire pointée par le pointeur donné en argument de delete.

              On peut parfaitement delete l'adresse d'une référence crée depuis un objet allouée sur le tas si ça nous amuse. Puisqu'au fond c'est un pointeur pur déguisé.
              Ou bien peut-être que mon GCC 4.8 (en c++11) est permissif sur ce point ? J'avoue ne pas avoir lu la spéc' officielle. Trop chiant.

              D'ailleurs, j'ai même le droit de delete un objet alloué sur la pile.

              • [^] # Re: Retourne à la raison!

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

                Mais est-il vraiment à jeter pour autant ? N'est-ce pas là tout simplement le prix à payer pour avoir à la fois puissance et abstraction ?

                Oui, non. C'est mon avis, et devnewton s'intéresse à l'avis des gens… ☺

                Les pointeurs purs non plus n'ont pas d'information de propriétés, non ?

                Quand on passe une référence, inutile de préciser (dans la documentation, p.ex.) qu'on reste propriétaire de l'objet. C'est ce que je veux dire. Les pointeurs eux, ne disent rien sur la propriété mais je parle des références.

                On peut parfaitement delete l'adresse d'une référence crée depuis un objet allouée sur le tas si ça nous amuse. Puisqu'au fond c'est un pointeur pur déguisé.

                On peut faire delete sur un pointeur et pas sur une référence: c'est une fonctionnalité du pointeur qui n'est pas autorisée par une référence. Et si on prend un pointeur sur l'objet référencé par une référence, et bien on travaille avec un pointeur et plus avec une référence.

                D'ailleurs, j'ai même le droit de delete un objet alloué sur la pile.

                Ça, certainement pas, ça sent l'UB à plein nez. À moins que je n'aie pas compris ce à quoi tu fais allusion.

                • [^] # Re: Retourne à la raison!

                  Posté par . Évalué à 0.

                  Quand on passe une référence, inutile de préciser (dans la documentation, p.ex.) qu'on reste propriétaire de l'objet. C'est ce que je veux dire. Les pointeurs eux, ne disent rien sur la propriété mais je parle des références.

                  Hm… tu veux parler du fait que, logiquement parlant, les pointeurs signalent de façon claire qu'on travaille sur un objet vivant dans une portée distante ?
                  Le flou peut exister dans le cas des références, pour un œil non-attentif (l'opérateur . au lieu de ->). Avec un pointeur c'est plus évident de rester attentif sur les effets de bords. Surtout avec unique_ptr / std::move j'imagine.

                  c'est une fonctionnalité du pointeur qui n'est pas autorisée par une référence

                  Ah bah, oui, puisque la référence est un objet ! En fait je ne comprends pas vraiment ce qui te chagrine avec les références sur ce plan-là. Ce n'est qu'une manière de reproduire un objet sans copie, ni affectation, ni déplacement.
                  Personnellement, je vois ça comme quelque chose de cosmétique, de confort. Ça revient au même qu'un pointeur déréférencé, un peu enjolivé.
                  Bon, j'avoue que je ne sais pas encore sur quoi me fixer, 100% pointeur ou mixte pointeurs références. Après tout les références n'apportent rien qui n'existe pas déjà, dans l'absolu.

                  ça sent l'UB à plein nez

                  Probablement. Mais bon, de toute manière, un pointeur invalide aussi respire l'UB à plein poumon, et on a assez vite plein de pointeurs invalides partout.

              • [^] # Re: Retourne à la raison!

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

                Le soucis avec le C++ (comme le C d'ailleurs), c'est que ce qui fait sa force fait également sa faiblesse.

                Il est possible à chacun de travailler comme il lui plait. De définir des énumérations à coup de #define, de enum ou tout récemment, de manière fortement typée (enfin !) avec les class enum. Ainsi, chacun fait comme il lui plait. Mais le soucis justement, c'est que chacun fait comme il lui plait. Sur un gros projet où plusieurs personnes collaborent, il est donc nécessaire d'avoir des règles si on veut garder une certaine homogénéité.

                Le préprocesseur est, de mon point de vue, une hérésie de nos jours. Néanmoins, il peut servir à résoudre "simplement" des problèmes de portabilités à coup de #ifdef pour insérer du code différent selon les plateformes.

                On reproche souvent au C++ ses temps de compilation. Pour moi, cela vient de deux choses :
                - tout d'abord, l'utilisation massive des templates. Le C++ aborde le polymorphisme à coup de générique là où d'autres langages utiliseraient l'héritage. Les templates sont couteux en temps de compilation, rajoute du temps à l'édition de liens (car génère de nombreux symboles) et peuvent être couteux aussi en espace dans le binaire généré.
                - l'utilisation des macros. Une classe est déclarée dans des entêtes. Si cet entête change, même de manière anodine (par ex. ajout d'un saut de ligne pour aérer le code), alors cela va nécessiter la recompilation de tous les fichiers sources qui référencent directement ou indirectement ce fichier. Alors que si le fichier d'entête était "compilé" en un .class contenant juste l'ABI (et éventuellement le code pour les fonctions inline) de sorte d'avoir une représentation unique quelque soit l'organisation de l'entête, alors les temps de recompilation serait grandement réduit !

                Une chose qui fait que le C++ est également populaire à mon avis, c'est l'absence de ramasse-miette. Les nouveaux langages qui sortent en ont tous (c'est une simple constatation, pas un appel à débat sur ramasse-miette vs gestion manuelle de la mémoire).

                Un langage qui pourrait remplacer le C++, c'est l'Ada. C'est un langage clair. Il évolue régulièrement, et on ne peut pas faire (facilement) n'importe quoi. L'inconvénient ? C'est un langage verbeux.

                Et c'est le dernier point que je souhaitais aborder. Aujourd'hui, tout est fait pour faciliter la vie du développeur et pour qu'il aille plus vite (utiliser {} pour définir un bloc, ça va, un BEGIN et un END, c'est trop). Je ne dis pas que c'est une mauvaise chose, car cela peut augmenter le rendement d'un développer, mais que cela n'est pas sans conséquence, soit sur la lisibilité du code (quand il s'agit de syntaxe), soit sur l'augmentation de la puissance de calcul nécessaire (lorsqu'il s'agit d'outils). Par exemple :
                - les langages tournant dans une VM, c'est super pratique (gestion robuste des exceptions), mais cela rajoute la lourdeur de la VM, aussi bien à l'exécution qu'en terme d'empreinte mémoire).
                - ramasse-miette, qui permet au développeur de se libérer de la contrainte de la gestion de la mémoire mais au prix d'un surcoût qui peut être loin d'être anondin comme le ramasse-miette se met à l'oeuvre (en plus des effets pervers de cette notion, notamment sur le laxisme de la gestion des ressources en générale par le développeur)
                - on utilise des ORMs ? C'est bien, mais cela rajoute un léger surcoût (dans le cas où on sait s'en servir) à un gros surcout (dans le cas contraire) par rapport à des requêtes écrites directement.
                - On utilise du XML partout ? C'est bien, il y a le côté pratique car on peut utiliser un éditeur de texte pour voir ce qui se passe. Mais un fichier XML est volumineux. Parser du XML prend du temps (il n'y a qu'à regarder des benchmarks entre l'analyse d'un fichier XML et l'analyse d'un fichier binaire (protobuf par exemple).

                Lorsqu'on met tout bout à bout, on arrive à avoir des programmes "simples" qui nécessitent des monstres pour pouvoir tourner correctement. Mais qui peuvent être aussi développer plus facilement :
                - plus rapidement (et donc moins cher)
                - par un développeur moyennement compétent (et donc moins cher).

                Et j'ai constaté que bien souvent, le temps et l'argent gagné durant la phase de développement est, et plus que largement, contrebalancé par le temps (et donc le coût) de la maintenance…

                • [^] # Re: Retourne à la raison!

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

                  Et j'ai constaté que bien souvent, le temps et l'argent gagné durant la phase de développement est, et plus que largement, contrebalancé par le temps (et donc le coût) de la maintenance…

                  Ouais euh, quand tu vois qu'il y a régulièrement des buffer overflow parce qu'un dév. C (c'est pas la master race tellement douée qu'elle peut tout gérer à la main peu importe la complexité du projet ?) a oublié de vérifier la taille de sa chaîne, et même dans des programmes "éprouvés"… et je ne parlerai pas des Bobby Tables parce qu'au fond même un développeur PHP a droit à un respect de sa personne humaine…

                  J'accepterai les critiques sur ces fonctionnalités quand les bug ridicules sus-nommés n'arriveront plus jamais, et en attendant je suis bien content d'être un programmeur qui utilise un ORM et un langage à ramasse-miettes.

                  • [^] # Re: Retourne à la raison!

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

                    J'accepterai les critiques sur ces fonctionnalités quand les bug ridicules sus-nommés n'arriveront plus jamais, et en attendant je suis bien content d'être un programmeur qui utilise un ORM et un langage à ramasse-miettes.

                    Je n'ai jamais dis que ces fonctionnalités n'étaient pas utile. Seulement qu'elles avaient un coût. Ces fonctionnalités, je les utilise également au quotidien :)

                    Et pour les deux problèmes que tu cites, nul besoin d'avoir un ramasse-miettes ou un ORM pour les éviter, simplement savoir programmer et connaitre son langage et ses outils (std::vector/std::string et requêtes paramétrées)

                • [^] # Re: Retourne à la raison!

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

                  Une classe est déclarée dans des entêtes. Si cet entête change, même de manière anodine (par ex. ajout d'un saut de ligne pour aérer le code), alors cela va nécessiter la recompilation de tous les fichiers sources qui référencent directement ou indirectement ce fichier. Alors que si le fichier d'entête était "compilé" en un .class contenant juste l'ABI (et éventuellement le code pour les fonctions inline) de sorte d'avoir une représentation unique quelque soit l'organisation de l'entête, alors les temps de recompilation serait grandement réduit !

                  Même si les en têtes était pré compilé dans un fichier .class, une modification annodine de l'en-tête changerait aussi le fichier .class (ne fut-ce que le modtime) et forcerait aussi la recompilation de tous les fichier qui référencent directement ou indirectement ce fichier.

                  Oh! Et les en-tête précompilée ça existe déjà. Ça s'appelle .gch avec GCC et .pch avec clang. Et ça améliore effectivenement le temps de compilation car le compilateur ne dois pas recompiler le header pour chaque fichier qui le contiens.

                  Les entête pré-compilés ont leur propre problèmes, mais marchent assez bien en pratique.

                  Mais l'avenir nous offre une solution presque parfaite: les Modules. Déjà partiellement implémentés dans clang.
                  http://clang.llvm.org/docs/Modules.html

                  • [^] # Re: Retourne à la raison!

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

                    Même si les en têtes était pré compilé dans un fichier .class, une modification annodine de l'en-tête changerait aussi le fichier .class (ne fut-ce que le modtime) et forcerait aussi la recompilation de tous les fichier qui référencent directement ou indirectement ce fichier.

                    L'idée justement est que si le fichier .class généré est identique à celui déjà présent (pas de changement d'ABI donc), alors le fichier initial n'est pas remplacé et son modtime surtout pas modifié ! Ainsi, cela ne nécessite pas de recompiler tout ce qui en dépend ! Sinon, effectivement, on se rapproche grandement des en-têtes précompilés…

                • [^] # Re: Retourne à la raison!

                  Posté par . Évalué à 4.

                  on utilise des ORMs ? C'est bien, mais cela rajoute un léger surcoût (dans le cas où on sait s'en servir) à un gros surcout (dans le cas contraire) par rapport à des requêtes écrites directement.

                  Faut savoir qu'est ce que tu compare avec quoi. Bien des développeurs ne sont pas très grands connaisseurs des SGBD et ne font pas forcément des requêtes bien optimisées. À cela il faut ajouter le coup de la gestion de la donnée dans ton programme (la sérialisation et déserialisation dans une structure/un objet).

                  La question qui est intéressante c'est : est-ce que je saurais faire mieux que l'ORM ?

                  C'est un peu comme de dire qu'il faut acheter un reflex parce que le RAW c'est génial. Oui c'est génial quand tu sais correctement développer du RAW et que tu saura faire mieux que ce que fais l'appareil. Dans la pratique ce n'est pas le cas très souvent.

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

  • # CMake ?

    Posté par . Évalué à 6.

    J'aimerai bien mieux comprendre comment utiliser CMake. Si quelqu'un à une bonne source, je serais bien intéressé.

  • # Revenons à l'essentiel

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

    Je vois bien ce que tu fais devnewton ; sous couvert de trolls tu veux surtout nous montrer ton dernier jeu ;) Et bien j'ai testé et je dois dire que hormis une petit problème de recherche d'assets vite corrigé, le jeu est… waw ! C'est complètement différent de tout ce qu'on a pu voir jusqu'à maintenant. Bien que légèrement répétitif au début, on se prend vite au jeu et on se laisse entraîner par le rythme. C'est simple, sobre et efficace. À quand une version Apple Watch ?

Suivre le flux des commentaires

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