Sortie de la version 4.1 du compilateur GCC

Posté par  (site web personnel) . Modéré par rootix.
0
1
mar.
2006
GNU
Écrit à l'origine par Richard Stallman le logiciel GCC (GNU Compiler Collection) est devenu le compilateur de référence du monde du logiciel libre.

Après le tant attendu GCC 4.0 qui a vu la refonte complète son architecture interne voici maintenant la version 4.1 qui arrive.
Comme prévu la technologie SSA (Static Single Assignement) qui est au c½ur du nouveau GCC permet maintenant d'optimiser plus facilement le code source afin d'obtenir des améliorations générales. Le SSA est (en très gros) une forme intermédiaire entre le code source et le binaire dans laquelle chacune des variables du code source n'est assignée qu'une seule fois. Cette assignation unique a de nombreux avantages :
  • Les définitions et les utilisations de chacune des variables deviennent claires et explicites.
  • La majorité des analyses statiques du code source ne propagent les informations qu'à l'endroit strictement nécessaire.
  • Un grand nombre d'optimisations sur la forme intermédiaire SSA deviennent linéaire en temps.
  • De nombreux algorithmes deviennent plus concis et plus simples dans le cadre du SSA.
Après la grande bascule vers cette toute nouvelle technologie lors de la version précédente, l'équipe de développement de GCC s'est maintenant consacrée à l'amélioration poussée du code binaire produit par le compilateur. C'est donc le début des vrais bénéfices pour les utilisateurs !
  • On trouve ainsi dans cette nouvelle version 4.1 toute une série d'améliorations portant sur l'auto-vectorisation du code, notamment pour mieux profiter des unités multimédias des processeurs modernes (SSE ou Altivec). Cela ne remplacera pas des routines vectorisées "à la main" mais dans bien des cas c'est suffisant pour constater une amélioration significative de la vitesse d'exécution de certaines portions du code.
  • L'infrastructure pour faire des optimisations inter-procédures est maintenant en place. Il s'agit en fait de propager l'information d'analyse du source tout au long du graphe représentant le programme afin d'en tirer le meilleur parti possible et de générer une vue plus globale. Le profilage du source est ainsi rendu plus "intelligent" et il va plus en profondeur afin d'améliorer l'efficacité du binaire en sortie des différentes passes d'optimisation.
  • On trouve également une fonction pour marquer des portions de code en hot ou cold ce qui permet d'utiliser la mémoire cache des processeurs de façon plus rationnelle en ne chargeant que les instructions immédiatement utiles au programme en train de fonctionner (better instruction cache locality).
  • Du coté sécurité GCC est maintenant capable de générer automatiquement du code rendant plus difficile les attaques de type écrasement de pile (stack-smashing attacks). A noter qu'il s'agit d'une réimplémentation plus propre et moins intrusive du patch ProPolice d'IBM. Celui-ci était disponible en tant que patch externe pour les versions 3.x de GCC et il était activé notamment sous OpenBSD, DragonFlyBSD et dans la distribution IPCop. On trouvait également ce patch sous Gentoo mais il n'était pas activé par défaut.
    Maintenant que cette fonctionnalité de protection de la pile fait partie intégrante de GCC (ce qui était réclamée à corps et à cris depuis des années ) on peut penser que toutes les distributions vont faire profiter leurs utilisateurs de ce surcroît appréciable de sécurité.
  • Dans le domaine Java le compilateur spécialisé GCJ (qui peut générer du code natif ou du bytecode) a été grandement amélioré sur le plan de la stabilité et de la couverture des spécifications Java 1.4 (il se base maintenant sur GNU Classpath 0.19 avec un backport des corrections de bugs de Classpath 0.20). GCJ peut maintenant supporter beaucoup plus d'applications que précédemment : Le client bitorrent Azureus, le lecteur de fil RSSOwl ou le serveur applicatif JonAS en sont des exemples.
    Un article détaillé sur les nouveautés spécifiques du compilateur Java GCJ 4.1 et sur la future version 4.2 est disponible sur l'excellent site Linux Weekly News. On apprend ainsi que le support de Java 1.5 pourrait utiliser le compilateur ECJ du projet Eclipse au lieu de GCJX (et ceci une fois que la GPL v3 sera adopté car c'est cette dernière qui permet de renforcer la compatibilité entre les licences libres et de reprendre le code Eclipse dans le projet GCC).
  • Enfin coté support matériel on remarque l'intégration d'une nouvelle architecture. Il s'agit de MorphoSys qui est une architecture hybride composée d'un module programmable (TinyRISC) et d'un module hardware reconfigurable (RC Array).

Pour ce qui est des évolutions futures du compilateur on peut se pencher sur les articles (très) techniques issus de la publication du sommet GCC de 2005 à Ottawa.
On découvre que, expansion rapide de GNU/Linux aidant, beaucoup de grandes entreprises de logiciel et de hardware soutiennent le développement de GCC en payant des développeurs à plein temps : Intel consacre beaucoup d'effort au support de l'Itanium avec le projet Gelato et IBM fait de même avec le support de sa nouvelle architecture Cell. Ces deux types de processeurs étant très particuliers, ils nécessitent un compilateur extrêmement performant et moderne pour optimiser correctement le code généré.
Apple pour sa part finance l'amélioration du support du langage Objective-C alors que les deux poids lourd du monde Linux commercial, Novell/Suse et Red Hat, participent également activement aux améliorations du compilateur libre.
Bien entendu tout cela ne peut que renforcer le caractère incontournable de GCC dans le monde du logiciel libre et même au-delà.

PS1 : Pour faciliter son travail de développement l'équipe GCC a abandonné en fin d'année le logiciel de gestion des versions CVS et a migré vers Subversion (dont la version 1.3 est disponible). Après KDE c'est encore un poids lourd du monde du libre qui a basculé vers Subversion.
PS2 : Merci à alenvers pour ce post explicatif que j'ai repris sans aucune vergogne.

