jeudi 10 avril

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Articles précédents : Développeur

[11] Lancement du Google Summer of Code™ 2008
[173] LLVM 2.2 : Un concurrent pour GCC ?
[11] Appel à présentation pour le sous-thème Système/Embarqué des RMLL 2008
[15] Sortie de Grails 1.0
[52] Acceleo 2.2.0 : nouveaux générateurs PHP, Python et JEE
[132] Sortie de Vala 0.1.6
[4] Jelix 1.0
[8] PMO v 0.12 est sorti
[83] Ruby 1.9.0 est sorti pour Noël
[8] Sortie de Tcl/Tk 8.5.0

Liens connexes

GCC (385 hits)
Les nouveautés de GCC 4.3 (1511 hits)
Portage du code vers GCC 4.3 (480 hits)
La bibliothèque arithmétique GMPLib (306 hits)
La bibliothèque de calcul de précision MPFR (326 hits)

Dépêche modérée par

rootix

Dépêche éditée par

Développeur : Sortie de GCC 4.3

Posté par patrick_g (page perso, ). Modéré le 10 mars 2008.

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 (385 hits)
Les nouveautés de GCC 4.3 (1511 hits)
Portage du code vers GCC 4.3 (480 hits)
La bibliothèque arithmétique GMPLib (306 hits)
La bibliothèque de calcul de précision MPFR (326 hits)

> Lire la dépêche (137 commentaires, moyenne: 3,4).

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.

Fortran

Posté par ciol () le 10/03/2008 à 13:28. (lien). É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.

[ Répondre ]

[^]Re: Fortran

Posté par caouis () le 10/03/2008 à 15:47. (lien). É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).

[ Répondre ]
- [^]Re: Fortran
  
  Posté par Albert () le 10/03/2008 à 16:09. (lien). É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...
  
  [ Répondre ]
- [^]Re: Fortran
  
  Posté par Albert () le 10/03/2008 à 16:40. (lien). É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 :)
  
  [ Répondre ]

Merci pour cette news !

Posté par Maxime (Jabber id, ) le 10/03/2008 à 13:40. (lien). Évalué à 10.

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

Merci Patrick.

[ Répondre ]

[+] [^]Re: Merci pour cette news !

Posté par William Dauchy (page perso, ) le 10/03/2008 à 13:54. (lien). Évalué à -1.
tres bon !

--
Chty

[ Répondre ]

[^]Re: Merci pour cette news !

Posté par Pierre Jarillon (page perso, ) le 10/03/2008 à 15:11. (lien). Évalué à 4.
Normal que ce soit bon, c'est Patrick G. toujours égal à lui-même !

Je voudrais ajouter que Mandriva aussi a prévu de passer à Gcc 4.3. Mais ce sera après la version 2008.1 qui en est actuellement à l'étape de RC1.
La source de l'information : http://wiki.mandriva.com/en/2008.1_Detailed_Specifications

[ Répondre ]

[+] [^]Re: Merci pour cette news !

Posté par pa_pitufo_pa () le 12/03/2008 à 09:48. (lien). Évalué à -1.
O oui patrick_g, donne nous du plaisir oooooo

[ Répondre ]

Bug avec le kernel Linux

Posté par yannig (page perso, ) le 10/03/2008 à 13:43. (lien). É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 ...

[ Répondre ]

[^]Re: Bug avec le kernel Linux

Posté par patrick_g (page perso, ) le 10/03/2008 à 13:52. (lien). Évalué à 10.
La dépêche évoque le problème non ?

