La liste des changements signale également la suppression des options qui avaient été marquées obsolètes dans la version 3.3.x ou encore des problèmes de compatibilité binaire pour les plateformes SPARC ou MIPS.
![[en]](../images/en.png)
GCC (1635 hits)-
Changements (1300 hits)
-
Liste des miroirs (477 hits)
-
Obsolète (533 hits)
-
Liste des corrections (513 hits)
> Lire la dépêche (136 commentaires, moyenne: 1,8).
Vous avez demandé le commentaire #396685.
Run by 
Cette page a été générée par Templeet en 0.1854s (dont 0.0291 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Une release importante
Pour ceux qui utilisent le C++, ils y a deux points qui me semblent importants:
* La mise en oeuvre des "precompiled headers"
* Une réécriture complète du moteur de parsing du C++
Et bien entendu, une quantité impressionnante de corrections de bugs.
Bravo !
Lucio
[^]Re: Une release importante
precompiled headers ou comment diviser par 20 les temps de compilation!
AMHA, c'est une des plus grosses avancees de gcc. Si ca marche comme je l'espere. Tu compile un fois un gros header avec la stl qt et tout le bordel de ton projet, et hop, tes fichiers de 300 lignes se compilent instanements..
Je est un autre.
[^]Re: Une release importante
Pour l'instant c'est plus une "preview feature".
[^]Re: Une release importante
A noter que sous windows, _sans_ les precompiled header, visual compile deja entre 3 et 10 fois plus vite que gcc sous linux. Ca se sent des qu'on tape sur un gros projet.
Sinon, le but d'etre compatible standard pour etre compatible standard, c'est bof. Comme gcc est le seul compilateur aussi respectueux des standards, si tu ecris du code au poil pour gcc, j'ai peur que ce soit une garantie de peter sur d'autres compilateurs.
Pis le standard C++, c'est quand meme une horreur.
phil.freehackers.org
[^]Re: Une release importante
A noter que sous windows, _sans_ les precompiled header, visual compile deja entre 3 et 10 fois plus vite que gcc sous linux. Ca se sent des qu'on tape sur un gros projet.
VC++ compile tout en meme temps, ca laisse forcement la voie libre a pleins d'optimisations assez simples. genre, si tu as deja vu ce header avec le fichier precedent, hop, tu recupere le code qui est reste en memoire. ( bon, c pas aussi simple, ya des differences de contextes)
Mais bon, avec le systeme de makefile de unix, c'est plus complique a mettre en oeuvre avec gcc)
Je est un autre.
[^]Re: Une release importante
Donc en fait, il faudrait passer a un truc plus moderne que les makefile ? Pourquoi pas. Je payerai cher pour me debarasser des autotools et ca ne me generait pas tant que ca d'y inclure les makefile, si on propose un bon systeme equivalent.
Sinon, je note l'objectivite habituelle des linuxiens de base qui ont moinsse a tout va mon commentaire. Je m'interroge si c'est le fait que j'ai ose dire que un programme sous windows est mieux qu'un programme sous linux ou simplement que les gens moinssent des qu'ils voient le mot windows.
Dans les autres points ou on est a la rue sous linux, c'est les debuggeurs. On a que gdb et force est d'admettre qu'apres avoir utilise un debuggeur sous d'autre environnements (Visual pour ne pas le citer), on se rend compte que gdb est une bouse. En ce moment, je galere sous un projet parce que gdb refuse de suivre le chemin d'execution. Il me fait du step-by-step dans toutes les fonctions Qt mais zappe allegrement toutes mes fonctions a moi. Une vraie horreur.
phil.freehackers.org
[^]Re: Une release importante
...moinssent des qu'ils voient le mot windows.
Tu as raison... et ce n'est certainement pas à cause de ta justification rigolote de ne pas utiliser les standards !
[+] [^]Re: Une release importante
Si ton programme doit être portable, et que tu colles à mort à un standard qui n'est respecté que par un compilateur, t'as pas l'air con... Faut savoir être pragmatique dans la vie.
[^]Re: Une release importante
En général les compilateurs sont plus permissifs que le standard.
C'est bien la première fois que j'entends que coder selon les standards (du langage j'entends) rend le code moins portable.
Tu fais comment pour faire du code portable si tu ne suis pas le standard ?
PS : Bon je sais que quand les standards sont trop jeunes, les implémentations sont pas faites etc ... C'est par exemple (rien à voir avec les compilateurs, quoi que) ce qui se passe avec la dernière version du protocole MPI.
[^]Re: Une release importante
Parfois tu as des compilateurs vraiment pourri. Prenons au hasard Visual C++ (le meme qui est super rapide):
for( int i=0; i<1; i++) do_something();
for( int i=0; i<1; i++) do_something();
Le deuxieme ne va pas compiler ("variable i already declared") car Visual, dans sa magnitude, declare les variables de boucle a l'exterieur de l'espace de la boucle.
Ce cas est un peu extreme mais je suis sur que si tu chatouilles les template, tu es oblige d'ajouter des bugfix un peu partout pour chaque compilateur.
phil.freehackers.org
[^]Re: Une release importante
C'etait le cas dans VC6 mais heureusement il n'existe plus dans VC7, il et y a une option qui permet d'avoir l'ancienne portée du for.
[^]Portée des boucles for
En fait dans les première versions de la norme C++, la règle était que la portée d'une variable était le bloc d'accolade englobant, ce qui implique qu'un compilateur conforme au standard devait refuser de compiler ton code ci-dessus.
Comme c'était pas très intuitif,au début des années 90, la norme a été changée pour que les variables déclarées dans un for soient locales à la boucle.
Comme les gens qui ont conçu Visual voulaient garder un maximum de compatibilité avec le vieux code, ils ont fait en sorte que par défaut celui-ci applique l'ancienne règle de portée.
La nouvelle règle est en fait bien présente dans le compilateur mais n'est utilisée que si tu compile avec le flag --ansi.
[^]Re: Une release importante
Donc en fait, il faudrait passer a un truc plus moderne que les makefile ? Pourquoi pas. Je payerai cher pour me debarasser des autotools et ca ne me generait pas tant que ca d'y inclure les makefile, si on propose un bon systeme equivalent.
Non, je pensait plus a une sorte de gccd qui gèrerait cette cache.
il est lancé en début de makefile avec les options qui vont bien et on remplace $CC par un truc genre gcc-client, qui se connecte au serveur et qui donne le fichier a compiler. Comme ca on garde la gestion des dépendances de makefile tout en pouvant faire des optimisations de caches.
Cela dis, je délire surement totalement..
Je est un autre.
[^]Re: Une release importante
c'est prévu ! http://gcc.gnu.org/ml/gcc/2003-02/msg01911.html(...)
[^]Re: Une release importante
Le mail dont tu parle date d'un an. Des infos sur l'avancement du projet?
J'ai bien peur que ce projet ce soit transformé en "precompiled header support"
Je est un autre.
[^]Re: Une release importante
>J'ai bien peur que ce projet ce soit transformé en "precompiled header support
Je ne pense pas mais chaque chose en son temps, il y a une foule d'évolution qui sont prévues pour gcc. Ce document en est un excellent aperçu :
http://www.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf(...)
Ils y parlent entre-autre du "GCC compile server". L'idée est d'avoir un serveur de compilation (attention, il ne s'agit pas de compilation distribuée) qui compile l'ensemble des modules en gardant en mémoire ce qui a déjà été compilé. Non seulement ça permet d'obtenir des temps de compilation plus court (ils pensent obtenir de meilleurs résultats qu'avec les fichiers d'entête pré-compilé) mais ça permet d'effectuer davantage d'optimisations (comme les fonctions inline inter module). Ils tiennent à ce que la modification du makefile requise pour utiliser cette fonctionnalité soit minime (juste ajouter un paramètre à l'appel de gcc du style --server).
[^]Re: Une release importante
> Sinon, je note l'objectivite habituelle des linuxiens de base qui ont moinsse a tout va mon commentaire.
Rappel de ton post :
>> Sinon, le but d'etre compatible standard pour etre compatible standard, c'est bof.
>> Pis le standard C++, c'est quand meme une horreur.
Et
>> Comme gcc est le seul compilateur aussi respectueux des standards, si tu ecris du code au poil pour gcc, j'ai peur que ce soit une garantie de peter sur d'autres compilateurs.
Remplaçons gcc par mozilla et compilateur par navigateur pour voir ce que ça donne :
Comme mozilla est le seul navigateur aussi respectueux des standards, si tu ecris du code au poil pour mozilla, j'ai peur que ce soit une garantie de peter sur d'autres navigateurs.
Le moinsage ne me surprend pas.
> gdb est une bouse.
Utilise les debuggeurs des unix commerciaux (quand il n'utilise pas déjà gdb). La bousse aura soudain un parfum de rose.
Pour moi gdb est la rolls des debuggeurs et ddd est une bonne interface graphique.
Si gdb déconne sur ta distribution, fait un rapport de bug.
[^]Re: Une release importante
Remplaçons gcc par mozilla et compilateur par navigateur pour voir ce que ça donne :
Une page fonctionnera toujours plus ou moins, en mode dégradé, sur IE ou Opera.
Un source qui ne compile pas, ne compile pas. Il n'y a pas de demie-mesure.
[^]Re: Une release importante
Ça n'enlève rien au principe de respecter les standards.
Si tu fais du spécifique icc ou gcc, tu auras encore plus de problème.
Il faut que les compilateur s'alignent. Je préfère qu'il s'alignent sur des standards que le :
- "nivellement pas le bas pour que ça passe partout"
- ou "je code gcc comme un porc car je veux qu'il supporte les saloperies de Visual C".
[^]Re: Une release importante
Le probleme des standards ne se limite pas a l'axiome "tu dois respecter les standards". Je bosse par exemple dans un milieu (la carte a puce sans-contact) ou les mecs qui ecrivent les standards sont malheureusement un peu trop chercheurs. Ils ont plein de bonnes idees qui sont irrealisables techniquement, mais qui passent dans les standards. Resultat, le standard est impossible a implementer avec la techno d'aujourd'hui.
Par le passe, certains standards ont ete rendus completement obsoletes parce que impossible a implementer. Chacun est partie sur sa solution proprio et il faudra encore quelques annees pour refaire la convergence.
On a aussi eu des standards completement merdique au niveau du protocole.
Bref, implementer le standard est a priori une bonne idee sauf quand ce n'est pas le cas. Quel est l'interet d'un standard si difficile a implementer que personne ne peut le faire avant 10 ans ? Nul. La consequence, c'est qu'on va avoir 10 ans de soi-disant transition pour que les compilateurs rattrappent leur retard sur le standard pas pique des vers. Sauf que les messieurs du standards, parce qu'ils s'ennuient et pour justifier leur salaire, ils continuent a faire evoluer le standard. Donc au lieu de garantir l'interoperabilite comme il devrait le faire, le standard ne fait que mettre un poid sur les developpeurs.
Le probleme est particulierement apparent avec le C++ qui est un langage vraiment trop complexe quand on le creuse bien. Il apparait aussi un peu avec le w3c. Le xhtml c'est bien. Le SVG, c'est une super idee, mais quand on voit la difficulte d'implementation, on peut se questionner aussi. A quoi ca sert de definir une norme aussi difficile a implementer ? Si elle est tres difficile a implementer, elle ne va pas assurer l'interperabilite.
Je prefere de loin l'approche des RFC qui pour obtenir un statut final doivent montrer deux implementations reussies pendant plusieurs mois (c'est l'idee, je ne me souviens plus des details).
phil.freehackers.org
[^]Re: Une release importante
> Je prefere de loin l'approche des RFC qui pour obtenir un statut final doivent
> montrer deux implementations reussies pendant plusieurs mois (c'est l'idee, je
> ne me souviens plus des details).
Le coup des deux implémentations est maintenant vrai pour le W3C aussi.
[^]Re: Une release importante
Bonne nouvelle. Et c'est retro-actif ? J'aimerai bien voir les deux browsers qui supportent parfaitement le SVG.
phil.freehackers.org
[^]Re: Une release importante
amaya et mozilla compile avec les bonnes options?
[^]Re: Une release importante
Il y a largement plus de deux implémentations de SVG correctes. Par contre, effectivement je ne parle pas forcément des browsers.
Coté implémentation il y a un plugin Adobe, il me semble que macromédia (ou une autre boite du même milieu/niveau) a lancé un truc concurent, (le tout est pour MSIE/win, le plugin Adobe est de nouveau compatible mozo win/linux mais sans le support des scripts et des animations, ce qui limite pas mal). Mozilla et Amaya ont un support partiel SVG (qui a été refait récement pour Mozo, mais qui n'est toujours pas activé par défaut). X-SMILE sait faire du SVG à peu près correct.
> Et c'est retro-actif ?
Comment tu veux faire du rétro-actif la dessus ? les normes qui existent existent, je ne vois pas ce qu'ils peuvent en faire d'autre même si les implémentations actuelles ne sont pas complètes/parfaites.
[^]Re: Une release importante
Je suis d'accord avec toi. C'est le *principe* de respecter les standards qu'il faut retenir. Après, au cas par cas, on respecte ou non les standards. Mais ne pas respecter les standards gratuitement, sans bonnes raisons, est nul.
> Quel est l'interet d'un standard si difficile a implementer que personne ne peut le faire avant 10 ans ?
Ça fait une roadmap pour les 10 ans à venir :-)
Mozilla a mis combien de temps pour respecter les standards ?
Mozilla serait aussi bon si le projet devait aussi faire le travail réalisé par le w3c ?
De plus, qui participe pour faire les standards ? Pour w3c c'est mozilla, etc. Bref ceux qui réalisent des navigateurs et/ou utilisent le web.
> Sauf que les messieurs du standards, parce qu'ils s'ennuient et pour justifier leur salaire, ils continuent a faire evoluer le standard.
Là tu abuses. Il faut toujours un standard d'avance si le standard actuellement utilisé n'est pas satisfesant. Regarde le "merdier" des débuts d'html car il n'y avait pas de standard en avance. Des navigateurs incompatibles, des normes qui sortent à l'arrache pour remettre de l'ordre (html 3.2 et 4).
Maintenant que le w3c a repris de l'avance, tout le monde bossent dans la même direction.
De plus des nouveaux standards qui remplacent l'ancien il n'y en a pas tous les jours (regardes pour le C/C++ et SQL et compte le nombre de standard ANSI par exemple et divise par le nombre d'année).
Enfin, les nouveaux standards font toujours très attentions à la compatibilité. C'est plus rarement le cas des initiatives isolées.
Freedesktop travail pour faire des standards et éviter le bordel et la guerre entre Gnome et KDE.
Les standards c'est bien.
[^]Re: Une release importante
> Maintenant que le w3c a repris de l'avance, tout le monde bossent dans la même direction.
La, tu as raison, je me suis un peu egare.
Tout ca pour dire que les standards, je suis a fond pour mais quand meme avec quelques reserves d'ordre pragmatiques. La, j'en chie avec un protocole de merde developpe il y a 10 ans et encore utilise partout dans la carte a puce: T=0. Priez pour ne pas avoir a l'utiliser un jour.
phil.freehackers.org
[^]Re: Une release importante
Dans les autres points ou on est a la rue sous linux, c'est les debuggeurs. On a que gdb
DDD tu connais?
[^]Re: Une release importante
Oui, il connait, il sait que c'est un front-end à gdb.
[^]Re: Une release importante
Tout a fait. C'est d'ailleurs celui que j'utilise. J'ai bien essaye kdbg mais il est vraiment trop limite a l'utilisation.
ddd a des trucs un peu chiant (l'idee de sauver toutes les sessions avec un no a 25 chiffres) mais est quand meme bien pratique.
Sinon, quelqu'un sait ou trouver le plugin python pour ddd ? J'ai trouve des liens qui en parlent sur internet mais impossible de trouver ou il est.
phil.freehackers.org
[^]Re: Une release importante
> Il me fait du step-by-step dans toutes les fonctions Qt mais zappe allegrement toutes mes fonctions a moi. Une vraie horreur.
Ton programme est compilé sans aucune optim (ie aucun flag -O) ? Depuis gcc 3.qqchose, gdb a souvent du mal quand tu compiles en -O2, en le virant tout redevient normal en général.
[^]Re: Une release importante
Lorsque j'utilise gdb, j'ai pour habitude de compiler avec "-O0 -g2". C'est peut-être plus nécessaire mais ça marche bien.
[^]Re: Une release importante
gdb est largement superieur au debugeur de visual studio, au moins en temps que debugeur symoblique.
ex: tu as surchargé l'operateur[] dans une classe (au hasard la classe std::vector), et tu lui demandes d'afficher la 3eme valeur. Il suffit de faire un simple print a[3], sous VC++ c'est impossible on ne peut pas appeler une fonction operateur !
Pour ton probleme, tu dois avoir des problemes de flags de compil.
[^]Re: Une release importante
j'ai verifie, mes flags de compile sont ok, mes sources sont en phase avec mes binaires, je vois pas d'ou ca vient.
en fait, les limitations des logiciels dependant vachement de la facon dont tu les utilises. La facon dont j'utilise le debugger de visual ne m'a pas montre de limitations, alors que la facon dont j'utilise gdb oui.
Sous gdb, break my_class::my_method() ne marche toujours pas pour moi. J'en suis encore a mettre des no de lignes.
phil.freehackers.org
[^]Re: Une release importante
> break my_class::my_method() ne marche toujours pas
Faut virer "()"
[^]Re: Une release importante
Je peux t'assurer qu'une fois que tu maitrise gdb, le debugueur de VC++ est a la rue pour les trucs compliquer...
W-Fenec : Webzine rock/métal/indus
[^]Re: Une release importante
Bon ba puisqu'on parle de gdb : j'ai jamais réussi à debugger un programme avec des méthodes "inlinées". Il se plante toujours dans les numero de lignes. Si vous avez une solution, ça me ferait vraiment plaisir :)
[^]Re: Une release importante
Faut compiler avec -O0 et/ou -fno-inline .
[^]Re: Une release importante
J'ai prèsque jamais utilisé d'autres debuggeurs, mais j'utilise gdb de façon intensive, et je peux t'assurer que quand ça marche, c'est super, mais pour le C++, ça ne marche pas souvent.
J'ai régulièrement des segfaults de gdb, des fois, il passe sans s'arrêter sur un breakpoint (OUI, mon code est compilé avec -g), ... Mais la situation a tendance à s'améliorer avec le temps, alors ... wait&see !
[^]Re: Une release importante
Et avec ou sans -Ox ?
« Unlike most other C compilers, GCC allows you to use -g with -O.
The shortcuts taken by optimized code may occasionally produce sur-
prising results: some variables you declared may not exist at all;
flow of control may briefly move where you did not expect it; some
statements may not be executed because they compute constant
results or their values were already at hand; some statements may
execute in different places because they were moved out of loops.
»
(du man de gcc)
[^]Re: Une release importante
sans -O. Pas fou l'autre, le débug de code optimisé, je laisse ça a d'autres ;-)
[^]Re: Une release importante
va dire ça aux autres ... la majorités des trucs que tu récupères sous forme de source sont compilés en -g -02 ...
y a une différence entre -g et -ggdb ?
[^]Re: Une release importante
Tu vas 1 peu vite à dire qu'un programme sous windows (Visual), est mieux qu'un programme linux. Pour 1 projet scolaire en C++ j'avais une appli à développer, qui devait compiler aussi sous Win pour pouvoir bosser avec mon binôme et sur une partie de code largement tiré du Stroustrup et standard après m'être renseigné, ben VC++ m'a tranquillement jeté. Pour 1 prog qui est mieux, bof bof...
Sinon, comme l'a dit 1 autre contributeur c'est sûrement ton argument "massue" sur le respect des standards qui t'as value le moinssage.
[^]Re: Une release importante
Et dans ce cas que se passe-t-il si "tout en meme temps" ça ne tient pas en mémoire (dans le cas d'un très gros programme) ?
C'est une question parce que du temps ou je codais en VB, j'ai l'impression d'avoir eu ce problème... du coup l'approche "compilation fichier par fichier de façon indépendante" de python (ou dans une moindre mesure java) me paraît meilleure.
[^]Re: Une release importante
Tiens, je crois (je suis même presque sûr) que OCaml permet cela. D'ailleur, il me semble que s'est en partie pour permettre la compilation indépendante de modules que Xavier Leroys y a inclue la notion de "spécification de type manifeste". Il faudrait que je regarde d'un peu plus près (en tout cas, les module en OCaml, c'est un vrai bonheur).
[^]Re: Une release importante
Je ne savais pas que VC++ fonctionnait comme ça mais du coup, quelle est l'intéret des fichiers d'entête pré-compilé ?
[^]Re: Une release importante
N'importe quoi !
Visual c++ utilise devenv.exe qui a son tour utilise cl.exe qui est le compilo standalone de MS.
Visual C++, comme gcc, compile les fichiers un par un.
Visual C++ est plus rapide a compiler que gcc. C'est un fait. Mais Visual C++ avale des trucs 100 fois moins complique que gcc aussi. Des qu'on essaye de faire des trucs un peu sioux avec des templates, Visual C++ a besoin d'etre tenu par la main pour inferer les types. Pas gcc. Bon il y a quand meme eu de sacre ameliorations sur la Version 7 (.NET) depuis la version 6. Mais AMHA, Visual est encore loin de gcc en ce qui concerne le respect du standard.
Visual C++ ne compile que pour une architecture. Combien d'archi de supportee par gcc ?
[^]Re: Une release importante
Tout ca est vrai. Notamment avec boost, visual souffre pas mal.
Mais ca me fait mal quand je compile mon projet en 1 minute sous windows et 5 minutes sous Linux. Va t'en defendre l'excellence technique de linux et la nullite de microsoft apres ca.
En plus linux, le truc dont il regorge, c'est vraiment des developpeurs. On pourrait s'attendre a ce que les outils soient nickels et faciles a utiliser mais c'est loin d'etre le cas.
phil.freehackers.org
[^]Re: Une release importante
Je suis d'accord avec toi : ca fait mal de compiler plus vite sous windows que linux.
Je ne repondais que sur la partie fausse "windows compile tous les fichiers d'un projet en une seule passe et garde un buffer en memoire de sa precedente compilation". ouf !
Personnellement, je trouve que les outils sont nickels : ils marchent et permettent de faire des trucs que l'on ne peut pas faire facilement sous windows.
C'est vrai qu'au niveau rapidite ce n'est pas la panacee. La cause est connue : les multiples architectures et les multiples langages supportes par gcc.
[^]Re: Une release importante
Si tu compares la derniere version de VC++ (.NET 2003), tu verras que celui qui est a la rue niveau standards n'est pas forcement celui qu'on croit
[^]Re: Une release importante
Ben justement, je bosse tous les jours sur Visual C++ 7.1.3088 (.NET framework 1.1.4322) ...
Le pire a la limite, c'est pas tant sur le respect des standards (ils ont fait de gros efforts de ce cote la), mais c'est le reporting d'erreur.
Regulierement, vc++ sort une internal error parce qu'en signalant une erreur dans ton code il se plante sur sa reprise sur erreur...
Ce qui est marrant aussi c'est que de temps en temps un gars de l'equipe fait un portage sur Linux/gcc. Ca lui permet de trouver des bogues que gcc nous remonte via des erreurs/warnings que vc++ ne voit pas ...
[^]Re: Une release importante
Je suis un grand fan du couple GCC/GDB pour le développement, je développe toute la journée avec GCC et je fais de temps en temps un port VC.NET et il est évident pour moi que ta dernière phrase marche très bien dans l'autre sens.
En règle générale, le fait d'utiliser plusieurs compilateurs/platformes sur un projet apporte un énorme gain en robustesse.
[^]Re: Une release importante
Oui, j'ai le meme probleme de reporting d'erreurs dans VS7.1. A tel point que j'utilise g++ pour compiler et verifier les erreurs. Mais il est vrai que VS7.1 a fait d'enormes progres du coté du respect des standard et notamment du coté des templates, deja avec VS7.0 il y avait eu des progres importants mais maintenant on peut dire que VS7.1 est au niveau de gcc du coté du respect des standard.
[^]Re: Une release importante
cf. http://www.cs.clemson.edu/~malloy/papers/ddj2/paper.pdf(...) pour une comparaison du respect des standards par les differents compilos.
Quand aux internals errors, ca je veux bien le croire, j'en ai rencontre 2 dernierement, mais ca tous les compilos en ont, j'en ai rencontre sur gcc/g++ aussi.
[^]Re: Une release importante
ça m'etonnerai que le gain de vitesse vienne de là, vu que sous VC++ aussi il y a un compilateur en ligne de commande comme sous UNIX. Il est juste appelé en tâche de fond par l'IDE, mais c'est un processus à part.
D'ailleurs, sous Windows aussi tu peux utiliser des makefiles avec NMAKE.
[^]Re: Une release importante
> * Une réécriture complète du moteur de parsing du C++
Est-ce que ça veut dire que c'est la fin des "Parse error before '('" et qu'on aura enfin des vrais messages d'erreur ?
[+] [^]Re: Une release importante
Je vois pas ce que tu leurs trouves aux messages d'erreur actuels.
Tu préférerais un message du type "il manque surement un point-virgule ou une accolade avant '('. Il faudrait que tu sois plus concentré pendant que tu codes, codeur de m...".
[^]Re: Une release importante
Code 5 minutes en Ada avec GNAT, et tu comprendras ce que c'est qu'un message d'erreur explicite.
Sur
#include
string ma_fonction(int x);
g++ 3.2 donne
errmsg.cpp:2: parse error before `)' token
Bon, il était pas obligé de me dire
"string should be std::string"
mais si il me disais
"string: identifier not declared"
Je serais déjà content.
[^]Re: Une release importante
Bien évidemment, il fallait lire
#include < string >
string ma_fonction(int x);
C'est encore templeet le méchant qui m'a bouffé une balise ...
[^]Re: Une release importante
g++-3.4 /tmp/to.cpp
/tmp/to.cpp:2: erreur: « string » ne nomme pas un type
c'est donc bien mieux :)