Elmoricq a écrit :Je veux bien.
 
 
dakor
 
Je me présente. Je suis spécialiste depuis 10 ans en programmation C++ de haut niveau. J'ai travaillé sur tout une variété de systèmes et de compilateurs dans de nombreuses missions. Un jour, on me propose une mission : un développment en C++ sous linux. Je me dit chouette, enfin une nouveauté. J'était assez enthousiaste après avoir lu quelques articles sur cet OS. J'en bavais d'avance.
 
Et enfin, je commence ma mission. Première étape, installation et configuration de l'OS. La première partie se passe bien, la redhat s'installe comme un charme et reconnais tout sans problème sur ma station de travail. Je lis mon mail, surf sur le web (à la recherche de documentations techniques bien sur), et accède aux ressources partagées des autres machines. Bien. Commençons maintenant à relire quelques spec. Je lance OpenOffice... Je lance OpenOffice ... Ah non, il avait pas planté, il est juste long à ouvrir, pardon. C'est pas grave, ouvrons les documents de spéficication : MAIS C'EST QUOI CETTE HORREUR. Les shémas sont explosés, le mode révision perdu, les polices ont viré au grand n'importe quoi (mention particulière aux polices utilisées comme bibliothèque de symboles techniques). Bon, je ferme cette chose et je vais me l'imprimer depuis autre autre machine. Je met le document dans un dossier partagé de mon PC, et vais embêter un des développeurs sous windows. Voisinage réseau, et ... MAIS OU EST MA MACHINE ?. Rien n'y a fait, après des heures de configurations de samba (avec swat, avec l'outil de redhat qui plante, à la main, tout seul ou avec l'aide de forums), bide complet. Impossible d'acceder à la machine linux depuis les autres machines du réseau. Je me renseigne un peu sur le projet samba, et j'apprends qu'ils ne travaillent que par reverse engeenering sur les protocoles, et qu'ils sont extrèmements en retards. Ici, je suis dans un réseau windows 2000 avec active directory et tout le tralala, et bien, ça ne marche pas. La version de samba présente sur ma machine ne reconnait pas ce protocole.
 
Bon, je vais devoir bosser avec toutes mes specs imprimées sur papier, et sans contact réseaux. Merci, on a pas l'impression de retourner en arrière.
 
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).