Données privées et publiques

[Romu']

Bonjour !
Le choix a été long entre poster ce message dans "Conception" ou "Structure de données"...

le contexte : Un module d'un programme est chargé de lire un fichier dont les données sont dans un certain format, et de créer à l'ouverture de celui-ci une liste chaînée image des entrées du fichier (c'est plus facile à manipuler par la suite).
Un élément de cette liste est représenté par cette structure, qui reprend exactement le format du fichier :

Code:


struct entry {
    unsigned char options;
    unsigned char date[2]; /* [0] : jour, [1] : mois */
    unsigned char length; /* longueur du texte */
    unsigned char* text;

    struct entry* next;
};


mon idée : Pour l'utilisateur de ce module (ou bibliothèque, finalement), je pense que ça ferait plus "propre" de proposer une structure qui ne garde que les informations utiles pour lui.
De plus, j'ai pu lire plusieurs fois les "problèmes" que peut poser l'utilisation de types qui ne sont pas int pour les entiers et double pour les flottants : on pense gagner en mémoire par exemple en utilisant short au lieu de int mais finalement non et on en profite pour perdre en rapidité d'exécution aussi, etc...
Donc comme structure de données publiques j'ai pensé faire ceci :

Code:


struct Rem_entry {
    unsigned int options; /* unsigned car on utilise des opérateurs bit-à-bit pour ce champ */
    int date[2];
    int length;
    const unsigned char* text; /* 'const' : le texte ne doit pas pouvoir être modifié en utilisant cette structure directement. Je ne suis pas certain de l'utilité de 'unsigned' ici mais dans le doute... */
};


Ai-je bon, et est-ce vraiment utile ?
Merci d'avance !

[-ed-]

Ai-je bon, et est-ce vraiment utile ?

J'ai un peu du mal à saisir quelle est la question...

En tout cas, pour les chaines, c'est char et non unsigned char. Quand à la date, tu peux utiliser un tableau de 2 unsigned char, ou 2 int séparés

Code:


int jour;
int mois;


Je ferais plutôt comme ça :

Code:


struct Rem_entry
{
  unsigned int options; /* unsigned car on utilise des opérateurs bit-à-bit pour ce champ */
  int jour;
  int mois;
  int length;
  const char* text;
};


[Romu']

J'ai un peu du mal à saisir quelle est la question...

En fait, je me posait la question de l'intérêt de fournir à l'utilisateur une structure de données qui transforme les types char utilisés dans la structure "interne" en types natifs (je crois que c'est comme ça qu'on appelle int pour les entiers et double pour les flottants ?) pour éviter les codes de transformation à chaque fois que l'utilisateur voudra faire des opérations sur la date par exemple, et qui ralentissent l'exécution.

Je crois que c'est pour cette raison qu'il faut éviter d'utiliser des short sauf lorsque l'on a de grandes quantités de nombres (petits) à stocker et que la place en mémoire manque. Je fais peut-être fausse route en essayant de me préoccuper de ce genre de détails mais j'aimerais éclaircir le sujet.

En tout cas, pour les chaines, c'est char et non unsigned char

Ok. Il y a une raison particulière à ça ou c'est juste écrit dans la norme que c'est comme ça que ça fonctionne ?

[-ed-]

En fait, je me posait la question de l'intérêt de fournir à l'utilisateur une structure de données qui transforme les types char utilisés dans la structure "interne" en types natifs (je crois que c'est comme ça qu'on appelle int pour les entiers et double pour les flottants ?) pour éviter les codes de transformation à chaque fois que l'utilisateur voudra faire des opérations sur la date par exemple, et qui ralentissent l'exécution.

Il y a 2 impératifs contradictoires à gérer au mieux.

Les types 'natifs' (int, long, double) prennent plus de place mais les traitement sont plus rapides.

En gros, on utilise les types natifs pour les calculs et les type optimisés (char, short, float) pour le stockage.

Après, tu fais tes choix en fonction de ces impératifs.

En tout cas, pour les chaines, c'est char et non unsigned char

Ok. Il y a une raison particulière à ça ou c'est juste écrit dans la norme que c'est comme ça que ça fonctionne ?

C'est la norme. Tu tiens aux justifications détaillées ?

[Romu']

En gros, on utilise les types natifs pour les calculs et les type optimisés (char, short, float) pour le stockage.

Ok, merci bien, maintenant c'est définitivement gravé et je ne me poserai plus de questions !

C'est la norme. Tu tiens aux justifications détaillées ?

La question laissant sous-entendre qu'il y en a, je suis allé mener ma petite enquête dans la norme (ou en tout cas dans le draft de celle-ci qu'on accède par ce site).
Apparemment, char est un type différent de signed/unsigned char même s'il se comporte comme l'un des deux (pourquoi donc ?). Par contre avec le fait que ces 3 types soient appelés les types caractère, que des fonctions qui manipulent des caractères parlent de conversions en unsigned char, je suis perdu...
Je prend volontiers les explications détaillées.

[-ed-]

La question laissant sous-entendre qu'il y en a, je suis allé mener ma petite enquête dans la norme (ou en tout cas dans le draft de celle-ci qu'on accède par ce site).
Apparemment, char est un type différent de signed/unsigned char même s'il se comporte comme l'un des deux (pourquoi donc ?). Par contre avec le fait que ces 3 types soient appelés les types caractère, que des fonctions qui manipulent des caractères parlent de conversions en unsigned char, je suis perdu...
Je prend volontiers les explications détaillées.

En fait il n'y a pas de type 'caractère'. Il y a :

• Le type 'char' (ou 'plain char') qui est fait pour les caractères et qui est utilisé pour les chaines de caractères et les fonctions de manipulation de ces chaines (str*())de <string.h>). Son type peut être signé ou non selon l'implémentation (et selon le charset utilisé : ASCII : signé, EBCDIC : non signé))
  
• Le type unsigned char qui a une plage garantie de 0 à 255 et qui sert comme petit entier (peu recommandé, sauf stockage). C'est comme ça qu'on crée un flux d'octets, par exemple avant qu'il soit émis par une écriture fichier (FILE) ou une socket (SOCKET).
  
• Le type signed char est rarement utilisé. Il peut servir comme petit entier signé (plage garantie -127 à 127).
  

[Romu']

et selon le charset utilisé : ASCII : signé, EBCDIC : non signé

Je ne vois pas pourquoi une implémentation qui utiliserait l'ASCII se devrait d'avoir un char signé ?

Sinon, une question me reste :
les fonctions déclarées dans ctype.h demandent que la valeur qui leur est passée soit représentable par un unsigned char si elle n'est pas EOF. Pourquoi donc ?
Edit : après relecture de la norme, il semble qu'il y ai un rapport avec ce qui est dit sur les constantes de type caractère ('a', 'b' ...) et qu'il faille différencier représentation et valeur, puisque dans leur exemple on lit que \xFF peut valoir -1 ou +255 selon que char soit signé ou pas. C'est une piste mais ça reste flou.

[-ed-]

et selon le charset utilisé : ASCII : signé, EBCDIC : non signé

Je ne vois pas pourquoi une implémentation qui utiliserait l'ASCII se devrait d'avoir un char signé ?

Moi non plus, mais c'est comme ça. Sans doute le résultat de l'évolution...

Ne jamais perdre de vue que, contrairement au Pascal, qui est un langage 'universitaire', le C est un langage 'industriel', qui résulte d'évolutions, d'adaptations, de compromis, de prise en compte de l'existant etc.

les fonctions déclarées dans ctype.h demandent que la valeur qui leur est passée soit représentable par un unsigned char si elle n'est pas EOF. Pourquoi donc ?

Probablement par ce que des calculs sont faits dessus à l'aide d'opérateurs 'bits', ce qui nécessite que les types soient non signés pour que le résultat soit portable. Il faut donc faire attention avec les caractères > 127 en ASCII (car char risque fort d'être signé). Le cast en unsigned char est indispensable, sinon la promotion en int se fera via une extension de signe.

Par exemple si un char fait 8 bits, et que ceux-ci sont à 1 : 11111111, cela exprime 2 valeurs possibles :

unsigned char : 255
signed char (complement à 2) : -1

Un unsigned char valant 255 promu en int de 16-bit vaut 255 : 0000000011111111
Un char valant -1 promu en int de 16-bit vaut -1 : 1111111111111111. Cela est dû au mécanisme dit "d'extension de signe" propre au codage "complément à 2" (le plus répandu) des entiers signés.

[Romu']

Merci pour toutes ces précisions.

[Contenu sponsorisé]