Bonjour,
Pourquoi est-ce que ce programme suivant:
 

 
Donne:
 

 
et pas:
 

 
Je vois mal où est mon erreur.

il n'y pas d'erreur, il y a du bourrage ce qui est tout à fait normal quand ça n'est pas obligatoire.

Taz veut dire que ton compilo a préféré aligner le membre 'b' de type 'unsigned long' sur un multiple de 4 octets... Il a donc ajouté deux octets inutilisés après 'a'...
C'est parfois moins pénalisant en temps d'accès... c'est même parfois obligatoire.
 
Edit: il y a parfois aussi "bourrage" en fin de structure pour les mêmes raisons car le compilo ne doit pas créer de problème d'alignement dans les tableaux...

Ah je connaissais pas le "bourrage". Et comment on fait si on veut lire un élément avec la fonction fread par exemple? On va lire 8 octets avec sizeof(structure_ab) en argument de fread. Alors qu'on veut en lire que 6.

Tu t'en occupes pas. Tu écris une struct et tu lis une struct. Tout le monde retrouve ses petits. C'est juste pas portable niveau format de fichier.

Tu as une directive "#pragma pack", si tu veux modifier le comportement de l'alignement... mais faut pas faire n'importe quoi avec (les push/pop sont alors bien pratiques).

je l'attendais celle là    
 
Toujours les mêmes à conseiller des trucs que personne n'utilisent sauf pour coder un kernel.
(Le premier qui me dit "c'est pour coller à une représentation binaire" il a perdu)
 
Une petite astuce, si c'est possible, c'est d'ordonner tes membres dans ta struct par taille décroissante et les grouper par type.

Merci à Taz pour cette mise en garde, on a vite fait de croire qu'on va coller à une représentation binaire mais on rencontre des problèmes d'endianess, donc de portabilité...
La question serait donc de savoir si le format de fichier est figé ou modifiable...

Tu peux packer autant que tu veux sur sparc, ça ne donnera rien. Pour utiliser une représentation binaire portable, il faut la définir et l'implémenter en lisant octet par octet.
 
S'il s'agit d'un exercice, je pense que tout ça n'entre pas en compte. Il doit s'agir d'écrire un fichier et de le relire.

Un exercice? Non je m'amuse à travailler les fichiers bmp.  Pour l'instant mon programme fonctionne en lisant octet par octet (fgetc) le fichier bmp pour les insérer dans un tableau. Maintenant je veux faire ça avec des structures à la place des tableaux. Et j'essaye de lire et écrire mes structures (fread) en respectant le format bmp. C'est beaucoup plus pratique ... à 1ère vue.
 
Le problème c'est que je récupère des images bmp et c'est pas moi qui choisit le format d'écriture. Donc si j'ai une structure de 16 octets (alors que la somme des variables fait 14) qui représente l'entête du bmp et que fread m'écrit 16 octets (au lieu des 14 octets requis par le bmp) ça va pas aller.

lit octet par octet et remplis ta structure. Forcer une binary representation == pas bien

Ok, dommage je trouvais fread pratique.

il est préférable d'exporter et d'importer les champs de ta structure un par un en mettant au point un format d'enregistrement comme un simple tag/longueur/valeur.  
Tu pourra ainsi gérer par la même occasion des modifications de la structure comme l'ajout ou la suppresion d'un champs et les modification de types

Tu peux utiliser fread, mais juste pas directement sur ta structure comme expliqué.

Ok donc en fait j'ai fait des fonctions qui lisent une structure et la mettent dans un tableau, dans le bon ordre et la bonne taille. Après c'est vrai que j'y avait pas pensé, je peux écrire le tableau en un seul coup avec fread pour l'écrire dans le fichier.
 

 
Pour l'endianess je devais plutôt utiliser une constante définie par une marco du style:
 
#ifdef WINDOWS ENDIANESS 'l'
#elif LINUX ...
 
C'est une bonne idée?

deja l'endiannes ca depend pas de l'OS mais plutot de la famille du processeur
 
et non, c'est atroce. La bonne stratégie, à mon sens, est de sérialiser entiérement la SDD de manière endian-independant, et de reconstrurie les chsoes proprements à chaque fois.

Sérialiser la SDD?  
Ah pour l'endianess je savais pas. La différence serait plutôt PC <-> Mac alors. Comment prendre en compte ça pour que ça soit portable?
 
Pour être plus clair voilà ma démarche:
 
- lecture du fichier bmp et enregistrement des valeurs en prennant en compte l'endianess
- insertion des valeurs dans une structure
- lecture des valeurs à partir de la structure
- enregistrement du fichier bmp (à partir des valeurs) en prennant en compte l'endianess
 
Donc je ne fais la conversion qu'a l'écriture et la lecture.

avec les mac x86, non...

On écrit du code portable. On définit un format de données indépendant de toute machine et on s'y tient. C'est pas plus compliqué que ça.
 
Ici, c'est le format BMP qui est la référence. Il faut faire ce qui est demandé, c'est tout. Si c'est bien fait (octet/octets, décalages...) c'est portable.