Savoir quel membre d'une union est utilisé

Bonjour à tous,

Pour représenter un type de données, j'ai l'union suivante :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

typedef union { short brut; struct { unsigned codeop : 6; unsigned mode : 4; unsigned source : 3; unsigned dest : 3; } codage; } mot;

---

• La structure codage qui contient 4 champs de bits.
• Cette structure est contenue dans une union mot, en concurrence avec un short

Selon le principe de l'union, j'utilise le type mot soit comme un struct codage, soit comme un short.

Jusqu'ici tout va bien.

Mon problème est le suivant : comment savoir quelle "partie" de l'union est utilisée ?

Exemple :

Code:

---

1 2	mot unMot; unMot.brut = 32;

---

Je voudrais savoir si unMot est un short, ou un struct codage.

J'ai essayé

Code:

---

1 2 3

if ( unMot.codage == NULL ) { printf("Le mot est un short"); }

---

Bien évidemment cela ne fonctionne pas.

Pourriez-vous éclairer ma lanterne ?

Ce qui ce fait dans ces cas là, c'est de rajouter un entête qui indique quelle partie de l'union il faut utiliser :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

typedef union { short brut; struct { unsigned codeop : 6; unsigned mode : 4; unsigned source : 3; unsigned dest : 3; } codage; } mot;   typedef struct { short indicateur; // 0, on utilise le champs codage de l'union, 1: on utilise le champ brut de l'union mot union_mot; } stucture_tag_t;   int main(void) { stucture_tag_t valeur; valeur.indicateur = 0; valeur.union_mot.brut = 12;   if(valeur.indicateur == 0) { printf("Le mot est un short"); } else if(valeur.indicateur == 1) { printf("Le mot est un champ de bits"); } else { printf("Je ne sais pas"); } }

---

Par contre, il faut de la rigueur lorsque l'on rempli la structure et l'union pour mettre des valeurs cohérentes

Citation:

---

Envoyé par Christophe_

Pourriez-vous éclairer ma lanterne ?

---

Pour compléter ce que propose ram-0000, j'ajouterais que le principe même de l'union est d'utiliser le même emplacement mémoire pour tous les membres de l'union. La question n'est donc pas de savoir quel membre est utilisé mais à quoi sont employées les données que l'on trouve dans l'instance de ton union. Tu ne peux donc pas savoir à priori quel est le membre utilisé.

Si certains langages te permettent de le faire, c'est parce qu'ils tiennent un état des membres utilisés ou non dans une autre variable. La solution est donc, comme indiquée, d'encapsuler ton union dans une autre structure, pour l'accompagner d'un champ type.

Certaines bilbiothèques telles que celle de X-Window optimisent encore un peu ce procédé : une union composée exclusivement de structures dont le premier champ est invariablement un int. Ainsi, même sans avoir à faire de magic cast, on pouvait identifier facilement le contenu et utiliser le membre adéquat, sans avoir à traîner un nom de membre explicite tel que « data » ou autre ...

Citation:

---

Envoyé par Obsidian

Certaines bilbiothèques telles que celle de X-Window optimisent encore un peu ce procédé : une union composée exclusivement de structures dont le premier champ est invariablement un int. Ainsi, même sans avoir à faire de magic cast, on pouvait identifier facilement le contenu et utiliser le membre adéquat, sans avoir à traîner un nom de membre explicite tel que « data » ou autre ...

---

+1, j'ai pas osé en parler mais c'est exactement à cela que je pensais

Merci à vous pour ces réponses.

Je prends bonne note de l'encapsulation de l'union.

Néanmoins, je suis tenu d'utiliser l'union mot. Je ne peux donc pas créer de nouvelles structures de données comme vous le proposez :(

Y-a-t-il un quelconque autre moyen de procéder ?

Citation:

---

Envoyé par Christophe_

Y-a-t-il un quelconque autre moyen de procéder ?

---

Non..

Comme on te l'a dit, c'est fait justement pour ne pas le savoir :P

Quel est le problème exactement ???

Citation:

---

Envoyé par souviron34

Non..

Quel est le problème exactement ???

---

Soit un tableau de 500 mot, censé représenté la mémoire d'un ordinateur.
Chaque mot contient soit une instruction assembleur (membre codage) soit une donnée (membre brut).

Le membre mode de la structure codage représente un mode d'adressage.
Pour certaines valeurs de ce mode d'adressage, le mot suivant dans la mémoire doit obligatoirement être une donnée (donc membre brut utilisé)

Une petite illustration (ADD, REGREG et REGIMM sont des constantes définies) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

// La mémoire mot memoire[500] = { // Pour le mode REGREG, pas besoin de mot de donnée {.codage = {ADD, REGREG, 4, 2} },   // Par contre pour le mode REGIMM, le mot suivant l'instruction doit être une donnée {.codage = {ADD, REGIMM, 0, 2} }, {.brut = {120} };

---

Le premier codage est indépendant, puisqu'en mode REGREG.
En revanche, le deuxième codage doit obligatoirement être suivi d'un brut puisqu'il utilise le mode REGIMM.

Lors du contrôle de la validité du code, je dois donc vérifier que le mot suivant le deuxième codage est bien un brut. Autrement dit, que c'est bien le membre brut de l'union qui est utilisé.

Citation:

---

Envoyé par Christophe_

Bonjour à tous,

Pour représenter un type de données, j'ai l'union suivante :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

typedef union { short brut; struct { unsigned codeop : 6; unsigned mode : 4; unsigned source : 3; unsigned dest : 3; } codage; } mot;

---

• La structure codage qui contient 4 champs de bits.
• Cette structure est contenue dans une union mot, en concurrence avec un short

Selon le principe de l'union, j'utilise le type mot soit comme un struct codage, soit comme un short.

Jusqu'ici tout va bien.

Mon problème est le suivant : comment savoir quelle "partie" de l'union est utilisée ?

---

Je ne comprends pas à quoi sert cette union. J'espère que tu n écris pas dans un membre en croyant récupérer les données dans l'autre, car ce n'est absolument pas portable. Une union sert exclusivement à rendre une zone mémoire 'générique', et ce, à l'aide d'un 'sélecteur' :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

enum select {SELECT_BRUT, SELECT_CODAGE};   struct data { enum select select; union { short brut; struct { unsigned codeop : 6; unsigned mode : 4; unsigned source : 3; unsigned dest : 3; } codage; } mot; };

---

Nota ceci est techniquement possible, mais le résultat n'est pas portable :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

#include <stdio.h>   union mot { short brut; struct { unsigned codeop:6; unsigned mode:4; unsigned source:3; unsigned dest:3; } codage; };   int main (void) { union mot mot; mot.brut = 01234;   printf ("codeop = %u\n", mot.codage.codeop);   return 0; }

---

Citation:

---

Envoyé par Emmanuel Delahaye

Je ne comprends pas à quoi sert cette union. J'espère que tu n écris pas dans un membre en croyant récupérer les données dans l'autre, car ce n'est absolument pas portable. Une union sert exclusivement à rendre une zone mémoire 'générique', et ce, à l'aide d'un 'sélecteur' :

---

L'union est utilisée pour que l'on puisse y stocker indifféremment un brut ou un mot. Je l'utilise donc bien comme une zone de mémoire générique.

Citation:

---

Envoyé par Emmanuel Delahaye

Nota ceci est techniquement possible, mais le résultat n'est pas portable :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

#include <stdio.h>   union mot { short brut; struct { unsigned codeop:6; unsigned mode:4; unsigned source:3; unsigned dest:3; } codage; };   int main (void) { union mot mot; mot.brut = 01234;   printf ("codeop = %u\n", mot.codage.codeop);   return 0; }

---

---

Tout d'abord la portabilité n'est pas un critère important dans ce projet.
Sur le code que tu me donnes, mot utilise le membre brut de l'union.
L'affichage (d'un champ du membre codage) donne 28 chez moi. Je pensais que cela provoquerait un bug. D'ou provient ce 28 ?

Si on initialise l'union en tant que brut, alors mot.codage devrait être un espèce de pointeur null non ?


L'idéal serait que j'arrive à détecter que mot n'est pas un codage, mais bel et bien un brut

Citation:

---

Envoyé par Christophe_

L'idéal serait que j'arrive à détecter que mot n'est pas un codage, mais bel et bien un brut

---

Tu ne peux pas, c'est impossible, à moins d'utiliser un des artifices cités plus haut.

Très bien !

Je vais me résoudre alors.. :(

Merci beaucoup pour toute votre aide

Citation:

---

Envoyé par Christophe_

L'union est utilisée pour que l'on puisse y stocker indifféremment un brut ou un mot. Je l'utilise donc bien comme une zone de mémoire générique.

---

OK. Tant que tu n'écris pas d'un coté pour lire de l'autre, ça va.

Citation:

---

Tout d'abord la portabilité n'est pas un critère important dans ce projet.

---

Plus que tu ne le penses... (voir plus loin).

Citation:

---

Sur le code que tu me donnes, mot utilise le membre brut de l'union.
L'affichage (d'un champ du membre codage) donne 28 chez moi. Je pensais que cela provoquerait un bug. D'ou provient ce 28 ?

---

Justement, tout le problème est là. On doit pouvoir trouver une explication rationnelle basée sur

- L'endianness
- Le padding
- L'ordre des bits dans les champs de bits
- Les phases de la lunes

en étudiant la doc du compilateur et en essayant de savoir quelle est la combinaison exacte "machine + système + compilateur + config du compilateur" qui fait que ça marche comme ça.

Si un paramètre change, rien ne garantit que le comportement soit le même. C'est ça le problème de la non-portabilité. Le fonctionne est bel et bien défini, mais dans des conditions très précises que l'on maitrise rarement... alors bien sûr, on peut s'assoir dessus et prier pour que rien ne change, surtout le jour de la démo devant les clients et en présence du grand chef à plumes...

On peut aussi écrire du code portable, c'est à dire indépendant de la plateforme. C'est moins stressant ...

Citation:

---

Si on initialise l'union en tant que brut, alors mot.codage devrait être un espèce de pointeur null non ?

---

On n'initialise pas 'en tant que'. On écrit dans un des membres, c'est tout. Ça positionne les bits de la zone mémoire d'une certaine façon, ce qui a une signification différente (valide ou non) dans les autres membres de l'union. Il n'y a pas de pointeur, pas de gestion dynamique. Tout cela est complètement statique et conventionnel.

Citation:

---

L'idéal serait que j'arrive à détecter que mot n'est pas un codage, mais bel et bien un brut

---

Il n'y a rien à 'détecter'. C'est à toi de savoir ce que tu fais et de mettre dans le sélecteur la constante qui indique quel élément de l'union est utilisé.

Ok je pense que tout devient clair.

En gros si j'initialise en tant que brut à 1000 0101 0011 0111, et qu'ensuite je demande codage.codeop qui est sur 6 bits, alors l'ordinateur va me sortir 6 bits parmi ceux de l'initialisation.

Lui il n'en a rien à faire si c'est un brut ou un codage, tout ce qui l'intéresse c'est le nombre de bits que je demande.

J'ai cru comprendre que les bits "choisis" par l'ordinateur étaient fonction des critères que tu énonces ci-dessus.

J'espère avoir bien compris, et encore une fois merci pour votre aide

Citation:

---

Envoyé par Christophe_

J'espère avoir bien compris, et encore une fois merci pour votre aide

---

Tu as bien compris.

Citation:

---

Envoyé par Emmanuel Delahaye

J'espère que tu n écris pas dans un membre en croyant récupérer les données dans l'autre, car ce n'est absolument pas portable.

---

Pire que pas portable (ce que j'ai tendance a comprendre comme defini par l'implementation -- dans le cas present pour des problemes de padding et de boutisme par exemple), c'est un comportement indefini et donc le compilateur peut supposer que ca n'arrive pas. Les optimiseurs utilisent de plus en plus ce genre de latitude, et parfois de maniere apparemment non causale (chercher gcc et strict-alias ou VRP par exemple). C'est peut-etre avec la prochaine version de ton compilateur ou quand quelqu'un activera une optimisation supplementaire que les problemes arriveront.

Ah, je pensais que c'était au moins défini par l'implémentation...

D'un autre côté, certaines implémentations peuvent définir cela sans que la norme l'exige, donc ça reste indéfini côté norme, mais une implémentation particulière le définit quand même...

Citation:

---

Envoyé par Christophe_

Ok je pense que tout devient clair.

En gros si j'initialise en tant que brut à 1000 0101 0011 0111, et qu'ensuite je demande codage.codeop qui est sur 6 bits, alors l'ordinateur va me sortir 6 bits parmi ceux de l'initialisation.

---

Non. Il va faire ce qu'il veut. C'est de l'indefini (ce qui n'empeche pas un compilateur de le definir, mais la il faut chercher dans la doc -- simplement le fait qu'il fasse ce que tu desires maintenant n'est pas une garantie).

