Souci avec fenetre C++

Bonjour,

Un souci concernant la mise en place d’un software, il me parle de C++ et je n’y connais rien ?

J’ai acheté un software sur le site : http://www.datadoctor.org/

De là on m’a donné un lien pour le telecharger, pas de problèmes, je l‘ai installé, il fonctionnait bien, mais comme j’avais mal rentré des donnés, j'ai voulu le désinstaller ( sous XP avec Ajout/supression des programmes) et cela je l’ai fait 2 fois.

Resultat des courses, lorsque je clic maintenant sur le raccourci, j’ai la fenêtre suivante :


Microsoft Visual C++ Debug Library

Debug Assertion Failed!
Program: ...ta Doctor Ba, Link Checker\Data Doctor Ba, Link Checker.exe
File: fgets.c
Line: 60
Expression: str != NULL
For information on how your program can cause an assertion
falure, see the visual C++ docimentation on asserts
(Press Retry to debug the application)

ET impossible d’aller plus loin.

Pourtant je l’ai installé sans problème sur un autre ordinateur après ?

Dans quelle direction aller pour résoudre cela ?

Merci

Salut,
Le mieux est encore de contacter l'éditeur pour lui signaler ton problème. Ici, cela concerne plus les problèmes de développement. Et visiblement, tu as installé/désinstallé puis réinstallé un soft ... qui visiblement a un bug. L'éditeur est encore le mieux placer pour t'aider.

Merci pour la réponse.
C'est pas des Français qui gèrent cela.

Je leur ai envoyé un mail avec le probleme.. s'ils répondent.. dur..dur.

L'anglais c'est pas mon point fort.

Ça ne choque personne d'entendre parler d'un logiciel vendu en version DEBUG ?
Car les assertions c'est qu'en DEBUG, je me trompe?

Enfin bref, moi j'apporte pas la solution au problème donc je peux me coucher :s

Salut,

Citation:

---

Envoyé par LittleWhite

Ça ne choque personne d'entendre parler d'un logiciel vendu en version DEBUG ?
Car les assertions c'est qu'en DEBUG, je me trompe?

Enfin bref, moi j'apporte pas la solution au problème donc je peux me coucher :s

---

Ce n'est pas aussi net que cela...

On trouve, effectivement, beaucoup d'assertion dans la version debug, mais, d'un autre coté, dans le cadre d'un développement utilisant la programmation par contrat, il y a quelque chose d'illogique à désactiver les assertions dans la version release.

En effet, il est souvent préférable dans un tel contexte de faire en sorte qu'une assertion non respectée provoque l'arrêt pur et simple de l'application (voire d'autres actions particulières) car ce n'est pas forcément parce que le contrat était respecté durant toute la période de tests qu'il se sera encore forcément lorsque l'utilisateur posera se "sales mains pleines de doigts" sur l'application :aie:

Citation:

---

Envoyé par koala01

En effet, il est souvent préférable dans un tel contexte de faire en sorte qu'une assertion non respectée provoque l'arrêt pur et simple de l'application (voire d'autres actions particulières) car ce n'est pas forcément parce que le contrat était respecté durant toute la période de tests qu'il se sera encore forcément lorsque l'utilisateur posera se "sales mains pleines de doigts" sur l'application :aie:

---

Ah! Vous évoquez parfaitement une des questions récentes que je me posais ( d'ailleurs, faudra que je demande l'avis sur le forum bientot ;) )

Mais finalement, dans l'utilisation actuelle que j'ai de l'assertion, c'est plus de la sécurité pour voir si le programmeur en lui même ne fait pas des erreurs de codage ( genre je passe NULL à une fonction ). Comme ça, au lieu d'avoir un bug qui se signalera de manière très aléatoirement, je n'aurais qu'un assert à plus tot.

Citation:

---

Envoyé par LittleWhite

Ah! Vous évoquez parfaitement une des questions récentes que je me posais ( d'ailleurs, faudra que je demande l'avis sur le forum bientot ;) )

Mais finalement, dans l'utilisation actuelle que j'ai de l'assertion, c'est plus de la sécurité pour voir si le programmeur en lui même ne fait pas des erreurs de codage ( genre je passe NULL à une fonction ). Comme ça, au lieu d'avoir un bug qui se signalera de manière très aléatoirement, je n'aurais qu'un assert à plus tot.

---

Attention quand même, ce que j'ai écrit reste à prendre "avec des pincettes" :aie:

En effet, il y a beaucoup de contextes à prendre en compte pour déterminer si une assertion doit être ou non prise en compte dans la version release et, surtout, pour déterminer le meilleur moyen de la prendre en compte.

Tu prend l'exemple d'un pointeur ne pouvant être nul, et c'est, justement l'exemple qui peut s'avérer le plus marquant:

Posons nous d'abord la question de savoir ce qui peut, en version release, provoquer le fait de passer un pointeur nul :P

Ce peut être une erreur de logique, qui aurait du être remarquée en période de test, et la condition n'a, a priori (et pour autant que la batterie de tests soit correcte) pas vraiment à être testée en mode release.

Par contre, le pointeur peut être nul parce que... l'allocation de la ressource a échoué...

Dans ce cas, le contrat est également rompu, mais j'ai presque envie de dire que seules les circonstances sont responsables de cette rupture de contrat...

