Discussion :

[Udani]

Bonjour,

j'ai écris un code en C++, l' un des résultats (output)que j'avais eu est le suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

-1.#IND

ça veux dire quoi svp?
c'est bizzare,

[3DArchi]

NaN.
Ton calcul échoue (par exemple sqrt(-1) retourne NaN).

[befalimpertinent]

ça sent la division par zero.
Postes le bout de code qui provoque cette sortie pour qu'on puisse t'en dire plus

[JolyLoic]

Une division par 0 donnerait un infini, pas un NAN.

[Garulfo]

Bonjour,

j'ai écris un code en C++, l' un des résultats (output)que j'avais eu est le suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

-1.#IND

ça veux dire quoi svp?
c'est bizzare,

C'est la manière dont Microsoft signale un "Quiet NaN". Tu pourras trouver un peu d'explication ici : http://www.cisl.ucar.edu/docs/trap.e...rrortypes.html
Tu as fait une opération qui ne mène pas à un nombre. 3DArchi t'en donnes un exemple. Ça n'a rien de bizarre donc.

Vérifies tes calculs au fur et à mesure, quitte à placer des asserts avant les opérations sensibles. Une bonne activité de débuggage en vue donc.

[Garulfo]

ça sent la division par zero.
Postes le bout de code qui provoque cette sortie pour qu'on puisse t'en dire plus

Mauvaise idée. Il faut qu'il cherche par lui-même. Si on l'aide, il retombera dans le piège la prochaine fois. S'il en bave, il va s'en souvenir

[Udani]

Merci pour vous réponses. En effet il s'agit d' un valeur "qui n' est pas bonne" et qui est presque nul. J'ai utilisé un autre compiler ( DevC++ au lieu de Visual C++ 2005 express ) qui a donné une valeur qui est : 2.23237e-307 !!!
je vais essayer de vous poster la partie du code concernée.
Mais avant je tiens à vous informer que j'ai pas encore compris ce que fait le debbugeur. Serais t-il possible de connaitre la partie de ma méthode qui est la cause de mon malheur ? comment ? aidez moi svp!

[koala01]

Salut,

D'après ce que tu écris, j'aurais tendance à dire que tu essaye de faire une opération mathématique (sans doute une division) avec des valeurs dont l'une au moins n'est pas correctement initialisée.

Si tu travailles avec des structures (ou des classes) pense à respecter scrupuleusement le principe du RAII (Ressource Aquisition Is Initialisation, ou, si tu préfères en français : l'acquisition de ressources est l'initialisation).

Si tu travailles avec des pointeurs, veilles à bien utiliser la valeur "pointée par" ton pointeur, car, autrement, la valeur utilisée sera... le résultat de la conversion de l'adresse en valeur, et tu aura compris que ce n'est sans doute pas ce que tu veux faire

Si, enfin, tu travailles "simplement" avec des variables de types "primitifs", veille à ce que leur valeur soient "cohérentes" avec ce à quoi elles servent.

Peut être devrais tu régler ton compilateur sur un mode "paranoïac" et veiller à trouver une solution pour supprimer chaque avertissement qu'il t'affiche (en commençant par le premier, car il y en a parfois "en cascade" )

[Garulfo]

[...]
je vais essayer de vous poster la partie du code concernée.
Mais avant je tiens à vous informer que j'ai pas encore compris ce que fait le debbugeur. Serais t-il possible de connaitre la partie de ma méthode qui est la cause de mon malheur ? comment ? aidez moi svp!

Tu n'as pas besoin d'un débuggeur: apprends à tracer toi même ton programme avant d'utiliser un débuggeur (et par la suite, apprends à utiliser un débuggeur pour ne pas galerer bêtement). Place régulièrement dans ton programme des affichages aux points sensibles. Tu verras avec quelles valeurs tu fais ton calcul. C'est long, pénible et error-prone lorsque tu les enlèves. Mais c'est un bon apprentissage.

