Debugger - problème avec les "double"

Bonjour,

J'ai de gros problèmes d'incohérence avec le debugger Borland C++ Builder.

Explication :

Code:

---

1 2 3

double fAbstract = monObjet.getAbstract(); if( fAbstract > 0 ) monTraitement();

---

la variable fAbstract a la valeur 2519691 par exemple, et le débugger refuse catégoriquement de rentrer dans la fonction monTraitement();
J'arrive à corriger le problème, en supprimant le .obj de mon fichier et en supprimant le fichier .tds
Cela me fait perdre beaucoup de temps dans mon développement puisque, lorsque je teste mes développements je tombe sur des problèmes qui n'existent pas puisque c'est le débugger qui part dans les choux.

Je travaille dans un très gros projet, pour info le tds fait un peu plus de 52Mo. Le débbuger a été patché pour qu'il accepte une telle taille de projet...

Néanmoins quand je fait de petites modifs dans certains fichier, je tombe sur des erreurs étranges comme je viens de l'expliquer...

Quelqu'un peut il m'aiguiller?

Si besoin de plus d'info, me le demander.... Merci d'avance.

Essaie:

Code:

---

if (fAbstract > 0.0)

---

ou la grosse artillerie:

Code:

---

if ((double) fAbstract > (double) 0.0)

---

pour éviter la conversion en int du compilateur

En fait cela n'a rien à voir, ce n'est pas un effet de bord.

J'ai une valeur bien suppérieure à 0, c'est vraiment le débugger à mon sens qui lache...

Pourquoi parles tu uniquement du debugger ? En dehors de l'exécution sous debugger, l'application (et notamment le test que tu donnes en exemple) fonctionne t'elle ?

Bonjour,

j'ai le même problème avec BCB 5, dans un gros projet également.

cependant, changer le "0" en "(double)0.0" n'a rien changé au problème, et en ce qui me concerne ma solution depuis un moment déjà c'est le reboot... donc pas très pratique non plus...

que dire de plus sinon que ce n'est pas systématique, ce qui est d'autant plus étrange (et malheureusement "acceptable" vu qu'un reboot règle la plupart du temps le problème).

J'ai essayé, il y a de ca un moment, de chercher un peu partout si il y avait des limites connues de BCB ( en terme de tailles de fichiers de traitements et autre ) mais je n'ai rien trouvé...

voili voilou, en espérant que ces soucis inspirent quelqu'un...

A bientot.
nasplit.

josse95, si je parle du debugger c'est parce que je vois bien la valeur en mode débugger, mais sans le débugger je te confirme que ça ne change rien, un log me donne la valeur de la variable fAbstract.

Le code que je donne est vraiment simplissiste je vous l'accorde, mais c'est pour bien vous montrer qu'il s'agit d'un problème avec le double et bcb.

J'ai entendu dire que l'on arrivait peut être à la limite de bcb avec un projet d'une telle taille ? oui - non?
Je me corrige, quand je disais avant que l'on avait patché le débugger j'ai dit une bétise, c'est le ilink que l'on a patché justement à cause de la taille du fichier .tds qui est immense...

Et comme ça ?

Code:

---

1 2 3 4 5 6 7

double fAbstract = monObjet.getAbstract(); if ( fAbstract <= 0.0 ) { } else { monTraitement(); }

---

Ou encore :

Code:

---

1 2 3 4

if ( fAbstract > 0.000000001 ) { monTraitement(); }

---

Merci d'avoir répondu,

fAbstract = 2519691;

J'ai supprimé les .obj et les .tds, j'ai rebooté et je n'avais plus le problème, si je post un message c'est bien parce que la compil me fait souvent ce genre de chose : une incohérence entre le code et ce qui devrait se passer !

Je réponds tout de suite à une autre question, oui je suis sûr d'avoir compilé mon fichier, d'autant plus que la modif que j'ai fait dans se fichier n'avait pas lieu sur cette ligne, pourtant c'est bien à cet endroit qu'il est parti dans les "choux", c'est un phénomène "paranormal" :P

J'ai mis un bout de code, ce n'était pas pour qu'on me le corrige mais bien pour qu'on me dise pourquoi la compil par dans les "choux" ... ?

Bonjour,

Quand un programme a un comportement incohérent, notamment quand un bout de code apparemment simple a un dysfonctionnement, on a vite tendance (c'est humain) à incriminer l'OS ou le compilateur.
Dans la quasi totalité des cas, il s'agit pourtant d'un effet de bord: un bout de programme situé en amont du code sur lequel on focalise interfère avec celui-ci, en raison d'un débordement mémoire, d'un pointeur mal initialisé ou autre. Le comportement d'un effet de bord est souvent aléatoire, ce qui fait qu'il n'est pas évident à détecter. Pour ma part, j'essaie (dans la mesure du possible) de mettre en commentaire des parties de code en amont jusqu'à ce que le phénomène disparaisse.
Peut-être que dans ton cas, il ne s'agit pas de ça, mais j'ai un doute quand même ...

Essayez de lancer Codeguard pour vérifier les débordements, on ne sais jamais.
Autre chose: Quelle version De BCB utilisez vous ? et avez vous testé sur une nouvelle installation de BCB sur une nouvelle machine ?
(je dis ça parce que ce type de mésaventure m'est arrivé, suite à installation de Nouveaux composants.. et sur des projets pas très lourds)
et dernière chose retirez les optimisations et mise en registre des variables, car souvent on n'arrive pas à suivre le processus correctement en debug.

J'utilise BCB5, ce dernier est patché.
ilink32 est également patché comme je l'ai dit précédemment.
A titre indicatif, j'ai encore le service pack 1 de windows xp.

Je n'ai pas l'optimisation de code active...

à titre d'info mes plus gros projets font dans les 32Mo en tds, et je suis dans un domaine technique.

Je pense donc qu'il peut allègrement dépasser les 50 Mo dans des domaines de Gestion.

Tentes de faire une bascule sur une nouvelle machine avec une réinstalle, voire passer à BCB6.
Là je vois pas :?
(sauf peut être reconstruire ton projet.. fichier Bpr.)

pour ma culture,
ou puis je trouver ce patch pour accepter que BC5 C++ accepte d'avoir des tds de plus de 32 mo ?
je suis rejetté de mon cote

sinon quand j'ai des phénoménes comme le tien et j'en ai eu..je reinstalle borland 5 et son patch1 ... et cela ca arrive souvent....
je ne sais pas ce qui se passe...

pas de réponse pour pouvoir avoir la possibilité d'un tds plus gros que 32mo?
passer en BC6 me fait @@@@ car le wrapper COM/DCOM ne donne pas la meme chose qu'en BC5...et commme je n'ai pas eu de réponse claire la dessus, je maintiens mon BC5 patch1

Bonjour,

J'ai les fichiers, mais je n'ai pas de lien vers leur provenance, néanmoins en cherchant dans google j'ai trouvé ces liens :

http://info.borland.com/devsupport/bcppbuilder/patches/

J'ai joint (zippé) les fichiers que j'ai utilisé pour patcher mon linker (bcb5) :

En fait je me suis renseigner sur l'origine du linker que je vous ai joint et à priori il provient de bcb6 tout simplement...

Ce dernier règle le problème de la taille du tds !