Retard(s) pour la prochaine version de C++

Posté par  . Modéré par Mouns.
Étiquettes : aucune
24
24
juil.
2009
Technologie
C'est maintenant officiel, la très attendue nouvelle version de C++, officieusement appelée C++0x s'appelle maintenant C++1x. Des difficultés importantes ont été rencontrées par le comité de normalisation concernant l'utilisation des concepts, une façon présentée comme plus sûre d'utiliser des templates. Il a été finalement été décidé de retirer les concepts du prochain standard.

La nouvelle mouture de C++, devrait être publiée en 2010 ou 2011 Les concepts, attendus par beaucoup de développeurs, devaient permettre, entre autres, de réduire l'importante verbosité des erreurs de compilation lors de l'utilisation de classes template (notamment les conteneurs de la bibliothèque standard C++). Auparavant, le compilateur devait remonter toute la couche d'appels dans l'implémentation du conteneur, qui devenait alors visible au développeur. Les concepts devaient alors permettre de lever l'erreur beaucoup plus tôt. Un exemple est donné sur le site de la branche «concepts» de C++ :

http://www.generic-programming.org/software/ConceptGCC/

Évidemment, les concepts, c'est beaucoup plus qu'un compilateur moins verbeux. Il s'agit aussi d'une garantie sur le type générique utilisé dans une classe template et les amateurs de programmation générique se frottaient déjà les mains.

Malheureusement, de sérieux problèmes se sont mis sur la route du comité de normalisation. Un problème technique, lié aux concepts implicites, pouvant gêner l'utilisateur, d'abord, et surtout le fait que les développements des principales implantations des concepts (notamment gcc) sont au point mort.

Plusieurs décisions étaient envisageables, comme attendre encore 5 ans avant d'avoir un nouveau standard, ou bien sortir les concepts tels quels (et prendre le risque qu'ils passent à la trappe, comme le mot clé "export" du C++98). Il a été finalement décidé de les retirer pour ne pas impacter les autres changements tant attendus.

C++1x est actuellement partiellement pris en charge par plusieurs compilateurs. Du côté du « core language », on peut suivre l'évolution de la prise en charge par gcc sur la page suivante :
http://gcc.gnu.org/projects/cxx0x.html

Les aventureux pourront tester les nouveautés en ajoutant l'option «-std=c++0x» à l'invocation du compilateur.

La Nemesis de gcc, Visual Studio, n'est pas en reste et propose elle aussi une prise en charge, probablement présentée dans le lien suivant (video silverlight que je n'ai pas pu lire) :
http://www.microsoft.com/france/vision/mstechdays09/Webcast.(...)
Chez intel, un début de prise en charge :
http://www.intel.com/software/products/compilers/docs/clin/m(...)

Au niveau de la prise en charge des nouveautés de la bibliothèque standard, (TR1) on peut noter les avancées de gcc ici :
http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch01.(...)

Il est tout à fait possible d'utiliser les classes de TR1 avec le standard C++ actuel en préfixant l'inclusion des headers par TR1. Les classes seront alors dans l'espace de nommage std::tr1. L'utilisation de l'option «-std=c++0x» permet de s'affranchir de ces formalités.

Dinkumware, fournisseur officiel de la bibliothèque standard C++ à la sauce visual, revendique quant à lui une prise en charge complète du TR1 :
http://www.dinkumware.com/tr1_compare.aspx

Les concepts mis à part, la prise en charge du nouveau standard par les principaux compilateurs est donc en bonne voie, ce qui est un atout majeur pour l'adoption de C++1x.