Comme je l'ai dit tu peux aussi ajouter des asserts (#include <cassert>)

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
resultat = sqrt(valeur) / coefficient ;

deviendrait, par exemple,

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
assert (valeur > 0);
assert (coefficient != 0);
resultat = sqrt(valeur) / coefficient ;

dépendant de ce que tu penses avoir à ce moment du code. Ceci à l'avantage de ne pas demander de modifications de code une fois que tu as fini. Pour ne pas tenir compte des asserts tu rajoutes

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

#define NDEBUG

juste avant l'include.

[...]
Peut être devrais tu régler ton compilateur sur un mode "paranoïac" et veiller à trouver une solution pour supprimer chaque avertissement qu'il t'affiche (en commençant par le premier, car il y en a parfois "en cascade" )

C'est un très bon conseil. J'impose toujours à mes étudiants de mettre le maximum d'avertissement (option --Wall) et tous les enlever. Quand on fait des programmes de débutant, on devrait toujours pouvoir le faire.

[befalimpertinent]

Place régulièrement dans ton programme des affichages aux points sensibles

Pas d'accord, modifier le contexte autour de l'erreur c'est la meilleur façon de la perdre. Apprendre à utiliser un debugeur est le meilleur conseil qu'on puisse lui donner.
Avec VS, par exemple, places un point d'arret à un endroit suspect (F9), exécutes en mode Debug ton programme et vérifies les valeurs en exécutant ton code pas à pas(F10) . ça ne devrait par résister trop longtemps.

[Jean-Marc.Bourguet]

Apprendre à utiliser un debugeur est le meilleur conseil qu'on puisse lui donner.

Je crois que les opinions varient. Apprendre a se passer du debugueur est a mon avis un meilleur conseil que d'apprendre a s'en servir.

Je ne suis pas de ceux qui les prétendent inutiles mais leur utilité est plus limitée que ne l'affirment ceux qui les prétendent indispensables. Ils sont souvent aussi une perte de temps énorme quand ils ne sont pas la meilleure technique.

[3DArchi]

Je crois que les opinions varient.

Effectivement, c'est presque du domaine du troll. A mon sens, si tu maîtrise le debugger, utilise-le de façon privilégiée. Sinon, les bonnes vieilles traces ont aussi du bon. Mais c'est souvent plus laborieux. Mais avant de préférer l'un à l'autre, autant maîtriser son environnement de dev.

[Jean-Marc.Bourguet]

Effectivement, c'est presque du domaine du troll. A mon sens, si tu maîtrise le debugger, utilise-le de façon privilégiée. Sinon, les bonnes vieilles traces ont aussi du bon. Mais c'est souvent plus laborieux. Mais avant de préférer l'un à l'autre, autant maîtriser son environnement de dev.

Bizarre, mon point de vue est que le debugeur est souvent plus laborieux au final. Plus incremental, donc on veut voir tout de suite et on réfléchit moins a l'aspect d'ensemble; or c'est en reflechissant qu'on trouve les problemes. Ca tient aussi a la nature des bugs recherche -- les miens sont souvent des interactions subtiles ou une vision trop pres du code n'indique pas la nature reelle du probleme.

[3DArchi]

Bizarre, mon point de vue est que le debugeur est souvent plus laborieux au final. Plus incremental, donc on veut voir tout de suite et on réfléchit moins a l'aspect d'ensemble; or c'est en reflechissant qu'on trouve les problemes. Ca tient aussi a la nature des bugs recherche -- les miens sont souvent des interactions subtiles ou une vision trop pres du code n'indique pas la nature reelle du probleme.

A la réflexion, tu as raison au moins à 50%. Mon expérience m'a plutôt amené à penser que 80% de bugs sont dus à des lacunes en tests unitaires, et donc on les trouves plus facilement avec le debugger. Mais là où je te rejoint, c'est que les bugs subtils (multi-thread, réseau, dynamique d'échange de messages windows ...) sont en général plus facilement diagnostiqués en analysant la dynamique d'ensemble avec des traces.