Le livre met en garde contre la lecture d'un bloc d'octets à partir d'un fichier directement dans une structure de données. Le problème avec ceci est qu'il peut y avoir des octets de remplissage sans nom entre les éléments individuels d'une structure de données, et le nombre et la position de ces octets dépendent entièrement de l'implémentation. Vous pouvez toujours utiliser les appels fread et fwrite pour lire et écrire des données depuis et vers un fichier, mais vous devez lire et écrire chaque élément de la structure de données individuellement, plutôt que de lire ou d'écrire la structure entière en une seule fois.
Vous devez également garder à l'esprit les autres problèmes de portabilité. Par exemple, les différents types numériques ont des tailles dépendantes de l'implémentation. Pour la portabilité, vous pouvez utiliser les types définis dans l'en-tête stdint.h. Il peut également y avoir des différences dans la représentation en virgule flottante et en nombre entier non signé, mais la plupart des systèmes et formats de fichiers utilisent maintenant IEEE 754 et deux-complément respectivement, donc les problèmes de compatibilité sont beaucoup moins fréquents avec ces types. Assurez-vous de savoir ce que vos spécifications disent.
Merci beaucoup. Il semble que ce ne soit pas une question de fread ou de fwrite, parce que, pour autant que je sache, le data struture est toujours implémenté de manière dépendante. Est-ce que vous voulez insister sur ce problème quand vous parlez de fread ou fwrite? – WuFa
@forest: C'est exactement * parce que * fread/fwrite ne sait pas à propos du remplissage que leur utilisation peut échouer. Par exemple, étant donné 'struct A {int i; char c; }; ', vous avez besoin de deux appels fread (un pour chacun des * i * et * c *) plutôt qu'un (pour toute la structure). Le point sur les types d'entiers portables est que vous ne dépendez pas du nombre spécifique de bits utilisés par 'int' (qui peut varier selon la plate-forme et même les paramètres du compilateur). –