Reprise du message précédent :
n'étant pas programmeur, la qualité des débuggeurs sous nux me laisse froid, par contre, le fait que MS en imposent un au client (pour le moins intrusif si les descriptions sont vraies) dans un soft qui fédère un grand nombre de développeur est pour moi un constat d'échec.

 
 
oue ms c'est des mechants      
 
nan mais faut arreter parfois

 
Les debuggeurs sous nux laissent froid les programmeurs aussi
(on peut meme parler des compilo )

 
désolé mais c'est le cas, MS n'est pas gentil, leur but _est_ de maitriser le marché et si possible le monde (au sens économique du terme).
 
maintenant, tu pourras objecter que c'est le cas de toute les entreprises. Peut-être (surement), mais dans le cas de MS, elle en a les moyens et elle les utilise pour y parvenir, quitte à être dans l'illégalité.

 
Bon, commençons donc à travailler. Je fait un premier essai from scratch, je linke avec la librairie fournie par notre fournisseur, ça compile, ça linke.
 
Je lance mon application pour la première fois, plantage. Bon, c'est pas grave, c'est du C++, j'ai l'habitude. Je vérifie mon code, tout va bien. Et même avec un exemple bête, ça plante. Bon, j'appelle le support :
 
- bonjour, je vous appelle, j'ai un problème, ça plante
(je passe sur les explication)
- vous utiliser quelle version de gcc ?
- 3.2 ?
- quelle version de glibc ?
- 2.3.4
- quelle vers
 
Bon, en fait il s'avère que gcc change d'ABI quasiment à chaque version, obligeant à recompiler tout à chaque fois. Sauf que comme notre fournisseur nous fourni des librairies pré-compilées, il faut EXACTEMENT la même version de compilateur, le librairie C++, de glibc, que lui. Sympa. Heureusement que l'on a qu'un seul fournisseur de biblioythèques. QU'es-ce que cela donnerais avec une dizaine de fournisseurs différents, chacun réclamant une version de gcc différente !
 
Bon, passons. J'ai besoin d'un parseur XML. J'ai de la chance, j'ai le choix sous linux. Je porte mon choix sur Xerces. Je l'utilise partout où j'ai besoin, ça marche pas mal. Et un jour : PAN!, je tombe sur un bug. Bon, ça arrive. Voyons sur le site... Ah oui, il est connu. Et corrigé dans la dernière version. Mise à jour de xerces et ... plus rien ne compile ! A quoi cela sert-il de standardiser l'interface DOM si on peut la changer à chaque version ? En effet, l'API de xerces 1 et de xerces 2 n'ont absolument rien à voir. Donc pour mettre à jour, il faut tout réécrire. Merci. Sympa. FInalement, on va le garder notre bug, on va planquer ça dans un coin, mettre un bout de scotch pour que ça tienne, et ça ira bien.
 
 
Maintenant, l'application commence à être un peu grosse et c'est devenu catastrophique de lenteur ! En effet, gcc est vendu comme un compilateur efficace, respectueux des standards, mais on oublie de dire quelques trucs : c'est une charette incroyable. Pas de support des headers précompilés (sauf dans une hypothétique future version, mais de toutes façon, je suis coincé sur la version actuelle), ce qui fait que la compilation est monstrueusement lente. Mais d'un facteur deux par rapport au visual C++ 6 pour le même fichier.
 