[ Répondre ]
- [^]Re: Bug avec le kernel Linux
  
  Posté par yannig (page perso, ) le 10/03/2008 à 13:55. (lien). Évalué à 0.
  Exact, j'avais pas fait gaffe que ça y été ...
  
  [ Répondre ]
  - [^]Re: Bug avec le kernel Linux
    
    Posté par patrick_g (page perso, ) le 10/03/2008 à 14:08. (lien). Évalué à 7.
    A noter que LWN propose un bon article explicatif avec plein de commentaires intéressants => http://lwn.net/Articles/272048/
    Il est pour l'instant réservé aux abonnés et ne sera libéré que jeudi 20 mars (c'est l'occasion de s'inscrire à LWN pour aider à faire vivre le meilleur site technique sur Linux qui existe).
    
    [ Répondre ]

Surtout...

Posté par Francois Revol (page perso, ) le 10/03/2008 à 13:54. (lien). Évalué à 0.

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

[ Répondre ]

[^]Re: Surtout...

Posté par Snarky (Jabber id, page perso, ) le 10/03/2008 à 15:06. (lien). Évalué à 10.
Déjà que visiblement, il compile pas Linux...

[ Répondre ]
- [^]Re: Surtout...
  
  Posté par Mjules (page perso, ) le 10/03/2008 à 18:26. (lien). Évalué à 2.
  Le svn d'il y a trois jours le compile en tout cas :
  http://fate.multimedia.cx/
  
  [ Répondre ]
  - [^]Re: Surtout...
    
    Posté par Matthieu C () le 10/03/2008 à 19:43. (lien). Évalué à 3.
    oui mais il donne sur x86 des binnaires plus lent que les precedentes version de gcc...
    
    [ Répondre ]

Auto vectorisation

Posté par Ontologia (page perso, ) le 10/03/2008 à 15:44. (lien). É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...

[ Répondre ]

[^]Re: Auto vectorisation

Posté par Troy McClure (page perso, ) le 10/03/2008 à 17:36. (lien). É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];
}

?

[ Répondre ]
- [^]Re: Auto vectorisation
  
  Posté par Ontologia (page perso, ) le 10/03/2008 à 18:03. (lien). É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.
  
  [ Répondre ]
- [^]Re: Auto vectorisation
  
  Posté par Thomas Douillard () le 10/03/2008 à 18:38. (lien). É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".
  
  [ Répondre ]
  - [^]Re: Auto vectorisation
    
    Posté par Troy McClure (page perso, ) le 10/03/2008 à 18:56. (lien). É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.
    
    [ Répondre ]
    - [^]Re: Auto vectorisation
      
      Posté par Nicolas Boulay () le 11/03/2008 à 16:31. (lien). É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é.
      
      [ Répondre ]
      - [^]Re: Auto vectorisation
        
        Posté par Troy McClure (page perso, ) le 11/03/2008 à 16:49. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: Auto vectorisation
        
        Posté par Nicolas Boulay () le 11/03/2008 à 16:54. (lien). É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.
        
        [ Répondre ]
- [^]Re: Auto vectorisation
  
  Posté par Benjamin Dauvergne () le 10/03/2008 à 23:07. (lien). É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.
  
  [ Répondre ]
- [^]Re: Auto vectorisation
  
  Posté par benoar (Jabber id, ) le 12/03/2008 à 15:15. (lien). É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 ...
  
  [ Répondre ]
  - [^]Re: Auto vectorisation
    
    Posté par Troy McClure (page perso, ) le 12/03/2008 à 15:23. (lien). É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
    
    [ Répondre ]

closures

Posté par Guillaume Gimenez (page perso, ) le 10/03/2008 à 16:15. (lien). Évalué à 1.

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

[ Répondre ]

[^]Re: closures

Posté par Gilles G. () le 10/03/2008 à 16:25. (lien). Évalué à 3.
Les closures, c'est pas une caractéristique du langage plutôt que du compilateur?

[ Répondre ]
- [^]Re: closures
  
  Posté par MrLapinot (Jabber id, page perso, ) le 10/03/2008 à 16:32. (lien). Évalué à 2.
  Gcc implémente une extension à C pour gérer les fonctions internes, mais avec un mécanisme de trampoline, pas de fermeture.
  
  --
  Mr Lapinot - Electrons prisonniers (blog)
  
  [ Répondre ]
  - [^]Re: closures
    
    Posté par Guillaume Gimenez (page perso, ) le 10/03/2008 à 16:42. (lien). É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.
    
    [ Répondre ]
