Discussion :

[lenectar]

Bonjour tout le monde,
comme le titre l'indique j'ai quelque souci avec des structures, je souhaiterai lire des fichiers binaire structurés pour cela j'ai fait une structure avec les éléments du fichiers, normalement la taille de ma structure aurai du etre de 35 octets, mais ca n'est pas le cas elle fait beaucoup plus 40 ou 50 octets je crois car je n'ai pas rangé les variables par type, donc du coup quand je veux lire mon fichier, à chaque fois j'ai juste les trois premieres valeurs qui sont correctes les autres étant fausses ( caractères étranges ou valeurs totalement fausse ).
Donc je voudrai savoir si y'a une solution pour moi (un parametre a ajouter lors de le définition de la structure ou autre chose ) me permettant d'avoir une structure de 35 octets et pas 40 ou plus et me permettant ainsi faire une lecture correcte du fichier.

Merci de bien vouloir m'aider

Le code que j'ai écrit ressemble a ça

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
 
 
typedef struct Test1
{
long var1;
long var1;
long var3;
char var4;
double var5;
long var6;
char var7;
char var8;
double var9;
}Test1;
 
int main(int argc, char** argv) 
{
 
// on ouvre le fichier 
/*****/
//on va juste lire les premieres valeurs 
Test1 *y;
fichier.read((char *)(* y),(sizeof(Test1)));
 
.....
.....
}

[10_GOTO_10]

Très vraisemblablement un problème d'alignement des structures. Elles doivent être alignées sur un byte dans ton fichier (alors que la valeur par défaut est en général 4 ou 8 bytes).

[Skyounet]

Je comprends pas pourquoi tu veux une structure de 35 octets exactement?

Si tu sais comment sont codées les données dans le fichier et la structure exact, tu refait la meme et tu fait un fread c'est tout

[lenectar]

Merci a vous d'avoir repondu,
si je veux une longueur de 32 octets ( pas 35 désolé ) c'est parce que le fichier est structuré ainsi 32o+32o+.......
avant j'avais un premiere version de mon programme qui lisait toute les valeurs du fichiers une par une, ça marchait tres bien, chaque boucle me lisait 32 octets.
Voici le code

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
 
 
// ouverture du fichier 
/*****/
 
 
int val1 = 0;
int val2 = 0;
int val3 = 0;
int val4 = 0;
int val5 = 0;
int val6 = 0;
int val7 = 0;
int val8 = 0;
double val9 = 0;
int val10 = 0;     
 
//lecture du fichier binaire 
while(fichier_in.read(reinterpret_cast<char*>(&val1),4))
{      
 
     fichier_in.read((char*)(&val2),4);
     fichier_in.read((char*)(&val3),4);
     fichier_in.read((char*)(&val4),1);
     fichier_in.read((char*)(&val5),1);
     fichier_in.read((char*)(&val6),1);
     fichier_in.read(reinterpret_cast<char*>(&val7),4);
     fichier_in.read(reinterpret_cast<char*>(&val8),4);
     fichier_in.read((char*)(&val9),8);
     fichier_in.read((char*)(&val10),1);
     /*
     instruction .......
     */
 
}

Mais comme je lis de tres tres gros fichier ça met énormément de temps c'est pour cela pour cela que j'ai opter pour un code dans ce style beaucoup plus rapide :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
 
 
 
typedef struct{   
 
 
 
    long var1;//1       
 
    long var2;//2 
 
    long var3;//3 
 
    char var4;//4
 
    char var5;//5
 
    char var6;//6
 
    long var7;//7
 
    long var8;//8
 
    double var9;//9
 
    char var10;//10        
 
 
}Test1;      
 
 
 
 
 
using namespace std;
 
int main(int argc, char *argv[])
{
 
cout << sizeof(Test1) << endl;
 
std::ifstream fichier_in;
 
fichier_in.open("C:\\fichier.bin", std::ios::in | std::ios::binary);
 
 
 
if (fichier_in.good())
{
std::cout << "Le fichier est bien ouvert " << std::endl;
}  
else 
{ 
std::cout << "Le fichier n'est pas bien ouvert " << std::endl;
}
 
 
int cpt=0;
Test1 *o;
 
//while(fichier_in.read((char*)(y),sizeof(Test1)))
 
while(fichier_in.read((char*)(o),sizeof(Test1)-8))
     {
 
     cout <<"taille de Test1 "<< sizeof(Test1) << endl; 
     cout << "1 :" << o->var1<< endl;
     cout << "2 :" << o->var2<< endl; 
     cout << "3 :" << o->var3<< endl; 
     cout << "4 :" << o->var4<< endl; 
     cout << "5 :" << o->var5<< endl; 
     cout << "6 :" << o->var6<< endl; 
     cout << "7 :" << o->var7<< endl; 
     cout << "8 :" << o->var8<< endl; 
     cout << "9 :" << o->var9<< endl; 
     cout << "10 :" << o->var10<< endl; 
 
     system("pause");             
 
     cpt++ ;                                 
 
     }
 
fichier_in.close();    
 
 
    system("PAUSE");
    return EXIT_SUCCESS;
}

