Sortie de GCC 4.3

Posté par  (site web personnel) . Modéré par rootix.
Étiquettes :
0
10
mar.
2008
GNU
La nouvelle version 4.3 de GCC (GNU Compiler Collection) vient de sortir.
Cette version du compilateur du projet GNU, initié par Richard Stallman, est particulièrement importante et a été testée depuis des mois de façon intensive par les distributions car elle sera le compilateur utilisé par Fedora 9, par OpenSuse 11.0 et par Debian Lenny - ce message détaillé donne une bonne idée du travail ayant lieu actuellement chez Debian pour pouvoir utiliser GCC 4.3 dans la future version stable de la distribution.

Ci-dessous, les nouveautés concernant GCC, gfortran, gcj et les optimisations mises en oeuvre.
  • GCC 4.3 utilise (et donc dépend de) la bibliothèque GMPLib (GNU Multiple Precision Arithmetic Library) et la bibliothèque de calculs flottants MPFR afin d'évaluer et de remplacer, lors de la compilation, les appels à des fonctions mathématiques ayant des arguments constants par leurs résultats. Ainsi, quelle que soit la précision en virgule flottante de la plate-forme matérielle faisant tourner GCC, on peut avoir des résultats uniformes. Un article du site Interstice explique simplement quel est l'utilité du projet MPFR (projet français soutenu par l'INRIA) et propose même une petite applet ludique pour faire des calculs avec une grande précision.
  • La plupart du travail du compilateur se fait quand le code source a été transformé en une représentation intermédiaire nommée le Register Transfer Language. Dans cette étape RTL diverses optimisations se déroulent successivement. GCC 4.3 remplace plusieurs de ces passes d'optimisations par une nouvelle passe unifiée de "forward propagation" et il en résulte une plus grande vitesse de compilation ainsi qu'une amélioration du code généré.
  • Les optimisations interprocédurales, qui ne s'intéressent pas à des lignes isolées mais à des grands blocs de code, ont été réorganisées pour utiliser au mieux la forme SSA. Cela permet à l'analyse interprocédurale d'être moins coûteuse en temps et plus précise mais cela ouvre surtout la porte à l'inclusion de beaucoup d'améliorations au dessus de cette infrastructure réorganisée. En particulier l'inlining (c'est à dire le remplacement d'un appel à une fonction par une copie de la fonction elle-même) va être optimisé et les choix fait par le compilateur seront plus judicieux pour éviter que l'inlining ne consomme trop de mémoire.
  • Une nouvelle option (-frecord-gcc-switches) permet d'inclure directement dans le binaire généré par GCC la liste des options ayant été utilisées pour compiler le source. Cette information est stockée sous forme de texte ASCII dans le binaire en sortie.
  • Le futur standard ISO C++0x débarque déjà dans GCC. La version 4.3 est la première à incorporer (avec l'option -std=c++0x) un support partiel de cette nouvelle et ambitieuse version de C++. L'état d'avancement du projet peut être suivi sur cette page et une présentation en français du support expérimental de C++0x est disponible ici.
    Pour ceux qui veulent dès maintenant se pencher sur les problèmes de compatibilité, le projet GCC a pensé à vous. Il est possible d'utiliser l'option -Wc++0x-compat pour générer des warnings sur un segment de code qui serait correct en ISO C++ 1998 et qui serait incorrect dans le futur C++0x.
  • Le compilateur Java utilisé (GCJ) se base désormais sur le compilateur d'Eclipse (Ecj) ce qui apporte instantanément le support de toutes les nouveautés de Java 1.5. Cet import du code du projet Eclipse a été rendu possible par la GPLv3 qui est compatible avec la licence Eclipse.
    Tom Tromey, l'auteur du projet gcjx qui devait initialement apporter le support de Java 1.5 à GCC, explique dans ce mail pourquoi l'import d'Ecj est finalement une meilleure solution. Il est assez remarquable de constater qu'un développeur accepte de jeter aux orties son travail pour privilégier la réutilisation du code d'un autre projet. Comme Tom l'écrit: "sharing code is preferable to working in isolation".
  • Le compilateur gfortran améliore encore sa conformité à la norme Fortran 95 et continue d'incorporer graduellement les nouveautés de la norme Fortran 2003. Cette dernière introduit notamment la programmation orientée objet au coeur du vénérable langage Fortran et permet également une interopérabilité avec le C via des bindings. Ce mail récapitulatif fait le point sur le travail des développeurs GCC sur l'année 2007 en ce qui concerne le Fortran.
  • Afin de "faire le ménage" dans le code et de se conformer autant que possible aux standards en vigueur (ISO C99 par exemple), le compilateur GCC 4.3 est devenu encore plus strict sur la syntaxe du code source. Une page spéciale est consacrée aux diverses adaptations qui pourraient être nécessaires si votre code ne respecte pas les standards. Pour les paresseux il existe l'option -fpermissive qui permet de convertir les nouvelles erreurs en simples warnings...mais c'est évidemment une solution temporaire et il est préférable de nettoyer son code.
    À noter que cette sévérité renforcé de GCC 4.3 a déclenché un début de polémique sur la liste de diffusion du noyau Linux. Aurélien Jarno, un développeur Debian, a posté un message démontrant que Linux ne respectait pas l'interface binaire des processeurs x86/x86-64. Le nouveau fonctionnement de GCC 4.3 met en évidence ce non-respect et cela peut provoquer des bugs alors que les versions précédentes étaient plus tolérantes. Étant donné que Linux a toujours fonctionné avec cette particularité, ainsi d'ailleurs que NetBSD, OpenBSD et FreeBSD, plusieurs personnes ont accusé les développeurs de GCC d'être trop stricts et ont demandé à ce que l'ancien comportement tolérant soit rétabli. La controverse n'est pas terminée mais il est probable qu'une option permettant de contourner le problème de l'ABI x86/x86-64 sera ajoutée à brève échéance.
  • Toujours dans cette optique d'améliorer la propreté du code les fichiers d'en-têtes (headers) de la bibliothèque standard du langage C++ (la libstdc++) ont été nettoyés.
    Plutôt que la solution inefficace et lente d'inclusion générale qui prévalait jusqu'à maintenant (voir cette entrée Bugzilla), un examen précis a eu lieu afin de restreindre au minimum ces headers et ainsi augmenter la vitesse de compilation. Auparavant l'inclusion d'un fichier d'en-tête provoquait l'inclusion en cascade d'une multitude d'autres headers même si ces inclusions indirectes n'étaient pas nécessaires à la compilation. Avec GCC 4.3 il faudra mettre dans son #include exactement ce qui est nécessaire pour son programme et les gens qui comptaient sur les inclusions indirectes vont donc devoir modifier leur source (voir le paragraphe "Header dependency cleanup" de cette page). Outre le gain en vitesse évident généré par cette solution on peut penser que le fait de n'intégrer que ce qui est strictement indispensable ne peut être que bénéfique pour la propreté du code.
  • En ce qui concerne les nouveautés spécifiques aux plate-formes on peut noter l'apparition d'options qui optimisent le code spécifiquement pour les processeurs Intel Core 2 (-mtune=core2 et -march=core2) ou aussi les options activant le support des extensions multimédia SSE3 et SSE4.
    GCC 4.3 peut maintenant générer du code ciblant les SPU (Synergistic Processor Unit) du processeur Cell ou du code ciblant les ARMv7. Les gros mainframes d'IBM comme le System z9 et son unité de calcul décimal sont également supportés.
  • Enfin une amélioration de la documentation (qui pourra sembler mineure à ceux qui n'ont jamais jeté un oeil sur le monstrueux manuel gcc) permet de filtrer l'aide en passant un ou plusieurs arguments. Ainsi un --help=warnings ne présentera que l'aide relative aux warnings.

Pour la suite...
Après la sortie en mai dernier de la précédente version 4.2 de GCC, s'est déroulé en juillet le sommet annuel 2007 des développeurs. Les lecteurs intéressés pourront lire le gros fichier pdf (162 pages) compilant l'ensemble des articles techniques ainsi que ce fil sur la mailing-list GCC pour faire le point sur les nouveautés envisagées pour le futur GCC 4.4.

Aller plus loin

  • # Fortran

    Posté par  . Évalué à 7.

    "I don’t know what the language of the year 2000 will look like, but it will be called Fortran", Tony Hoare, 1982.

    • [^] # Re: Fortran

      Posté par  . Évalué à 0.

      ouai, enfin quand on regarde les performances de g95 sur le shootout http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)
      ça fait un peut peur .
      de plus j'ai l'impression qu'il n'est pas trés utilisé dans le milieu scientifique justement à cause de ses performances ( ce qui est un comble pour du Fortran).

      • [^] # Re: Fortran

        Posté par  . Évalué à 10.

        g95 n'est pas gfortran. En fait gfortran est un fork de g95. Tu parles de perfs mais en etant totalement honnete gcc n'est pas vraiment fait pour ca ni repute pour...

        Si tu veux avoir des perfs avec un compilos il faut en prendre un vraiment specialise pour ton architecture. De tout de facon mis a part cas super particulier la "lenteur" de gcc est largement compense par l'amelioration des capacites des ordis. Je fais tourner chez moi sur mon laptop ds simulations qui avant ne tournait que sur station dec alpha et ceux avec gcc (chose qui au passage a permis de montrer des bugs et des trucs bizarre fait par le compilo DEC). Apres si vraiment tu as besoin de truc encore plus puissant tu passes soit sur des grappes de calculs, cray etc et la generalement ton probleme c'est plus la mise en paralleles que le compilo utilise :) (surtout que de tout de facon tu n'as generalement plus le choix a ce moment
        la!)

        Mais c'est vrai que mes experiences personnels m'ont montre que le fortran lahey etait le plus rapide sur pc x86 et surtout tres proche de la norme, ifort etant trop bugges pour etre utilise a l'epoque la situation s'est peut etre ameliore de ce cote la. Par contre lahey en tant que client j'ai pas vraiment apprecie le jour ou le compilo apres un upgrade de la libc6 a arrete de fonctionner et qu'ils ont refuse de filer un patch et ne voulait que me vendre la futur version (pas encore sortie). Heureusement les devs de la libc6 etant sympa, ils m'ont trouve un moyen et file un patch pour contourner le probleme, patch que j'ai envoye a lahey et qui n'a jamais ete diffuse...

      • [^] # Re: Fortran

        Posté par  . Évalué à 5.

        autre petite remarque sur les test g95 dont tu parles. Il faut savoir que g95 se sert encore de gcc 4.0.3 du coup toutes les ameliorations de rapidites introduites sur les versions 4.1, 4.2 et maintenant 4.3 ne sont pas utilise.

        En tous cas je n'utilise pas plutot l'un que l'autre mais j'aime bien compiler mes softs avec plusieurs compilos permet de trouver des bugs 1) dans ton soft 2) dans le compilo (cela m'a permis plusieurs fois de ramener des bugs pour le dev de g95 et les devs de gfortran). De plus certains collegues ont l'un ou l'autre du coup si ca passe partout c'est mieux :)

  • # Merci pour cette news !

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

    Encore une fois un très bon travail. Bien rédigé et intéressant.

    Merci Patrick.

  • # Bug avec le kernel Linux

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

    Apparemment, cette nouvelle version entrainerait un bug qui n'aurait pas été vu jusque là au niveau des flags de gestion des processeurs x86 (direction flag = DF). Ce flag a une importance sur des accès à la mémoire (voir lien ci-dessous pour plus de détail).

    Le bug a été remonté par Aurélien Jarno le 5 mars dernier (http://lwn.net/Articles/272204/). A remarquer qu'apparemment, les *BSD sont concernés mais pas Solaris. Un patch a déjà été mis en ligne par Aurélien Jarno pour le corriger (http://lwn.net/Articles/272203/).

    A prioris, le risque de faille de sécurité est faible mais pas inexistant. A suivre ...

  • # Surtout...

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

    est-ce qu'il arrive à compiler ffmpeg ?
    sinon ça vaut même pas la peine :)

  • # Auto vectorisation

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

    Comme précisé dans cette news somptueuse, l'autovectorisation est en standard dans Gcc 4.3. On l'attendait avec impatience.

    Qu'est-ce que c'est exactement :

    Pour pas mal de type de boucle (celle-ci : http://gcc.gnu.org/projects/tree-ssa/vectorization.html#vect(...) ) Gcc va être capable de produire du code MMMX, SSE, ou altivec sur powerPC. Voire, d'après ce que j'ai compris, du SPU du cell.
    Ceux qui veulent lire des vidéos HD sur leur linux installé sur la PS3 vont être content (parce que pour avoir passé une après midi à essayer de le faire marcher, faire accéder au codec le spu du cell, c'est mission impossible).

    D'après cette note http://gcc.gnu.org/wiki/AutovectBranchOptimizations , la vectorisation est automatique. Gcc détecte ce qui est optimisable dans le code.

    Ca veut dire, que ça risque d'être très intéressant de recompiler pas mal de logiciels gourmand en calcul avec cette nouvelle version de gcc.

    La 4.2 gérai un peu de vectorisation, mais de manière très limitée et à condition qu'on active le switch correspondant.

    Il va y avoir des benchs à refaire...

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

    • [^] # Re: Auto vectorisation

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

      Et comment est-ce que ça gere les histoires d'alignement ? pour que SSE, Altivec et cie soient efficaces il faut que les données soient correctement alignées en mémoire (sur un multiple de 16 bytes), comment fait -il quand il ne voit qu'un "float*" ou un "double*", par exemple pour vectoriser ce genre de fonction:

      void saxpy(float a, float * restrict x, float *restrict y, int n) {
      for (int i=0; i < n; ++i) y[i] += a*x[i];
      }

      ?

      • [^] # Re: Auto vectorisation

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

        D'après ce que j'ai compris, il retrouve les données de départ par analyse de flot (du pauvre, parce que SSA, c'est assez limité), et si elles sont pas trop loin, il les alignent.

        Je suppose qu'il aligne toutes les données, de toutes façons.

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

      • [^] # Re: Auto vectorisation

        Posté par  . Évalué à 4.

        Warning : j'y connais rien, ce ne sont que des suppositions.

        En même temps ici il ne voit pas qu'un float * et un double *, il voit que ce sont des tableaux, rien que syntaxiquement ( x[n] ).


        Après il faut détecter que chaque tour de boucle ne dépend que de "i", l'indice, et que a est constant, en gros que rien à part l'indice ne dépend d'un tour de boucle précédent.

        Du coup tu peux parralelliser le tout sachant que ça doit être un "pattern" dans une boucle, détectée par le compilateur : Rien qui ne dépend du tour de boucle précédent, un indice qui accède à des adresses consécutives en mémoire, une taille constante (n).

        Après, pour savoir ce que tu dois aligner, tu dois avoir un moyen déterminer les variables tableau/pointeur à l'appel de la fonction ... par analyse de flot par exemple, pas forcément dans tous les cas, comme le disait Ontologia. Sûr que si c'est de l'allocation dynamique t'as intérêt à ce que ce soit aligné "de base".

        • [^] # Re: Auto vectorisation

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

          > si c'est de l'allocation dynamique t'as intérêt à ce que ce soit aligné "de base".

          C'est un bon exemple, puisque ce n'est pas le cas: sous linux, malloc renvoie des addresses alignées sur 8 bytes, pas sur 16, donc on a une chance sur deux d'avoir un buffer mal aligné (sous macos par contre malloc renvoie toujours un buffer bien aligné).

          Maintenant il y a des situations où avec la meilleur volonté du monde, le compilateur ne peut pas savoir que les addresses qu'il recevra seront bien alignées. Si par ex. ma fonction saxpy fait partie d'une bibliothèque (qu'on pourrait appeler "blas" pour fixer les idées..), eh bien à ce moment que peut faire le compilateur ? gerer tous les cas ? (x bien aligné , mais pas y, x et y bien alignes, etc). Je crois que c'est ce que fait la lib http://math-atlas.sourceforge.net/ , mais ça me semble difficilement envisageable pour un compilateur sinon bonjour le bloat.

          • [^] # Re: Auto vectorisation

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

            Je ne pense pas que gcc puisse aligner ce qu'il faut. Il va générer une entrée de boucle scalaire et une sortie aussi scalaire. Le milieu seulement sera vectoriel avec les accès aligné.

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

            • [^] # Re: Auto vectorisation

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

              Le milieu seulement sera vectoriel avec les accès aligné.

              Si il n'y a qu'un operande je peux le concevoir, mais quand il y a deux operandes (comme dans saxpy), ou plus, ça devient très compliqué, à moins d'en provilegier une et d'accèder aux autres de façon non alignée.

              • [^] # Re: Auto vectorisation

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

                oui, c'est compliqué. L'autovecorisation de gcc est faite pour ceux qui y font attention sans devoir faire de l'asssembleur à la main. C'est déjà pas mal.

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

      • [^] # Re: Auto vectorisation

        Posté par  . Évalué à 7.

        Comme toujours avec les histoires d'alignement: il génère un prologue et un épilogue qui gèrent les parties non-alignées
        en début et fin de boucle. C'est pareil si on devait écrire ça à la main. Comme ça fait du code en plus il faut en général du profiling ou des
        informations statiques pour décider si c'est vraiment utile ou pas de vectoriser la boucle en question. Les JIT ou compilo super fortiche sont
        capables de faire du versioning, i.e en fonction du site d'appel d'utiliser une version vectorisé ou pas de la fonction contenant la boucle, voir
        d'inliner tout ça. Mais ça demande soit du profiling soit de faire du JIT.

      • [^] # Re: Auto vectorisation

        Posté par  . Évalué à 2.

        Tiens c'est marrant je viens de découvrir le mot-clé "restrict".
        Justement, j'allais demander comment gcc réglait les problemes d'aliasing, et j'ai ma réponse.
        Mais alors, il va falloir apporter quelques modifications au code existant afin qu'il soit automatiquement vectorisé : on le voit meme dans les exemples cités plus haut, il faut mettre du "restrict" assez souvent ...

        • [^] # Re: Auto vectorisation

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

          y'a aussi un #pragma ivdep qui existe sur certains compilos et qui dit explicitement que les iterations de la boucle qui suit sont indépendantes, mais je crois que gcc ne le connait pas

  • # closures

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

    Euh... toujours pas de closures à l'horizon ? snif

    • [^] # Re: closures

      Posté par  . Évalué à 3.

      Les closures, c'est pas une caractéristique du langage plutôt que du compilateur?

      • [^] # Re: closures

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

        Gcc implémente une extension à C pour gérer les fonctions internes, mais avec un mécanisme de trampoline, pas de fermeture.

        • [^] # Re: closures

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

          c'est vrai
          $ info "(gcc)Nested Functions"
          et avec un peu de maquillage et quelques macros, ça peut ressembler à des closures mais tout ça seulement en C.

      • [^] # Re: closures

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

        effectivement, je voulais parler de c et c++ en général et de la norme à venir C++0x en particulier.

        Mais bon vu les superbes extensions qu'on a eu précédemment, ça ne me pose aucun problème que gcc soit plus rapide à évoluer que le langage lui-même

        • [^] # Re: closures

          Posté par  . Évalué à 1.

          Les closures se font très bien en C++98 (foncteurs, DSEL pour expressions lambdas...)

          Il y a néanmoins tout de même une nouvelle syntaxe plus intuitive pour C++0x, mais pas encore implémentée dans GCC.

  • # gcc lave plus blanc ?

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

    Je vois toujours des références à du « code propre » et j'avoue que ça m'agace un peu.

    On vante les mérites de gcc qui respecte au poil les standards C et C++ et qui refuse donc de compiler du « code sale ».

    J'avoue que la terminologie a le don de m'énerver. Non pas que je sois un fan du code pas propre, mais pour moi, code propre et respect des standards du C++ et de C sont deux choses distinctes.

    Par exemple, aujourd'hui, il n'existe aucun compilateur C++ qui supporte à 100% et sans bug le standard du C++. Donc un code qui serait « parfaitement propre » (d'après cette définition) et qui utiliserait toutes les fonctionnalités du standard ne marcherait nulle part. Trop cool !

    D'un autre côté, un code qui supporterait un très large panel de compilateur et de plate-forme marchera sur plein de machines, en supportant les divers bugs et sous implémentation du standard sera « sale » mais beaucoup plus utile.

    Dans cette catégorisation, il est à noter que le code de gcc est sale, tout comme le code de Linux (et la news le rappelle à juste titre).

    Pour certains on a l'impression que le respect absolu des standards du C++ est un but en soi, le développement d'un logiciel n'étant qu'accessoire. Et bien non, le but c'est développer un logiciel, et le respect de certains standards, ce n'est qu'un moyen pour assurer dans certains cas une portabilité. Côté développement logiciel, c'est d'ailleurs plutôt le non-respect des standards qui assure une certaine portabilité.

    Et un développeur peut avoir des trucs plus intéressants à faire (ajouter une fonctionnalité demandée par des utilisateurs, corriger un bug important) que modifier son logiciel pour qu'il compile avec la dernière version de gcc.

    Bref, le respect du standard, mais il faut aussi se mettre au niveau des besoins pratiques des gens, et le respect strict à 100% du standard n'est peut-être pas le besoin le plus criant.

    • [^] # Re: gcc lave plus blanc ?

      Posté par  . Évalué à 6.

      Je ne sais pas pour le C++ (je n'en fais pas) mais pour le C respecter la norme est quand même source de portabilité et évite d'avoir à modifier son code quand on change de compilo. Donc oui avoir des compilo qui respectent la norme à 100% c'est important. Il me semble plus sain de compter sur du code propre pour perdurer que sur des failles du compilateur qui au fil des versions peuvent disparaître ou ne pas exister si tu changes de compilateur.

      • [^] # Re: gcc lave plus blanc ?

        Posté par  . Évalué à 2.

        >mais pour le C respecter la norme est quand même source de portabilité

        Mouai, le C99 a mis beaucoup de temps à être adopté par les compilateurs..

    • [^] # Re: gcc lave plus blanc ?

      Posté par  . Évalué à 4.

      Effectivement avec du C ou C++ 100% standard tu ne ferais pas grand chose.
      Le fait d'utiliser des extensions ou librairies tierces en connaissance de cause ne
      remet pas en cause le 100% C++ standard, son but étant, ama, de garantir que
      la construction syntaxique que j'utilise marchera sur tous les compilateurs et
      plateformes sur lesquels je souhaites porter mom code. Le C ou le C++ c'est X
      sociétés qui l'implémente il est donc bon que tout le monde se base sur une
      base commune qu'on appel le standard.
      Les critiques des développeurs des divers noyaux (qui au passage ne sont pas des
      développeurs 'normaux') sont plutôt sur le fait que le compilateur ne propose
      pas d'options permettant des contournements. Activer une option pour avoir un
      comportement particulier en connaissance de cause c'est OK.

      Personnellement je vois aujourd'hui du code C fait par des développeurs qui
      ne connaissaient du langage que le nom : résultat pour du code développé sur les
      5 dernières années sur Solaris 2.8 est un gcc 2.x on ne pourra jamais faire
      évoluer le compilateur, si on doit passer sous Solaris 10 il faut impérativement
      que notre version de gcc fonctionne dessus, sinon on perd tout nos développement.
      Pour moi, vu ce que je viens de voir ces deux dernières années il est impératif que par défaut ce soit le standard courant qui compile ça limitera la casse (en tout cas je l'espère).

    • [^] # Re: gcc lave plus blanc ?

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

      En même temps, quand tu vois la taille du bousin, faut pas s'étonner que personne n'implémente...

      Vous êtes prêt à avaler la définition du standard du C++ ? Ses 1205 pages ? Le pdf de 8 Mo, quasiment sans images ?

      C'est ici : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n246(...)

      Aller je suis gentil, il n'y a *que* les 400 premières pages qui servent à définir le langage.

      Le C++ est pire que l'administration française, c'est une accumulation de couche les unes sur les autres. A ce stade, ça devient de la sédimentation !

      Alors, à la décharge des divers implémenteurs, je les comprends, je compatie à leur douleur, même.

      Bon après tout, si de gens aiment des langages pas beau, mal conçu, avec des concepts certes très intéressant, mais qui constitue une véritable usine à gaz qui rend le code impossible à débugguer... Grand bien leur fasse.

      Pour ma part, et moinssez moi, faites vous plaisir, je pense qu'il faut que ce langage disparaisse, et vite.

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

      • [^] # Re: gcc lave plus blanc ?

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

        Ce qui est bizarre c'est que tout le monde crache sur C++ et qu'en même temps tout le monde complimente Qt.
        Je ne sais pas ce qui explique cette universalité de la critique dans un cas et de la louange dans l'autre. Pourtant avec un langage horrible et méprisable il semble difficile de faire un toolkit magnifique et élégant non ?
        Ou alors c'est juste que les gens répètent ce qu'ils entendent dire sans juger par eux-même ? Mais ça n'expliquerait pas cette unanimité impressionnante. Il faut donc admettre qu'on peut faire un beau toolkit avec un langage tout pourri comme le C++.
        Bizarre.

        • [^] # Re: gcc lave plus blanc ?

          Posté par  . Évalué à 4.

          Je ne suis pas vraiment d'accord avec toi, le C++ n'est pas pourri il est complexe certes mais permet beaucoup pour ceux qui savent le maitriser pour preuve comme tu le sites QT.
          Dans le C++ il y a plusieurs niveaux de programmeurs (beaucoup plus de niveau que dans d'autre langage)
          Personnellement j'utilise le C++ en tant que langage final (je développe une application final) je suis un développeur de fin de chaine, et j'aime bien pouvoir dans certain cas pouvoir profiter des multiples paradigmes que le C++ propose tout en étant capable de savoir que mon code marchera dans le futur (QT est proprio mais sa licence et la masse de développeurs KDE me rassure).
          Le C++ n'est pas simple (le C non plus quand on veut garantir son fonctionnement ailleurs) mais il est expressif et possède de nombreux contributeurs comme TT qui permettent d'aborder des domaines comme le GUI de façon simple est efficace.

          Certes si on veut pouvoir faire pas grand chose sans se compliquer la vie et se la jouer rebel il existe un langage visuel basé sur des instructions symboliques à destination des débutants plus connu sous le nom d'un acronyme barbare qui m'échappe, mais qui n'a rien à voir avec de la programmation pérenne et efficace.

          • [^] # Re: gcc lave plus blanc ?

            Posté par  . Évalué à 8.

            QT est proprio mais sa licence et la masse de développeurs KDE me rassure

            Tu parles de la licence pour faire du logiciel propriétaire avec Qt ? Parce que sinon Qt c'est du GPL tout ce qu'il y a de plus classique. Par contre si un jour pour une raison ou une autre Qt n'est plus développé il passera sous licence BSD.

            • [^] # Re: gcc lave plus blanc ?

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

              Par contre si un jour pour une raison ou une autre Qt n'est plus développé il passera sous licence BSD.
              On s'en fou presque, aux dernières nouvelles la GPL est libre aussi ;-)

        • [^] # Re: gcc lave plus blanc ?

          Posté par  . Évalué à 4.

          Ce qui est bizarre c'est que tout le monde crache sur C++ et qu'en même temps tout le monde complimente Qt.

          Au contraire, les adeptes du C++ moderne adorent C++ et n'aiment pas trop Qt.
          En effet, Qt n'est pas écrit en C++ mais en C++/MOC, afin d'y rajouter des fonctionnalités qui se font très bien de manière native, de manière plus élégante et surtout de manière type-safe.
          De plus, Qt a ses propres conteneurs etc. et donc dédouble une partie importante de choses mieux réalisées par d'autres bibliothèques, en partie la bibliothèque standard.
          Et pour finir, utilisation intensive de pointeurs etc., contraire aux idiomes standards de la programmation en C++.

          • [^] # Re: gcc lave plus blanc ?

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

            TROLL DETECTED!

            Qt est écrit en pure C++ !
            Le MOC est un générateur de code qui génère automatiquement, dans un fichier cpp séparé, du code qu'il aurait été rébarbatif à d'écrire sois même.

            • [^] # Re: gcc lave plus blanc ?

              Posté par  . Évalué à 2.

              Oui, donc Qt est écrit dans un langage qui n'est pas du C++ puisqu'il doit être précompilé par le préprocesseur MOC pour étendre certaines macro ... Sinon, un compilateur C++ n'est pas capable de compiler un fichier source Qt.

              Qt a fait ce choix lorsque les différents compilateurs n'offraient pas un support complet du langage et ne l'a pas revu depuis. Les signals/slots peuvent par exemple être implémentés dans le langage (Cf implementation boost http://www.boost.org/doc/html/signals.html ) Il faut cependant bien dire que la syntaxe est peut être moins agréable avec cette implémentation.

              • [^] # Re: gcc lave plus blanc ?

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

                Qt, et le code écrit avec Qt, est écrit en C++ pure. toute les macro sont des macro C++, étendue par le préproceseur de GCC.
                le MOC ne modifie pas le code écrit par le développeur il n'étend pas de macro.

                Le moc va lire les en-têtes, pour générer un autre fichier c++ qui va permettre l'introspection. En gros, ça consiste à mettre le noms des signaux et des slots sous forme de chaîne de caractères dans une structure statique. Tu pourrais écrire ce code toi même si tu ne veux absolument pas utiliser moc, mais ce serait stupide car le moc fais ce travail pour toi.

                Et puis, les générateur de code c'est bien :-)
                http://doc.trolltech.com/4.3/templates.html
                (ce document explique les raisons pour laquelle Qt utilise moc)

                • [^] # Re: gcc lave plus blanc ?

                  Posté par  . Évalué à -5.

                  Je peux traduire tout code Python en code C.
                  Donc, d'après ton raisonnement, si j'écris du Python, j'écris en fait du C ?

                  Quant a ton document, il ne donne aucun réel argument.

                  À noter que le système d'introspection et de propriété n'amène rien du tout, si ce n'est un système particulièrement inélégant de typage dynamique.

                  • [^] # Re: gcc lave plus blanc ?

                    Posté par  (Mastodon) . Évalué à 2.

                    > À noter que le système d'introspection et de propriété n'amène rien du tout, si ce n'est un système particulièrement inélégant de typage dynamique.

                    Voilà toute la différence entre une personne qui développe activement en comprenant parfaitement les fondements nécessaires à ce qu'elle fait et une personne qui recherche "l'élégance" a tout pris, notion au combien subjective et donc quête purement utopiste (personnellement, je trouve Qt et MOC très élégant, comme je trouve ruby très élégant pour d'autres raisons, d'autres diront autre chose).

                  • [^] # Re: gcc lave plus blanc ?

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

                    Si tu code avec Qt, le code que tu écris, c'est du C++. Il n'est pas modifié. Il est parfaitement compris, tel quel, par le compilateur C++, car il respecte rigoureusement la syntaxe C++, c'est du C++.

                    Montre moi un exemple de code écrit en utilisent Qt qui n'est pas du C++ pure.


                    Pour ce qui est du document, il donne des arguments. Notemment le fait que la syntaxe eut été plus lourde et moins agréable sans.
                    Et l'introspection, c'est utile pour le debug par exemple. Ou encore pour rendre son application scriptable.

                    • [^] # Re: gcc lave plus blanc ?

                      Posté par  . Évalué à 1.

                      On te dit que ton code pour Qt, *avant* d'être passé par le préprocesseur, n'est pas du C++.

                      class DisplayWidget : public QWidget
                      {
                      Q_OBJECT
                      public:
                      DisplayWidget(QWidget *parent = 0);

                      signals:
                      void actionRequested(const QString &name);
                      };

                      Je doute qu'un seul compilateur C++ sache te compiler ce code.

                      • [^] # Re: gcc lave plus blanc ?

                        Posté par  . Évalué à 3.

                        Ben... Gcc, msvc... Ils arrivent le compiler parfaitement.
                        Parce que quand tu regardes les fichiers include, Q_OBJECT, c'est :
                        #define Q_OBJECT \
                        public: \
                        Q_OBJECT_CHECK \
                        static const QMetaObject staticMetaObject; \
                        virtual const QMetaObject *metaObject() const; \
                        virtual void *qt_metacast(const char *); \
                        QT_TR_FUNCTIONS \
                        virtual int qt_metacall(QMetaObject::Call, int, void **); \
                        private:

                        • [^] # Re: gcc lave plus blanc ?

                          Posté par  . Évalué à 2.

                          Ca c'est pour "Q_OBJECT". Et pour "signals:", il se passe quoi ?

                          • [^] # Re: gcc lave plus blanc ?

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

                            pareil: une macro défini dans un fichier include (qobjdefs.h [1]) 
                            #define signals protected
                            Et pour info, du code en glib utilise aussi pas mal de macro de ce genre, et ça reste du C. exemple eu hasard: ([2]) 
                            G_DEFINE_TYPE(GeditPanel, gedit_panel, GTK_TYPE_VBOX)
static void gedit_panel_finalize (GObject *obj)
{
        if (G_OBJECT_CLASS (gedit_panel_parent_class)->finalize)
                (*G_OBJECT_CLASS (gedit_panel_parent_class)->finalize) (obj);
}

                            
[1] http://websvn.kde.org/trunk/qt-copy/src/corelib/kernel/qobje(...)
[2] http://svn.gnome.org/viewvc/gedit/trunk/gedit/gedit-panel.c?(...)

                            • [^] # Re: gcc lave plus blanc ?

                              Posté par  . Évalué à 4.

                              J'ai du mal a voir l'utilite de la macro signals, a part pourrir du code qui n'a pas ete prevu au depart pour Qt et qui aurrait eu l'idee d'utiliser "signals" comme non de variable par exemple.

                              En ce qui concerne glib, je sais, il y a des macros partout, mais est-ce qu'il y a besoin d'un preprocesseur externe comme moc ?

                              • [^] # Re: gcc lave plus blanc ?

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

                                La macro signal est interpretée par le moc qui va savoir que la fonction est un signal. le moc va alors la générer le corps de ce signal automatiquement pour toi. si on prends ton exemple, moc va générer ce code dans un fichier annexe: 
                                void DisplayWidget::actionRequested(const QString & _t1)
{
    void *_a[] = { 0, const_cast<void*>(reinterpret_cast<const void*>(&_t1)) };
    QMetaObject::activate(this, &staticMetaObject, 0, _a);
}
                                Le développeur de gedit a lui du perdre un peu de temps à écrire le code de son signal manuellement. Tu va trouver que la syntaxe de ce code auto-généré est laide mais c'est pas grave vu que c'est du code auto-généré, seul le compilateur est sensé le lire

                                • [^] # Re: gcc lave plus blanc ?

                                  Posté par  . Évalué à 1.

                                  Bon, si j'ai bien compris:

                                  - Le code source avant le passage de moc peut etre compilé directement, parce qu'il n'y a que des macros qui sont definies par des headers Qt (donc, c'est bien du C++).
                                  - Le pre-processeur moc ne sert qu'a generer le corps de certaines fonctions membres, dans un fichier intermediaire (et c'est toujours du C++).
                                  - On pourrait ecrire les fonctions generees a la main (en C++), mais c'est fastidieux, d'ou l'usage de moc.

                                  Si ca ressemble vraiment a ca, je ne voit pas comment on peut affirmer que "Qt/moc c'est pas du C++". Bon, il y a toujours la macro "signal" qui choque un peu, mais franchement, on doit pouvoir trouver pire.

                                  Merci pour les explications.

                                  • [^] # Re: gcc lave plus blanc ?

                                    Posté par  . Évalué à 2.

                                    Si ca ressemble vraiment a ca, je ne voit pas comment on peut affirmer que "Qt/moc c'est pas du C++". Bon, il y a toujours la macro "signal" qui choque un peu, mais franchement, on doit pouvoir trouver pire.
                                    Et c'est ce que Gof défend depuis plusieurs jours.

                                    Pour ma part, le principal problème que j'ai avec ce système, c'est que ça peut coincer au niveau des outils pour générer des diagrammes UML... (ben oui, ils gèrent pas les macros)

            • [^] # Re: gcc lave plus blanc ?

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

              Cette "pureté" (je n'aime pas le terme non plus), c'est ce qui apporte la portabilité du développeur.

              A avoir des macros, même simplificatrices, qui s'utilisent en place des artifices officiellement fournis par le langage, on s'engage dans un sous-dialecte qui n'aide pas à la migration des développeurs.

              C'est comme cela que l'on se retrouve à avoir du C++/MOC, du C++/MFC, etc
              Résultat, on se retrouve avec des gens qui doivent ouvrir une nouvelle doc (propriétaire! (à un framework)) pour utiliser des structures qui sont pourtant fournies en standard, lorsqu'ils migrent sur des projets qui reposent sur d'autres frameworks (wxWidgets, Qt, MFC, ACE, ...)

              Attention, il est normal de s'adapter aux widgets du framework. Ce que je considère de complètement anormal est de s'adapter relativement aux choses dont un équivalent est pourtant fourni en standard (je pense aux itérateurs aliens (dans le contexte C++) de Qt, à leur FOREACH, etc, et de même pour les autres frameworks qui empiètent sur la SL, ou qui poussent à l'utilisation de macros dans le code client)


              Après, et cela n'engage que moi, je ne crois pas en la pérennité des sous-dialectes -- même si certains font de la résistance (-> MFC). Si TT/Nokia poussait certains des éléments de Qt dans le prochain standard, ma foi cela pourrait assurer une pérennité. Mais, AFAIK, ce n'est pas le cas. Ils m'ont l'air de rester gentiment dans leur coin avec leurs clients. A côté de ça Adobe, dont ce n'est pourtant pas le métier de fournir un framework de fenétrage, publie des articles "théoriques", et s'investit dans les communautés motrices relativement à l'avenir du C++ (au travers de 3-4 individus).

              • [^] # Re: gcc lave plus blanc ?

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

                Quel est l'équivalent standard du foreach de Qt ? Le fait est qu'il n'y en a pas, et que si Qt l'a introduit c'est bien parce que ce genre de truc est diablement pratique

                • [^] # Re: gcc lave plus blanc ?

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

                  hum ... std::for_each() ?

                  • [^] # Re: gcc lave plus blanc ?

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

                    pose toi la question pourquoi personne ne veut utiliser ce truc: ce que propose Qt est pratique. std::for_each ne sert à rien, et considerer ça comme un equivalent du foreach de qt je trouve que c'est un peu pousser grand-mêre dans les orties.

                    Le foreach de qt est optimal dans le sens ou il minimise la redondance de ce que tu as a taper.

                    • [^] # Re: gcc lave plus blanc ?

                      Posté par  . Évalué à 2.

                      Personnellement je trouve la combinaison de std::for_each et boost::lambda autrement plus élégante (et puissante) que le foreach de Qt.
                      Cela permet par exemple d'écrire
                      vector v(10);
                      for_each(v.begin(), v.end(), _1 = 1);

                      Ou encore
                      for_each(v.begin(), v.end(), cout << *_1 << '\n');

                      Etienne

                      • [^] # Re: gcc lave plus blanc ?

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

                        On rentre dans les boosteries, c'est déjà une bibliothèque supplémentaire à utiliser. On peut aussi pinailler sur le fait que nommer l'element courant "_1" soit vraiment elegant. Ou bien que c'est plus joli d'imbriquer des foreach "à la Qt" que d'imbriquer deux std::for_each l'un dans l'autre.

                        • [^] # Re: gcc lave plus blanc ?

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

                          Tout à fait. C'est de nouveau un sous dialecte ; avec les problèmes de portabilité de développeurs que j'évoquais précédemment.

                          Au détail que boost a légèrement noyauté le prochain standard et que l'ensemble de ses définitions complètent généralement la SL plutôt que de chercher à s'y substituer.

                      • [^] # Re: gcc lave plus blanc ?

                        Posté par  . Évalué à 4.

                        Sauf que tu donnes là un exemple simple. Dès que dans le bloc de ton FOREACH, tu as plus de 4-5 instructions, for_each devient franchement imbitable (obligé de créer une fonction annexe, avec impossiblité d'accéder directement aux variables des blocs supérieurs...)

                    • [^] # Re: gcc lave plus blanc ?

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

                      Et le jour où ton employeur t'affecte à un projet C++/MFC ou C++/gtkmm ?

                      Mon point n'était pas lié à la simplicité apportée (cf ma seconde phrase deux messages plus hauts) , mais à la non portabilité des développeurs introduites par ces dialectes propriétaires. Soit une vaine (?) tentative de décrypter ce qui est entendu par "pur".

                      La practicité du foreach de Qt est un fait. Il y a des gens qui se sont amusés à inventer le même genre de trucs avec boost. Leur pérennité est juste faible vu qu'il va y avoir autre chose pour remplacer: http://en.wikipedia.org/wiki/C%2B%2B0x#Range-Based_For_Loop

                      C'est le problème des extension propriétaires. Si elle les restent, le standard fini par gagner -- quand il y a redondance.

                      • [^] # Re: gcc lave plus blanc ?

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

                        On est d'accord.

                        Je n'avais pas entendu parler de ce que tu cites sur le "range-based for loops" mais si c'est vraiment inclu dans c0x c'est super.

                        Au moins le foreach de Qt aura eu le mérite de mettre en évidence qu'il y avait une vrai demande pour ce genre de construction. Ce qui n'etait pas évident au départ; a chaque fois que j'ai vu ce sujet abordé tous les c++-gurus se braquent sur le mode "la stl est parfaite tu pas besoin d'autre chose"

                • [^] # Re: gcc lave plus blanc ?

                  Posté par  . Évalué à 2.

                  Quel est l'équivalent standard du foreach de Qt ? Le fait est qu'il n'y en a pas, et que si Qt l'a introduit c'est bien parce que ce genre de truc est diablement pratique

                  Si je me rapport à http://doc.trolltech.com/4.1/containers.html#the-foreach-key(...) ça a vraiment l'air de vouloir éviter de faire peur aux allergiques des iterateurs (ce que certains commentaires ici même tendraient à justifier). Parceque

                  QMap<QString, int> map;
                  [...]
                  foreach (QString str, map.keys())
                      qDebug() << str << ":" << map.value(str);


                  S'écrit en C++
                  QMap<QString, int> map;
                  [...]
                  for (QMap<QString, int>::iterator it=map.begin(); it != map.end(); ++it)
                      qDebug() << it->first << ":" << it->second;


                  Et on a l'avantage d'éviter la copie de QString et l'appel à map.value() qui fait une recherche dans la map (QMap pouvant être remplacé par std::map avec exactement la même utilisation).

                  • [^] # Re: gcc lave plus blanc ?

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

                    Comme je le dis plus haut, c'est totalement sous optimal, tu es obligé de rappeler le type de ton conteneur pour indiquer le type des iterateurs (et des fois ça peut etre vraiment long, source d'erreur), et d'appeler explicitement begin et end.

                    • [^] # Re: gcc lave plus blanc ?

                      Posté par  . Évalué à 3.

                      Comme je le dis plus haut, c'est totalement sous optimal, tu es obligé de rappeler le type de ton conteneur pour indiquer le type des iterateurs
                      Je pense que tu n'utilises pas assez de typedef, je le fait de façon systématique pour rendre le code plus lisible et les évolutions plus aisées. Mon seul regret est que, comme en C, cela ne déclare pas un nouveau type mais ne fait qu'un alias.

                      (et des fois ça peut etre vraiment long, source d'erreur),
                      Erreur qui est détectée à la compilation.

                      et d'appeler explicitement begin et end.
                      C'est l'idiome qui veut cela et c'est quand même l'idiome le plus standard du C++, c'est quand même la leçon numéro 0 quand on aborde les conteneurs, tu remarquera que les développeurs de Qt ont trouvé le concept suffisamment bien foutu pour l'utiliser dans leurs conteneurs.

                      • [^] # Re: gcc lave plus blanc ?

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

                        C'est l'idiome qui veut cela et c'est quand même l'idiome le plus standard du C++

                        Oui et 99% du temps on travaille sur le conteneur entier au lieu de ne travailler que sur une partie. D'ou l'interet d'un foreach qui ne te redemande pas systematique de preciser les bornes. Ou bien d'avoir un concept de "paires d'iterateur", enfin n'importe quoi qui permette de réduire le nombre de caractères tapés et surtout le risque d'erreur ( genre si le begin et le end sont pris sur deux conteneurs differents).

              • [^] # Re: gcc lave plus blanc ?

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

                Les macros font partie officiellement du standard C/C++


                Alors oui, quand on utilise un bibliothèque, il faut utiliser la doc de la bibliothèque, ses structures de données, et son style d'API. Mais c'est innévitable.
                Que suggères tu ? Que l'on utilise plus de bibliothèque autre que la stdlib et la libc ?
                On ne devrais utiliser ni Qt, ni Gtk, ni GLib, ni boost, ni ... ? et refaire tout dans chaque applications ?

                • [^] # Re: gcc lave plus blanc ?

                  Posté par  . Évalué à 3.

                  Que suggères tu ? Que l'on utilise plus de bibliothèque autre que la stdlib et la libc ?

                  Et je cite le message de Luc auquel tu réponds :
                  Attention, il est normal de s'adapter aux widgets du framework. Ce que je considère de complètement anormal est de s'adapter relativement aux choses dont un équivalent est pourtant fourni en standard

                  De mon côté je suggère que tu apprenne à lire les messages auxquels tu réponds.

                  • [^] # Re: gcc lave plus blanc ?

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

                    Mouai. Le standard du C++ propose à la fois une syntaxe et une bibliothèque. Ok pour se conformer au langage (bien que quand une spec fait 1200 pages, on peut se poser la question de la logique qui préside à ce langage).

                    La bibliothèque standard du C++ demande un apprentissage au même titre que Qt, Gtkmm, MFC ou autre chose.

                    La std::lib étant plutôt pourrie et malpratique à utiliser, je ne vois pas pourquoi il faudrait préférer la std::lib par rapport à un truc pratique et rapide à utiliser. Parce que Bjarn Soustroup a réussi à le faire passer dans l'ISO ?

          • [^] # Re: gcc lave plus blanc ?

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

            Au contraire, les adeptes du C++ moderne adorent C++ et n'aiment pas trop Qt.

            Qu'est ce que le c++ moderne au juste ? un espece de machin "tout templates" hyper lourd avec des messages d'erreurs inintelligibles qui se déplient sur 500 lignes, un langage qui demande 2 go de ram et 10 minutes pour compiler un programme de deux lignes tellement on abuse des templates et on les pousse dans leurs limites ? C'est vraiment devenu un sport de faire les construction les plus tordues et de triturer le langage dans tous les sens, et je ne suis pas sûr qu'à la fin la lisibilité, la maintenabilité, et même la performance soient au rendez-vous.

          • [^] # Re: gcc lave plus blanc ?

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

            Moi je voit Qt comme Java ou .Net, une plateforme, un langage + une librarie très complète et *uniforme* ! Et le langage en question c'est pas le C++, c'est le C++/MOC.
            Les deux seuls reproches que je ferai c'est de ne pas implementer les signaux/slots en C++ pur et l'absence totale d'exceptions.

            Et qu'est ce qui te permet d'affirmer que les conteneurs Qt sont moins bons que la STL ? Qt utilise massivement le copy on write (http://doc.trolltech.com/4.3/shared.html#implicitly-shared), je ne crois pas que la STL le fasse, pourtant c'est une fonctionnalité non négligeable. De plus pour avoir utilisé les deux, je trouve les conteneurs Qt bien plus utilisables que ceux de la STL, c'est moins générique d'accord, mais c'est plus pratique (sort est une methode, pas une fonction externe, QList).
            Je ne compare même pas QString à std::string, ça n'en vaut pas la peine.

            • [^] # Re: gcc lave plus blanc ?

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

              > Qt utilise massivement le copy on write

              Le COW n'est pas un gage de qualité pour tout le monde. Le seul intérêt que je lui vois, c'est de palier à l'absence de sémantique de déplacement dans la version courante du C++ (le C++0x introduira les rvalue references qui changeront la donne -- compter 15 ans avant que Qt en profite (volonté de supporter toutes les plateformes, même celles qui ne sont plus supportées par les fournisseurs de compilos)). Et juste pour cela : faire des retours de fonctions par valeur, on sort une usine à gaz, à savoir le COW.


              > sort est une methode, pas une fonction externe

              Et oui, sort s'applique aussi sur les tableaux, pas que sur les vecteurs ou les files. Pourquoi dupliquer le code ?

              Une école tend à considérer que les fonctions ne doivent être membre qu'en dernier recourt -- je simplifie.
              Visiblement, Stepanov aurait mis bien moins de choses en membre comme begin()/end() s'il avait pu faire ce qu'il voulait.
              Cf ses notes sur la programmation: http://www.stepanovpapers.com/notes.pdf

              > std::string

              souffre en effet d'un certain nombre de défauts.

              • [^] # Re: gcc lave plus blanc ?

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

                Donc on va avoir 3 moyens de désigner un objet en C++:
                Une référence
                Un pointeur
                Une rvalue reference

                Et après on s'étonne que tant de gens trouvent le C++ trop complexe...

                Je code en C++/Qt tous les jours, et ça me plait mais il y a quand même des trucs que je trouve inutilement complexe.

                Si on prend Java, le langage est très simple, trop diront certains. Mais cette simplicité permet d'avoir des outils de manipulation automatique du code très efficaces (eclipse & co). Et au final on code plus vite en java qu'en c++. Exemple, j'ai jamais vu de completion automatique marcher à 100% sur du C++ pourtant c'est un outil qui permet vraiment de gagner du temps surtout si la doc est intégrée comme dans eclipse.

                • [^] # Re: gcc lave plus blanc ?

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

                  4. Ne pas oublier les simples valeurs.

                  Je n'ai jamais dit que le langage était simple.

                  Quant à la complétion automatique, les polymorphismes moins dynamiques (macrotage hérité du C, template, ...) n'aident effectivement pas. Dans leurs blogs, des gens de l'équipe de VS parlent qu'ils sont en train de remettre les choses à plat. Il faudra voir ce que cela pourra bien donner. Je serais curieux aussi de tester (dans 2 ans ...) cet autre outil dont on nous a fait de la pub ces dernières semaines (histoire de remplacer ctags qui ne comprend vraiment pas grand chose au C++)

          • [^] # Re: gcc lave plus blanc ?

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

            Je plussoie allègrement.

            Les fans du C++ crachent sur Qt parce que ce n'est pas du C++ pur. [je pense au passage que la notion de pureté du langage est tout aussi débile que la propreté du code que gcc aime bien]

            Je pense que ce qui fait que Qt a autant de succès malgré le fait que Qt soit écrit en C++, c'est justement que Qt simplifie énormément l'utilisation du C++, et la rend à peu près aussi simple que du python ou du java (plus simple même à mon avis pour le cas de java).

            Quelques exemples en vrac :
            - trouver de la doc facile à comprendre sur le C++ et ses classes outils, c'est la galère. A l'inverse, la doc de Qt est excellente.

            - les conteneurs Qt sont bien foutus et bien documentés, à l'inverse du C++ qui a une approche plus mathématiquement complet mais peu intuitif. Par exemple, pour transformer une chaine de caractère en minuscule et la casser en liste de chaines, en Qt, tu fais un s.toLower().split(' ') alors que le même code en C++ classique demande la compréhension de la notion d'itérateur, de mélange entre fonctions C (tolower) et C++ (les itérateurs). La notion de string en C++ n'existe pas vraiment. Une string n'est qu'un cas particulier d'un tableau de caractère, un tableau n'étant lui-même que le cas particulier d'un conteneur qu'on peut parcourir en avant, en arrière et qu'on peux accéder par index. Tu dois donc faire un parcours de ta chaîne avec un itérateur en lui appliquant un algorithme (tolower) pour obtenir ton résultat. Ca m'a pris 2h de lecture de doc la première fois pour réussir à faire ça.

            - pour faire des trucs un peu intéressants en C++, il faut vite utiliser des template qui sont difficiles à comprendre, difficiles à utiliser et qui font ramer la machine. A l'inverse Qt est vraiment facile à appréhender, grâce à son excellente doc et aux "extensions" apportées au C++.

            Globalement, quand je programme en C++/Qt, je pense que j'utilise environ 10% du standard C++ et je fais plein de trucs intéressants. A l'inverse, quand je fais du C++ pur, je galère pour faire ce que je veux parce que je dois utiliser plus de C++ (disons 20 à 30%) et je peine à faire des trucs intéressants.

            Dans une de mes vieilles interviews, Eirik Eng le PDG de Trolltech disait que un binding python pour Qt a peu de sens pour Trolltech, parce que Qt apporte au C++ beaucoup de services conviviaux pour les programmeurs, qui sont déjà présents à la base en python. Le besoin de Qt pour le python est donc moindre, et se limite uniquement à la partie graphique. [1]

            Voilà, je pense que ca répond à la question initiale.


            [1] ca n'emêche pas le binding d'être maintenu avec une très bonne qualité, mais à l'écart de Trolltech. Pour java, Trolltech en revanche héberge directement un binding java.

            • [^] # Re: gcc lave plus blanc ?

              Posté par  . Évalué à 2.

              - pour faire des trucs un peu intéressants en C++, il faut vite utiliser des template qui sont difficiles à comprendre, difficiles à utiliser et qui font ramer la machine. A l'inverse Qt est vraiment facile à appréhender, grâce à son excellente doc et aux "extensions" apportées au C++.

              Je remarque que Qt :
              - fournit des containers dont l'interface est plus que largement inspirée de la STL [http://doc.trolltech.com/4.0/qmap.html]
              - utilise de plus en plus de templates
              - utilise largement les templates en interne pour te fournir l'interface qui te convient (cf par exemple qalgorithms.h)


              J'ai d'ailleurs une question, comment fait-on pour trier un QVector ?

              Contrairement à ce que certains semble prétendre, je ne crois pas que "Les fans du C++ crachent sur Qt", que beaucoup (dont mois) considèrent comme une très bonne bibliothèque. En revanche, je crois que les développeurs Qt sont plus conscients que vous ne semblez l'être de la richesse du C++.

              • [^] # Re: gcc lave plus blanc ?

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

                > - fournit des containers dont l'interface est plus que largement inspirée de la STL

                Depuis Qt 3, tous les conteneurs Qt sont à la fois accessible avec les méthodes Qt (que je trouve mieux nommé pour ma part : first(), last(), append() ) et sont devenus compatibles avec la STL, en fournissant notamment les front(), back(), etc. La version 2 de Qt n'était pas compatible avec les algo STL du tout et était beaucoup critiquée pour cela.

                Je ne suis pas d'accord pour dire que les conteneurs sont inspirés par la STL. Ils sont inspirés par les besoins des développeurs, d'où par exemple la présence d'une QString qui est autre chose qu'un vector et la présence d'une QStringList qui est autre chose qu'un vector< vector< tchar > > . Map, Hash, List, Array sont des besoins génériques des programmeurs qui n'ont été inventés ni par Qt ni par la STL.

                Je ne suis donc pas d'accord avec ton affirmation même si aujourd'hui ca ne fait plus beaucoup de différence. L'approche de Trolltech a été de comprendre les besoins et de fournir une lib qui y répondait.

                Les dernières versions de Qt sont de plus en plus souples, avec par exemple la possiblité de désactiver les macros signal et slots, et autres subtilités qui peuvent poser des problèmes de compabilité avec la STL (notamment avec boost::signal).


                Je n'ai pas dit que Qt n'utilisait pas de template. La grosse différence entre Qt et la stdlib, c'est que les template sont très très peu visibles dans Qt. Dans 90% des cas, Qt fournit déjà des services pratiques. par exemple, tu peux itérer sur une QStringList sans template et sans pénalité en passant pourtant par des indexes.

                Dans la std::lib, les template sont partout dans tous les sens. Pour faire une opération super simple, il faut se taper des template (j'ai donné un exemple plus haut).

                > Contrairement à ce que certains semble prétendre, je ne crois pas que "Les fans du C++ crachent sur Qt"

                Disons que Qt a été très critiqué pour ne pas avoir de conteneurs compatibles STL (ce n'est plus le cas aujourd'hui), utiliser un générateur de code séparé plutôt que d'être purement C++, pour avoir sa propre notion de typage plutôt que d'utiliser les RTTI, etc.

                Un certain nombre de ces critiques ont disparu aujourd'hui, en grande partie à mon avis parce que Trolltech a fait des efforts pour rapprocher Qt de la STL.

                Il n'en reste pas moins qu'on lit tous les mois des critiques de Qt parce que ce n'est pas du C++ pur.

                Un truc que j'ai apprécié, c'est qu'en connaissant 10% du standard C++ et en ne connaissant rien en template, j'ai pu coder sans problème en Qt.

                Pour faire des programmes en std::lib, j'ai du au contraire me plonger dans les notions de template, d'itérateurs, etc tout ca pour découvrir que le service tout simple dont j'avais besoin n'existait pas dans la lib (convertir une chaîne de caractère en minuscule). C'est d'ailleurs un autre reproche qu'on peut faire à la std::lib : sans la lib c, elle ne sert pratiquement à rien. Alors que en Qt, je n'ai encore jamais eu besoin de faire du C.

                > J'ai d'ailleurs une question, comment fait-on pour trier un QVector ?

                Dans Qt 2, tu ne pouvais pas choisir ton algo de tri :
                http://doc.trolltech.com/2.3/qarray.html

                Mais on avait bien un template, j'imagine que c'est ce que tu voulais prouver.

                Par contre, le QVector de Qt 3 et 4 peut être trié avec les algos de la STL.

                C'est marrant, quand on critique la STL, les gens ressortent toujours l'exemple du sort. On peut en effet trier n'importe quel container avec la STL, et on peut aussi choisir son algo de tri très facilement.

                Perso, dans ma vie de programmeur, j'ai encore jamais eu besoin de la flexibilité offerte par la stl pour le tri. En revanche, il ya plein de petites choses dont j'ai besion très très souvent, qui ne sont pas dans la STL mais qui sont présentes dans Qt.

                Un autre truc marrant d'ailleurs, c'est que en interne, QVector convertit tout en char * (void * pour les puristes) et utilise les fonctions de la libc comme un gros bourrin. Pas si fan des template que ca les développeurs de Qt. Je pense qu'ils ont gratté quelques millisecondes de temps d'exécution avec ce type de ruse.

                > les développeurs Qt sont plus conscients que vous ne semblez l'être de la richesse du C++.

                Ca j'en suis persuadé. Ils connaissant toute la richesse du C++, toutes les failles des compilateurs qui soi-disant l'implémentent (rappelons par exemple que MSVC 6, un compilo très répandu ne savait pas gérer les variables déclarées à l'intérieur des for), tous les trucs pour gagner du temps, réduire la taille, etc.

                Ils arrivent à transformer un langage hyper compliqué et mal documenté en un truc simple et pratique à utiliser. Plus je connais le C++ et la diversité des compilateurs et de leurs problèmes, plus j'ai de respect pour les développeurs de Trolltech.

                • [^] # Re: gcc lave plus blanc ?

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

                  > Un certain nombre de ces critiques ont disparu aujourd'hui, en grande partie à mon avis parce que Trolltech a fait des efforts pour rapprocher Qt de la STL.

                  Je me demande s'ils n'ont pas également abandonné certains compilos encore plus vieux et exotiques que certains pas vraiment réputés pour leur niveau de conformité.
                  Clairement l'approche à l'opposé de celle de boost.

                  > C'est d'ailleurs un autre reproche qu'on peut faire à la std::lib : sans la lib c, elle ne sert pratiquement à rien

                  Ben ... pourquoi tout réinventer ?
                  Accessoirement, je n'avais pas relevé précédemment, mais il y a une version C++ de tolower qui prend une locale en paramètre (le C++ a une approche que je trouve assez bizarre vis à vis de l'I18n). De fait, il est est faux de dire qu'il _faut_ repartir sur le C (dans ce cas! Dans d'autres, je ne dis pas).


                  > C'est marrant, quand on critique la STL, les gens ressortent toujours l'exemple du sort. On peut en effet trier n'importe quel container avec la STL, et on peut aussi choisir son algo de tri très facilement.

                  C'est un exemple de la séparation organisation/algorithme sauce STL. Je me sers tout autant des copy_if (OK, c'est un oubli du standard), remove_xxx, equal_range, etc.
                  De nouveau, le PDF de Stepanov est des plus intéressants.

                  • [^] # Re: gcc lave plus blanc ?

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

                    > Je me demande s'ils n'ont pas également abandonné certains compilos encore plus vieux et exotiques que certains pas vraiment réputés pour leur niveau de conformité.

                    > Clairement l'approche à l'opposé de celle de boost.

                    Oups, j'ai foiré la transition ^^'
                    Je voulais dire: dans ce cas: ils ont dû enfin abandonné certains vieux compilos ; alors leur volonté me parait d'être de supporter tous les compilos encore utilisés en industrie (donc VC6 p.ex)
                    A l'opposé boost néglige les anciennes versions des compilos.

            • [^] # Re: gcc lave plus blanc ?

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

              > de mélange entre fonctions C (tolower)

              Ou de savoir chercher dans une FAQ ...
              Mais même là, la réponse n'est pas simple suite à divers choix relatifs à l'interface de std::string, et aux locales.
              Sinon, boost c'est pas mal aussi...

              Mais c'est sûr, qu'à faire du C++ sans connaitre la SL (-> itérateurs et autres algorithmes), on passe à côté de pas mal de choses et on se complique bien la vie. L'absence de vrais supports pour enseigner ce C++ (plutôt que du C avec des classes) n'aide pas.


              [sinon, j'ai globalement la même perception qu'Etienne -- pour la petite histoire, Stroustrup utilise Qt dans son enseignement du langage]

        • [^] # Re: gcc lave plus blanc ?

          Posté par  . Évalué à -1.

          > Je ne sais pas ce qui explique cette universalité de la critique

          Simple, la majorités des gens ne comprend pas C++ et est trop fainéante pour l'apprendre. Au-lieu de reconnaitre sa paresse, ben elle critique (sans savoir tout le géni qu'il y a dans C++).

          • [^] # Re: gcc lave plus blanc ?

            Posté par  . Évalué à 9.

            d'autres, c'est la grammaire ou l'orthographe.

          • [^] # Re: gcc lave plus blanc ?

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

            Euuh, Le langage D propose quasiment tout ce que propose C++, Templates compris, avec une définition plus courte et une syntaxe beaucoup plus propre.

            Eiffel.. euh non, mauvais exemple.

            Aller, je vais quand même pas passer outre la défense de ma chapelle : Lisaac, permet de faire bien plus de choses qu'en C++, avec une définition beaucoup plus courtes, et même sans nécessiter de templates, le compilateur fait tout tout seul avec l'analyse de flot*, et ce avec sensiblement les mêmes perfs : http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?t(...)


            Le génie, c'est de tout mettre tout ces concepts avec quelques primitives de base, et de produire un compilateur capable de tout faire, rapidement, avec celle-ci.


            * Bientôt poussé à fond, ie. sur les collections statiques

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

          • [^] # Je suis paresseux

            Posté par  . Évalué à 3.

            C'est un peu brutal comme remarque. Et aussi bête que de dire: ceux qui ne connaissent pas ADA, ce fabuleux langage, sont des idots. Ou encore: ceux qui n'utilisent pas Ruby, cette merveille, sont vraiment nuls. Etc.

            Je suis probablement paresseux d'apprécier la simplicité du c.

            Pour mon compte tout à fait personnel, le c++ (le vrai, pas juste l'utilisation de quelques fonctionnalités) ne m'a pas encore apporté de bénéfices.

            Je fais des applications légères (2000 lignes maxi) et pour le moment le c m'a toujours donné de bien meilleurs résultats.

            D'autres ont des goûts différents, des besoins différents.

            • [^] # Re: Je suis paresseux

              Posté par  . Évalué à 0.

              > Et aussi bête que de dire: ceux qui ne connaissent pas ADA, ce fabuleux langage, sont des idots. Ou encore: ceux qui n'utilisent pas Ruby, cette merveille, sont vraiment nuls. Etc.

              Je ne connais pas ADA ni Ruby, je ne les critique pas. Tu vois la nuance ?

            • [^] # Re: Je suis paresseux

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

              On écrit Ada pas ADA.

        • [^] # Re: gcc lave plus blanc ?

          Posté par  . Évalué à 4.

          >Ce qui est bizarre c'est que tout le monde crache sur C++

          Pas tout le monde: juste ceux qui l'ont utilisé ;-)
          Mon avis personnel: beurk! Vive Scala ou D si on veut vraiment un langage proche du C++.

          >Pourtant avec un langage horrible et méprisable il semble difficile de faire un toolkit magnifique et élégant non ?

          Certes, mais difficile != impossible, donc rien de contradictoire ou de bizarre là dedans..

        • [^] # Question d'esprit

          Posté par  . Évalué à 2.

          A mon très humble avis, la bataille entre C et C++ a les mêmes racines que celle entre emacs et consort. C'est juste une question relative à l'esprit de chacun. Certaines personnes sont mieux avec tel langage car cela correspond mieux à la manière dont leur esprit fonctionne.

          Le C++ étant nettement plus abstrait, cela requière des esprits adaptés. Je n'utilise que peu le C++ car il ne me correspond pas, et il ne correspond pas à mes besoins. Par contre je comprend qu'un autre puisse trouver avantage en ce langage et qu'il soit plus à l'aise avec.

          D'un côté strictement pratique, les *bons* programmes en C++ sont souvent bien difficiles à pénétrer (je ne parle pas de ceux qui sont mals écrits). Je prend l'exemple de la famille des serveurs vnc: ce n'est qu'un avis personnel mais le code est incompréhensible. Alors que celui de Qt est clair (comparativement à sa taille). Et bien j'ai rencontré plus de programmes comme vnc que comme Qt.

        • [^] # Re: gcc lave plus blanc ?

          Posté par  . Évalué à 5.

          Ce qui est bizarre c'est que tout le monde crache sur C++ et qu'en même temps tout le monde complimente Qt.

          Parce que même si le C++ est mal fichu, mal standardisé et inutilement compliqué, il permet de créer des API qualité?

      • [^] # Re: gcc lave plus blanc ?

        Posté par  . Évalué à 0.

        Certaines choses sont exprimées à la fois dans le standard C et dans le standard C++.
        Et bien C est bien plus court, mais est totalement incompréhensible...

        Le fait que le standard C++ soit plus long lui permet d'être clair et précis.

        • [^] # Re: gcc lave plus blanc ?

          Posté par  . Évalué à 7.

          Je vois pas en quoi le C est incompréhensible. C'est justement le fait qu'il soit court qui lui a apporté le succès. Pour citer le K&R, « Un programmeur peut s'attendre avec raison à connaître, à comprendre et à utiliser effectivement la totalité de ce langage ».
          La preuve : le K&R fait 200 pages, définition de la grammaire comprise.

          • [^] # Re: gcc lave plus blanc ?

            Posté par  . Évalué à 4.

            Le K&R (dans sa dernière version) est un livre d'exercices pour apprendre le C89.
            Ce n'est nullement la norme. La grammaire n'est qu'une toute petite partie de la définition d'un langage, le plus important c'est la sémantique.

            La norme C99+TC1+TC2, elle est là (c'est un working draft, bien sûr, parce que la version finale faut l'acheter) : http://open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf

            Elle ne fait que la moitié de la taille du standard C++0x, mais comme je l'ai dit, si tu compares certains passages tu constateras que là où le standard C est flou et pas clair le standard C++ est explicite.
            De plus, bon, il parait évident que C++0x est un peu plus compliqué que C99, car ayant plus de fonctionnalités, donc c'est plus long à définir.

            Je rappelle que le lien donné précédemment n'est pas C++98, ni C++03, ni C++03+TR1 mais un working draft qui date un peu de C++0x.
            D'ailleurs, pour référence, je fournis ces liens :
            Draft de C++98 datant de 97 : http://www.open-std.org/jtc1/sc22/open/n2356/
            Corrections effectuées en 2003 : http://www.acceleratedcpp.com/authors/koenig/c++std/revision(...)
            Dernier working draft de C++0x : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n252(...)

            • [^] # Re: gcc lave plus blanc ?

              Posté par  . Évalué à 0.

              Ok, tu parlais de la norme et pas du langage. Comme d'habitude les gens m'ont plussoyé pour rien. Je suis désolé, en plus je te connais de developpez.com et je t'aime bien, personne ne peut lutter contre toi sur la connaissance du C++.

      • [^] # Re: gcc lave plus blanc ?

        Posté par  . Évalué à 5.

        Vous êtes prêt à avaler la définition du standard du C++ ? Ses 1205 pages ? Le pdf de 8 Mo, quasiment sans images ?

        Tiens c'est marrant, ça me rappelle le langage eiffel. Avant la normalisation par l'ECMA (qu'aucun compilo n 'implémente pour le moment), la définition du standard était le bouquin de B. Meyer. Et ben pour un langage avec moins de fonctionnalités que le C++ et surtout une lib standard bien plus restreinte (ainsi que des concepts que personne n'a jamais su implémenter, genre SCOOP) , on dépassait allègrement les 1200 pages. Le langage n'est pourtant pas mauvais. Comme quoi ...

      • [^] # Re: gcc lave plus blanc ?

        Posté par  . Évalué à 2.

        C'est du grand n'importe quoi ces commentaires.

        C++ est un langage. Tu peux utiliser un langage au niveau maternelle (c'est à dire C), ou au niveau Bac L(C++ / STL) ou au niveau doctorant en linguistique (C++/Boost).

        C'est pas parce que tu ne comprends pas un mot du langage que le langage est nul.

        C'est un peu comme l'analogie avec le français et l'anglais.
        Tous comme le français est d'une richesse importante, l'anglais est encore plus riche.
        C'est sûr que pour le français de base (pléonasme ?), "l'anglais c'est nul, on comprend rien", et la majorité le parle à la texane japonaise, il n'empêche que tu peux exprimer des concepts impossible à décrire en français sans faire de périphrase (comme "pas cher").

        Seulement, tu peux rester à ton niveau, et comprendre les textes (codes) à ton niveau, ou tu peux décider de continuer à évoluer, et apprendre ce que le quidam de base ignore.
        Alors seulement tu comprends que c'est carrément plus pratique de dire "cheap" (5 lettres) au lieu de "pas cher" (8 lettres).

        Je suis d'accord avec le fait que le compilateur qui crache un message d'erreur de 500 caractères, c'est comme un anglais qui te réponds en vieux patois irlandais: c'est chiant à comprendre.
        C'est là où il y a du boulot à faire au niveau du compilateur (ICC, est pas trop mal pour ses messages d'erreur, et clang est prometteur), mais c'est pas la faute au langage.

        Si on compare au Java, par exemple, le langage est basique - simple-, du coup les outils de développement compensent en offrant les fonctionnalités du langage manquante (les templates du C++ <=> refactoring d'Eclipse, etc...).
        C'est sûr c'est plus simple à apprendre, mais t'es vite obligé de réécrire du code existant parce que tu veux changer un paramètre d'une classe, etc...

        Regarde un peu le projet Juce ( www.rawmaterialsoftware.com/juce ) pour un exemple de codage d'application cross-platform en c++ vraiment clean.

        • [^] # Re: gcc lave plus blanc ?

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

          Avoues quand même que le niveau de compétence exigé pour écrire du bon C++ est bien plus élevé que pour du bon C.

          Les templates de C++ lui ont permit de rajouter des fonctionnalités supplémentaires, mais bon le template programming n'est pas un exemple de clarté...

          Il y a plein de choses complexes (héritage multiple correct, gestion des recopies, etc...)

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

          • [^] # C++ : RAII et programmation générique

            Posté par  . Évalué à 8.

            L'avantage du C++ c'est avant tout le RAII.
            Pouvoir redéfinir les sémantiques de copie, d'affection, de construction et de destruction de nouveaux types qu'on définit permet de ne pas avoir à faire de gestion manuelle des ressources (comme la mémoire) en garantissant que tout est libéré même face à des erreurs qui surviennent durant l'exécution (exceptions).
            À lui seul, cet idiome empêche 90% des défauts de C d'apparaître (gestion de mémoire manuelle, fuites mémoires, dangling pointers...).

            Le deuxième avantage, c'est la programmation générique. On peut programmer des composants réutilisables sans avoir à utiliser du typage ou du dispatch dynamique.
            Les langages de la famille ML se vantent de leur polymorphisme paramétrique et de leurs modules, mais les fonctionnalités pour la programmation générique de C++ (les templates) permettent bien plus de choses, et sont plus faciles à comprendre pour un programmeur proche du système (mais peut-être pas pour un fan de lambda-calcul).

            Celle-ci peut toutefois parfois être compliquée si on veut réaliser certaines choses car nécessitant d'exploiter un peu de méta-programmation pour vérifier certaines propriétés sur les types. De bons outils, comme ceux de boost, peuvent toutefois fortement aider.

            La programmation générique sera grandement simplifiée par l'introduction en C++0x des concepts. Ceux-ci permettent de vérifier simplement certaines propriétés sur des types, d'une façon similaire à l'héritage, mais de manière non-intrusive (sans que le type soit explicitement défini comme sous-typant un certain autre type -- le sous-typage est implicite).

            Certains aspects de la programmation générique resteront toujours complexes et pour les gurus, comme la réalisation d'un DSEL, même si boost.proto aide beaucoup.

            L'héritage permet d'avoir du polymorphisme dynamique à la Java, ce qui est souvent synonyme de programmer plus ou moins à la Java, avec des pointeurs dans tous les sens, de la sémantique d'entité et de la gestion de mémoire "globale" (refcounting ou GC).
            Bien évidemment, programmer avec l'héritage, une sémantique de valeur et une gestion de mémoire "non globale" peut se faire, mais en pratique ce n'est pas fait.
            Les gens adeptes de cette approche, quand ils codent proprement, utilisent alors plutôt shared_ptr.

            La mode actuelle vers laquelle se dirige le C++ moderne est cependant de ne pas utiliser l'héritage, mais de préférer le sous-typage implicite non-intrusif, comme les concepts donc, et avec des objets valeurs (qui restent implémentés par des fonctions virtuelles et des templates sous le capôt) .
            Un exemple populaire étant function<R (T1... TN)>, qui permet de contenir un objet de n'importe quel type à partir du moment où on peut l'appeler avec la signature choisie. D'autres exemples plus génériques sont boost.any et choses similaires.
            Le futur étant quelque chose dans le genre de adobe::poly -- qui a eu quelques publications scientifiques ces derniers temps [1] --, qui permet vraiment d'avoir de la programmation générique comme avec les templates avec du polymorphisme dynamique au lieu du polymorphisme statique qui les caractérise.

            L'héritage multiple etc. est vraiment très peu utilisé. Principalement par la programmation par contrats ou par les frameworks fortement orientés objet (comme le sont bien souvent les GUI toolkits).

            Donc réellement, les aspects intéressants du C++ sont le RAII et les templates.
            Dire que ce sont des fonctionnalités complexes uniquement pour utilisateurs avancés me semble donc une aberration.
            Si ces aspects ne sont pas bien connus par la personne, ou pas utilisés, je pense donc que celle-ci passe vraiment à côté de ce qu'est C++.

            [1] http://www.emarcus.org/papers/MPOOL2007-marcus.pdf
            http://www.emarcus.org/papers/MPOOL2007-slides-marcus.pdf (même chose sous forme de slides)

            • [^] # Re: C++ : RAII et programmation générique

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

              C'est quoi l'objectif final de toute ces bidouilles, avoir de la généricité tout en gardant une vérification de type ?
              Quand je lis ça j'ai l'impression de lire la présentation de bidouille énorme possible avec de la magie noire en perl qui au final permettent des choses très puissante mais ça reste de l'exploitation de truc tordu.

              Enfin la vraie question derrrière tout ça, c'est : est-ce que c'est utile pour 90% des personnes qui developpent des logiciels ? ou est-ce que l'investissement de temps a apréhender tout ces concepts est récupéré derrière et apporte vraiment quelque chose ?

              Je critique pas particulièrement, mais je suis pas fan des arguments qui t'explique que ça poutre mais que tu peux pas comprendre sans te dire vraiment l'intérêt derrière tout ça (à part la beauté du concept)

              • [^] # Re: C++ : RAII et programmation générique

                Posté par  . Évalué à 2.

                C'est quoi l'objectif final de toute ces bidouilles, avoir de la généricité tout en gardant une vérification de type ?

                Dans le cas des concepts, l'interet c'est de faire verifier par le compilateur que l'argument d'un template presente bien les proprietes (fonctions/types) necessaires pour le bon fonctionnement du template en question. Ca va permettre d'eviter les messages d'erreurs types 500 lignes, avec a la place un vrai message intelligible. C'est un vrai progrès par rapport au duck-typing de la situation actuelle.

                est-ce que c'est utile pour 90% des personnes qui developpent des logiciels ? ou est-ce que l'investissement de temps a apréhender tout ces concepts est récupéré derrière et apporte vraiment quelque chose ?

                Si on limitait la cible a 90% du public, on utiliserait windows, non ? Plus serieusement, c'est clair que C++ est un langage complexe, mais on n'est pas obligé non plus de mettre en oeuvre toute cette complexité. Pour réaliser des choses simples, on peut rester simple (cf Qt), mais devant des problemes complexes, on est bien content de trouver tout le support necessaire dans le langage (cf Boost.Graph pour des graphes de grande taille).

                Sinon, je plussoie fortement loufoque: si on ne devait retenir qu'une seule chose de C++, c'est le RAII pour la gestion des ressources.

              • [^] # Re: C++ : RAII et programmation générique

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

                C'est quoi l'objectif final de toute ces bidouilles, avoir de la généricité tout en gardant une vérification de type ?

                Imagine, tu est dans l'objet Collection<E>
                Tu veux faire une méthode d'intersection qui te permet de prendre une collection<F> en argument
                et de rendre une autre Collection<E> qui soit l'intersection de E et F selon une fonction de comparaison
                f(E,F) -> boolean |-> E == F; que tu vas lui donner en paramètre.
                Par exemple, je sais pas, un exemple débile : F est un type date, E est un type String dont le contenu contient toujours un numéro d'année.
                Tu veux la liste des string qui contiennent le numéro d'année (par exemple "2008") qui soit le même que la collection de date que tu lui donne en argument.
                ça te permet de faire
                Collection<E> list1,result;
                Collection<F> list2;

                result = list1.intersection(& F autreliste, * pointeurCradeSurFonctionDeComparaisonMaisAvecUnLangagePourriCommeC++TasPasLeChoix);

                Evidemment, sans type Block comme en Smalltalk/Ruby/IO/Lisaac, t'es obligé de passer par un pointeur de fonction, mais voilà la puissance est là :
                Quand tu écris la fonction d'intersection, tu connais pas E, tu connais pas F, et ça marche dans tout les cas (pas en C++ parce que si ta fonction fait n'importe quoi... ça plante, et le compilateur vérifie pas)

                loufoque nous donnera surement une bidouille pour contourner ça proprement !

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

                • [^] # Re: C++ : RAII et programmation générique

                  Posté par  . Évalué à 3.

                  Evidemment, sans type Block comme en Smalltalk/Ruby/IO/Lisaac, t'es obligé de passer par un pointeur de fonction

                  Pourquoi un pointeur de fonction ? En C, je veux bien, mais en C++ on utilisera plutot un objet pour ca.

                  Quand tu écris la fonction d'intersection, tu connais pas E, tu connais pas F, et ça marche dans tout les cas

                  Moui. J'ai bien l'impression que j'ecrirais ceci pour le predicate d'intersection:


                  template < typename E, typename F >
                  bool compare( E e, F f ) { return e == f ; }


                  Je ne connais ni E, ni F, et ca marche dans tous les cas ou l'operateur de comparaison == est defini. Dans les autres, le compilateur va couiner, et c'est tres bien ainsi.

                  pas en C++ parce que si ta fonction fait n'importe quoi... ça plante, et le compilateur vérifie pas

                  Ah. Et dans les langage que tu cites, une fonction qui fait n'importe quoi, ca ne plante pas, et le compilateur verifie ? Pour toutes les valeurs de n'importe quoi, meme les grandes ?

                  • [^] # Re: C++ : RAII et programmation générique

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

                    Ah. Et dans les langage que tu cites, une fonction qui fait n'importe quoi, ca ne plante pas, et le compilateur verifie ? Pour toutes les valeurs de n'importe quoi, meme les grandes ?

                    En Smalltalk/Ruby/IO ça devrait planter à l'exécution.
                    En Lisaac, le compilateur te gueulera dessus à la compilation, et refusera de compiler.

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

                • [^] # Re: C++ : RAII et programmation générique

                  Posté par  . Évalué à 4.

                  En C++, on généralise les fonctions aux foncteurs, c'est à dire tout type qui peut s'appeler tel une fonction (donc éventuellement une classe avec un operator() surchargé).
                  C'est comme ça qu'on fait des closures etc.

                  boost::lambda (et autres du même genre) génère automatiquement un foncteur à partir d'une expression lambda.

                  Et en C++0x y'a une syntaxe spéciale pour exprimer les fonctions lambda.

                  Donc franchement, je ne vois pas pourquoi tu parles de pointeurCradeSurFonctionDeComparaisonMaisAvecUnLangagePourriCommeC++TasPasLeChoix. D'autant plus que la fonction utilisera par défaut operator==, donc il s'agira d'un argument optionnel.

                  Et je vois pas non plus pourquoi tu mets des & et * ? C'est n'importe quoi. Et cette définition de result vide alors que tu le redéfinis après, c'est tout simplement sous-optimal et stupide.

                  Je pense qu'intersection devrait être une fonction libre : il ne s'agit nullement d'une propriété propre à ta liste.
                  Accessoirement elle devrait écrire sa sortie sur un itérateur pour pouvoir mieux être exploitée.
                  Bref, un design à la std::set_intersection, mais sans tri. (ça va faire un bel algo en O(n*m) tout pourri)

                  Quand on voit que les gens qui critiquent le C++ ne savent même pas des trucs basiques comme ça, ça fait peur.

                  • [^] # Re: C++ : RAII et programmation générique

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

                    Quand j'ai "subi" VC++ 6, mes collègues m'ont expliqué que le seul moyen de faire des fonctions en C++, c'était le pointeur.
                    De même, quand j'ai voulu passer un paramètre sans le &, le compilateur m'a gueulé dessus, et on m'a expliqué pourquoi c'était pas possible.
                    Bon après, il parait que VC++ 6, c'est pas le meilleur.

                    Je ne connais pas C++ car pour moi, et c'est, je suis d'accord, un avis très très tranché, un langage dont la spec fait 500 pages c'est ------> poubelle.
                    Je pense pour ma part qu'une spec de langage, ça doit pas dépasser 80 pages, exemples compris. Un bon langage est minimaliste, pas bloated. Sinon on met des années à le maîtriser, on se complique inutilement, et à part faire plaisir aux quelqu'un comme toi, qui maîtrisent (très bien) la chose, on ennuie tout le monde.
                    Faut pas s'étonner que Java se soit imposé.

                    Cela dit, j'avoue que j'ai un peu regardé les templates pour piquer les rares fonctionnalités de c++ qui n'existent pas dans Lisaac, afin qu'on les y mettent. C'est en debug, ça va arriver bientôt.

                    Je me suis documenté sur les foncteurs en C++ (http://h-deb.clg.qc.ca/Sujets/Divers--cplusplus/CPP--Foncteu(...) : je ne sais pas si cette doc te parait valable )
                    Désolé, mais c'est un workaround tordu pour implémenter le type block bien connu des langages comme smalltalk/ruby/lisaac/io/...
                    Le type bloc est une fonction à évaluation retardé, elle peut recevoir un ou plusieurs paramètre et en renvoyer plusieurs (bien que ça dépende du langage)
                    Parce que franchement, utiliser les opérateurs pour redéfinir () et utiliser le constructeur comme foncteur, c'est tordu de chez tordu.
                    N'avaient qu'à implémenter le type block et ça aurait été réglé.
                    Le problème, c'est que c'est dur à compiler du block, et c'est très très dur d'avoir des perfs avec. Ils ont alors préféré faire un truc hyper compliqué, mais qui refile le sale boulot au programmeur.

                    Parce que tu sais ce que sont les templates en définitive ?
                    De l'analyse de flot codé à la main par le programmeur !
                    Comme le compilateur est beaucoup trop gros pour faire de l'analyse de flot lui-même et détecter les chemins de code à optimiser (évidemment, il y a 500 pages de specs à implémenter), en effectuant de l'évaluation partielle de code sur le code statique, on demande au programmeur de baliser l'analyse de flot parce que le compilateur ne sait pas le faire !

                    Je revient au type block : l'itérateur devient inutile, puisque tu fait ton foreach naturellement, et que le coût est exactement le même.


                    Ton idée de généraliser l'intersection est très intéressante : je la mettrai bien dans object.

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

                    • [^] # Re: C++ : RAII et programmation générique

                      Posté par  . Évalué à 4.

                      VC++ 6 est un tres mauvais compilateur, c'est un fait reconnu. M'enfin, il faut dire que le C++ est un langage standardisé ISO, et le vendeur de VC++ a quelques petits problemes a respecter les standards qui ont été fait par d'autres (même si dans le cas de C++, ca a fini par s'améliorer).

                      Mais bon, si tu ne connais C++ qu'a travers ce compilateur, et que tu refuse d'aller plus loin parce que la norme fait plus de 500 pages, tu ne crois pas que c'est un peu limité comme point de depart pour critiquer comme tu le fais ?

                      un langage dont la spec fait 500 pages c'est ------> poubelle.
                      Je pense pour ma part qu'une spec de langage, ça doit pas dépasser 80 pages

                      Est-ce que les 80 pages en question sont seulement destinée au programmeur qui va utiliser le langage, ou bien elles sont suffisantes pour un fournisseur extérieur qui voudrait implémenter un compilateur sur une architecture à priori inconnue des concepteurs du langage ?

                      Un bon langage est minimaliste, pas bloated.

                      Non. Un bon langage, c'est d'abord un langage adapté au problème à traiter. Ensuite, on regardera d'autres critères : portabilité, performance, sécurité, pérennité du founisseur, facilité pour trouver des programmeurs, disponibilité d'outils d'instrumentation et debogage, etc. Si on considère ces critères, le seul bon langage parmi ceux que tu cites serait smalltalk... et encore, il faudra peut être gratter pour trouver des programmeurs.

                      Evidemment, après, pour se faire plaisir dans le monde universitaire, on peut faire des langages minimalistes, jolis et académiques. Du point de vue recherche, c'est tres bien, je ne critique pas cet aspect, mais du point de vue industriel, ca n'est vraiment pas un critère majeur.

                      Parce que franchement, utiliser les opérateurs pour redéfinir () et utiliser le constructeur comme foncteur, c'est tordu de chez tordu.
                      N'avaient qu'à implémenter le type block et ça aurait été réglé.

                      Ca depend de la definition de "tordu". La redéfinition d'operateur, en particulier operator(), existait avant l'apparition des templates et du besoin de foncteur. A partir de la, il a semblé plus "tordu" de modifier le langage et faire évoluer tous les compilateurs existant, plutot que d'utiliser une fonctionnalite qui existait déjà.

                      Ton idée de généraliser l'intersection est très intéressante : je la mettrai bien dans object.

                      J'espere que tu ne va pas mettre toutes les "fonctionnalites interessantes" dans object...

                      • [^] # Re: C++ : RAII et programmation générique

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

                        VC6 qui date accessoirement de 97, pour une norme qui date, elle, de 98. Pour un compilo qui pré date la norme, il s'en sort pas trop mal.

                        Si seulement il ne s'était pas imposé comme un standard persistant en industrie... :(

                    • [^] # Re: C++ : RAII et programmation générique

                      Posté par  . Évalué à 2.

                      Faut pas s'étonner que Java se soit imposé.
                      Java c'est pas forcément imposé parce qu'il est "trop top méga cool", mais entre autre parce qu'il y a une vrai API très large, avec une vrai doc.

                      Essayez de trouver comment ouvrir "simplement" sans rechercher pendant 2 jours une librairie, un socket SSL (exemple au hasard) , voila quoi ...

                      my 2 cents

                • [^] # Re: C++ : RAII et programmation générique

                  Posté par  . Évalué à 1.

                  Ah oui et bien sûr, si tu ne peux pas comparer tes éléments, tu auras une erreur à la compilation et non à l'exécution, bien évidemment.

                  Je ne sais réellement pas d'où tu sors tout ce tas de choses fausses sur C++.

            • [^] # Re: C++ : RAII et programmation générique

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

              "le sous-typage implicite non-intrusif" Je ne vois pas trop ce que cela donne. Tu as plus d'infos ?

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

        • [^] # Re: gcc lave plus blanc ?

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

          C'est la philosophie du C++ qui me dérange. Et là, d'accord, ce n'est que mon avis.

          Je suis pour des langages minimalistes. des langages définis avec une ou maximum deux dizaines de primitives, une dizaine de mots clé, admettons une vingtaine.
          Si le langage est bien conçu et les primitives bien choisies, tu peux aller très loin.

          Les langages à la smalltalk/ruby/io/lisaac ont ma préférence car ils sont minimalistes en étant bien plus puissant. Toutes les structures de contrôles sont définies en lib, et énormément de choses le sont avec des primitives de base.
          En c++, tu pleures avec ton pauvre for et ton while.

          Quand au template, c'est un problème de compilation : les templates servent à précompiler toutes les données statiques disponible à la compil. Un bon compilateur à analyse de flot sait le faire, sans imposer au programmeur de concevoir les templates.
          En mettant en dur ta regexp dans une chaine, et la chaine à matcher, le compilateur est capable, par analyse de flot, de calculer la réponse.
          Si la chaine cible n'est pas là, il compilera l'automate.
          Pas besoin de template qui palie aux faiblesse d'un compilateur, sur lequel tous les énormes efforts sont portés à implémenter une norme pléthorique, plutot que de faire un compilateur puissant, mais simple.

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

    • [^] # Re: gcc lave plus blanc ?

      Posté par  (Mastodon) . Évalué à 10.

      Ça me rappelle les débats sur le respect des standard du web...

      Pour moi, un code qui compile sur un compilo mais qui n'est pas standard, c'est du même ordre que de dire "mon HTML marche sur IE" --> /dev/null

      Pour moi, un code propre respecte les standards (condition nécessaire) et le support des bugs de compilateurs ne doit être que temporaire.

    • [^] # Re: gcc lave plus blanc ?

      Posté par  . Évalué à 5.

      D'un autre coté quand on voit ce qui ce passe chez un certain microsoft c'est gère mieux :
      - Ils sont pas foutu d'avoir un compilo qui s'approcherait des standards C.
      - ils ont des includes pas standard qui font que des compilos comme gcc (mingw) ne peuvent pas forcement bien les parser et à cause de leur licence on ne peut pas les patcher.
      - leur libc est à l'image de leur compilo.
      Bref c'est que du bonheur de faire du code portable en prenant en compte windows (ca me rappel le code html pour ie).

      Pour le couple gcc/glibc, ce que je regrette c'est que les gens ne se rende pas forcement compte de ce qui est standard et ce qui ne l'est pas.
      Et malheureusement, je crois pas qu'il existe de moulinette qui donnerait la conformité du code (ISOC, POSIX, BSD, extension gcc, extension glibc, extension linux, ...).

      • [^] # Re: gcc lave plus blanc ?

        Posté par  . Évalué à 3.


        Pour le couple gcc/glibc, ce que je regrette c'est que les gens ne se rende pas forcement compte de ce qui est standard et ce qui ne l'est pas.
        Et malheureusement, je crois pas qu'il existe de moulinette qui donnerait la conformité du code (ISOC, POSIX, BSD, extension gcc, extension glibc, extension linux, ...).

        Il y a quand même l'option -std= de gcc, et également dans la glibc, il y a un certain nombre de define qui définissent ou non certaines fonctions (cf /usr/include/features.h).

        Cela dit, je te rejoins sur le fait que nombre de développeurs ne se soucient pas de la portabilité et activent tout par défaut sans séparer les parties spécifiques au système utilisé, ce qui oblige à aller taper dans tous les coins pour faire le portage. On se retrouve vite avec une soupe de #ifdef dans tous les fichiers.

        • [^] # Re: gcc lave plus blanc ?

          Posté par  . Évalué à 2.

          Il y a quand même l'option -std= de gcc
          Sauf que ca ne verifie pas tout si je me souviens bien.

          et également dans la glibc, il y a un certain nombre de define qui définissent ou non certaines fonctions (cf /usr/include/features.h).
          Idem c'est tres vite limité.
          Par exemple certaines fonctions POSIX ont des extensions linux sans garde fou (ie define a definir).

          Il n'y a pas non plus de séparation ISOC/POSIX.

    • [^] # Re: gcc lave plus blanc ?

      Posté par  . Évalué à 6.


      Par exemple, aujourd'hui, il n'existe aucun compilateur C++ qui supporte à 100% et sans bug le standard du C++. Donc un code qui serait « parfaitement propre » (d'après cette définition) et qui utiliserait toutes les fonctionnalités du standard ne marcherait nulle part. Trop cool !

      D'un autre côté, un code qui supporterait un très large panel de compilateur et de plate-forme marchera sur plein de machines, en supportant les divers bugs et sous implémentation du standard sera « sale » mais beaucoup plus utile.


      Que les compilateurs n'implémentent pas tout le standard C++, soit, mais j'attends d'un compilateur qu'il implémente de façon standard ce qu'il implémente. Je ne sais pas si tu as eu à faire du C++ portable du temps de Visual Studio 6 mais c'était la plaie.

      Ça ne me dérange pas de devoir me restreindre à une partie du standard en fonction de la portabilité que je désir (d'autant qu'il n'y a pas grand chose à éviter en dehors de la directive export), mais ce que j'implémente je ne veux pas avoir à le coder une fois pour chaque compilateur. Et je ne veux pas non plus m'appuyer sur une spécificité d'un compilateur qui a toutes les chances de changer lors d'une version ultérieure.


      Étienne

    • [^] # Re: gcc lave plus blanc ?

      Posté par  . Évalué à 2.

      Le frontend propriétaire EDG (utilisé notamment par le compilateur Comeau) supporte à 100% le standard C++98 et les corrections de 2003.

      Pour ce qui est du non-respect des standard, c'est à cause de cela que la plupart des codes ne compilent plus.
      Le fait que ça marche à cause d'un comportement erroné ou non documenté du compilateur ne devrait pas être exploité.

    • [^] # Re: gcc lave plus blanc ?

      Posté par  . Évalué à 4.

      Moi cette réthorique que la "dictature" des standards me ... fatigue.
      Cette réthorique remet en cause l'intérêt des standards (des vrais, pas des bouses comme MS-OOXML).
      Ça donne une vision simpliste du monde puis ça tire des conclusions.
      MS est un excellent porte-parole des anti-standards...

      > Donc un code qui serait « parfaitement propre » (d'après cette définition) et qui utiliserait toutes les fonctionnalités du standard ne marcherait nulle part. Trop cool !

      N'importe quoi.
      Enfin le standard donne des possibilités pour faire des choses non proposées par le standard. Le standard C/C++ ne dit rien sur l'assembleur. N'empêche qu'on peut ajouter de l'assembleur dans du C/C++. N'empêche que le standard C/C++ n'interdit pas les pragma. Etc.
      Mais quand le standard dit que pour faire un truc bien précis, il faut le faire "comme ci", ben il faut le faire "comme ci" et pas "comme ça".
      Le standard dit que pour ajouter deux variables, il faut utilisé l'opérateur "+". Inventer l'opérateur "⊕" pour concurrencer le standard est sans intérêt.


      > Côté développement logiciel, c'est d'ailleurs plutôt le non-respect des standards qui assure une certaine portabilité.

      N'importe quoi encore...
      Ben le code Windows est super portable selon toi...

      Ce qui fait la portabilité, c'est le respect des standards. Ce n'est pas en inventant des solutions dans son coin qu'on assure la portabilité. Linux s'appuit sur le standard Posix, les applis conçues pour Posix (applis Unix en général) se portent sans problème sur Linux (ou *BSD).

      N'assassinez pas bêtement les standards alors que leur intérêt n'est plus à démontrer. Mais c'est comme tout, rien est parfait. Un standard doit continuellement être amélioré (d'où les implémentations qui sont toujours en retard sur le dernier standard).

    • [^] # Re: gcc lave plus blanc ?

      Posté par  . Évalué à 10.

      Côté développement logiciel, c'est d'ailleurs plutôt le non-respect des standards qui assure une certaine portabilité.

      Voila un point de vue interessant. Je me bats toute la journee contre du code qui a ete écrit dans l'ignorance complete des standards, quels qu'ils soient, et bien entendu je dois le porter sur une autre plateforme.
      Si tu pouvais preciser, nous donner des exemples, ca serait bien, merci.

  • # STL parallèle

    Posté par  . Évalué à 6.

    Je n'ai pas encore eu le temps de me pencher dessus mais on m'a signalé qu'il y avait maintenant un mode parallèle expérimental pour la STL. Je ne sais pas non plus à quel point ça dépend de gcc 4.3 (ou pas) mais en tout cas, ça m'a l'air d'un truc intéressant à suivre.

    http://gcc.gnu.org/onlinedocs/libstdc++/parallel_mode.html

  • # MPFR et GMP

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

    Je ne comprend pas trop comment vont être utilisées ces bibliothèques.

    Est ce que les appels aux fonctions sur des flottants (par exemple un sinus) vont être wrappés sur des fonctions de MPFR et/ou GMP ?

    Ou, est-ce juste applicable aux calculs faisables en dur (par exemple float a = sin(b);) ?

    Du coup, faut-il compiler MPFR pour la cible ou pour l'hôte ?

    • [^] # Re: MPFR et GMP

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

      C'est pour faire les calculs en dur sans faire d'erreur d'arrondi qui dépendent de l'hote.

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

      • [^] # Re: MPFR et GMP

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

        Un exemple ?

        Je trouve bizarre qu'on laisse dans son code un truc du style
        foo = sin(0.1234567890)

        • [^] # Re: MPFR et GMP

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

          C'est pourtant théoriquement la façon portable de définir certaines constantes, comme pi et log(2). Dans la mesure où une implémentation C peut utiliser une grande précision pour le type double, mettre la constante en dur avec un #define pourrait ne pas être suffisant. Maintenant, en pratique, c'est l'inverse qui se produit (l'utilisation de MPFR est une première amélioration dans ce sens).

          N'oublie pas aussi que de telles expressions peuvent apparaître via l'utilisation du préprocesseur.

          • [^] # Re: MPFR et GMP

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

            Cela peut arriver aussi dans l'appel d'une fonction avec des paramètres constants, c'est de la bête propagation de constante. C'est d'autant plus efficace avec des libraries généralistes que l'on utilise. (j'imagine que des lib comme CImg doivent bien en profiter)

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

    • [^] # Re: MPFR et GMP

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

      C'est dit dans la dépêche : « GCC 4.3 utilise GMP et MPFR afin d'évaluer et de remplacer, lors de la compilation, les appels à des fonctions mathématiques ayant des arguments constants par leurs résultats. »

      Ça ne change rien du tout aux dépendances du programme compilé. C'est uniquement gcc qui utilise GMP+MPFR.

      Ces bibliothèques sont vraiment excellentes :-) La libc utilise des bouts de GMP pour l'implémentation de strtod() : conversion d'une chaîne (nombre décimal) vers un type double IEEE754. Le code est super complexe mais je pense qu'il a une excellente précision. En fait, si j'ai bien compris, il utilise un calcul en entier (type mpn_t) puis convertit tout à la fin en flottant.

      • [^] # Re: MPFR et GMP

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

        C'est surtout que strtod doit fournir l'arrondi correct et qu'il y a des cas difficiles à arrondir. D'ailleurs, il y a un bug dans strtod qui fait qu'il n'arrondit pas toujours correctement: http://sourceware.org/bugzilla/show_bug.cgi?id=3479

        • [^] # Re: MPFR et GMP

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

          Je ne sais pas si la libc va jusqu'à respecter ce genre de contraire : « The worst case is 752 digits for double, for numbers near Nmin/2 ». Dans les sources de la libc (2.5), je lis :

          #define howmany(x,y) (((x)+((y)-1))/(y))
          /* Maximum size necessary for mpn integers to hold floating point numbers. */
          #define MPNSIZE (howmany (MAX_EXP + 2 * MANT_DIG, BITS_PER_MP_LIMB) + 2)

          J'obtiens 1130 pour DBL_MAX_EXP + 2 * DBL_MANT_DIG. C'est le nombre de chiffre décimaux ?

  • # Re:

    Posté par  . Évalué à 4.

    > car elle sera le compilateur utilisé par Fedora 9

    Je ne peux parler pour les autres distributions, mais c'est déjà le compilateur de (la future) F9.
    Tout (noyau compris) a été compilé avec gcc 4.3 (et deux fois car au premier essai il y avais un bug :-)), depuis plusieurs semaines gcc 4.3 est intensivement testé.
    L'aide des distributions pour les tests est plus que précieuse. Ça fait aussi plein plein de remontés upstream.

Suivre le flux des commentaires

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