Discussion :

[mchk0123]

J'aimerais faire un sondage rapide :

Quel débuggeur utilisez vous (standalone ou intégré) pour des programmes C++ lorsque vous développez avec des outils open source ?

[Luc Hermitte]

Celui du compilo ? Ce n'est pas comme si il y avait beaucoup de choix dans la gamme des compilos open-source. J'ai pu en manquer, mais j'en vois deux. GCC (=> gdb pour débugguer), et je crois que le compilo de Sun est passé open-source dans la continuité d'open-solaris (=> dbx).

Note: pour linux il y a clewn (un patch pour que vim intègre gdb) et http://zero-bugs.com/ (qui semble être une alternative à gdb qu'il semble intéressante à considérer) que je testerai à l'occasion.

[mchk0123]

Merci.

Pour info, j'ai essayé dbx, il est trés trés proche de gdb (à moins que ce ne soit l'inverse ;-)) mêmes fonctions, même présentation, il n'y a que les commandes qui changent un peu.

Pour ce qui est des front-ends aux debuggeurs, vous avez des retours d'expérience ?
J'avais essayé il y a quelques temps ddd, plutôt complet et simple d'utilisation.
En existe-t'il d'autres ?

[Luc Hermitte]

ddd n'est qu'une encapsulation vaguement graphique. Derrière, c'est gdb, dbx, ou un troisième autre debuggueur qui sera utilisé.

De temps en temps je m'en sers car c'est plus pratique pour visualiser le code tandis que je me ballade dans la pile d'appel des crashs.
Ce qui n'empêche pas que je fais explicitement appel à certaines primitives propres à dbx quand je veux explorer l'état des divers threads. De temps à autres ddd se fige, voire plante alors que dbx s'en sort un chouilla mieux. dbx est extensible dans un dialecte dérivé de ksh. ddd, je n'ai toujours pas trouvé comment lui dire que l'exploration (graphique) d'une std::string doit se contenter d'afficher une seule info (la donnée pointée dont le nom est dépendant de telle ou telle implémentation de la SL), ni comment filtrer les affichages avec STLfilt.

Bref, ce n'est quand même pas l'apanacée quand on a connu VC++.

Après, il existe d'autres encapsulations. Pratiquement chaque IDE se lance là dedans. Certains m'avaient parus mieux foutus comme Code Insight (de cygnus/redhat) je crois.

Mais je ne suis toujours pas convaincu. J'attends de rebosser sous linux pour tester zero-bugs.

[mchk0123]

Mais j'y penses, je me rappelles avoir utilisé un front-end graphique à dbx, front-end qui était livré avec le compilateur C++ de SUN.
Bon il était pas super joli, mais éfficace et surtout trés stable.

Je me rappelles plus de son nom, mais si dbx est passé en libre, il y a de fortes chances qu'il soit aussi disponible. Je vais investiguer tout ça ... A bientôt.

[Luc Hermitte]

Ils ont des outils qui me semblent très intéressants (*) avec leur version 10 ou 11 de leur suite de développement (qui est maintenant open-source).
Malheureusement, au taf' on a une vieille version du compilo (et de l'OS), et vu l'état d'avancement du projet les chances de montée de version ne cessent de diminuer.

(*) ils ont des trucs pour détecter les inter-blocages, et suivre plus simplement les fuites de mémoire.

[mchk0123]

Arf ... impossible de trouver le nom du programme front-end.

D'ailleurs de mémoire, le seul endroit où figurait son nom c'était dans .../bin et dans les man pages ...

Comme ça fait presque 7 ans que j'ai plus touché à une SUN, ... ça risque d'être difficile.

[Luc Hermitte]

Tu t'es balladé depuis http://developers.sun.com/sunstudio/index.jsp ?

[mchk0123]

Oui oui déjà vu que SUN mettait effectivement en libre STUDIO 11.
Ils ont bien avancé depuis lors, en particulier je retiens OpenMP 2.5 + génération de code pour archi x64 ? (par contre c'est pas trés clair là dessus).
En tout cas c'est un joli cadeau d'avoir porté leur compilateur C/C++ (et aussi forcément JAVA) sur Linux x86-x64.

Note : Je savais même pas pour SUN OS 10.