[Skyounet]

Ah ouais mais la t'es pas dans le bon forum ici c'est le forum C, et toi tu as du C++ c'est la porte à côté. ^^

[Jean-Marc.Bourguet]

Le problème est bien un problème d'alignement. En général, les processeurs ne peuvent pas lire n'importe quel type de donnée à n'importe quelle adresse. Pour chaque type, il y a un alignement, une donnée de ce type doit se trouver à une adresse multiple de l'alignement. Suivant les processeurs, ne pas respecter les contraintes d'alignement peut entraîner une perte de performance (le processeur fait la lecture, mais plus lentement, cas des x86), un problème silencieux (le processeur le lit pas ce qui a été demandé mais autre chose et ne donne aucune information de ce qui s'est produit, je n'ai aucun exemple réel en tête, mais le MMIX de Knuth est dans ce cas) ou bien il y a une erreur (cas des Sparcs).

En général, pour les types de base (les seuls que connaisse réellement le processeur) l'alignement est généralement égal à la taille (si un int est sur 4 bytes, il doit se trouver à une adresse multiple de 4, mais un long double sur 10 bytes aura vraissemblablement un alignement de 8 ou de 16).

Pour les types composés comme les structures, on peut définir aussi un alignement. Ce sera généralement l'alignement du membre le plus contraint.

Ceci est vrai quel que soit le langage. Mais le C impose une contrainte de plus: la taille doit être un multiple entier de l'alignement.

Comment cela se traduit-il en pratique?

La position d'un membre d'une structure par rapport au début de celle-ci est au minimum la somme de la position du membre précédent et de la longueur de celui-ci (ou bien il y aurait un recouvrement). Mais en plus il peut se trouver du "padding", de l'espace inoccupé rendu nécessaire pour que la position soit un multiple de l'alignement du membre. De même il peut y avoir du padding à la fin de la structure pour faire en sorte que la taille soit un multiple de l'alignement de la structure.

Dans ton exemple, la structure contient deux doubles qui ont vraissemblablement un alignement de 8, donc la structure aura aussi un alignement de 8. Si on prend qu'un char est 1 BYTE (ça c'est pas une hypothèse, c'est une contrainte en C), un long est 4 BYTES et un double 8 BYTES, il y aura 3 bytes de padding après var4 et 2 après var8. Dans le cas présent, réordonner les membres ne permet pas de diminuer le nombre total de bytes de padding (mais c'est parfois possible). Note que du padding supplémentaire pourrait être ajouté n'importe où (sauf avant var1) tant que les contraintes d'alignement sont respectées (mais je doute que ça arrive en pratique).

Si tu veux lire un format fixé comme l'entête d'un fichier, il ne faut pas lire d'un bloc une struct décrivant naïvement ce format mais lire les champs un à un. De plus, comme rien ne garanti le format binaire d'un long par exemple et qu'il y en a déjà en pratique au moins 2 utilisés, il faut faire la lecture en lisant byte par byte et en recomposant le long.

Naturellement, les même précautions sont à prendre lors de l'écriture.

[lenectar]

Merci Jean-Marc pour ta réponse je vois bien maintenant pourquoi il m'affiche une taille de plus de 32 octets, si j'ai bien compris tu me conseille de repondre mon premier prog et lire les valeurs une par une
ça s'annonce mal pour moi, il n'y a aucune autre solution ? une autre façon de lire un fichier binaire structuré?

[Trap D]

Tu peux dans les options de compilation forcer le compactage sur 1 octet, comme cela ta structure fera 32 octets.

[Jean-Marc.Bourguet]

Tu peux dans les options de compilation forcer le compactage sur 1 octet, comme cela ta structure fera 32 octets.

Si c'est une option de compilation, ça veut dire que c'est pour l'ensemble du programme... donc y compris pour les structures de la bibliothèque standard (est-elle prévue pour?). Ça ne fonctionne que sur les archi où les accès non alignés sont possibles, et même pour elle il y a un coût en performance. Et ça ne règle pas le problème de la représentation binaire (il y a des machines et des modes de compilation où les long font 64 bits, il y a des machines petit et grand boutien...)

C'est une approche peut-être envisageable pour un programme jetable mais qui ne me semble pas robuste du tout.

[Jean-Marc.Bourguet]

Merci Jean-Marc pour ta réponse je vois bien maintenant pourquoi il m'affiche une taille de plus de 32 octets, si j'ai bien compris tu me conseille de repondre mon premier prog et lire les valeurs une par une
ça s'annonce mal pour moi, il n'y a aucune autre solution ? une autre façon de lire un fichier binaire structuré?

Lire ton entête comme un tableau de bytes que tu réinterprètes après?

[Médinoc]

Avec des pragmas, dans un bon compilo, tu peux choisir que seule la structure en question soit compactée sur un seul octet.

