Conversion de données

En même temps....
Si on en est là... autant:
1.a. Vérifier qu'on est sur une plateforme avec 'char = 8 bits' (mais c'est aussi valable pour l'union)
1.b. Vérifier que unsigned long long int est un entier 64 bits (chez moi je préfère utiliser un truc genre __int64).
2. Stocker les 8 chars dans un tableau
3. La norme assurant que &(tableau[idx+1]) = &(tableau[idx]) + sizeof(element de tableau) [en l'ocurrence 1] alors on peut écrire:

Code:

---

1 2 3 4 5 6

char tab[8]; // lecture du tableau tab[0] = 0x30; tab[1] = 0x89; ... // utilisation du tableau comme int64 *((unsigned long long int*)tab) ...

---

A noter que le code résultant est absoluement identique à l'utilisation de l'union (à mon avis plus propre).
Mais il reste tout de même à vérifier les tailles des types avant.

A vrai dire, je ne suis pas particulièrement fanas des cast "sauvages", surtout s'il faut commencer par caster un tableau en un pointeur sur un autre type pour finir par... prendre l'élément pointé par ce pointeur...

Tu me dira que c'est finalement exactement ce que fait l'union quand la taille des différents champs est calculée pour être identique, mais je reste malgré tout dans l'optique que c'est plus clair que le cast "sauvage"...

En outre, cela présente l'avantage de nous laisser une certaine latitude sur le nombre de caractères fournis...

En effet, le code (*(unssigned long long *)tab) serait fortement de nature à poser problème si, pour une raison ou une autre (l'incurie ou la distraction du programeur aidant), tab ne devait pas avoir été déclaré comme... un tableau de 8 char (sur base de la convention que l'on a décidé d'utiliser ici)...

Par contre, je t'accorde effectivement le fait qu'il faudrait au minimum s'assurer du nombre de char entrant dans un unsigned long long (ou dans un __uint64), étant donné que la seule chose dont on soit sur, c'est que c'est un nombre entier de char :aie:

Citation:

---

Envoyé par koala01

En gros, elle interdit juste d'essayer de travailler sur plus d'un champs de l'union à la fois.

---

Et ce que tu essaye de faire, c'est justement travailler sur plusieurs champs à la fois, puisque tu espère lire dans un des choses correspondant à ce que tu as écrit dans l'autre, et donc au moment de la lecture, tu suppose que les deux sont actifs simultanément.

Le texte exact est :

Citation:

---

Envoyé par Le standard

In a union, at most one of the data members can be active at any time, that is, the value of at most one of the data members can be stored in a union at any time. [Note: one special guarantee is made in order to simplify the use of unions: If a PODunion contains several PODstructs that share a common initial sequence (9.2), and if an object of this PODunion
type contains one of the PODstructs, it is permitted to inspect the common initial sequence of any of PODstruct members; see 9.2. ]

---

Citation:

---

Envoyé par koala01

Ainsi, tu ne pourrais pas envisager quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10 11

union MyUnion { char chartab[8]; long long mylong; }   void foo() { MyUnion u; u.chartab[1]=0xff,u.mylong=0xFAFAFAFAFAFA; }

---

---

Si, justement. Là, tu n'as pas pas supposé que deux champs étaient actifs simultanément, mais successivement. Donc pas de problème.

Pour le code que je donnais en exemple, je ne dis pas... par contre, je traduis peut être mal, mais, pour moi,

Citation:

---

, the value of at most one of the data members can be stored in a union at any time

---

ca signifie

Citation:

---

la valeur de maximum un membre peut être stockée à chaque fois

---

Il s'agit donc de l'acces en écriture aux membre, et non de l'acces en lecture...

Il n'y a donc rien qui interdise, étant donné qu'un membre ne sera considéré actif que justqu'à la fin de l'instruction dans laquelle on l'utilise, de travailler sous une forme (désolé, je travaille encore avec un antique 32 bits)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

union MyUnion { unsigned char tab[4]; unsigned int entier; }; int main() { MyUnion mu; mu.tab[0] = 0X40; mu.tab[1] = 0X40; mu.tab[2] = 0X40; mu.tab[3] = 0X40; cout<<hex<<mu.entier; return 0; }

---

Je t'avouerai d'ailleurs que je n'arrive pas à trouver une situation (en mono-thread) dans laquelle les deux membres seraient actifs ne même temps...

koala01: Mais là, tu accèdes à un champ que tu ne viens pas de stocker --> comportement indéfini, mu.entier est considéré comme non-initialisé.

Okay, je vois ou tu veux en venir...

Mais, "considéré comme" non initialisé ne veut pas dire qu'il ne le soit pas forcément... et, dan le cas présent, il est effectivement initialisé (même si c'est de manière détournée, mais du simple fait du fonctionnement intrincèque de l'union) :aie:

En outre, les unions pouvant avoir des fonctions et - dans le cas qui nous intéresse - plus particulièrement un constructeur, il est possible d'envisager d'en rajouter un qui initialiserait bel et bien le membre le plus long à 0 ;)

Enfin, même si je sais que le "ça marche chez moi" ne doit pas inciter à tirer des conclusions, il se fait que... "ça marche chez moi", et cela donne exactement le résultat auquel je m'attendais :aie:

Je t'avouerai, pour préciser les choses, que je ne suis pas particulièrement fana des unions, et que je suis donc *peut-etre* passé à coté de quelque chose...

Je prend donc les remarques que l'on peut me faire sur le sujet d'un point de vue "didactique" (ce qui justifie quelque part mon insistance)

Mais, à moins (et je ne demanderais pas mieux) que l'on m'explique (en dehors d'un "comportement potentiellement indéfini") clairement où mon raisonnement blesse, je trouve que l'union est sans doute de nature à apporter une sécurité supplémentaire par rapport à un transtypage sauvage, même si cette sécurité s'applique plus au transtypage (unsigned long) long ->char* qu'au transtypage char*-->(unsigned long) long.

A mon sens, les comportements indéfinis peuvent résulter du fait qu'il n'est pas possible de prédire l'ordre dans lequel le code (et le CPU) va charger les registres, ni la granularité des accès aux différents champs d'une union.
=> Les comportements peuvent varient en fonction du compilo et le CPU.
- W

Citation:

---

Envoyé par wiztricks

A mon sens, les comportements indéfinis peuvent résulter du fait qu'il n'est pas possible de prédire l'ordre dans lequel le code (et le CPU) va charger les registres, ni la granularité des accès aux différents champs d'une union.
=> Les comportements peuvent varient en fonction du compilo et le CPU.
- W

---

Je vais peut-être (surement :question:) avoir l'air buté, mais, je ne suis pas convaincu...

En effet, le propre d'une union est de faire de manière à ce que tous ses membres utilisent le même emplacement mémoire, dont la taille est celle du membre le plus grand.

Dés lors, tant que l'on travaille sur des type primitifs compatibles et assurant l'alignement des données, il ne devrait pas y avoir de problème.

J'admets qu'une union du genre de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

union MyUnion { struct Squeletton { unsigned char tail; //8 bits (par convention) unsigned short middle; //16 bits (chez moi) unsigned char head; //8 bit; }; Squeletton part; unsigned int entier; //32 bits (chez moi) };

---

posera des problèmes, car l'alignement des données fait que la structure Squeletton ne fera pas 32 bits comme on pourrait s'y attendre, mais plutôt... (chez moi) 48 (:aie:), et que la taille "finale" de l'union sera dés lors de ...(toujours, chez moi) 64 bits (re :aie:)

Par contre, si la base de réflexion est de se dire (histoire de pouvoir donner des valeurs précises):

Citation:

---

un unsigned long long prend la taille de 8 char consécutifs

---

et que l'on crée une union dans laquelle l'un des membres est un "tableau de 8 char consécutifs", ainsi que je le propose avec mon fameux

Code:

---

1 2 3 4 5

MyUnion { unsigned char tabchar[8]; unsigned long long entier; }

---

l'alignement des données est maintenu, que ce soit en mémoire ou en registre, et ce, même si un unsigned long long est trop grand pour tenir dans un seul registre...

En effet, la priorité primordiale d'une union est que l'ensemble de ses membres utilisent le même emplacement mémoire, d'une taille égale au membre le plus grand.

Dés lors, qu'il faille monopoliser un ou plusieurs registres pour y placer l'instance de l'union, ce seront les même instructions qui seront utilisée qu'il s'agisse d'y placer l'instance au départ de tabchar ou au départ d'entier...

Et si une instruction demande de donner la valeur X au caractère se trouvant en 5 eme position, le compilateur devra de toutes manières prendre en compte le décalage nécessaire (que ce soit dans le registre ou directement en mémoire) permettant de dépasser les quatre premiers...

Au final, je ne vois pas en quoi la granularité des membres de l'union ou l'ordre dans lequel le CPU la chargerait en registre serait de nature à apporter un comportement indéfini...

Maintenant, comme je l'ai dit, il se peut que la logique que je suis ne soit pas correcte... mais alors, qu'on me dise où ;)

Si j'ai :

Code:

---

1 2 3 4 5 6 7 8 9

union U {int i; char c};   char f() { U u; u.i = 42; // <= Supprimable à l'optimisation return u.c; }

---

Je m'attends à ce qu'un compilateur optimisant bien supprime l'écriture dans u.i, puisqu'il voit qu'elle ne sert à rien.

Certains compilateurs ne le font peut-être pas, pour permettre plus de chose sur les unions que ce que permet la norme, mais ils seraient en droit de le faire.

L'exemple est un peu osé... Mais est une bonne illustration.

Je pensais à des cas beaucoup plus tordus mais je n'ai pas encore trouvé d'exemple qui marche.
- W

Merci JolyLoic... au moins, maintenant, je comprend où mon raisonnement blessait ;):hola:

Mais, donc, si je comprend bien, avant de vouloir accéder - en lecture - "à l'autre membre" que celui auquel on vient d'accéder en écriture, il faut s'assurer d'avoir "validé" l'écriture pour que le compilateur ne soit pas tenté de supprimer une instruction qu'il jugerait sans effet :question:

En fait, il n'y a pas de moyen garanti par la norme de faire ce que tu veux (par contre, ton compilateur peut garantir plus, je crois que ce que tu veux faire est garanti par Visual C++, par exemple, car ils utilisent cette écriture dans certaines API windows). Pour avoir le droit de lire un membre d'une union, il faut :
- Soit avoir écrit dedans auparavant, et ne pas avoir écrit dans un autre membre entre temps.
- Soit être dans un cas particulier comme le suivant :

Code:

---

1 2 3 4 5 6 7

union U { struct T1 {int i; long j}; struct T2 {int i; double d}; T1 t1; T2 t2; };

---

Tu as le droit de lire la partie i de t2 après avoir écrit t1.


Pour ce qui est du problème initial, je préfère généralement travailler par décalage de bits, ce qui a aussi pour effet de me permettre de maîtriser simplement ce qui se passe, et de manière indépendante de la plate-forme, de son boutisme,... Et ce même dans les cas où l'écriture à base d'union marche.