Pourquoi utiliser les champs résultat de structure de données pour des opérations d’I/O ?

(par exemple, d’un champ buffer zoné vers un champ interne packé, ou d’un champ de buffer *YMD vers un champ interne *ISO). Mais, même si tous les champs sont de type caractère, il est plus rapide de faire une seule grosse assignation que d’en faire plusieurs petites.

Il existe une autre raison pour utiliser les champs de résultats de structure de données pour des opérations d’I/O : si l’on craint que certains des champs contiennent des données invalides, on peut différer la découverte de ces données en utilisant une structure de données de résultat. La totalité du buffer est copiée octet par octet dans la structure de données sans se préoccuper des types de sous-champs, et donc les données invalides ne sont pas détectées par l’opération READ, comme elles le seraient si l’on utilisait I-specs. Vous pourrez ensuite tester les sous-champs vous-mêmes, avec beaucoup plus de maîtrise, comme le démontre le code de la figure 13.

Il est une troisième raison qui plaide pour l’utilisation des champs de résultats de structure de données pour les opérations d’I/O : quand on utilise un champ de résultat de structure de données, on contrôle exactement ce que l’opération d’entrée modifie (ou ce que l’opération de sortie utilise). Ensuite, quand la valeur d’enregistrement se trouve dans la structure de données, on peut mieux choisir le moment où l’on changera la valeur. Faute d’utiliser une structure de données dans le champ résultat, il faudra compter sur les champs I-spec et O-spec globaux. Même si l’on sauvegarde le résultat de l’opération d’entrée dans une structure de données séparée, il faudra quand même s’interroger sur les effets secondaires induits par la modification des champs I-spec globaux.