Je sais qu'avec Visual et mingW ça marche, mais je ne sais pas si c'est bon pour un autre gcc... (regarder du coté de #pragma pack, j'ai essayé aec man mais ça foire...)

[lenectar]

Merci Jean-Marc pour ta réponse je vois bien maintenant pourquoi il m'affiche une taille de plus de 32 octets, si j'ai bien compris tu me conseille de repondre mon premier prog et lire les valeurs une par une
ça s'annonce mal pour moi, il n'y a aucune autre solution ? une autre façon de lire un fichier binaire structuré?

Lire ton entête comme un tableau de bytes que tu réinterprètes après?

Je vois pas ce que tu veux dire par entête, mon fichier binaire ne semble pas en avoir il est structuré ainsi :
4octets+4octets+4octets+1octets+1octet+1octet+4octets+4octets+8octets+1octet(fin de la premiere serie de valeur)4octets+4octets+4octets +1octets+1octet+1octet+4octets+4octets+8octets+1octet(fin de la seconde serie de valeur )+octets+4octets+4octets+1octets1octet+1octet +4octets+4octets+8octets+1octet+.....(ainsi de suite jusqu'a la fin du fichier)

Et comme un fichier peut avoir plus d'un million de valeur.... dans la premiere version de mon programme la lecture du premier fichier mettait énormément de temps et comme je dois en lire plus de 10...
J'ai essayé le pragma pack(1) comme me l'a dit Trap D éffectivement ça l'air de fonctionner, comme c'est le début du programme il se pourrai que plus loin de mon programme je rencontre des problemes avec les structures de la bibliothèques standart comme l'a dit Jean-Marc.
Je vais faire quelque recherche sur ce que dit Médinoc, je pense que ça pourrai arranger les choses,
de toute façon je vous tiens au courant de l'avancement de mon programme.

Merci encore a vous tous

[lenectar]

apparament il faudrait entourer la structure avec des pragma pack()
comme ceci

Code :

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

1
2
3
4
5
6
 
#pragma pack(1)
 
//structure
 
#pragma pack(0)

donc je pense qu'avec ceci ça ne dérangera pas les structures de la bibliothèque standart.

[Médinoc]

Sur un compilateur qui le supporte, ceci est préférable:

Code :

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

1
2
3
4
5
6
#pragma pack(push)
#pragma pack(1)
 
struct { ... };
 
#pragma pack(pop)

Mais je ne sais pas si un GCC "normal" le supporte...

[Pouic]

On peut aussi faire ceci (gcc) :

Code :

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

1
2
3
4
5
6
 
#define PACK_STRUCT     __attribute__((packed))
typedef struct          ma_struct
{
 <...>
}       PACK_STRUCT     the_struct;

[Jean-Marc.Bourguet]

Et comme un fichier peut avoir plus d'un million de valeur.... dans la premiere version de mon programme la lecture du premier fichier mettait énormément de temps et comme je dois en lire plus de 10...

Il me semble très étrange que ça ait une importance. Une petite mesure rapide ici montre un surcout d'une recomposition manuelle de moins de 10% par rapport à une simple lecture sur le disque (autrement dit, la mesure commence à être difficile à répèter sur une machine un tant soi peu chargée, les effets de cache -- en particulier le cache du contenu des disques par l'OS -- doivent être pris en compte pour que la mesure ait un sens) ce qui chez moi veut dire: ça ne vaut vraissemblablement pas la peine de chercher à faire mieux, surtout au pris d'incompatibilité du soft avec d'autres architectures ou la même quand on passe en 64 bits (les long font 64 bits en 64 bits partout depuis qu'il y a du 64 bits; naturellement MS arrivant 10 ans après tout le monde sur ce marché a décidé de faire autrement... )

Quant aux doubles il y a au moins 3 formats binaires différents rien que pour ceux qui se réclament du standard IEEE...

De plus, je suppose que ta structure "packée", tu l'utilises telle quelle dans les traitements, et donc tu te payes un tas d'accès non alignés (et donc plus coûteux) dont tu n'imputes pas le coût à la méthode de lecture.

[lenectar]

Jean-Marc je programme sur mainframe ibm et windows je sais pas si ça joue énormément

[Jean-Marc.Bourguet]

Jean-Marc je programme sur mainframe ibm et windows je sais pas si ça joue énormément

A priori tu dois avoir de gros problème de portabilité de tes fichiers d'un système à l'autre. Les 390 sont grands boutiens, les x86 petits boutiens, les 390 ont des flottants à eux (mais il me semble qu'ils ont ajouté les flottants IEEE), les x86 ont des flottants IEEE (et note qu'il y a plus de variations dans la représentation binaire des flottants IEEE que petit et grand boutien).

De toute manière entre définir précisément un format puis écrire des routines qui lisent et écrivent ce format et "le format format binaire c'est le résultat d'un dump de la mémoire de cette structure avec le compilateur X version Y et les options de compilation Z et les pragmas T" je crois qu'il n'y a pas photo.

On pourrait éventuellement arriver à devoir optimiser les routines d'E/S de la sorte, mais après avoir écrit les routines génériques et après avoir mesuré que le gain était nécessaire pour atteindre les objectifs de performance. Mais je n'ai jamais vécu le cas.