Citation:

---

Envoyé par Christophe_

En gros si j'initialise en tant que brut à 1000 0101 0011 0111, et qu'ensuite je demande codage.codeop qui est sur 6 bits, alors l'ordinateur va me sortir 6 bits parmi ceux de l'initialisation.

Lui il n'en a rien à faire si c'est un brut ou un codage, tout ce qui l'intéresse c'est le nombre de bits que je demande.

---

En dehors des aspects de padding cités ci-dessus, un dessin vaut mieux que mille mots...


La place réservée pour une union est (au minimum, voir ci-dessus) la taille du plus grand élément... Si donc tu as par exemple

Code:

---

1 2 3 4 5 6 7

union {   double d ; int i ; char c ;   } T ;

---

En mémoire tu auras, lorsque tu déclares une variable de ce type, à l'adresse de départ :

Code:

---

1 2 3 4 5 6 7 8

T ..................................... d ..................................... i ................... c ....

---

Comme la place réservée est celle du plus grand, il y a place pour n'importe quoi de prévu dans l'union.

Cependant, vu que tout est au même endroit, et que tout est censé démarrer à la même adresse, tu ne peux pas savoir qu'est-ce qui a été affecté, puisque les bits sont tous settés (peut-être avec des valeurs farfelues), même si tu écris un char. Si tu fais T.c = 'a', les bits suivants donnent à priori quand même une valeur de int ou de double...

Par conséquent, une fois écrit, il n'y a aucun moyen de savoir quel membre a été écrit. Même une exploration bit à bit ne te donnerais rien...

Mes prédecesseurs ont très bien expliqué l'usage...