Bonjour,

Je travaille sur un projet en C qui fonctionne très bien. La dernière fois que j'ai essayé de retester mon projet avec les mêmes données, parfois ça marche et parfois ça bug.

Je n'ai pas trouvé la raison pour laquelle il bug.

C'est pourquoi je cherche une fonction en C qui me permettra de savoir quelle était l'erreur.

Merci d'avance

Hello,

marwamokni1 a écrit:

(....) C'est pourquoi je cherche une fonction en C qui me permettra de savoir quelle était l'erreur. (....)

Ça n'existe pas si tu ne l'as pas écrite.

Au pifomètre, c'est le style de comportement qu'on a en cas de dépassement de bornes d'un tableau.

marwamokni1 a écrit:

C'est pourquoi je cherche une fonction en C qui me permettra de savoir quelle était l'erreur.

• Compile ton projet avec les sanitizers clang (-fsanitize=address,undefined en tant que minimum)
• Mets les warnings au maximum (-Wall -Wextra)
• Utilise valgrind, utilise lldb

Il fonctionne pas très bien s'il bug alors

marwamokni1 a écrit:

Je n'ai pas trouvé la raison pour laquelle il bug.

REMETTRE PIECE. ESSAYER ENCORE.

A. Démarche "débugging"

Bon, si ça bugge, c'est qu'à partir d'un moment de l'exécution, ça ne fait pas ce que qu'on voudrait. Y a pas de mystère.

Il faut déterminer quand.

1. Trouver des exemples de données pour lesquelles le problème se pose. Essayer de réduire ces données, pour avoir un exemple minimal.

2. Regarder ce qui se passe. Soit avec un débugger (il faut apprendre à s'en servir), soit en faisant afficher les résultats intermédiaires.

Attention, débugger est une démarche active. C'est pas juste appuyer sur une touche pour passer à l'instruction suivante. Il faut constamment garder en tête ce qui est en train de se passer, et ce qu'on voudrait, sans confondre les deux. Faire des hypothèses ("quand le programme arrive  ici n devrait valoir 12"), les vérifier (breakpoints, consultation variable, tiens c'est 13), et remettre en cause le raisonnement quand ça ne colle pas (c'est la programme qui fait pas ce que je veux, ou je me suis planté et le résultat normal c'est vraiment 13 ?). C'est très fatigant.

On conseille donc de ne pas faire de bugs.

B. Tests unitaires

A défaut, on évite d'avoir à les chercher dans un programme complet. Un programme bien écrit, c'est un tas de fonctions qui ont un rôle bien spécifié.

Donc on écrit des séries de tests qui font tourner les fonctions sur des exemples de données, et vérifient qu'on obtient un résultat déterminé.