Discussion :

[sphere369]

Bonjour,

J'ai lu le chapitre sur les méthodes de debugages expliquees dans le livre "C++ trucs et astuces pour les nuls"...mais a moins que ce soit moi qui me trompe cela m'a l'air d'embrouiller plus qu'autre chose.

Qu'en pensez vous? Notamment des methodes de tracages de flux....

Comment au quotidien procedez vous pour le debugage (sous VC+6).

D'avance merci pour votre aide.

Sphere

[Davidbrcz]

Tout le monde n'a pas accès à ce livre.
Peux tu détailler les méthodes.

Merci.

[LittleWhite]

Bonjour,

Je dirai ma méthode change selon le bug. Sous Visual Studio , j'ai tendance à vérifier les valeurs de mes variables, pour être bien sur qu'elle contiennent ce que j'attends.
( Je n'ai pas accès au livre non plus :p )
Il faut savoir qu'un débuggage commence par un bug, les genres dépendent ( erreur de segmentation, fuite de mémoire , ou comportement imprévu ( "programme ne faisant pas ce qu'il doit" ) )
Pour les bugs de comportement :
Lorsque je code, et que j'aperçois le bug, je regarde bien ce qu'il m'affiche ( dépend si c'est du graphique , du texte ... ) et je refléchit, comment ce cas arrive, après je vais placer mes breakpoints pour examiner ce cas

Les erreurs de segmentation, c'est simple, Visual coupera le programme avant son crash, on remonte la pile d'execution pour voir son propre code, et regarde qu'elle valeur pause problème et hop un breakpoint quelque ligne d'avant pour pouvoir retracer le problème en ayant toute les données.

Au sinon, un papier et un crayon c'est très bien

[3DArchi]

( Je n'ai pas accès au livre non plus :p )

Je confesse être un fanatique du debugger :
-> Pour voir l'état de ma/mes variables,
-> Pour voir le retour des fonctions de bibliothèque (boîte noire) que j'appelle (parfois il y a une distance entre la doc et le comportement observé),
-> Pour comprendre du code complexe plus rapidement qu'en l'analysant de manière statique,
-> Avec visual, pour voir comment mes templates sont résolus,
-> Et bien d'autre cas qui sont tellement évident qu'ils ne me viennent pas à l'esprit.

J'ai cette démarche quand j'ai un bug ... mais aussi quand j'en ai pas. L'analyse avec une feuille et un crayon doit être la première étape, mais ensuite, comme pour tout théorie, il faut confirmer les prévisions aux observations

Enfin, le debugger n'est pas le seul outil. Les traces sont aussi des moyens assez puissant pour analyser du code, et en particulier pour en avoir une vue dynamique.

[Mat007]

Salut,

Depuis que je fais des tests unitaires je ne débogue quasiment plus (un peu de temps en temps dans les cas où "ça plante" mais c'est très rare).
C'est bien je trouve comme méthode, on gagne beaucoup de temps et on peut se concentrer sur ce qui est utile.

MAT.

[3DArchi]

Salut,

Depuis que je fais des tests unitaires je ne débogue quasiment plus (un peu de temps en temps dans les cas où "ça plante" mais c'est très rare).

Les tests U (comme tous les tests) sont aussi une indispensable pratique pour produire du code fiable. Cela ne m'empêche pas de continuer à utiliser le debugger. J'utilise les testU 'seuls' généralement pour la non régression. Pour les premières validations, je regarde quand même si tout se passe comme j'ai cru l'écrire.

[sphere369]

Enfin, le debugger n'est pas le seul outil. Les traces sont aussi des moyens assez puissant pour analyser du code, et en particulier pour en avoir une vue dynamique.

Bonjour,

D'apres le tutoriel de Laurent Gomila (page 22, paragraphe "5.2 - Les points de trace", la possibilité de créer des traces (= tracage de flux) semble prise en compte avec Visual Studio 2008: Merci de bien vouloir confirmer cette conclusion.


Les codes montrés ci-dessous ( Inclusion du traçage dans les applications et journalisation des applications) n'ont ils donc plus aucun intérêt des lors que l'on utilise Visual Studio 2005 ou 2008?

[koala01]

Bonjour,

D'apres le tutoriel de Laurent Gomila (page 22, paragraphe "5.2 - Les points de trace", la possibilité de créer des traces (= tracage de flux) semble prise en compte avec Visual Studio 2008: Merci de bien vouloir confirmer cette conclusion.


Les codes montrés ci-dessous ( Inclusion du traçage dans les applications et journalisation des applications) n'ont ils donc plus aucun intérêt des lors que l'on utilise Visual Studio 2005 ou 2008?

Une réponse de normand se profile face à cette question.

Dans "un monde parfait", tu as effectué tous les tests possibles et imaginables, et tu es sur à 100% que ton application est absolument exempte de bugs au moment où elle passe en production (comprend: au moment où elle est fournie au "client").

Tu peux donc envisager de supprimer les taces de ta version "release".

La journalisation est un peu différente: elle peut "simplement" avoir comme objectif de fournir... un journal d'activité qui peut parfaitement être nécessaire "par ailleurs", ce qui la rend malgré tout de facto indispensable.

Seulement...

Si nous vivions dans un monde parfait, tout le monde aurait du travail, il n'y aurait plus ni guerre ni racisme, tout le monde mangerait à sa faim, et j'aurais une charmante personne pour dormir près de moi toutes les nuits

De plus, il ne faut pas oublier que ton application peut être soumise à des situations dont elle n'est pas personnellement responsable: si tu essaye d'accéder à un fichier verrouillé par une autre application, tu subira de plein fouet une erreur à laquelle ton application est strictement incapable d'apporter une solution correcte

Tout cela pour dire qu'il faut malgré tout pondérer les expressions comme "je suis sur qu'il n'y a plus la moindre erreur dans mon code" ou "je suis sur d'utiliser la meilleure logique possible"...

C'est cette pondération qui te permettra soit de réévaluer ton point de vue, soit de considérer que rien n'est jamais acquis, et surtout pas le "0 défauts" (parce que ton application peut subir des défauts qui ne sont pas de son propre chef).

Et, si tu garde cette indispensable pondération dans ton point de vue, tu te rend compte que ce n'est pas parce qu'un outil particulier te fournit une possibilité qui reste, malgré tout, indispensable y compris une fois que ton application a quitté le stade du développement, que tu peux décider d'abandonner cette possibilité aux bons soins seuls de cet outil