Discussion :

[Benoit_T]

Bonjour,

Je dispose d'une application delphi dans laquelle est sérialisée le record suivant:

Code :

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

1
2
3
4
5
TNoeud = record
           Ident : string[10];
           CoordX : longint;
           CoordY : longint;
end;

La lecture dans l'application delphi s'effectue comme il suit:

Code :

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

BlockRead(FBIN, noeud, sizeof( TNoeud ) );

Mon problème est que je désire lire ces objets sérialisés dans une application ... C++ !

Du coup, ma question est la suivante: quel est le format binaire exact de cette sauvegarde. Mes deux supposition sont les suivantes:

1:
1 octet pour chaque caractère de la chaîne * 10 + 4 octets pour CoordX puis 4 octets pour CoordY.

2:
1 octet pour chaque caractère de la chaîne * 10 + 2 octets "dummy" pour obtenir 4*3 octets alignables sur 3 mots mémoires de 32 bits + 4 octets pour coordX puis 4 octets pour CoordY.

S'il y a des bits dummy pour aligner la chaîne de caractère sur des mots mémoires, ceux-ci sont-ils avant la chaine ou après dans le fichier binaire?

Cordialement,

[Paul TOTH]

Alors

1) un STRING[x] est automatiquement un ShortString, donc il y a un index 0 qui contient la longueur utile de la chaine (le nombre de caractères réellement utilisés)

2) ça dépend des options de compilation

donc tu as au minimum ceci

Code c :

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

1
2
3
4
5
6
7
 
struct {
  Char IdentLen
  Char Ident[10];
  int CoordX;
  int CoordY;
}

ça serait le cas sur un "packed record", maintenant tu peux avoir du padding pour aligner la structure.

Pour le savoir, le plus simple est d'ajouter ceci dans le code Delphi

Code :

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

1
2
3
4
5
6
7
 
var
  node : TNoeud;
begin
  ShowMessage('SizeOf(TNoeud) = ' + IntToStr(SizeOf(node)));
  ShowMessage('@TNoeud.CoordX = ' + IntToStr(Cardinal(@node.CoordX) - Cardinal(@node)));
end;

avec ça tu as la taille de la structure et la position du champ CoordX à l'intérieur

[Benoit_T]

Merci pour ces précisions, grâce à votre suggession, je viens de vérifier, coordX est en position 12 et coordY naturellement en position 16. Ma seconde intuition était donc bonne.

Après, dans les douze premiers octets de la sauvegarde sérialisée, il me faut savoir quels octets représentent vraiment la chaîne.

prenons l'exemple de la chaîne "a1000" serait-ce plutôt:

1er octet pour la longueur utile, donc 5 puis 5 octets pour la chaîne, puis 6 octets "dummy" ?

Pour une petite chaîne de caractère, bien que dans le code on précise la taille (10), n'y a t'il pas le risque que la sérialisation "tronque" cette chaîne en 8 octets (2 mots mémoire)? De même la chaîne "a1" tiendrait sur un mot mémoire...

Cordialement,

[Paul TOTH]

Merci pour ces précisions, grâce à votre suggession, je viens de vérifier, coordX est en position 12 et coordY naturellement en position 16. Ma seconde intuition était donc bonne.

Après, dans les douze premiers octets de la sauvegarde sérialisée, il me faut savoir quels octets représentent vraiment la chaîne.

prenons l'exemple de la chaîne "a1000" serait-ce plutôt:

1er octet pour la longueur utile, donc 5 puis 5 octets pour la chaîne, puis 6 octets "dummy" ?

Pour une petite chaîne de caractère, bien que dans le code on précise la taille (10), n'y a t'il pas le risque que la sérialisation "tronque" cette chaîne en 8 octets (2 mots mémoire)? De même la chaîne "a1" tiendrait sur un mot mémoire...

Cordialement,

les octets "non utils" ont une valeur non déterminée... par exemple

Code :

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

1
2
3
4
5
 
begin
  node.Ident := '1234567890'; // tout est défini avec un #10 devant
  node.ident := 'abc'; // on obtient #3'abc4567890'
end;

les ShortString sont des tableaux statiques, donc l'allocation est de taille fixe.