Perso, pour du code multithreadé, je n'ai pas trouvé vraiment mieux que du printf-like[*] et analyse de logs.
Avec bien sûr de la compilation conditionnelle (non seulement globale avec _DEBUG et NDEBUG, mais aussi du DEBUG_MODULE au début des sources C, que je peux commenter/décommenter afin de désactiver/activer les lignes de déboguage d'un module).
L'argument du temps de compilation me semble, en 2006, avec les machines et les compilateurs que l'on a, un peu léger. Ca eu été vrai [**], ça l'est encore pour de très gros projets (OS, KDE & Co), mais faudrais pas exagérer.
Par contre, ça peut en effet avoir un gros inconvénient comme tu l'indiques: ça ajoute du temps d'exécution qui peut faire disparaître des bugs (typiquement quand on fait du pilotage d'instruments).
D'un autre côté, si en qq printf on n'a pas trouvé, en effet, passer au débugger, utiliser des points d'arrêt, de l'affichage du contenu de variables... tu as raison de vouloir montrer l'existence de ces outils, mais de là à considérer que le débogage via des traces est nocif, non.
[*] Des fonctions varargs qui ajoutent quelques infos, et qui soit renvoient vers un système de log, soit font du printf.
[**] Il y a une douzaine d'années j'avais un projet qui mettait une heure et quart à compiler, sur un 486DX33 sous Windows... on évitait autant que possible les "Rebuild All", mais la gestion des compilations sous l'environnement VC++ était suffisament foireuse pour qu'on soit régulièrement obligé de le faire. Quand le Pentium est arrivé, on est tombé à 1/4 d'heure de compil - le bonheur.
Et un peu auparavant, j'avais eu la joie de travailler en assembleur sur un Solar au CEA... compilation de plusieurs heures avec sortie du résultat sur une imprimante - là on dépouille vraiment le résultat.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Mouaif...
Posté par lolop (site web personnel) . En réponse au journal printf debugging considered harmful. Évalué à 5.
Avec bien sûr de la compilation conditionnelle (non seulement globale avec _DEBUG et NDEBUG, mais aussi du DEBUG_MODULE au début des sources C, que je peux commenter/décommenter afin de désactiver/activer les lignes de déboguage d'un module).
L'argument du temps de compilation me semble, en 2006, avec les machines et les compilateurs que l'on a, un peu léger. Ca eu été vrai [**], ça l'est encore pour de très gros projets (OS, KDE & Co), mais faudrais pas exagérer.
Par contre, ça peut en effet avoir un gros inconvénient comme tu l'indiques: ça ajoute du temps d'exécution qui peut faire disparaître des bugs (typiquement quand on fait du pilotage d'instruments).
D'un autre côté, si en qq printf on n'a pas trouvé, en effet, passer au débugger, utiliser des points d'arrêt, de l'affichage du contenu de variables... tu as raison de vouloir montrer l'existence de ces outils, mais de là à considérer que le débogage via des traces est nocif, non.
[*] Des fonctions varargs qui ajoutent quelques infos, et qui soit renvoient vers un système de log, soit font du printf.
[**] Il y a une douzaine d'années j'avais un projet qui mettait une heure et quart à compiler, sur un 486DX33 sous Windows... on évitait autant que possible les "Rebuild All", mais la gestion des compilations sous l'environnement VC++ était suffisament foireuse pour qu'on soit régulièrement obligé de le faire. Quand le Pentium est arrivé, on est tombé à 1/4 d'heure de compil - le bonheur.
Et un peu auparavant, j'avais eu la joie de travailler en assembleur sur un Solar au CEA... compilation de plusieurs heures avec sortie du résultat sur une imprimante - là on dépouille vraiment le résultat.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN