Re: Oui

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)

On peut en dire autant du debuggeur, il y a aussi des bugs qui ne se produisent qu'en dehors du debuggeur.

parce que savoir quand une variable est modifié et par ou (avoir la stack), est parfois essentiel à la correction d'un bug.

C'est vrai mais honnetement ça ne m'arrive pour ainsi dire jamais , à par dans les cas où ça sent la corruption de mémoire , et là en général je commence par sortir valgrind

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…

Il suffit de ne pas faire des traces monstrueuses, debugger au printf pour moi ça ne veut pas dire farcir chaque ligne de code avec un printf("prout oulala %d:%d\n", FILE,__LINE__) , tout comme je ne commence pas par lacher un milliard de breakpoints avant de demarrer gdb

Parce que changer une valeur sans avoir à tout recompiler permet de tester des cas plus larges.

Certes

Parce que dès qu'on joue un petit peu avec des theads, les traces ont un impacte dans l’ordonnancement.

Le debuggeur aussi , d'autant plus si tu as été obligé de recompiler ton code avec les optimisations un peu moins fortes pour avec des stack trace qui ressemblent à quelque chose