Et le link. Ah ce link. Un vrai bonheur. Le visual C++ 6 est globalement 8 à 10 fois rapide pour linker la même application (en enlevant le link différentiel, sinon c'est pire: 20 fois). Résultat : dans les cycles de débuggage intensif, je perds tellement de temps que ma productivité est divisées par deux ou par trois par rapport à ceux qui font la même chose sous windows (à machine égale bien sur).
 
Et alors pour débugger, ...
 
Je croyais que faire pire que le link n'était pas possible. Et bien si !
 
Sous linux, il n'y a qu'un seul débugger : gdb. C'est con, mais c'est comme ça. Tous les debuggers que l'on trouve sous des surcouches graphique à gdb. J'installe toute une série de débuggeurs, et je les testes.
 
Alors, on commence par supprimer ceux qui n'arrivent pas à charger mon binaire (il fait 100Mo), ceux qui sont incapables d'afficher les sources ensuite (gvd parse toutes les sources, au demmarage, vu la taille, c'est pas une bonne idée, je l'ai tué après une heure), ceux qui ont une interface pourrie et ... il y en a plus un seul.
 
Bon, ne gardons que ceux qui ont une interface pourrie alors. Je fini par utiliser ddd.
 
La commande la plus utilisé dans ce débugger est : "restart debugger". C'est génial comme truc, il perd pieds tous les deux ou trois lancement d'application, se met à s'arrêter n'importe ou, est incapable d'afficher la moindre variable, bon, on recommence (et au passage, on perds les points d'arrêts et les "watchs" que l'on avait posé).
 
Ensuite cet outil est grandiose pour afficher du code. Pas de coloration syntaxique, pas de recherche dans les fichiers ouverts (bon, il faut que je pose un point d'arrêt dans cette méthode, lisons tout le fichier pour la trouver... MERDE, je suis dans le fichier généré par yacc...). Et un vrai bonheur pour lire le contenu des variable, puisqu'il ne reconnais que les tpyes définis dans mon application. Je veux avoir des informations sur un ifstream, ou sur une des classes provenant des bibliothèques fournisseurs, et j'ai le droit à un laconique "incomplete type". Sans compter cet affichage sous forme d'arbre qui est incapable d'avoir un placement correct, et que ça ne dérange pas d'afficher 25 fois la même variable.
 
C'est génial ce débugger. En fait, j'ai généralement plus vite fait d'aller sur une machine windows pour essayer de comprendre ce qui se passe. Au moins, le debugger du visual, il est capable d'afficher toutes les informations que je lui demande.
 
Encore une petite méchanceté pour la route ? Il ne vérifie pas ou on pose les breakpoints. Donc si vous le mettez sur une ligne ou il n'y p pas de code à exécuter, il ne s'arrêtera pas. Bon, on s'y fait. Mais là ou ça devient drôle, c'est que l'on rajoute une ligne de code plus haut, ça décale le code, mais pas les points d'arrêts, donc il ne s'arrêtes plus. Sympa ça.
 
Bon, maintenant je vais devoir attaquer le profiling de l'application. Il va falloir que j'exploite ce que me sortent valgrind et gprof, je crois que je vais avoir de la lecture. Beaucoup de lecture. Au moins pour comprtendre comment marchent ces outils. Avant de lire leurs mégas-octets de logs divers et variés (merci à valgrind qui me sort tous les problème mémoirre de X, notamment leurs utilisations de variables non initialisées, mais c'est mon application qui m'interresse).

 
Eux, je pencherais plus pour Boeing, GE, ou autre, plus que MS (qui courbent l'echine devant le gvt americain)

 
 
Merci beaucoup pour la fraicheur de ton propos, kadreg, je pense que tout le monde va profiter de ton experience et adopter son point de vue en consequence

http://www.liberation.fr/page.php?Article=293309

nan mais serieux, kan c kiya un vrai debuggueur sous linusque

 
Merci pour cette lecture du matin, j'ai bien rigoler

floups : too late, je l'ai déjà forwardé à tous les geeks de mon carnet d'adresse. Un bon moyen de savoir ce que c'est qu'une femme...

Il y a des choses fausses dans ce qu'à dit Elianor ?
J'ai entendu dire que GCC ne changeait plus (enfin !) son API à chaque version. C'est vrai depuis quelle version ?

 
moi mon probleme, c'est surtout qu'avec un compilo du grand mechant, je gagne 30% de perf par rapport a un gcc 3.4.3

Une quoi  

et ça compile sur autre chose que x86/win32 ?

 
Le grand méchant c'est Intel sous linux ?
Ou tu compares GCC et les produits Microsoft équivalent sous Windows ?
Le gain de performance est pour du code C ou C++ ?

j'ai pas teste sur un autre type de plateforme
(le jour ou je veux faire du portable, je me met au java..ou au .Net )

java portable

 
en tout cas pas du java utilisant le jdk de sun

 
je ocmpare mes perfs sous gcc 3.4.3 avec le compilo livre avec visual 2003 (qui semble ne fonctionner que sous windows x86)
 
C++
(code servant principalement a illustrer la diffence de perfs entre les deux)
(mais je note les immenses progres depuis les versions 2.x)

 
C'est du vécu intégral.
 

 
C'est vrai. Sauf bug (les problèmes reportés sont entre gcc 3.2 et 3.2.2, ou il y a un changement pour les paramètres par défaut sur les constructeurs. C'est fstream qui me foutait la merde ...).

 
 
principalement sur telephone portable    
 
code once, execute anywhere
 
(nan, c'est pas ca ?)

 
Y a-t-il un équivalent à xmlspy sous linux ?
 
Edit : kxmleditor à l'air pas mal.

 
kdevelop c'est très bien comme debogueur et comme IDE

 
faut voir le bon coté des choses, tu as le temps et une bonne excuse pour glander sur le forum
 

 
quand c'est ki ya un gcc avec des messages d'erreurs plus clair

j'avais pas vu ca
http://www.hardware.fr/news/7510/N [...] re.fr.html

 
du style "check ur code u moron !"

 
 
bah tu vois je preferais limite, parce que parse error before MACHIN alors que en fait c'est une virgule oublié 5 déclarations aprés  ben c'est con mais quand il l'heure de la fatigue ca fait perdre du temps

 
c'est meugnon tout plein  

T'as qu'à utiliser le compilateur de VC++. Il est très bien, très clair, et il est aussi gratuit que gcc (sauf qu'il est pas "libre", donc tu peux pas te vanter de connaître les 3 étudiants roumains dont le français est le 3ème langue vivante qui en font la traduction).

 
 
bah j'ai besoin d'un truc qui compile sous nulix m'enfin je vais quand meme voir ce que donne ce vc++ ^^
 
 
salouperie de temps climatique de merde, fait trop chaud

Ptite question PHP    
 
Ça marche comment les boutons "prévisaliser" ?  
C'est de quel type le input ? submit aussi ?

le bouton prévisualiser dans punbb :

 
 
bah en gnal ca va, sauf si le code est vraiment "inhabituel"
 
(sauf les .h qui te generent 500 lignes d'erreurs pour un ; oublie

 
 
c'est ce que je dis

 
le visual se limite à 100 erreurs, parce que des fois, il part en boucle sur des erreurs de parsing

 
 
et il a bien raison, parce que 100 erreurs d'un coup tu les corriges pas forcement en une fois (ou en tout cas pas sans en faire d'autres
 
(et gcc aussi se limite sur les erreurs, profondeur de template, toussa )