Aller plus loin

  • # Ca c'est de la bonne dépêche !

    Posté par  . Évalué à 10.

    Merci à l'auteur et tous ceux qui ont contribué à nous apporter une information si claire et détaillée !

    Une petite question tout de même : les améliorations apportées dans cette nouvelle mouture produisent donc des binaires plus performants au final pour le même code source, si j'ai bien compris. Mais qu'en est il du temps de compilation lui-même ? Y-a t'il un surcout à ce niveau ?

    Sinon, pour quel type de code/projets bénéficiera t-on le plus des améliorations de gcc 4.1 ? Et peut-on redouter des incompatibilités de certains codes sources comme ce fut le cas lors du passage à gcc 4.0 ?
  • # Esperons que la qualité suivra

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

    J'ai eu quelques problèmes avec GCC 4.1 qui est plus restrictif au niveau du code.

    MPlayer ne veux pas compiler avec, il impose gcc-3. Je me suis amusé à le forcer à utiliser gcc 4, ça ne compile effectivement, et il génère une erreur interne.

    De même, le code généré par le compilateur Lisaac, qui a la particularité de gérer lui-même sa mémoire (ie. un gros malloc au début, et une gestion "à la main" des zones mémoires dans le code), ne compile généralement pas le code généré par le compilateur. Ce code est pourtant conforme à C99 (au minimum tout le corps du code).
    Remarque GCC 3 déconne aussi parfois. Avec le même code craché par le compilateur, on remarque, si l'on compile en -O {2,3,s}, que le compilateur invente des registres (!!!). C'est vraiment assez marrant à regarder.

    Il serait donc peut être intéressant qu'un jour, une équipe, comme celle de Xavier Leroy à l'INRIA s'amuse à prouver quelques morceaux du compilateur.
    Ce qui a été fait pour un compîlateur mini C.

    http://pauillac.inria.fr/~xleroy/compcert-backend/

    GCC reste néanmoins un excellent logiciel, sans lequel le libre ne serait à mon avis pas ce qu'il est.

    Félicitation à l'équipe.

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

    • [^] # Re: Esperons que la qualité suivra

      Posté par  . Évalué à 1.

      pour mplayer, c'est de la faute des developpeurs qui travaillent comme des cochons.
      • [^] # Re: Esperons que la qualité suivra

        Posté par  . Évalué à 10.

        J'arrive pas à croire que ce genre de réflexion ait été marqué comme pertinente par les lecteurs de linuxfr.

        Autant tu as raison qu'une partie du code C qui ne compilait pas avec GCC-4.x était moche, et le fait de l'adapter pour qu'il soit compatible avec GCC4 a été une bonne chose, autant les modifications qu'il y a eu à faire pour adapter l'assembleur inline a été un vrai cauchemar. La faute à certaines version de GCC qui ne respectent même pas les spécifs de leur propre docs. La faute aussi à l'équipe de GCC qui considère que c'est normal qu'un code ne puisse compiler que quand on active les optimisations: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203#c14 , la faute à l'équipe de GCC de considérer que c'est une situation normale que GCC ne puise pas réaliser son allocation de registre avec certains codes asm inline valides.
        Oui, le code de MPlayer n'est pas ce qu'on puisse rêver de mieux en matière de qualité de code, mais ton aide est la bienvenue si tu veux remédier à ce problème.
        • [^] # Re: Esperons que la qualité suivra

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

          C'etait pertinent. Dans le bug que tu cites, justement, il y a de l'assembleur inline a la tonne qui devrait compiler sur une architecture notoirement pauvre en registres (i386). Le compilateur ne peut pas trouver de registres libres pour toutes les instructions sans passes d'optimisation. Ce n'est pas comme si GCC n'arrivait pas a compiler du C sans optimisation.
          • [^] # Re: Esperons que la qualité suivra

            Posté par  . Évalué à 5.

            Il devrait tout de même réussir à le compiler (tant que ce n'est pas impossible)... Même si on ne lui demande pas d'optimiser il devrait essayer de compiler parce que c'est le but, qu'on lui ait demandé d'optimiser est juste une indication sur la façon d'aboutir au résultat final.
            Par ailleurs la suite de la discussion est assez surréaliste avec un gros mensonge où quelqu'un confond NP-complet et "impossible", ce qui, même pour un étudiant en informatique comme moi est vraiment gros...

            Il faut aussi tenir compte du fait que mplayer a une très grosse base de code assez ancien, ce qui ne peut pas aider, et que mplayer a également "besoin" d'utiliser du asm inline s'il veut garder la légèreté qui fait sa qualité en tant que lecteur vidéo. Franchement mplayer est l'aïeul du multimédia (vidéo) Linux et avec ffmpeg continue à être l'un des acteurs les plus important du multimédia libre. Alors insulter mplayer pour la qualité de son code c'est vraiment une réaction détestable ! Rien ne t'empêche d'aider au développement.

            --
            Jedaï
            • [^] # Re: Esperons que la qualité suivra

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

              Par ailleurs la suite de la discussion est assez surréaliste avec un gros mensonge où quelqu'un confond NP-complet et "impossible", ce qui, même pour un étudiant en informatique comme moi est vraiment gros...

              Oulala, je me sens visé...

              Je n'ai pas dit que NP impliquait impossible. J'ai laissé entendre qu'on ne sait pas (et son auteur ne le sait pas non plus, je suis bien placé pour le savoir) comment le compilateur Lisaac réagira si on lui demande de compiler 1 000 000 de lignes.
              Il consomme 512 Mo pour compiler 50 000 lignes (lib incluse) en 15 secondes (sur un athlon 2Ghz). Combien lui faudra t-il de mémoire et de temps pour compiler 1 000 000 de lignes ? On ne sait pas, on a jamais essayé.

              L'analyse de flot (ie. l'algorithme testant toutes les branches de programme pour par exemple détecté qu'une variable est défini par n:=2*n+1 et 10 km virer un test de parité car il ne sert à rien) est un algorithme extrêmement consommateur de ressources, car exponentiel.

              Pas impossible en théorie, mais potentiellement impossible sur le PC que j'achète chez l'assembleur du coin.

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

              • [^] # Re: Esperons que la qualité suivra

                Posté par  . Évalué à 1.

                Je n'ai pas dit que NP impliquait impossible. J'ai laissé entendre qu'on ne sait pas

                C'est pas la question.
                Au pire tu peux utiliser la pile pour avoir tous les registres dispo (minus ceux en parametre) quand tu rentre dans un bloc asm inline.
            • [^] # Re: Esperons que la qualité suivra

              Posté par  . Évalué à 6.

              Ben ouai mais en même temps c'est dur d'intervenir sur un projet ou la fonction main fait 4000 lignes ;) (enfin elle faisait environ ça la dernière fois que j'ai regardé :p)
            • [^] # Re: Esperons que la qualité suivra

              Posté par  . Évalué à 10.

              « Alors insulter mplayer pour la qualité de son code c'est vraiment une réaction détestable ! Rien ne t'empêche d'aider au développement. »

              Tu veux dire, mis à part les fonctions de 4000 lignes et les hacks qu'on retrouve dans tous les sens ?
        • [^] # Re: Esperons que la qualité suivra

          Posté par  . Évalué à 6.

          A ce propos, j'ai proposé aux dev de MPlayer de quoi corriger la tonne de warning portant sur les "differ in signedness" afin déjà de corriger les plus simples qui sont dans les arguments de fonctions...

          Il semble cependant en effet que ce ne soit pas leur priorité et même trouvent les changement alourdissant le code.

          Maintenant la question est vaut il mieux un code peut-etre un peu lourd mais qui compile sans erreurs, ou garder le code "leger" mais vomissant des pages d'injures à la compile ?
          • [^] # Re: Esperons que la qualité suivra

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

            Ben c'est vrai que differ in signedness c'est un warning chiant. Si tu veux les enlever il faut spécifier le signe sur chaque char *: unsigned char * ou signed char *. Sinon tu vas corriger les warnings sur x86 et en ajouter sur ppc, ou vice-versa. C'est débile d'avoir ajouté ce warning dans -Wall. -- A mon humble avis.
            • [^] # Re: Esperons que la qualité suivra

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

              Personnellement ça m'a déjà sauvé la vie (une sombre histoire de "c == EOF" qui n'était jamais vrai sur PPC). Mais si t'aimes pas t'es toujours libre de rajouter -Wno-sign-compare.

              Par ailleurs -Wsign-compare n'est pas activé par -Wall mais par -Wextra (anciennement -W).

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Esperons que la qualité suivra

        Posté par  . Évalué à -9.

        lol effectivement...
        par contre xine a l'air bien ecris
    • [^] # Re: Esperons que la qualité suivra

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

      C'est corrigé depuis longtemps...
      Prend le CVS ca marche sans probleme
      (Pas testé avec le 4.1 pour le moment mais nickel pour le 4.0 je l'utilise plusieurs heures par jour sans probleme (vive le multiposte free))
      • [^] # Re: Esperons que la qualité suivra

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

        Bah pas chez moi :(


        [...]
        tvi_v4l2.c:1519: error: array type has incomplete element type
        tvi_v4l2.c:1519: error: invalid application of 'sizeof' to incomplete type 'struct v4l2_buffer'
        tvi_v4l2.c:1519: error: invalid application of 'sizeof' to incomplete type 'struct v4l2_buffer'
        make[1]: *** [tvi_v4l2.o] Erreur 1
        make[1]: Leaving directory `/home/montaigne/Logiciels-packagés/MPlayer/libmpdemux'
        make: *** [libmpdemux/libmpdemux.a] Erreur 2

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

    • [^] # Re: Esperons que la qualité suivra

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

      J'ai eu quelques problèmes avec GCC 4.1 qui est plus restrictif au niveau du code.

      On dit pas "plus restrictif", mais "plus respectueux des standards" :-) Avec l'option -Wall, gcc sort des avertissements souvent pertinant ou pouvant détecter des bugs. Les corriger prend du temps (si on n'avait jamais utilisé -Wall), mais ça ne peut qu'être bénéfique !

      Bon, après il existe peut-être des faux-positifs ... mais j'en ai jamais rencontré.

      Pour les extrémistes : options -ansi voir ... (aïe) -pedantic :-P

      Haypo
      • [^] # Re: Esperons que la qualité suivra

        Posté par  . Évalué à 7.

        « Pour les extrémistes : options -ansi voir ... (aïe) -pedantic :-P »

        Euh, je n'utilise jamais -ansi, parce que de toute manière je serais obligé de définir certaines macros spécifiques à GCC, alors autant garder l'environnement de base. Mais je ne vois pas en quoi --pedantic est une option d'extrêmiste.

        -Wall -W -pedantic

        me semblent les options minimales pour qui veut faire un code un minimum correct (éventuellement avec l'option -std=c99 histoire de se mettre au goût du jour - mais bon, comme GCC n'implémente pas toutes les options de C99, ce sera du C99--).
      • [^] # C'est très bien -pedantic mais avec -std=c99 quand même

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

        Et pour les masochistes, il y a splint(1).

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Esperons que la qualité suivra

      Posté par  . Évalué à 2.

      De même, le code généré par le compilateur Lisaac [...] ne compile généralement pas le code généré par le compilateur.

      Pourrais-tu expliquer/expliciter à un béotien ? J'avoue que j'ai rien compris du tout...

      [...] qui a la particularité de gérer lui-même sa mémoire (ie. un gros malloc au début, et une gestion "à la main" des zones mémoires dans le code)

      "Le code", celui de l'appli ? ou celui du compilo ? Tu parles d'une forme de GC ?

      Le fonctionnement de Lisaac a l'air assez intéressant, mais relativement obscur. Merci d'avance.
      • [^] # Re: Esperons que la qualité suivra

        Posté par  . Évalué à 5.

        sur le 1 :
        AMHA (Ontologia pourra me contredire) on a

        code Lisaac --(compilo Lisaac)--> code C --( gcc )--> executable

        Et ça coince à l'étape gcc, alors que normalement le code C généré est complètement correct.


        Sinon, pour le 2, toujours AMHA, ca doit être le code C généré qui a des fonctions de gestions de mémoire maison, et qui gère l'allocation à l'intérieur du gros "malloc", sans doute une forme de gc, oui, mais là, je suis moins sûr ;)
        • [^] # Re: Esperons que la qualité suivra

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

          Je répond au post grand-père en ajoutant quelques commentaires à ta réponse utile.

          Effectivement, Thomas a bien décrit le fonctionnement du compilateur.

          La gestionnaire mémoire est tout simplement défini dans le fichier memory.li qui se trouve dans la lib du compilateur.
          Rappelons que Lisaac est un compilateur ultra minimaliste : il ne connait même pas la conditionnelle, elle est défini dans la lib.

          Un gros malloc est effectivement effectué au début, et un GC gère toute la mémoire.
          Comme tout est intégralement compilé, le GC est défini dans la libairie en fait (le fameu memory.li)

          Ça coince effectivement au niveau de la compilation avec gcc.

          Je compare ce qui n'est pas comparable, mais comparer du C est beaucoup plus difficile que compiler du Lisaac (quoique, compiler l'héritage dynamique est extrêmement difficile, nécessite une analyse de flot sur touts le code et constitue de toutes façon un algo de complexité exponentielle), du moins compiler proprement : la grammaire de Lisaac tiens en 20 lignes, celle du C en 4 pages...

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

    • [^] # Re: Esperons que la qualité suivra

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

      Il serait donc peut être intéressant qu'un jour, une équipe, comme celle de Xavier Leroy à l'INRIA s'amuse à prouver quelques morceaux du compilateur.
      Ce qui a été fait pour un compîlateur mini C.


      Et la marmotte qui met le chocolat dans le papier d'alu, tu la prouves aussi en Coq ?
      Sérieusement, on est très très très très loin de pouvoir prouver du code C un tant soit peu non trivial, alors des bouts de gcc...
      • [^] # Re: Esperons que la qualité suivra

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

        C'est pas une question de trivialité, c'est une question de grammaire.

        Ce qu'à fait X. Leroy, c'est de prouver le parser, la transformation du code source en code intermédiaire , l'allocation de registres et la traduction du code intermédiaire en code objet.

        Prouver du code C, c'est plutôt l'oeuvre de Jean-Christophe Filliatre http://why.lri.fr

        C'est vrai, que vu la taille de la grammaire, prouver du C non trivial est pas chose facile.

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

      • [^] # Re: Esperons que la qualité suivra

        Posté par  . Évalué à 5.

        Il me semble qu'il existe ce genre de compilos partiellement prouvés dans le domaine de de l'embarqué, peut être pas avec le C en entier, mais au moins avec des sous ensembles, ultras-chers par ailleurs.

        (La flemme de fouiller dans mes notes pour voir si j'ai noté des trucs là dessus)
  • # Gentoo

    Posté par  . Évalué à 2.

    Vivement que Gentoo supporte officiellement la série 4 de GCC... Y'a pas à dire, elle commence à se faire attendre ;-)

    Pour le moment on peut quand même l'utiliser à coup d'entrées dans les fichiers de configuration de portage (le système de gestion de paquets de Gentoo) mais ça reste officiellement non supporté, même en ~arch qui est l'équivalent d'un "unstable" debian (obligation de rajout d'une variable d'environnement / de configuration I_PROMISE_TO_SEND_PATCHES_WITH_BUGS par exemple, en stipulant bien que si ton système casse avec GCC 4.x, pour le moment c'est ton problème.)

    M'enfin... Je garde espoir, sachant que c'est surtout le code de certaines appllis qui ne compilent pas avec GCC 4 qui fait que le support officiel tarde.
    • [^] # Re: Gentoo

      Posté par  . Évalué à 3.

      En plus gcc 4.1 sous gentoo compile quasiment tout, j'ai juste des problemes avec vlc, sinon tout le reste de mes package marche nickel !
      • [^] # Re: Gentoo

        Posté par  . Évalué à 1.

        Ouaww', je trouve ça plutôt impressionnant que GCC 4.1 fonctionne déjà si bien sous Gentoo.
        Enfin je suis peut être impressionné pour rien, mais c'est une application très "critique" en production dans une distribution comme Gentoo.
        C'est un réel progret pour les distribution dite "source", mais je pense tout de même que GCC 4, va mêtre encore beaucoup de temps pour arriver en production dans la branche stable. Mais tout est relatif.
    • [^] # Re: Gentoo

      Posté par  . Évalué à 7.

      Pour suivre l'avancement de la chose, on peut se surveiller les dépendances de ce meta-bug :
      http://bugs.gentoo.org/showdependencytree.cgi?id=117482
      Ça fait finalement assez peu de problèmes pour les gcc-4.x je trouve (comparativement à tout ce qui marche déjà bien quoi).

      M'enfin... Je garde espoir, sachant que c'est surtout le code de certaines appllis qui ne compilent pas avec GCC 4 qui fait que le support officiel tarde.

      Tout à fait. Pour enfoncer encore un peu le clou, disons qu'il n'est pas vraiment question que gcc4 atteigne le ~arch tant qu'il restera des problèmes connus avec certains paquets qui sont fonctionnels par ailleurs. La branche ~arch n'est pas un terrain de jeu où l'on a le droit de sciemment provoquer des régressions, mais c'est une branche pour les paquets candidats à la stabilité. Aux imprévus près, elle est censée être complètement cohérente, enfin autant que possible.

      Perso, je trouve ça plutôt rassurant que les devs Gentoo se tiennent à cette politique, y compris pour des paquets où la demande populaire peut devenir, comme ici, assez pressante. Et puis bon, c'est pas non plus comme si les ebuilds étaient absent de Portage et que ça prenait plus d'une dizaine de secondes pour y avoir accès...
  • # ObjectiveC++

    Posté par  . Évalué à 7.

    Parmi les modifs attendues de cette nouvelle version, il y a si je ne m'abuse le support pour l'Objective-C++ (mélange d'Objective-C et de C++ dans un même code). Ceci devrait notamment permettre le portage d'un certain nombre d'applis libres du monde MacOS vers GNUstep.
  • # apple et gcc

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

    Apple fait un peu plus que supporter l'obj-C, ça a été les premiers à adopter gcc 4.0 et maintenant ils envisagent des changements assez radicaux dans gcc:
    http://www.kdedevelopers.org/node/1628
    http://gcc.gnu.org/ml/gcc/2005-11/msg00888.html
    (le but étant de permettre des optimisations au moment du link)
  • # Ubuntu Dapper

    Posté par  . Évalué à 1.

  • # A propos des optimisations de code

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

    Je travail dans le domaine de l'électronique industrielle et de l'informatique embarquée. En gros ça veut dire que je joue avec des composants qui disposent d'un espace adressable relativement faible (de l'ordre de la centaine de ko).
    Dans mon domaine on a l'habitude de travailler avec compilateurs relativement chers qui offrent des optimisations de codes très, très poussées (codewarrior, microtec, hi-tec, etc).

    De puis quelques temps j'ai commencé à travailler avec le compilateur GCC et ses outils annexes, plus par curiosité et pour des développements personnels.
    J'ai vu dans une doc de GCC version 3.xx, que celui-ci était incapable de faire une optimisation de code au niveau "module". En gros ça veut dire que si on utilise une fonction d'un module/fichier C d'une librairie, tout les fonctions du module sont importées dans le binaires.
    Ce qui est relativement génant pour moi à moins de fractionner tous mes fichiers pour les exploser dans des fichiers séparés. Ce qui n'est pas forcément simple à faire ni agréable.

    Je voulais simplement savoir si dans la version 4.0 ou 4.1 c'était encore le cas ? Quelqu'un sait où je pourrait trouver cette info ?

    Et pour compléter encore un peu, est-ce qu'il y a quelque part des infos concernant la pertinance des optimisations et éventuellement un comparatif par rapport à d'autres compilateurs commerciaux ou libre ?

    Sinon, super dépêche, très intéressante.
    • [^] # Re: A propos des optimisations de code

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

      Si c'etait une lib static c'etait déjà le cas.

      Pour les lib dynamiques, depuis gcc4.0 en C++ au moins il y a -fvisibility qui révolutionne la vie des librairies dynamiques :
      : http://gcc.gnu.org/wiki/Visibility
    • [^] # Re: A propos des optimisations de code

      Posté par  . Évalué à 4.

      Je n'ai plus vraiment les chiffres en tête mais au boulot on a fait des tests sur ARM7 entre gcc 3 et le compilo ARM ADS1.2 et il n'y a pas photo. ADS est plus performant en taille de code (20% je crois) et le code généré est plus rapide.
      • [^] # Re: A propos des optimisations de code

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

        tu avais testé l'efficacité de l'option -Os ?

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

        • [^] # Re: A propos des optimisations de code

          Posté par  . Évalué à 3.

          Je ne me rappelle plus les conditions exactes du test (ce n'est pas moi qui les ait fait, le "on" désignait la boite où je bosse) mais il y a eu plusieurs configurations de testées et dans mon souvenir ADS était toujours meilleur sur les 2 domaines (taille code, vitesse d'exécution). Faudrait que je retrouve le rapport de test...
          • [^] # Re: A propos des optimisations de code

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

            C'est un fait connu que gcc n'est pas un excellent compilateur dans tous les domaines. C'est pas facile de compiler tous les langages de la terre sur toutes les architectures de l'espace et d'etre meilleur que tout le monde. Ce qu'il faut juger, c'est la distance. 20%, ca me parait acceptable tout en restant a ameliorer. Au dela, c'est qu'il y un truc qui ne va pas.

            En general, gcc se fait battre par des compilos optimises pour des architectures specifiques, qui ont beaucoup moins de contraintes globales que gcc.

            En vitesse de compilation, il se fait battre a plat de couture par Visual C++ vieille version.

            Des projets comme KDE galerent parce que la gestion du code virtuel dans les classes n'est pas optimal. De ce que j'en comprends, le support C++ evolue tres lentement ce qui ralentit parfois de facon notable des gros projets C++. KDE etant probablement le plus gros projet Open Sourc en C++ qui utilise gcc.

            Sur des archis embarques petite, je doute que gcc soit vraiment super efficace. Pour ce type d'architecture, ecrire un compilateur qui ne fait que du C et tient compte de certains caracteristiques des petits micros permet de meilleurs resultats que l'artillerie gcc.

            Tu peux regarder sdcc (http://sdcc.sf.net) qui parait plus adapte. Sur certains projets, il arrivait au niveau de Keil.

            Sinon, je travaille aussi dans l'embarque sur des micro 8bits et la facon dont tu ecris ton code a une influence certaine sur la taille du code genere par certains compilateurs. Certains vont mieux optimiser les acces aux variables globales, d'autres les acces aux variables locales. Certains n'aiment pas du tout les pointeurs (genre Keil, il aime pas du tout du tout les pointeurs au dela de 64K sur une archi 8 bits), d'autres les digerent facilement. Et chacun ont leur bugs : Codewarrior qui addresse les membres d'une structure sur un registre == pas possible d'avoir une strucutre plus grosse que 255 octets.
            • [^] # Re: A propos des optimisations de code

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

              En vitesse de compilation, il se fait battre a plat de couture par Visual C++ vieille version

              D'un certain coté, écrire des programmes avec Visual C++ vieille version, ça me gave vu qu'il est limité point de vue support des templates (et c'est normal, il est vraiment vieux). La nouvelle version n'a rien à envier à gcc point de vue lenteur :-) (faudrait que je mesure la vitesse de compil sur gcc et vc7 sur notre gros projet).
            • [^] # Re: A propos des optimisations de code

              Posté par  . Évalué à 6.

              C'est un fait connu que gcc n'est pas un excellent compilateur dans tous les domaines. C'est pas facile de compiler tous les langages de la terre sur toutes les architectures de l'espace et d'etre meilleur que tout le monde. Ce qu'il faut juger, c'est la distance. 20%, ca me parait acceptable tout en restant a ameliorer. Au dela, c'est qu'il y un truc qui ne va pas.

              Je n'ai pas critiqué gcc. La question était de savoir si des comparatifs existaient entre gcc et des compilos commerciaux. J'ai apporté ma très modeste pierre avec une réponse basée sur des souvenirs...

              Certe 20% ce n'est pas énorme et pas génant sur un PC mais dans l'embarqué c'est très pénalisant et pourtant je travaille sur une archi 32 bits (ARM7 et ARM9) avec des binaires de 2Mo. Mais 20% de plus c'est inacceptable chez nous... surtout si en plus le code est moins efficace. Mais il faudrait peut-être refaire le test avec cette version 4.1 de gcc pour voir l'évolution.

              Tu peux regarder sdcc (http://sdcc.sf.net) qui parait plus adapte. Sur certains projets, il arrivait au niveau de Keil.

              Je ne connaissais pas mais c'est inadapté à mon cas (32 bits, arm7 et arm9).
  • # Toujours pas l'intégration de GOMP...

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

    Le futur des PC c'est le multi-core, vu que la course au Ghz est enfin finie.

    En gros, bientot le seul moyen d'augementer les perfs pour une appli, utiliser les threads....puisqu'on pourra bientot plus acheter de plus gros proc...

    Quelques docs pour ceux qui n'ont pas suivi :
    - The Free Lunch Is Over de Herb Sutter (comité de normalisation du c++ : http://www.gotw.ca/publications/concurrency-ddj.htm )
    - Managing Concurrency: Latent Futures, Parallel Lives ( http://www.gamearchitect.net/Articles/ManagingConcurrency1.h(...) )

    Les optimisations de gcc 4 ne peseront pas lourds, face à des compilateurs qui savent gérer les multi-core (vc8, ic9, etc...), notemment par le support d'OPENMP ( http://www.openmp.org/drupal/ )

    Vivement l'intégration d'OPENMP dans GCC plutot que de laisser ca en dans une branche inconnue ( http://gcc.gnu.org/projects/gomp/ ).

    En tout cas, j'espere que les cours d'algo pour étudiant en ce moment mette plus l'accent qu'avant sur ce problème épineux... sinon "ca va pas etre facile".
    • [^] # Re: Toujours pas l'intégration de GOMP...

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

      C'est prévu pour 4.2 et certaines distribs l'ont mis quand même dans leur paquet gcc 4.1 version x64.
    • [^] # Re: Toujours pas l'intégration de GOMP...

      Posté par  . Évalué à 2.

      Je sors justement d'un cours de programmation concurentielle où on a abordé la difficulté de créer des programmes efficaces avec des processus se déroulant en parallèle. On a aussi un peu parlé d'optimisations faites à la compilation mais c'est vrai que ce n'était pas très approfondi pour l'instant.

      Mais bon, en même temps, pour le premier cours sur le sujet du semestre, fallait pas en demander trop !
      • [^] # Re: Toujours pas l'intégration de GOMP...

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

        > la difficulté de créer des programmes efficaces avec des processus se déroulant en parallèle.

        Sans meme aller jusqu'a l'efficacite, concevoir et debugger un programme dont les morceaux s'executent en parallele est enormement plus complexe que de concevoir et debugger un programme normal.

        Perso, je pense que les threads ne doivent etre utilises qu'en cas d'extreme necessite couplee avec une necessite extreme. Genre calculs mathematiques, programmes gerant n connexions, etc.

        Pour parallelise un programme plutot monotache dans son fonctionnement, c'est tout de suite beaucoup plus complique. Il faut isoler des portions du programme qui n'ont pas besoin d'ecrire des donnes communes, il faut regarder l'ordonancement de chaque tache pour voir si on peut pas en lancer qqs'une avant les autres, etc.

        Je prefere plutot que mon noyau et son scheduler qui s'occupe de paralleliser l'utilisation des ressources de ma machine, que le compilateur qui essaye de paralleliser un programme.

        Pour en revenir aux programmes pseudo-monotaches, je me demande a quel point ce n'est pas plus simple de faire un scheduler interne (ce qu'a fait mplayer) que de faire de la programmation par thread a tout va. Au moins, avec ton scheduler, tu sais ou tu vas.
        • [^] # Re: Toujours pas l'intégration de GOMP...

          Posté par  . Évalué à 4.

          « Je prefere plutot que mon noyau et son scheduler qui s'occupe de paralleliser l'utilisation des ressources de ma machine, que le compilateur qui essaye de paralleliser un programme. »

          C'est dommage. Si un compilateur est capable, moyennant un léger surcoût à la compilation, d'extraire les instructions indépendantes, je ne vois pas pourquoi on ne pourrait pas en profiter pour paralléliser automatiquement le programme (création de pipelines logiciels, déroulage de boucles, déroulage/fusion, etc)
          • [^] # Re: Toujours pas l'intégration de GOMP...

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

            Je crois que l'on parle de deux choses différentes : l'optimisation du code et la conception d'un logiciel.
            Au niveau optimisation, le processeur fait tout son possible pour explorer en avance de phase plusieurs chemins d'exécution, le compilateur va faire de son mieux pour détecter dans le code source des choses vectorisables, etc. etc.
            Mais le parallélisme de l'application, par exemple les politiques d'ordonnancement ou d'accès aux donées partagées, si ce n'est pas décrit dans le code source, le compilateur ne peut pas l'inventer.
            • [^] # Re: Toujours pas l'intégration de GOMP...

              Posté par  . Évalué à 2.

              « Mais le parallélisme de l'application, par exemple les politiques d'ordonnancement ou d'accès aux donées partagées, si ce n'est pas décrit dans le code source, le compilateur ne peut pas l'inventer. »

              Ben euh... Au moins la « threadification », le compilateur peut faire quelque chose...
    • [^] # Re: Toujours pas l'intégration de GOMP...

      Posté par  . Évalué à 2.

      En parlant de OpenMP, ou puis-je tester ce truc ?
      Impossible de trouver du code ou quoi que ce d'autre que leur spec et presentation...

      C'est que je veux le voir tourner ce truc !
    • [^] # Re: Toujours pas l'intégration de GOMP...

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

      Mon avis sur la question s'exprime en une ligne : L'idéal serait de cacher au maximum cette complexité au programmeur, bref faire en sorte que le compilateur gère lui-même.

      Bertrand Meyer, le concepteur d'Eiffel à conçu pour cela le modèle SCOOP : http://se.inf.ethz.ch/teaching/ss2004/0268/lectures/251-0268(...) pour Simple Concurrent Object-Oriented Computation

      C'est un modèle qui propose une syntaxe pour Eiffel permettant de définir quand est-ce qu'un appel de message est asynchrone ou non.
      Eiffel Software l'a implémenté en 1995.

      Puisque la nature revient au galop ;-) je précise que le brouillon de publication que j'ai présenté sur ce site, n'est autre que l'adaptation du modèle SCOOP à un langage objet à prototype compilé.

      https://linuxfr.org/~Montaigne/20582.html

      L'idée de ce modèle est de permettre de la programmation parallèle, en pensant son code en tant que système multi agent.
      Les problèmes de multithread ne se posent pas trop car les zones mémoires entre thread sont, dans ce modèle, étanches. C'est un peu l'idée de SCOOP.

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

      • [^] # Re: Toujours pas l'intégration de GOMP...

        Posté par  . Évalué à 3.

        Eiffel Software l'a implémenté en 1995

        Je suis content de l'apprendre. En fait, à ma connaissance, SCOOP avec son mot-clé separate et un fichier de ressources un peu semblable aux fichiers d'assemblage de classes (permettant de savoir si le nouveau "processeur" est un thread, un autre processeur, ou une machine distante, ou autre chose), ça n'a jamais été implémenté en 2006. Que la spécification date de 1995, je veux bien le croire.
    • [^] # Re: Toujours pas l'intégration de GOMP...

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

      - The Free Lunch Is Over de Herb Sutter (comité de normalisation du c++ : http://www.gotw.ca/publications/concurrency-ddj.htm )


      J'en prends un extrait :
      The mainstream state of the art revolves around lock-based programming, which is subtle and hazardous. We desperately need a higher-level programming model for concurrency than languages offer today; I'll have more to say about that soon.


      <mode cynisme>
      Encore un qui semble vachement au fait de l'état de l'art (son papier ne cite que Java). Je suis impatient de voir ce qu'il va nous pondre.
      </fin du cynisme>

      Ca me parait être l'occasion de rappeler que dans gcc, il y a un compilateur Ada, et que Ada propose un modèle de programmation parallèle d'une puissance inégalée.
      Ces concepts sont intégrés depuis toujours dans le langage, ils ne s'agit pas d'une bibliothèque externe ou d'un concept minimaliste ajouté avec difficultés dans un langage pas du tout pensé pour ça.

      En Ada, les taches ou les objets protégés sont des citoyens de première classe. Ils peuvent être manipulés comme beaucoup d'autres types. On peut par exemple déclarer un tableau de tache.

      Si vous souhaitez faire un logiciel de calcul, de jeux, ou de traitement d'image, intégrant un tasking performant, basé sur un standard ISO, portable entre compilateur, portable entre OS, alors pas la peine d'attendre, c'est déjà dans gcc.

      J'espère que la banalisation des dual-core augmentera l'intéret des développeurs pour Ada, qui permet d'écrire un code unique pour Linux/Solaris/Windows/etc., exploitant les ressources disponibles sur la machine, quel que soit le nombre de processeurs.
      • [^] # Re: Toujours pas l'intégration de GOMP...

        Posté par  . Évalué à 4.

        J'espère que la banalisation des dual-core augmentera l'intéret des développeurs pour Ada

        J'ai de forts doutes : la mode est plus aux langages de scripts où on ne déclare pas grand'chose avant de s'en servir...
      • [^] # Re: Toujours pas l'intégration de GOMP...

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

        Il fait partie du comité de normalisation du C++.

        "mainstream" veut dire utilisé et accepté par tout le monde, industrie et academie.
        C++, Java, C#, ruby, python => mainstream
        ada, lisp, ocaml => peu utilisé, donc pas mainstream

        Ada ne fait malheureusement pas parti du "mainstream".

        Qui sait, les "task, "entry", "accept", "requeue", et autres "delay" feraont peut-etre leur coming-back.
  • # Protection de la pile par défaut sur les prochaines releases des distros

    Posté par  . Évalué à 10.

    Maintenant que cette fonctionnalité de protection de la pile fait partie intégrante de GCC (ce qui était réclamée à corps et à cris depuis des années ) on peut penser que toutes les distributions vont faire profiter leurs utilisateurs de ce surcroît appréciable de sécurité.

    Ça serait formidable !
    À ce jour, je n'ai pas eu d'autres echos que de la position de Fedora Core, dont un développeur expliquait sur une mailing-list que les packages sont désormais compilés avec cette option activée (la FC 5 sera donc releasée avec cette protection). Et évidement DragonflyBSD et OpenBSD qui utilisent son équivalent pour gcc3 depuis une paye.

    Qu'en est-il des autres distributions ? quelles sont celles qui ont annoncé leur position par rapport à cette option (qu'ils aient décidé de la supporter ou non) ?
    Qu'en pensent Debian, Ubuntu, OpenSuse et Mandriva ?

    Je suis particulièrement inquiet pour Debian, qui a longtemps tenu le haut du pavé en matière de sécurité, du fait de la très haute exigeance qualité de son équipe de developpeurs. Mais qui semble ne plus tenir le rythme, par exemple par rapport à Fedora (qui intègre maintenant par défaut SELinux , Exec-Shield, fstack-protector , FORTIFY_SOURCE...).
    Un grand nombre de ces protections (option /Gs de vc++, ACL ntfs, ...) sont même désormais intégrées dans les dernières releases de windows, cependant que (selon un sondage mené par debian-administration.org) les developpeurs Debian considèrent la sécurisation comme relativement secondaire (et je ne parle pas des couacs comme l'absence de maj sécu de juillet dernier, le temps de réponse aux problèmes de firefox en aout etc. !).
    Quel dommage s'il fallait se priver de la qualité et stabilité légendaires de Debian (sur ce plan, Debian ne fléchit pas !) pour avoir un environement sécurisé par défaut, lors de la prochaine release (et non, recompiler toute l'archive avec -fstack-protector, créer les polices SELinux pour les daemons courants et le système de base etc. n'est pas une solution triviale. Et oui, ces protections sont devenues nécéssaire, parceque les pirates ont, eux aussi, progréssé. D'où le besoin du secure "by default").
    • [^] # Re: Protection de la pile par défaut sur les prochaines releases des dis

      Posté par  . Évalué à 3.

      Depuis la version Suse 10.0, les applications sont compilées avec l'option -D_FORTIFY_SOURCE=2
    • [^] # Re: Protection de la pile par défaut sur les prochaines releases des dis

      Posté par  . Évalué à 2.

      Je suis particulièrement inquiet pour Debian, qui a longtemps tenu le haut du pavé en matière de sécurité, du fait de la très haute exigence qualité de son équipe de développeurs. Mais qui semble ne plus tenir le rythme
      Les boîtes comme RedHat ont acquis avec le temps de solide base pour développer leurs distributions. Debian est trop dépendant du dévouement, et de la bonne collaboration de ses développeurs. Un orchestre symphonique sans chef d'orchestre produit une cacophonie. Mais des monstres comme M$, IBM ont aussi leurs couacs. Il faudrait un juste milieux.
      • [^] # Re: Protection de la pile par défaut sur les prochaines releases des dis

        Posté par  . Évalué à 7.

        Un orchestre symphonique sans chef d'orchestre produit une cacophonie.

        C'est justement la saison de l'élection du chef d'orchestre chez Debian :
        http://www.us.debian.org/vote/2006/vote_002
      • [^] # Re: Protection de la pile par défaut sur les prochaines releases des dis

        Posté par  . Évalué à 2.

        Oui, c'est assez juste.
        Peut-être pas pour le besoin de dévouement: certaines de ces technologies ne demandent pas beaucoup d'efforts particuliers, le terrain a déjà été déffriché par les autres distros, et il y a aussi du suport commercial derrière Debian (Xandros, Ubuntu, Progeny, DCC, ...), mais je crois que tu a raison en pointant le besoin de collaboration et la difficulté de prendre des décisions collectives comme les causes principales de ce problème.

        Car même lorsque la mise en oeuvre de certaines de ces protections est assez simple, elle doit souvent être appliquée à toute l'archive ou aux composants centraux. Elle demande donc une décision collective (pour les mainteneurs gcc/glibc/kernel de Debian, ça représente peut-être plus de travail que la mise en oeuvre technique).
        Dommage, j'aurai préféré que, même sur ces questions, le modèle de fonctionnement démocratique soit le plus efficace :(

        Pour les chantiers plus lourds (comme l'intégration de politiques RSBAC ou SELinux), il aurait été juste que ceux qui tirent un profit commercial de Debian mettent leur responsabilité en oeuvre. Par exemple que DCC se montre enfin utile, plutot que de faire mal aux mouches !
    • [^] # Re: Protection de la pile par défaut sur les prochaines releases des dis

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

      Je ne suis pas sur qu'il faille toujours suivre RedHat ;-)

      Par exemple, sur SELinux, je prefererais que debian choissise par défaut RSBAC.

      http://www.rsbac.org/
    • [^] # Re: Protection de la pile par défaut sur les prochaines releases des dis

      Posté par  . Évalué à 2.

      En fait, au niveau sécurité, je me demande si SElinux n'est pas plutôt un TROU potentiel de sécurité.
      Après tout, ceux qui l'ont conçu sont les même qui aiment bien écouter les gens.
      • [^] # Re: Protection de la pile par défaut sur les prochaines releases des dis

        Posté par  . Évalué à 3.

        Si j'ai bien compris, ils l'ont conçu pour que Linux puisse répondre à leurs propres critères d'utilisation de logiciels pour des opérations sensibles, en fonction de contraintes légales qui leurs sont imposées.
        Bref, ils sont problablement les utilisateurs qui ont le plus besoin de cette technologie ; il est donc improbable qu'ils aient pris le risque de laisser des trous connus - même cachés. De même qu'ils n'ont surement pas choisi Rijndael pour devenir AES en fonction d'une quelquonque fragilité de l'algorithme, vu qu'ils seront contraints de l'utiliser quotidiennement.

        Celà étant dit il faut reconnaitre que les contraintes de la NSA sont assez tortueuse, et (en conséquence ?) SELinux un poil byzantin.
        Je suis d'accord avec Sytoka Modon (commentaire ci-dessus) pour privilégier RSBAC lorsque l'administration étasunienne n'est pas votre cible: le code est moins volumineux (potentiellement moins de bugs), le système est beaucoup plus facile à mettre en oeuvre (potentiellement moins d'erreurs d'admin) et surtout, certains composants de SELinux sont affectés par de sombres histoires de brevets logiciels qui font froid dans le dos.
        Mais de là à dire que SELinux est une régression en termes de sécurité ....

        Quoiqu'il en soit, ces systèmes sont peut-être contraignants et difficiles à mettre en oeuvre dans une distro (mais certaines l'ont fait ...) mais ça n'est pas le cas des options de renforcement à la compilation, comme fstack-protector et fortify ainsi que de certains patches du noyau ! C'est maintenant une responsabilité des mainteneurs de distribution, de contraindre un minimum de protections en les activants pour les binaires qu'ils produisent.

        Quand on apprend qu'une majorité (je n'ai plus les chiffres en têtes, peut-être 70%) des failles critiques indéxées par le CERT sont des buffers overflow, précisément, ce que protègent ces outils simples et non intrusifs (dont la mise en oeuvre n'est pas lourde mais doit être faite par ceux qui packagent), on peut trouver irresponsable, pour des mainteneurs de distribution, de les ignorer.
  • # C++0x

    Posté par  . Évalué à 4.

    C'est un peu off-topic (enfin pas temps que ca puisque ca sera surement interessant pour les futures-futures-... versions de GCC), mais je suis tombe par hasard sur un enieme article[1,2] de BS expliquant les nouveautes de la prochaine norme pour le C++.

    J'ai trouve que ce concept de "concept" etait vraiment tres interessant et devrait permettre de plus facilement resoudre certains problemes du C++ (notamment les collections d'objets polymorphiques qui devraient pouvoir etre vues comme des collections d'objets a n'importe quel endroit de l'arbre d'heritage)

    Par contre je n'ai pas trouve de mention concernant XTI (eXtended Type Information) [3] qui aurait du/pu resoudre les problemes de persistence des donnees (entre autre!).

    Quelqu'un a de plus amples informations concernant XTI ?

    [1] la version light
    http://www.artima.com/cppsource/cpp0x.html

    [2] la version poussee
    http://www.research.att.com/~bs/popl06.pdf

    [3] http://lcgapp.cern.ch/project/architecture/XTI_accu.pdf
    • [^] # Re: C++0x

      Posté par  . Évalué à 2.

      Par contre je n'ai pas trouve de mention concernant XTI (eXtended Type Information) [3] qui aurait du/pu resoudre les problemes de persistence des donnees (entre autre!).
      Il manque donc l'essentiel ... Les gens qui font les normes ne doivent pas être confronté aux même problèmes pratiques ...
      • [^] # Re: C++0x

        Posté par  . Évalué à 4.

        Mouais...
        Faut pas voir le mal partout, hein...
        Je crois surtout que c'est une histoire de manpower.

        Apparemment, Stroustrup est tout seul a implementer/developper cette librairie...
        Donc normal que cela prenne du temps.

        Moi, le seul reproche que je ferais ce serait: "mais pourquoi diantre ne pousse-t-il pas cette lib dans Boost comme ca pleins de gens (talentueux) s'y mettraient et contribueraient !?".

        Quand on voit le nombre d'applications dans la vraie vie (TM) qu'aurait XTI, je suis sur que ce n'est pas une question du probleme de la "tour d'ivoire".
        Juste un bete probleme de manpower (parce que BS, il a quand meme un vrai boulot aussi a cote).
  • # Commentaire supprimé

    Posté par  . Évalué à 6.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

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