Version imprimable
Bonjour,
J'ai crée un projet console c++ qui effectue des traitements de calculs avec des doubles puis j'affiche les résultats sur la console, tout va bien jusqu'au jour où j'ai décidé de convertir mon projet en 64 bits. J'ai modifié la machine cible et la configuration du projet et j'ai générée mais les résultats étaient différents de la version 32 :( sachant que j'ai rien modifié dans le traitement.
Avez vous une explication? et comment je peux résoudre mon problème svp?
Merci d'avance
Le plus probable, c'est que c'est un bug latent qui a été mis en évidence par ce changement de configuration.
Donc, on le règle comme n'importe quel bug, en déboguant et en vérifiant où ça part en sucette, avec un débogueur.
Je vour remercie pour la réponse, mais je ne vois comment le changement de configuration donne un bug?
Je pense que bacelar veut dire que le bug est déjà là dans la version x86. Il reste à le mettre en évidence.
Ou le bug vient d'un implementation defined behavior ou undefined behavior qui ne pose pas de problème en x86 mais qui en pose en x64.
Bonjour,
L'expérience montre que c'est assez souvent dû à un problème de taille pour les types, le cas le plus fréquent étant d'assimiler la taille d'un int et d'un pointeur, ce qui est vrai en x86, mais plus en x64. :)
Également supposer qu'un int a la même taille qu'un long, ce qui était vrai en x86 32 bits, mais n'est vrai que sur certaines plate-formes x64 (comme Windows) et faux sur d'autres (comme Linux).
Oui je pense que l'erreur vient de la différence de présentation des doubles en x86 et x64 , mais comment je peux résoudre mon problème?
Je vous remercie pour votre interaction
Est ce que vous pouvez m'expliquer encore svp?Citation:
Envoyé par Bktero
Moi, je conseillerai l'utilisation d'un débogueur (comme expliqué ici), ou d'un analyseur mémoire (comme Dr Memory).
Bref, je conseille comme les autres, y a plus qu'à !
Edit : comme le fait remarquer Danny-k dans un message suivant, je voulais ici parler de la taille de longet non de la taille de int. Le paragraphe suivant a été modifié suite à son commentaire.Citation:
Envoyé par 3aychoucha
Un exemple simple, en suite avec celui de Médinoc : la taille de long n'est pas figée en C. La norme te garantit seulement que sizeof(long) >= 4. C'est un implementation defined behavior, un "comportement dépendant de l'implémentation" en français. Sur x86, la plupart voire toutes les implémentations (comprendre : les différents compilateurs pour x86) on fait le choix que sizeof(long) serait égale à 4. Or, la plupart des implémentations sur x64 ont décidé que ce serait égale à 8. Quand tu as fait ton programme, tu t'es peut-être basé sur une hypothèse telle que sizeof(long) == 4. Sauf que c'est hypothèse n'est plus vraie en x64 et donc ton programme ne fonctionne pas de la même manière.
Les undefined behaviors sont beaucoup plus grave : ce sont des "comportements indéfinis". Ce n'est même pas laissé au choix de l'implémentation, ce sont des choses qu'il ne faut pas faire. Exemple : diviser par 0.
Lire à ce sujet :
- https://en.wikipedia.org/wiki/Undefined_behavior
- http://blog.llvm.org/2011/05/what-ev...ould-know.html
Qu'est ce qui te fait dire ça ? Peut-on voir le code ?Citation:
Envoyé par 3aychoucha
:plusser: comme expliqué ici http://www.developpez.net/forums/d12...ows-and-linux/Citation:
Envoyé par LittleWhite
Autre conseil : activer les options de warnings de ton compilateur ! Avec gcc ou clang, ce sont -Wall -Wextra.
tu peux essayer de faire une exemple minimum qui montre le problème
On a toujours pas vu de code :calim2:
J'ai toujours vu des doubles de 64 bits, en 32 ou 64 bits. :koi:
La dernière fois que j'ai entendu quelqu'un se plaindre de la taille d'un double.. c'était accompagné de reinterpert_cast n'ayant aucun sens. :aie:
Bktero: Qu'est ce qui te fait dire ça ? Peut-on voir le code ?
Je récupère les inputs à partir d'un fichier qui contient un ensemble de points pour faire un calcul de filtrage
j'ai remarqué que le résultat change lorsque je modifie le nombre de chiffres après la virgule,
Je vais essayer de déboguer pour voir le comportement,
Merci
Euh, à ma connaissance sur la plupart des OS (Windows, Linux) la taille d'un int sur x86 ou x64 (on va mettre à part les systèmes embarqués et autre où le int peut valoir 16 bits), est en grand majorité codé sur un DWORD de 32bits soit 4 octets, c'est le sizeof(long) qui est différent sous linux (pas sous Windows comme dit plus haut par Médinoc) qui lui vaut 8 octets en x64 et 4 en x86.Citation:
Envoyé par Bktero
Sera vrai dans à peu près 99% des cas rencontré, que ce soit en 32bits ou 64 bits.Code:sizeof(int) == 4
Tu as tout à fait raison, je ne devais pas être réveillé ! :cfou:
J'ai modifié mon message... :oops:
3aychoucha, sur quelle plateforme developpes-tu ?
Si c'est sous windows, il me semble que tous les types de base sont de même taille sauf size_t, et les pointeurs bien sûr (avec les assimilables comme intptr_t par exemple).
Bonjour à tous,
Si on veut être précis, sizeof retourne le ratio entre la taille d'un type donné et la taille d'un char.
le nombre concret de bits d'un char n'est pas définie par le standard.
CHAR_BIT (défini dans <climits>) indique le nombre de bits d'un char.
Il est valable (quoique rarrissime) que sur une architecture 64bits, un char fasse 64bits, et qu'ainsi, sizeof(char) == sizeof(short) == sizeof(long) == 1.
les types ont tous une taille multiple de celle de char (sizeof() n'a pas besoin d'arrondir), les types primitifs sont ordonnés dans leurs tailles (char, short, int, long, long long)
les types primitifs sont contraints de pouvoir représenter au moins une certaine plage.
Dans l'explication de Bktero, "La norme te garantit seulement que sizeof(long) >= 4" n'est pas vraie au sens de la norme.
C'est juste très, très fréquent, puisque CHAR_BIT=8 partout ou presque.
Je ne m'étais jamais fait la remarque (en tout cas pas aussi clairement) mais c'est tout à fait exact !!! :applo:Citation:
Envoyé par ternel
Je travaille avec visual studio 2012 sur windows 7 64 bitsCitation:
Envoyé par camboui