pb avec un fichier binaire et vc [RESOLU] - C++ - Programmation
Marsh Posté le 18-08-2007 à 15:01:46
pq ne pas faire une structure et tout lire d'un seul coup ?
Marsh Posté le 18-08-2007 à 19:51:17
le fichier a été généré sous quoi ?
il te reste plus qu'a traçer au debug pour voir où le décalage se produit.
Marsh Posté le 18-08-2007 à 20:05:53
Tu as vérifié l'endianess du processeur?
Si tu ne lis pas des données qui ont été générées avec le meme type de processeur -- little ou big endian -- le contenu des variables est chamboulé car elles ne seront pas stockées dans le meme ordre. Ex: (vieux) Mac et PC.
S'il s'agit de lire peu de données de config par exemple alors c'est alors bien plus robuste de passer par un fichier en texte (à la XML).
Sinon tu peux lire et ecrire octet par octet, et enfin si le fichier vient d'une source différente ou qu'il est normalisé et que tu peux pas changer son format, tu devras tester l'endianess et retourner les octets à la main si besoin. Sans indication et sans connaitre le type de cpu qui a écrit les données il faudra le "deviner", comme ici en pensant que -154 est un bon indicateur que l'endianess à changé entre l'écriture et ta lecture.
Marsh Posté le 18-08-2007 à 22:55:40
bjone a écrit : le fichier a été généré sous quoi ? |
Normalement, le fichier a été généré avec le même programme qui sert à le lire mais le programme est multiplateforme, je ne sais donc pas sur quel os/système.
jimko a écrit : Tu as vérifié l'endianess du processeur? |
J’avais bien pensé au problème de l’endian mais cela n’explique pas pourquoi l’exécutable téléchargé pour Windows arrive à lire ce binaire sans problème. Le fichier contient des données de configuration et des points de mesures (plusieurs dizaines de milliers).
Marsh Posté le 18-08-2007 à 23:12:19
Une erreur courante est de faire l'ouverture du fichier sans spécifier le mode binaire, et dans ce cas, pas de chance car c'est le mode texte qui est le mode par défaut.
Marsh Posté le 19-08-2007 à 13:07:13
billgatesanonym a écrit : Une erreur courante est de faire l'ouverture du fichier sans spécifier le mode binaire, et dans ce cas, pas de chance car c'est le mode texte qui est le mode par défaut. |
Le fichier est bien ouvert en mode binaire :
Code :
|
Marsh Posté le 19-08-2007 à 15:41:30
Le programme ci-dessous permet de tester le problème de l’endian et de l’hypothétique problème d’incompatibilité de fonctions du C incorporés dans un projet C++ :
Code :
|
Résultats:
Test avec fread:
Name=__ezGet.net dataFormat 5__This is the <u>native data</u> for ezDatar.
<font size='+4'>Now</font>, yo╠╠╠╠╠╠╠╠`↔1►╠╠╠╠üÏ■9¿ ↕
Time=8319591545089237109
StepX=8.67581e+020
StepY=4.51558e+027
XStart=0.0140029
Number=540959279
Test avec ifstream::read:
Name=__ezGet.net dataFormat 5__This is the <u>native data</u> for ezDatar.
<font size='+4'>Now</font>, yo╠╠╠╠╠╠╠╠PrQ►♦
Time=8319591545089237109
StepX=8.67581e+020
StepY=4.51558e+027
XStart=0.0140029
Number=540959279
Swap:
Time=8439854971802908019
StepX=4.72933e+022
StepY=0.237707
XStart=2.92643e+029
Number=794967584
Appuyez sur une touche pour continuer...
Ce test montre que pour les fonctions du C et les méthodes du C++ renvoient les mêmes valeurs, sauf pour la chaîne de caractères (???). Le swap des bits ne change rien, les valeurs sont toujours aussi catastrophiques...
Marsh Posté le 18-08-2007 à 14:25:24
Le problème vient du type size_t :
In Visual C++ 2005, time is a wrapper for _time64 and time_t is, by default, equivalent to __time64_t. If you need to force the compiler to interpret time_t as the old 32-bit time_t, you can define _USE_32BIT_TIME_T. This is not recommended because your application may fail after January 18, 2038; the use of this macro is not allowed on 64-bit platforms.
Message édité par moumout511 le 24-08-2007 à 13:15:28