Aller plus loin

  • # Traduction de claim

    Posté par  . Évalué à 10.

    Dinkumware, [...] clame quant à lui une prise en charge complète du TR1.

    Il me semble que revendique est une meilleur traduction du mot anglais claim.
  • # Un standard kikoo-lol ou obfuscisant ?

    Posté par  . Évalué à 2.

    Quel est l'intérêt de sortir C++1x, puisque nous y perdons la seule nouveauté du langage vraiment intéressante ?

    Ca fera plaisir aux industriels, puisqu'ils pourront enfin se mettre à pisser du code du standard précédent.
    Ca fera plaisir aux noobs qui pourront mettre du "auto" partout, de la même manière qu'ils ne savent pas utiliser correctement un "const" actuellement.
    Ca va faire plaisir aux gourous qui aiment coder des générateurs de code à coup de templates.
    Ca va faire plaisir aux brainfuckers avec une syntaxe encore plus ambiguë.
    Ca va faire plaisir aux adorateurs de performance puisqu'ils pourront encore supprimer des copies inutiles en rendant leur code illisible.

    Et pour les développeurs ? Ceux qui doivent réaliser un produit qui fonctionne à peur près ? Ah ben pour eux, non. Emmerdez-vous avec des pages et des pages d'erreurs.
    Arriver à obtenir des messages d'erreur clairs ? Vous pouvez rêver !
    Arriver à débugger du code imbitable écrit par un faux gourou passé avant ? Ahah, on va rire avec les subtilités ajoutées !

    Pourquoi se faire encore chier avec un langage dans une impasse évolutive ? Il y a d'autres langages... non ? D ? Ada (qui certes ne permet pas de metaprog) ? Des vrais langages pensés pour être utilisés, et non pour permettre à des spécialistes de mépriser le commun des mortels pour leur ignorance, et se faire faire de gros chèques.

    Mais qu'attendons-nous pour faire grève dès qu'il faut toucher à cette bouse infâme ?!
    • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

      Posté par  . Évalué à 10.

      Bon, je comprends que certains soient très malheureux par cette décision, mais ce n'est pas une raison pour décrier les nouveautés du prochain standard.
      Déjà, l'inclusion de certaines classes est vitale, comme les unordered_xxx, qui n'avaient pas pu être incluses en 98 faute de temps.

      Ensuite, la plupart des nouveautés sont faites pour améliorer la lisibilité du code et la facilité de développement:
      le mot clé auto que tu décries tant va permettre d'éliminer une verbosité pénible, sachant que la plupart du temps, il va servir à changer une ligne comme :


      for(typename mon_conteneur_au_nom_bien_long::const_iterator it= v.begin();v!=v.end();++it)

      en


      for(auto it= v.begin();v!=v.end();++it)


      Donc, bien utilisé, il n'apporte aucune ambiguïté.

      Un autre exemple, la délégation de constructeurs, venue de langages comme Java, va permettre d'éviter énormément de redondances avec des listes d'initialisation énormes à maintenir.

      Dernier exemple : les lambda expressions, qui n'a jamais pesté de devoir définir une fonction complètement triviale, pour l'inclure dans un for_each() 300 lignes plus bas ? L'ajout de cette feature permettra d'autant d'augmenter la lisibilité du code.

      Alors, que le langage devienne plus complexe, peut-être, mais les améliorations vont quand même dans le sens d'une lisibilité plus grande, d'une écriture plus coulante et d'une maintenance moins coûteuse.
      • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

        Posté par  . Évalué à 3.

        Tu peux expliquer ce que tu entends par "délégation de constructeurs, venue de langages comme Java" ?
        • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

          Posté par  . Évalué à 9.

          Oui, en C++98, contrairement à Java, tu ne peux pas invoquer un constructeur depuis un constructeur (de la même classe) :
          Mettons que tu aies 3 attributs à initialiser dans ta classe, tu crées un constructeur qui prend 3 arguments et tu t'en sers pour initialiser.
          Jusqu'ici, aucune différence,

          Si tu veux créer un second constructeur par défaut en Java, tu peux très bien créer un constructeur qui va se contenter d'appeler le premier avec des arguments codés en dur, alors qu'en C++, tu vas devoir les initialiser les attributs à la main.

          En plus, mettons que du dois rajouter un attribut, et que tu mets à jour le premier constructeur, mais pas le second. Dans le premier cas, le compilo râle, alors que dans le second, ça devrait passer, et tu te retrouves avec un attribut mal initialisé. Le monde peut alors commencer à s'écrouler
          • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

            Posté par  . Évalué à 1.

            Le premier exemple n'est pas le mieux choisi au vu de la possibilité en C++ d'avoir des valeurs d'arguments par défaut, mais je comprends bien ton propos et ça m'a l'aire pas mal.

            Dommage tout de même pour les concepts…

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

    • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

      Posté par  . Évalué à 3.

      Message précédent mal noté car un peu péremptoire probablement...
      Pourtant sur le fond je rejoins 'saucisson' : C++ est une accumulation de règles complexes destinées à clarifier ou contourner les problèmes posés par les règles précédentes.
      J'avoue, j'ai arrêté le C++ après avoir lu "que seules les personnes en charge de la spécification du langage pouvaient connaître toutes ses arcanes" (en substance).
      Effectivement, peu de personnes dans le monde sont capables d'écrire du vrai C++ en comprenant TOUT ce qu'elles écrivent (il y a un piège à chaque point-virgule).
      Pour avoir relu du code générique écrit par un vrai "C++ guru", ben... j'ai parcouru, demandé moults explications, puis simplement commenté : "Très (trop ?) bon niveau de codage" : franchement, ce n'était pas maintenable par un mortel normal.

      Objectivement, je ne trolle pas, mais vous voyez un avenir à C++ pour les terriens ?
      • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

        Posté par  (site web personnel) . Évalué à 10.

        En même temps il ne faut pas se sentir obligé d'utiliser en permanence toutes les features du c++ (d'autant que comme tu le dis il y a déjà pas mal de pièges dans le c++ "traditionnel"). En je crois qu'aujourd'hui encore la majorité du code c++ pondu quotidiennement c'est plutot du c++ à papa bien tranquillou avec des classes, des fonctions virtuelles, de la stl mais pas (ou peu) de templates ou de surcharges de l'opérateur virgule. Les templates sont très utiles pour construire des briques de base (par ex la stl, boost, etc), mais au-delà ils deviennent moins préponderants.

        Faut juste arriver à passer le plus vite possible le court moment de délire qui se produit quand on comprend la puissance des templates et qu'on essaye de faire executer la moitié du programme par le compilateur :) (en sacrifiant des poulets pour qu'il inline le reste comme il faut)
      • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

        Posté par  . Évalué à 3.

        Je suis plutôt d'accord, c'est la raison pour laquelle je m'intéresse au langage D qui est un C++ mieux fait, mais il a ses propres problèmes:
        -GC (Boehm-Demers-Weiser) primitif comparé à celui de Java (par exemple)
        -bisbilles entre librairie 'standard' incompatibles (Phobos vs Tango), mais ce point la est en cours de résolution.
        -pas de compilateur 100% libre (GDC semble mort et la releve pas encore prete).

        Bref le langage idéal n'existe pas..
        • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

          Posté par  (site web personnel) . Évalué à 2.

          Tu n'aimes pas Lisaac ? /o\

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

          • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

            Posté par  . Évalué à 5.

            Non, je n'aime pas Lisaac: je trouve sa syntaxe mal fichu, ce qui pour moi est rhedibitoire..
            • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

              Posté par  (site web personnel) . Évalué à 2.

              arf. C'est pourtant la plus simple et la régulière qui soit.

              Il existe aussi une lib wrapper pour que cela ressemble plus au C mais bon...

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

              • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

                Posté par  . Évalué à 4.

                >arf. C'est pourtant la plus simple et la régulière qui soit.

                Bah, remplacer 'a + b' par add(a,b) par exemple rendrait un langage plus 'regulier' et plus 'simple' mais *moins* lisible pour moi.
                Comme quoi..

                >Il existe aussi une lib wrapper pour que cela ressemble plus au C mais bon...

                As-tu un lien?
                Note que si c'est juste un generateur externe cela n'a pas beaucoup d'interet car ce qui compte c'est la syntaxe 'commune' utilisee par tous.
                Si c'est la future syntaxe du language c'est interressant, autrement c'est comme ceux qui faisait du Pascal en C en utilisant le preprocesseur: bof.
                • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

                  Posté par  (site web personnel) . Évalué à 2.

                  De mémoire, c'est un wrapper des fonctions de base (BAD_HABITS, ou truc du genre) (tout est prototype dans lisaac même les boucles for et les clauses if, d'où la syntaxe d'ailleurs). Lisaac n'utilise pas de préprocesseurs.

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

                  • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

                    Posté par  (site web personnel) . Évalué à 1.

                    La version beta est sur le git depuis tout à l'heure, et il l'a renommé I_DONT_KNOW_PROTOTYPING ;-)

                    - if cond:BOOLEAN then true_block:BLOCK :BOOLEAN <-
                    (
                    cond.if true_block
                    );

                    - while cond:BLOCK do body:BLOCK <-
                    (
                    cond.while_do body;
                    );


                    Tu peux en inventer des centaines :-)

                    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                    • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

                      Posté par  . Évalué à 3.

                      > Tu peux en inventer des centaines :-)

                      Cela ne resout PAS le chmilblick..
                      Le probleme numero 1 est la communication entre developpeurs, projets.

                      Avec un language minimaliste mais souple grace aux macros, chacun souffre et invente ses propre macros plus ou moins bonne --> mauvaise communication.

                      Pour moi, un bon langage offre donc une syntaxe 'officielle' agreable a utiliser pour les developpeurs: par exemple Scala.
                      • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

                        Posté par  (site web personnel) . Évalué à 1.

                        C'est pas des macro :)

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

                      • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

                        Posté par  (site web personnel) . Évalué à 3.

                        def qsort(list: List[Int]): List[Int] =
                        list match {
                        case Nil => Nil
                        case pivot::tail => qsort(for(i <- tail if i < pivot) yield i) ::: pivot :: qsort(for(i <- tail if i >= pivot) yield i)
                        }


                        C'est lisible ça ?

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

                      • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

                        Posté par  (site web personnel) . Évalué à 2.

                        1. Ce ne sont pas des macros, c'est de la librairie standard (cet objet est le père de OBJECT). Je disais juste qu'on peut en inventer des centaines "théoriquement", de par le type Block.

                        Tu modifie la librairie standard C++/Java/whatever toi ?
                        Moi pas, en tout cas.
                        Donc la syntaxe est "officielle".

                        2. La syntaxe, tu n'aimes pas c'est ton droit, et je me fais le porte parole de son concepteur :
                        a) A été mûrement réfléchi par quelqu'un qui a plusieurs centaines de milliers de lignes de code à son actif sur des projets volumineux
                        b) A intégré assez profondément une réflexion sur le génie logiciel, en particulier celle de Meyer et Eiffel, qu'il cite souvent.

                        Si tu respecte la lib standard, ce qui est la règle et très très rarement l'exception dans un projet, personne ne peut inventer de macro.
                        On peut certes inventer des structures de contrôles comme en Ruby, mais uniquement dans les lib du projets.

                        En passant, en C++, des macro on peut en faire à foison

                        PS : j'ai rien compris à l'exemple de code fourni en Scala par Nicolas plus bas, et pourtant je me suis intéressé à ce langage, qui me plait en tant que fan de Caml.

                        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

        Posté par  . Évalué à 4.

        Moi j'aime bien le C++
        pour moi il a 2 gros défauts, les templates plus ou moin bien gérés selon les compilos, et les itérateurs qui sont "lourds" à écrire
        Un autre défaut à mon goût, c'est la stl plutot vieillissante, pour moi c++ doit s'accompagner d'une lib type qt ou boost
        • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

          Posté par  . Évalué à 4.

          Pour le coup des templates, c'est vrai que c'est un peu chiant si tu veux faire du multi-arch et que tu as des vieilles archis exotiques (encore que, les compilateurs qui se retament sur des templates aujourd'hui, il en reste plus beaucoup et les grands compilos du marche ont tous un support plus que correct). Evidemment si t'es coince avec une vieille version d'un compilo proprio qui ice sur ton code et que tu peux pas mettre a jour, ca te fait une belle jambe.

          Les iterateurs, avec auto ca simplifie pas mal (c'est juste du sucre syntaxique de toute facon).

          Par contre pour la stl vieillissante, je suis pas trop d'accord avec toi. TR1 (deja dispo un peu partout) a apporte quelques nouveautes interessantes et il y a encore pas mal de trucs sympas a venir. Et puis boost a la base, c'est un peu le reservoir a idees pour le standard. La plupart des nouveautes dans la stl de C++1x ont mature dans boost pendant des annees. C'est pas mal comme systeme je trouve, puisque tu met dans le standard quelque chose dont tu es a peu pres sur de l'utilite et des chances d'implementation dans les compilos/stls (export, cough cough!).

          Pour QT, je t'avoues que j'ai pas trop d'experience dessus. Ils ont separe la partie GUI et classes de base il y a un petit moment, mais je sais pas si il y a beaucoup de projets qui les utilisent sans utiliser toute la couche GUI. Si tu as besoin d'une classe specifique que tu ne peux pas trouver ailleurs je vois bien l'interet de te baser sur QT, mais sinon pourquoi ne pas utiliser la stl de base direct (ca fait une dependance en moins, c'est toujours ca de gagne)?
          • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

            Posté par  . Évalué à 3.

            QT c'est un lecteur de vidéo.
            Qt, c'est la boite à outils de nokia.

            J'ai fait l'erreur pas mal de fois, donc je préfère prévenir maintenant.

            Envoyé depuis mon lapin.

          • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

            Posté par  . Évalué à 4.

            Pour qt l'interet rapport à la stl, c'est surtout son implémentation du pattern observer, et ensuite un ensemble de classes que je trouve cohérentes et bien faites, des classes "en plus (réseau, base de donnée, multimedia...), ou plus complètes, certains patterns implémentés, la "suppression" des itérateurs (en fait des macros pour en cacher la syntaxe), introspection, etc... Ensuite évidemment, ça depend du projet, si je peux utiliser qt ou pas.

            Bon ensuite j'aime beaucoup qt donc j'en fait beaucoup de pub, (et en toute honnêteté, je n'ai pas réessayer boost depuis quelques années) mais il y a quand même des défauts: preproc obligatoire, pas de multihéritage ou de template héritant de QObject (enfin si, mais par bidouille interposé)
      • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

        Posté par  . Évalué à 1.

        Parce que c'est simple de comprendre du java ? Le principe c'est la vm fait bien les choses de toute façon c'est trop complexe pour s'y pencher. C'est une plaie d'avoir des destructeurs à faire en java.

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

        • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

          Posté par  . Évalué à 1.

          La VM est très complexe, certes, mais pas le langage en lui-même : c'est ça qui compte non ?
          Concernant les destructeurs, ils n'ont plus lieu d'être si c'est pour libérer la mémoire. Pour les autres ressources (fichiers, etc.), ben vi c'est au programmeur de faire gaffe. Personnellement je n'ai jamais senti le besoin d'un destructeur, ni même vu de destructeurs dans du code java.
          Aurais-tu un exemple réaliste ?
    • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

      Posté par  . Évalué à 1.

      un peu aigri non?

      Pour coder en C++ depuis quelques années déjà, et dans plusieurs boites différentes, je n'ai jamais eu de soucis à comprendre un morceau de code c++, à la rigueur, un algorithme original pour faire un min sur 10 lignes, mais rien de transcendantal.

      Par contre j'utilise les template (j'ai horreur du copier coller) et lorsque c'est pertinent la redéfinition d'opérateur (en général [] ou (), mais parfois + ou - )

      le 'type' auto va me simplifier la vie, sans changer fondamentalement ma façon de coder

      for ( std::map< int, shared_ptr< PlonkBink > >::const_iterator it = palanque_.begin() ; ...

      va considérablement être simplifié

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

    • [^] # Re: Un standard kikoo-lol ou obfuscisant ?

      Posté par  (site web personnel) . Évalué à 3.

      La seule nouveauté intéressante ? Les concepts ne sont pas vraiment le truc qui servirait à tout le monde.

      On ne les aura pas ? Pas grave, STLfilt suffira à 99% des développeurs C++. Le SFINAE servira au 1% (et encore) qui fait de la méta-prog.

      En revanche, les ajouts à la bibliothèque standard, l'arrivée des threads et des quelques patterns/facilités qui tournent autour, et des sucres syntaxiques (nullptr, for, >sans espace>, ...) serviront à beaucoup.

      Quant à rvalue-references vs COW/expression templates, je me demande bien lequel retourne le plus de l'obfuscation ... Personnellement, j'ai choisi mon camp.

      Plus les lambda qui rendront enfin les algorithmes utilisables, au détail que comme en Perl il faudra apprendre à se restreindre.

      Quant à la critique "pensé pour être utilisé", c'est justement pour cela que les concepts ont été rejetés : il n'y a aujourd'hui aucune expérience validée de leur utilisation (i.e. un prototype fonctionnel). Ils ne voulaient pas re-commettre l'erreur déjà faite avec les spécifications d'exception ou export.
  • # Déçu

    Posté par  . Évalué à 9.

    Franchement, c'est un coup dur!
    Je programme en C++ sur 90% de mon code... et 10% de C.
    Les templates, et particulièrement celles de la Stl, Boost ou gtkmm et consorts génèrent des erreurs difficiles à diagnostiquer.
    Avec mon expérience, maintenant je décrypte ces erreurs très vite, mais il m'a fallu accumuler une grosse expérience pour acquérir des automatismes à ce niveau là.
    Du coup, quand il s'agit d'embaucher un développeur c++, prendre des débutants est un choix risqué, car je sais que je vais devoir passer énormément de temps à l'encadrer et lui expliquer comment trouver les sources d'erreurs... la productivité s'en retrouve bien vite plombée.
    J'attendais donc les concepts avec une grande impatience. même si je suis ravi qu'il y ait l'inclusion du mot clef "auto" et les fonctions "lambda", c'est une fonctionnalité indéniablement utile pour le débutant qui vient de sauter.
    ça me laisse un peu perplexe, et encore plus le fait que le standard se voit repoussé.
    Le comité de standardisation semble empêtré dans des débats interminable. Ils avancent à une vitesse d'escargot! Les techno c++ commencent à accumuler un retard considérable.
    Attendre encore 5 à 7 ans pour voir l'inclusion des concepts dans le c++ me semble être un avis de décès pour ce langage.

    J'attends encore un remplaçant convainquant, car D ne m'a pas encore séduit... même s'il a beaucoup d'atouts, il lui manque aussi les concepts et il y a encore trop peu de bibliothèques disponible à mon goût.

    Pour faire du code dépendant de la plateforme GLib, j'envisage d'approfondir mon étude de Vala, même s'il n'y a pas de templates mais plutôt des Generics comme en Java. Cependant ce langage est encore trop jeune pour passer en production de mon point de vue.
    • [^] # Re: Déçu

      Posté par  . Évalué à 5.

      C'est vrai qu'il faudrait un langage efficace, orienté objet, qui prendrait en charge les lambda-expressions et dont le système de typage, fort, permettrait de spécifier directement des conteneurs génériques et les algorithmes associés (itération, tri…). Voire même, tant qu'à faire, les regrouper dans des modules eux-mêmes manipulables par des foncteurs.

      Bon, je te laisse, j'ai du code Objective Caml à écrire.
      • [^] # Re: Déçu

        Posté par  . Évalué à 5.

        Avec ocaml tu peux certainement faire des conteneurs génériques, mais certainement pas du meta programming et encore moins de template meta programming et donc pas de concepts non plus... c'est indéniablement moins puissant que c++ ou D de ce point de vue...
        Ocaml répond à certains besoins, mais j'avoue que pondre une interface graphique avec du langage fonctionnel, même s'il supporte des paradigmes impératif est une vrai plaie...
        Par contre pour pondre des algorithmes, un compilateur etc... j'avoue qu'ocaml est au dessus du lot!
        • [^] # Re: Déçu

          Posté par  . Évalué à 2.

          Bien sûr, ce n'est pas comme si MetaOCaml existait. Oups.

          Après lecture des pages de WP données en lien, je ne vois pas ce qu'apportent les concepts que n'a pas OCaml. En résumé, de ce que j'ai compris, un concept permet de vérifier statiquement des contraintes sur une classe, en particulier sur la présence de méthodes avec une signature donnée. Ça ressemble fort à une tentative d'embarquer un langage de modules comme en ont les langages ML, dont Caml (c'est d'ailleurs très pratique).

          Quant à ta remarque sur l'interface graphique, j'en écris une en ce moment en gtk, et je ne comprends vraiment pas ce que tu veux dire. J'ai donné en C, je donne actuellement en Caml, et il n'y a pas photo. En C, pour créer la moindre fenêtre avec quelques malheureux contrôles, il faut se farcir des lignes et des lignes qui vont d'une marge à l'autre. En Caml, c'est beaucoup plus concis et donc plus pratique.
          • [^] # Re: Déçu

            Posté par  . Évalué à 8.

            MetaOcaml n'est plus maintenu depuis 2006 ... ça donne pas vraiment envie de l'utiliser.
            Mais je n'ai rien contre Ocaml, ce n'est juste pas un remplaçant à c++ à mes yeux.
            Quand à ta comparaison Ocaml vs C , on peut dire la même chose C++ vs C
            Et je trouve qu"écrire des interface graphiques, des serveurs asynchrones, faire de la programmation parallèle etc, ce n'est pas le fort d'ocaml si on le compare à C++
            Ce n'est donc pas une attaque, mais pour le code de mes productions, je ne mettrais jamais de Ocaml. Mais ce n'est que mon point de vue, et peut être ai-je tord.
        • [^] # Re: Déçu

          Posté par  . Évalué à 3.

          La bonne manière de faire des interfaces graphiques, de toutes façons, c'est de coupler un langage déclaratif à un solver qui va automatiquement déduire les widgets et leur taille et positionnement optimaux.
          Un exemple étant Adam & Eve d'Adobe. On pourrait directement écrire en déclaratif en C++ en utilisant un DSEL (et d'ailleurs, certains ont implémenté une version de Eve sous cette forme).

          GTK+, Qt, et consorts, c'est bien trop bas niveau.
          • [^] # Re: Déçu

            Posté par  . Évalué à 2.

            Il y a un langage déclaratif pour Qt si je ne m'abuse... mais je crois qu'il ne sortira officiellement des BACS que pour la 4.6
            Sinon, Il y a Glade pour Gtk/Gtkmm et le nouveau loadeur GtkBuilder... mais il s'agit plus de RAD que de langage déclaratif ici.
          • [^] # Re: Déçu

            Posté par  (site web personnel) . Évalué à 2.

            Et Qt Designer, c'est pas assez déclaratif ?
            • [^] # Re: Déçu

              Posté par  . Évalué à 1.

              Ça décrit la présentation, pas le type de données. Ce n'est pas vraiment de ça que je parle.
              XUL, à la limite, est bien plus proche.
            • [^] # Re: Déçu

              Posté par  . Évalué à 4.

              Et Qt Designer, c'est pas assez déclaratif ?

              Non, ça n'as rien a voir... QtDesigner tout comme Glade, c'est plutôt ce qu'on appelle du RAD (Rapid Application Developpement) avec un système de déclaration des widgets.

              Pour voir ce qu'est du Déclarative UI voici un lien vers le projet de Qt :
              http://labs.trolltech.com/blogs/category/labs/graphics/kinet(...)
        • [^] # Re: Déçu

          Posté par  (site web personnel) . Évalué à 1.

          J'ai essayé de comprendre ces fameux concepts en c++ : en gros une méthode peut travailler avec n'importe quel type compatible, mais en plus, on peut spécifier des contraintes.

          En Lisaac, on a essayé de mettre en place une évol permettant de faire tout ce qu'on peut faire avec les templates, sachant que le langage possède à la base la généricité au niveau de l'objet.
          ARRAY(E)
          La nouvelle fonctionalité de la prochaine version du compilo, consiste à permettre de définir des générique au niveau de la méthode.
          Je l'ai voulu, car je voulais pouvoir faire ça, dans l'objet ARRAY(E) (ie. tableau du type générique E )

          - intersect other : ARRAY(V) with comparator : {E,V;BOOLEAN} <-
          (
          ...
          );

          Où 'other' est donc une collection contenant un autre type, et 'comparator' la primitive pour l'intersection, ie. fonction prenant E et V en paramètre et renvoyant TRUE si les paramètres sont considérés comme "égaux".

          En situation, cela s'utilise comme suit

          + a : ARRAY(FOO);
          + b : ARRAY(BAR);
          + c : ARRAY(FOO);

          ... a et b sont remplis de diverses choses...

          c := a.intersect b with { v1 : FOO ; v2 : BAR ; v1.msg1 = v2.msg2 };

          Si je comprend bien (ou peut être que partiellement ?), il s'agirai de pouvoir définir des contraintes sur V ?
          En Lisaac, j'imaginerai comme suit, avec la sémantique des contrats disponibles dans ce langage :

          - intersect other : ARRAY(V) with comparator {E,V;BOOLEAN} <-
          [ -? { + v : V ; v := V.create; v != NULL } ]
          (
          ...
          );

          Façon moins déclarative de définir que ces exemples http://blog.emmanueldeloget.com/index.php/2008/08/27/136-le-(...) de vérifier qu'on ai bien un constructeur pour V.

          Mais en fait, lorsque je lis cela : http://www.devx.com/SpecialReports/Article/38864/0/page/2 , je me rend compte qu'il s'agit simplement de vérifier l'existance de méthodes.
          Pour vous éviter à décrypter, je résume :
          Si je fais :

          template<typename T>
          const T& min(const T& x, const T& y) {
          return x < y? x : y;
          }

          et le concept associé :

          concept LessThanComparable<typename T> {
          bool operator<(const T& x, const T& y);
          }


          je dois donc préciser au compilateur avec un concept que T doit avoir un opérateur '<'?
          Le compilateur n'est pas capable de le faire tout seul à la compilation ? C'est étonnant !

          En Lisaac, (compilation globale oblige), tout est vérifié par le compilateur : si le compilateur dit OK, alors il n'y aura pas de problèmes.

          Bref, j'ai parfois du mal à comprendre ce que ces features apportent de plus ?

          En tout cas ça m'intéresse si ça peut nous permettre de l'implémenter, en mieux ;-)

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: Déçu

            Posté par  . Évalué à 8.

            je dois donc préciser au compilateur avec un concept que T doit avoir un opérateur '<'?
            Le compilateur n'est pas capable de le faire tout seul à la compilation ? C'est étonnant !


            Il est tout à fait capable de le fait tout seul, l'intérêt des concepts c'est de rendre les messages d'erreur plus explicites, notamment lorsque plusieurs types templates sont imbriqués.

            Par exemple avec un code comme celui-ci :

            class Key {};

            int main()
            {
                std::map<Key, int> myMap;
                myMap[Key()] = 5;
            }


            Actuellement le compilateur te sort :
            error: no match for call to '(std::map<Key,int, std::less, std::allocator<std::pair<const Key, int> > >) (Key)'

            Alors qu'avec les concepts il pourrait sortir:
            error: Type Key doesn't respect concept LessThanComparable

            Étienne
      • [^] # Re: Déçu

        Posté par  . Évalué à 7.

        Le typage de OCaml n'est pas plus expressif ni plus sûr.
        Il y a généralement de meilleurs messages d'erreur, mais c'est facile quand on a pas de surcharge/spécialisation (nécessaire à la spécialisation des algorithmes et à la méta-programmation) et que la signature d'un symbole contient nécessairement les types les plus restrictifs qui permettent l'exécution de son corps.

        En C++, la résolution de surcharge ne prend en compte que la déclaration, pas la définition. C'est parce que généralement la déclaration est trop permissive (mais ça ne tient qu'aux gens de changer ça) que l'on obtient des messages d'erreurs "illisibles" quand une erreur survient, plus tard, dans la définition.

        Néanmoins, rien n'empêche de mettre l'intégralité du corps de la fonction dans la signature, d'une manière ou d'une autre, ce qui permettra de rendre le symbole visible uniquement si les types d'entrées satisfont l'intégralité des expressions.
        Ce serait encore plus pratique si on avait des lambdas polymorphiques, mais je ne suis pas certain qu'elles arrivent dans C++0x.

        Pour ce qui est des modules, c'est facile en OCaml quand on implémente la généricité simplement avec un seul code de fonction qui prend en fait un pointeur générique. Quand on a un langage efficace comme C++, où tout objet n'est pas soit un entier soit un pointeur garbage collecté, et que donc par conséquent on doit générer une version de chaque fonction non monomorphique pour chaque type qui l'utilise, faire un système de modules pose certains problèmes car il faudrait en fait faire une seconde passe de compilation à l'édition de liens, ce qui n'est pas vraiment le modèle traditionnel.

        OCaml, ce n'est pas si terriblement efficace, et ce par conception. Pour écrire du code efficace, (et ça concerne en fait tous les langages garbage collectés), bien souvent le seul moyen c'est d'allouer un gros Bigarray et de le manipuler comme si c'était de la mémoire. On se retrouve alors encore plus bas niveau que du C.
        • [^] # Re: Déçu

          Posté par  . Évalué à 4.

          Tu exagères.. Un gars a fait des graphes montrant la taille des programmes et leur efficacité (a part du fameux benchmark multi-language de Debian):
          http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of.html

          OCaml est *très* bien placé..

          Ceci dit personnellement OCaml ne m'intéresse pas à cause de son accent sur le coté fonctionnel qui me rebute, je suis plus intéressé par D ou Scala.

          • [^] # Re: Déçu

            Posté par  (site web personnel) . Évalué à 2.

            L'étude est super intéressante :) Lisaac n'est pas mal placé non plus :) (le shoutout est très orienté algo impératif, il y a très peu d'algo purement objet ou avec des threads)

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

    • [^] # Et pendant ce temps

      Posté par  (site web personnel) . Évalué à 2.

      le fortran avance... Avec un peu de retard, Fortran 2008 devrait sortir en 2010.

      La proposition à l'état actuelle

      ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1775.pdf
  • # Les concepts, c'est du sucre

    Posté par  . Évalué à 1.

    Il faut arrêter de dramatiser avec les concepts. Oui, c'est pratique et utile, mais ce n'est que du sucre.
    La même chose se fait parfaitement avec SFINAE, encore plus maintenant que le flou sur les expressions dans la signature a été levé.

    La seule chose, c'est que l'usage généralisé de SFINAE n'est pas démocratisé.
    • [^] # Re: Les concepts, c'est du sucre

      Posté par  . Évalué à 1.

      Pour ceux qui ne connaissent pas, le sucre syntaxique est en quelque sorte une notation raccourcie. Ça ne rajoute rien de nouveau au langage noyau (du C++).

      Que voulez-vous dans votre café ? Un peu de sucre syntaxique svp.
    • [^] # Re: Les concepts, c'est du sucre

      Posté par  . Évalué à 2.

      Oui m'enfin à ce point là autant dire que le C++ n'est que du sucre syntaxique par rapport au C (ex : GTK+ est codé en C, mais sur paradigme objet)…

      SFINAE + boost::enable_if, c'est un peu la solution de rafistolage pour arriver à ses fins. On arrive pas à une lisibilité de code exemplaire, rien qu'avec les paramètres fantômes :


      //overload for list nodes
      template<class SyntaxNodeT>
      SyntaxNodeT
      convert_node
      (
      const tree_node_t& node,
      typename boost::enable_if<syntax_nodes::utility::is_list_node>::type* = 0
      )
      {
      return convert_list_node(node);
      }

      //overload for optional nodes
      template<class SyntaxNodeT>
      SyntaxNodeT
      convert_node
      (
      const tree_node_t& node,
      typename boost::enable_if<syntax_nodes::utility::is_optional_node>::type* = 0
      )
      {
      return convert_optional_node(node);
      }

      //etc...


      Je préfèrerais écrire ça :

      //overload for list nodes
      template<ListNode SyntaxNodeT>
      SyntaxNodeT
      convert_node(const tree_node_t& node)
      {
      return convert_list_node(node);
      }

      //overload for optional nodes
      template<OptionalNode SyntaxNodeT>
      SyntaxNodeT
      convert_node(const tree_node_t& node)
      {
      return convert_optional_node(node);
      }

      //etc...


      Et encore, je vous montre pas la tronche des type traits qu'on se serait bien épargné de taper.
    • [^] # Re: Les concepts, c'est du sucre

      Posté par  . Évalué à 1.

      Tiens, allez, si, je vous montre. C'est tellement cradingue et inexpressif que ça vaut le coup d'être vu :

      /*
      * Utility types
      */
      typedef char yes_type;

      struct no_type
      {
      char padding[8];
      };



      /*
      * list_node type trait
      */
      namespace list_node_check
      {
      template<class T>
      static
      yes_type
      check_sig(typename T::item*);

      template<class T>
      static
      no_type
      check_sig(...);
      }

      template<class T>
      struct is_list_node
      {
      static const bool value = sizeof(list_node_check::check_sig(0)) == sizeof(yes_type);
      };



      /*
      * optional_node type trait
      */
      template<class T>
      struct is_optional_node
      {
      static const bool value = false;
      };

      template<class T>
      struct is_optional_node<syntax_nodes::optional_node>
      {
      static const bool value = true;
      };


      Un exemple d'intuitivité.

      Et encore, je suis sûr qu'on peut trouver des alternatives bien pires à ce qu'auraient proprement permis les concepts.
  • # Commentaire de Herb Sutter

    Posté par  . Évalué à 8.

    Herb Sutter est l'un des guru du C++, auteur de plusieurs livres de référence et il faut partie du comité ISO. Il a fait une petite analyse à la suite de la suppression des concepts : http://herbsutter.wordpress.com/2009/07/21/trip-report/

    Sous forme de questions/réponses, il explique :
    - Que la suppression des concepts s'est fait sur des décisions techniques et pas politiques
    - Que ça ne devrait pas prendre trop de temps de supprimer tout ce qui concerne les concepts du brouillon de la spec
    - Que ce n'était pas le point le plus important de C++0x
    - Que ça n'a qu'une incidence modérée sur l'expressivité du langage
    - Que les templates du C++, même sans concepts, restent très en avance en terme de généricité par rapport à ce qui est fait dans d'autres langage (il prend comme comparaison Ada, Java et .Net), il en a d'ailleurs fait personnellement l'expérience lors du développement de STL.NET
  • # C++ concepts: le festival off

    Posté par  . Évalué à 2.

    intéressant billet résumant le difficile parcours des concepts dans C++0x...

    http://cpp-next.com/archive/2009/08/what-happened-in-frankfu(...)

Suivre le flux des commentaires

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