- [^]Re: closures
  
  Posté par Guillaume Gimenez (page perso, ) le 10/03/2008 à 16:37. (lien). É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
  
  [ Répondre ]
  - [^]Re: closures
    
    Posté par loufoque () le 10/03/2008 à 22:03. (lien). É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.
    
    [ Répondre ]

gcc lave plus blanc ?

Posté par Philippe Fremy (page perso, ) le 10/03/2008 à 19:14. (lien). É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.

--
phil.freehackers.org

[ Répondre ]

[^]Re: gcc lave plus blanc ?

Posté par gpe () le 10/03/2008 à 19:48. (lien). É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.

[ Répondre ]
- [^]Re: gcc lave plus blanc ?
  
  Posté par reno () le 11/03/2008 à 10:24. (lien). É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..
  
  [ Répondre ]

[^]Re: gcc lave plus blanc ?

Posté par stephwww () le 10/03/2008 à 20:38. (lien). É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).

[ Répondre ]

[^]Re: gcc lave plus blanc ?

Posté par Ontologia (page perso, ) le 10/03/2008 à 20:49. (lien). É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.

[ Répondre ]
- [^]Re: gcc lave plus blanc ?
  
  Posté par patrick_g (page perso, ) le 10/03/2008 à 20:56. (lien). É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.
  
  [ Répondre ]
  - [^]Re: gcc lave plus blanc ?
    
    Posté par stephwww () le 10/03/2008 à 21:35. (lien). É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.
    
    [ Répondre ]
    - [^]Re: gcc lave plus blanc ?
      
      Posté par med (page perso, ) le 10/03/2008 à 21:49. (lien). É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.
      
      [ Répondre ]
      - [^]Re: gcc lave plus blanc ?
        
        Posté par Zenitram (page perso, ) le 11/03/2008 à 09:40. (lien). É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 ;-)
        
        [ Répondre ]
  - [^]Re: gcc lave plus blanc ?
    
    Posté par loufoque () le 10/03/2008 à 22:16. (lien). É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++.
    
    [ Répondre ]
    - [^]Re: gcc lave plus blanc ?
      
      Posté par Gof (Jabber id, page perso, ) le 10/03/2008 à 23:18. (lien). É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.
      
      [ Répondre ]
      - [^]Re: gcc lave plus blanc ?
        
        Posté par Julien () le 11/03/2008 à 17:02. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Gof (Jabber id, page perso, ) le 11/03/2008 à 20:35. (lien). É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)
        
        [ Répondre ]
        
        [+] [^]Re: gcc lave plus blanc ?
        
        Posté par loufoque () le 11/03/2008 à 22:14. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par rewind () le 11/03/2008 à 22:59. (lien). É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).
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Gof (Jabber id, page perso, ) le 11/03/2008 à 23:03. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par left () le 12/03/2008 à 08:42. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Pinaraf (Jabber id, ) le 12/03/2008 à 08:52. (lien). É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:
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par shbrol () le 12/03/2008 à 09:02. (lien). Évalué à 2.
        Ca c'est pour "Q_OBJECT". Et pour "signals:", il se passe quoi ?
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Gof (Jabber id, page perso, ) le 12/03/2008 à 09:28. (lien). É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?(...)
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par shbrol () le 12/03/2008 à 10:08. (lien). É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 ?
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Gof (Jabber id, page perso, ) le 12/03/2008 à 10:25. (lien). É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
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par shbrol () le 12/03/2008 à 11:55. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Pinaraf (Jabber id, ) le 12/03/2008 à 12:16. (lien). É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)
        
        [ Répondre ]
      - [^]Re: gcc lave plus blanc ?
        
        Posté par Luc Hermitte (page perso, ) le 12/03/2008 à 14:03. (lien). É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).
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Troy McClure (page perso, ) le 12/03/2008 à 14:33. (lien). É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
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Luc Hermitte (page perso, ) le 12/03/2008 à 14:40. (lien). Évalué à 2.
        hum ... std::for_each() ?
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Troy McClure (page perso, ) le 12/03/2008 à 14:53. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Etienne () le 12/03/2008 à 15:00. (lien). É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
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Troy McClure (page perso, ) le 12/03/2008 à 15:15. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Luc Hermitte (page perso, ) le 12/03/2008 à 15:37. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Moonz () le 13/03/2008 à 09:15. (lien). É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...)
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Luc Hermitte (page perso, ) le 12/03/2008 à 15:30. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Troy McClure (page perso, ) le 12/03/2008 à 15:53. (lien). É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"
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Etienne () le 12/03/2008 à 14:46. (lien). É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).
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Troy McClure (page perso, ) le 12/03/2008 à 14:58. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Etienne () le 12/03/2008 à 15:08. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Troy McClure (page perso, ) le 12/03/2008 à 15:21. (lien). É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).
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Gof (Jabber id, page perso, ) le 12/03/2008 à 14:48. (lien). É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 ?
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Etienne () le 12/03/2008 à 14:52. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Philippe Fremy (page perso, ) le 12/03/2008 à 17:00. (lien). É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 ?
        
        --
        phil.freehackers.org
        
        [ Répondre ]
    - [^]Re: gcc lave plus blanc ?
      
      Posté par Troy McClure (page perso, ) le 10/03/2008 à 23:30. (lien). É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.
      
      [ Répondre ]
    - [^]Re: gcc lave plus blanc ?
      
      Posté par alberthier (page perso, ) le 11/03/2008 à 11:08. (lien). É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.
      
      [ Répondre ]
      - [^]Re: gcc lave plus blanc ?
        
        Posté par Luc Hermitte (page perso, ) le 11/03/2008 à 15:03. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par alberthier (page perso, ) le 11/03/2008 à 17:03. (lien). É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.
        
        [ Répondre ]
        
        [^]Re: gcc lave plus blanc ?
        
        Posté par Luc Hermitte (page perso, ) le 11/03/2008 à 18:36. (lien). É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++)
        
        [ Répondre ]
    - [^]Re: gcc lave plus blanc ?
      
      Posté par Philippe Fremy (page perso, ) le 11/03/2008 à 17:05. (lien). É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.
      
      --
      phil.freehackers.org
      
      [

Articles précédents : Développeur

Liens connexes

Dépêche modérée par

Dépêche éditée par

Développeur : Sortie de GCC 4.3

Fortran

[^]Re: Fortran

[^]Re: Fortran

[^]Re: Fortran

Merci pour cette news !

[+] [^]Re: Merci pour cette news !

[^]Re: Merci pour cette news !

[+] [^]Re: Merci pour cette news !

Bug avec le kernel Linux

[^]Re: Bug avec le kernel Linux

[^]Re: Bug avec le kernel Linux

[^]Re: Bug avec le kernel Linux

Surtout...

[^]Re: Surtout...

[^]Re: Surtout...

[^]Re: Surtout...

Auto vectorisation

[^]Re: Auto vectorisation

[^]Re: Auto vectorisation

[^]Re: Auto vectorisation

[^]Re: Auto vectorisation

[^]Re: Auto vectorisation

[^]Re: Auto vectorisation

[^]Re: Auto vectorisation

[^]Re: Auto vectorisation

[^]Re: Auto vectorisation

[^]Re: Auto vectorisation

closures

[^]Re: closures

[^]Re: closures

[^]Re: closures

[^]Re: closures

[^]Re: closures

gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[+] [^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?

[^]Re: gcc lave plus blanc ?