parce que le printf debugging c'est mal, ça peut faire apparaitre des bugs étranges ou les faire disparaitre (dans tous les cas c'est la merde)
parce que savoir quand une variable est modifié et par ou (avoir la stack), est parfois essentiel à la correction d'un bug.
parce que des traces trop verbeuses peuvent avoir un gros impact sur les perfs; l'appli sur laquelle je bosse fait des traces de plusieurs centaines de Mo à l'heure, et on essaye de retreindre…
Parce que changer une valeur sans avoir à tout recompiler permet de tester des cas plus larges.
Parce que les tests unitaires ne valent jamais un utilisateur.
Parce qu'un fichier core, est le bonheur du dev devant corriger un bug.
Parce que dès qu'on joue un petit peu avec des theads, les traces ont un impacte dans l’ordonnancement.
Parce que les debuggeur ont largement évolués depuis la grande époque où poser un breakpoint sur un symbole dans gdb te faisais passer pour un gourou, et que maintenant on peut avoir la complétion automatique ou la pose d'un breakpoint sur une regexp. Parce que les watchpoint c'est quand même vachement plus pratique que de devoir recompiler tout le code.
Parce que quand on fait de l'objet, trouver la chaine pertinente à écrire dans les traces c'est pas toujours une partie de plaisir
Parce que emacs avec gdb-multi-window ça fait quand même vachement plus gourou, que le gars qui rajoute à tout va std::cout << FILE << ":" << LINE << "chaine absurde car les traces sont trop verbeuse, ça permet de faire un grep" << std::endl ;
Parce que gdb --pid $(pidof progEnCoursDexecution) permet de voir pourquoi le truc ne fait pas ce qu'il devrait sans avoir à recompiler et rajouter des traces.
Parce qu'une fonction ne dépends pas que de ses paramètres (accès à une base de donnée par exemple), et que tout tracer est vraiment galère.
Parce que ça ne plante jamais là où ça devrait.
Parce que valgrind n'est pas toujours suffisant
Bref, si j'use pas mal le printf debugging, bien souvent je m’aperçois que j'aurais été plus rapide avec un gdb
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Oui
Posté par fearan . En réponse au journal Un debugger est-il indispensable ?. Évalué à 5.
parce que le printf debugging c'est mal, ça peut faire apparaitre des bugs étranges ou les faire disparaitre (dans tous les cas c'est la merde)
parce que savoir quand une variable est modifié et par ou (avoir la stack), est parfois essentiel à la correction d'un bug.
parce que des traces trop verbeuses peuvent avoir un gros impact sur les perfs; l'appli sur laquelle je bosse fait des traces de plusieurs centaines de Mo à l'heure, et on essaye de retreindre…
Parce que changer une valeur sans avoir à tout recompiler permet de tester des cas plus larges.
Parce que les tests unitaires ne valent jamais un utilisateur.
Parce qu'un fichier core, est le bonheur du dev devant corriger un bug.
Parce que dès qu'on joue un petit peu avec des theads, les traces ont un impacte dans l’ordonnancement.
Parce que les debuggeur ont largement évolués depuis la grande époque où poser un breakpoint sur un symbole dans gdb te faisais passer pour un gourou, et que maintenant on peut avoir la complétion automatique ou la pose d'un breakpoint sur une regexp. Parce que les watchpoint c'est quand même vachement plus pratique que de devoir recompiler tout le code.
Parce que quand on fait de l'objet, trouver la chaine pertinente à écrire dans les traces c'est pas toujours une partie de plaisir
Parce que emacs avec gdb-multi-window ça fait quand même vachement plus gourou, que le gars qui rajoute à tout va std::cout << FILE << ":" << LINE << "chaine absurde car les traces sont trop verbeuse, ça permet de faire un grep" << std::endl ;
Parce que gdb --pid $(pidof progEnCoursDexecution) permet de voir pourquoi le truc ne fait pas ce qu'il devrait sans avoir à recompiler et rajouter des traces.
Parce qu'une fonction ne dépends pas que de ses paramètres (accès à une base de donnée par exemple), et que tout tracer est vraiment galère.
Parce que ça ne plante jamais là où ça devrait.
Parce que valgrind n'est pas toujours suffisant
Bref, si j'use pas mal le printf debugging, bien souvent je m’aperçois que j'aurais été plus rapide avec un gdb
Il ne faut pas décorner les boeufs avant d'avoir semé le vent