Tout le problème vient du fait que l'application ne peut absolument pas avoir à elle seule la responsabilité de prendre les mesures nécessaires pour donner l'assurance que le contrat sera respecté en cas de nouvelle tentative:

Elle peut essayer de libérer des ressources dont elle n'a plus besoin, mais ca peut être insuffisant et, dans le pire des cas, si la ressource n'a pas pu être allouée, c'est parce qu'une autre ressource la monopolise voire, suite à une restriction des droits de la part du système d'exploitation...

Dans le premier cas, (l'application tente elle-même de libérer des ressources dont elle est responsable), il faut espérer que cette libération de ressources sera suffisante, autrement, il faudra bien en arriver à quitter d'une manière ou d'une autre l'application.

Dans les autres cas (si une applications monopolise la ressource ou si la ressource est inaccessible suite à une limitation du système d'exploitation), l'application devra être quittée après avoir affiché un message d'erreur...

Oui, mais, si tu travailles en embarqué, tu n'aura pas forcément la possibilité d'afficher ce message d'erreur, et les actions à entreprendre seront donc différentes :P

C'est pour cela que j'estime (parce que j'ai lu un article qui me l'a soufflé, je l'avoue) que, dans la programmation par contrat, les assertions devraient effectivement rester actives dans la version release, même si les actions prises avant de quitter l'application doivent être adaptées à la destination sur laquelle l'application devra tourner ;)

Je suis à peu près en accord avec vous, mais pour moi, le NULL à cause d'un manque de mémoire doit être géré avant de commencer d'envoyer le pointeur un peu partout dans le reste duy programme. Donc, comme ce cas, je le gère ... je me dis que mon assert(pointeur!=NULL), et bah il ne va traiter que les erreurs du programmeur.

Car le cas ou pointeur est NULL serait s'il envoyer un pointeur, qu'il n'a jamais essayé d'allouer ( pour peu qu'il est la bonne habitude de donnée une valeur immediatement à la déclaration ) ou alors le pointeur à été désallouer ( pour peu qu'il remette à NULL le pointeur ).

Bien sur, je ne travaille pas sur les "énormes" ( dans la façon de géré ) cas des systèmes embarquer, ou des UI complexes ou il faut sauver les données des utilisateurs avant de tout quitter. Je pense que j'ai encore de la chance dans ma vie de programmeur.

De plus, dites moi si je me trompe, mais les asserts, une fois que le programme à trouver que la condition n'a pas été respecté, il stoppe le programme et ne libère rien ?
Donc dans le cas ou on laisse l'assert en Release il faut faire un truc du genre:

Code:

---

1 2 3 4

if ( b_assert == false ) // Liberation assert(b_assert);

---

Par exemple ... pour moi c'est un peu redondant :s

Pardon pour le gros hors sujet que j'ai installé :s

L'assertion de base appelle, si je me souviens bien, la fonction exit() qui elle-même invoque la fonction at_exit()

Et il me semble que la fonction at_exit() purge la pile, mais je crains de dire une bêtise sur ce point.

Quoi qu'il en soit, comme l'application rend la main au système d'exploitation juste après, on peut plus ou moins estimer qu'il fera correctement son travail en récupérant la mémoire allouée dynamiquement par l'application (car le problème ne se pose pas pour toutes les variables déclarées sur la pile :D)

Ceci dit, le phénomène est sensiblement identique à celui qui survient lorsqu'une exception est lancée et n'a pas été récupérée dans la fonction main, à ceci près qu'il ne donne pas l'occasion aux fonctions appelantes d'attraper l'exception: c'est le direct vers la sortie au lieu d'être potentiellement un omnibus :D

Je suis d'accord avec LittleWhite: Ce n'est pas aux assertions de gérer un échec d'allocation. Si l'on veut qu'un échec d'allocation détourne le flux du programme, c'est plus une exception qu'il faut utiliser.

Un moment j'aimais bien at_exit.

Jusqu'au jour, ou je me suis rendu compte, que pour faire un truc bien ( avec at_exit ) il fallait tout mettre en globale, pour faire une libération saine à chaque fois.

Par contre, maintenant je suis plus dans un système ou j'utilise un singleton, et la classe singleton "World" a une liste de tous les pointeurs ( car toutes les classes hérite de Object ) et que Object à sa construction, ajoute son pointeur dans World.
Et là, je n'ai plus qu'a detruire mon singleton ... et normalement j'évite toute fuite ...

Mais pour recentrer un peu, l'assertion doit être juste une aide pour le debugguage , et pour moi doit rester qu'en Debug. Si on veut avoir des retour sur les bugs engendré par un utilisateur, on utilise un système de verbose qui permet de faire des traces utile du programme.

En fait, le terme assertion signifie, de manière générale "qui est sensée être vrai"...

Je sais bien qu'une assertion en informatique est souvent considérée comme une aide au débuggage, mais, comme je l'ai indiqué, il n'est pas impossible de prévoir un système qui, en mode debug, fonctionne comme la macro assert et qui, en mode release, lance une exception ;)

Comme je l'ai fait valoir plus haut, si tu désactive l'assertion en mode release, tu peux avoir des surprises si, pour une raison ou une autre, tu es en rupture de contrat alors que, durant toute la période de test, cela ne t'est jamais arrivé.

A ce titre, l'assertion est, effectivement, une aide au débuggage, mais elle doit faire partie intégrante de ta politique de contrat également en mode release ;)