Pour que l'alignement des champs soit correct dans un type enregistrement décompacté, le compilateur insère un octet inutilisé avant les champs ayant un alignement de 2, et jusqu'à trois octets inutilisés avant les champs ayant un alignement de 4, si nécessaire.
Enfin, le compilateur arrondit la taille totale de l'enregistrement jusqu'à la limite en octets spécifiée par l'alignement le plus grand des champs
Si deux champs partagent une spécification de type commune, ils sont compactés même si la déclaration ne comprend pas le modificateur packed et si le type enregistrement n'est pas déclaré dans l'état {$A-}. Ainsi, par exemple, soit la déclaration suivante :
1
2
3
4
5
| Type
TMyRecord = record
A,B : Extended ;
C : Extended ;
end; |
A et B sont compactés (alignés sur les limites en octets) car ils partagent la même spécification de type. Le compilateur complète la structure avec des octets inutilisés pour s'assurer que C apparait sur limite de mot quadruple.
Lorsqu'un type enregistrement est déclaré dans l'état {$A-} ou lorsque la déclaration comprend le modificateur packed, les champs de l'enregistrement ne sont pas alignés,
mais des déplacements consécutifs leur sont plutôt affectés. La taille totale d'un tel enregistrement compacté est simplement la taille de tous les champs. Comme l'alignement des données peut changer, c'est une bonne idée de compacter toutes les structures enregistrement que vous avez l'intention d'érire sur disque ou de passer en mémoire à un autre module compilé avec une version du compilateur différente.
Création d'une structure dynamique
Répondre avec citation
)
Mais je peux pas arriver dans le projet et dire "Salut, c'est moi et je vais tout révolutionner"... Surtout que dans l'industrie, ils ne connaissent pas nos normes et nos standards... Dans l'industrie, la programmation d'un logiciel n'est vue que comme une suite de If-Then-Else-goto ou à peine plus. Du moment que ça marche, pourquoi se soucier de faire les choses bien comme les règles de l'art. 
Envoyé par Aka Guymelef
Partager