Discussion :

[sone47]

Bonjour,

Je souhaite remonter des infos bas niveau et désire les stocker dans une structure contenant une union pour ne pas gaspiller trop de memoire inutilement.

Dans mon union sont définis 2 structures d'infos, dont l'une d'entre elles est elle meme decoupée en 2.

Mon probleme est que lorsque je recupere bas niveau les data, je ne sais pas encore de quelle type elles seront (Info1 ou Info2) et je ne souhaite pas faire cette reconnaissance (c'est justement le job fait au haut niveau)

Ma question est donc, faut il toujours factoriser les champs pour avoir un premier champs commun précédant l'union et faire un memmove des data sur ce premier champs (l'union sera remplie sans savoir encore de quel type il s'agit [Question: l'ordre des champs est il garantie ?]).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
typedef struct COMPO_INFO_struct
{
   unsigned char     IdInfo;
   union
   {
      struct // INFO1
      {
         ENTETE_INFO1 EnteteInfo;
      }Info1;
 
      struct // INFO2
      {
            ENTETE_INFO2 EnteteInfo;
      }Info2;
   }info;
}COMPO_INFO;
 
// Et pour affecter le contenu:
COMPO_INFO message
memmove(&message.IdInfo, buffer, bufferSize) // buffer contenant soit un info1 soit un info2

Ou alors est il possible de faire un memmove sur l'union directement et non un des champs de son contenu, dans le cas ou il n'y a pas de factorisation?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
typedef struct COMPO_INFO_struct
{   
   union
   {
      struct // INFO1
      {
            unsigned char     IdInfo;
            ENTETE_INFO1 EnteteInfo;
      }Info1;
 
      struct // INFO2
      {
            unsigned char     IdInfo;
            ENTETE_INFO2 EnteteInfo;
      }Info2;
 
   }info;
 
}COMPO_INFO;
 
// Et faire quelque chose du genre:
COMPO_INFO message
memmove(&message.info, buffer, bufferSize) // Je pense pas que cela marche mais c'est pour l'idee

Mes questions portent donc sur ce qui est possible de faire, et surtout sur quelle solution adopter lorsque l'on utilise les unions.

Merci beaucoup d'avance,
Bonne fin de journée

[souviron34]

la solution serait plus classe, mais à condition de lire séparément le premier char . Bien qu'il soit souvent le cas que avec ta structure ce soit contigu, rien ne l'oblige...

Maintenant, normalement dans ton union tu devrais utiliser un troisème terme qui regrouperait le tout :

Soit en connaissant le max de la taille de INFO1 et INFO2 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
typedef union COMPO_INFO_struct
{
   unsigned char  Any[max] ; 
   struct // INFO1
     {
         unsigned char     IdInfo;
         ENTETE_INFO1 EnteteInfo;
      }Info1;
 
    struct // INFO2
      {
           unsigned char     IdInfo;
           ENTETE_INFO2 EnteteInfo;
      }Info2;
}COMPO_INFO;
 
COMPO_INFO message
memmove(message.Any, buffer, bufferSize)

ou en allouant dynamiquement et en déclarant Any comme unsigned char*

[sone47]

Bonjour Souviron34 et merci,

Laquelle des solutions serait plus classe, celle ou il n'y a pas de factorisation ?
Tu dis que rien n'oblige les champs á être contigus, cela dépend de quoi?

Concernant la solution que tu proposes, je connais les tailles max de mes structures qui sont fixes, penses tu que je devrai donc préférer rajouter un énième champs buffer de la taille max possible, et travailler dedans au bas niveau ? Maintenant si les champs ne sont pas obligatoirement contigus, le problème pourra toujours se poser.

En fait je voulais utiliser cette union car actuellement tout le process qui remonte les infos jusqu'au haut niveau est fait dans un simple buffer de char, donc chaque level tape dans le buffer á coup de grands casts et niveau maintenabilité et compréhension ca devient vite le bordel. Je pensais qu'en utilisant cette union cela clarifierai la structure générale des infos.
Maintenant c'est peut être mon concept justement qui n'est pas adapté aussi.

[diogene]

Tu dis que rien n'oblige les champs à être contigus, cela dépend de quoi?

du choix du compilateur pour l'alignement (l'adresse doit être sur un multiple de 1 byte, 2 bytes, 4 bytes,...) qu'il fait selon le type de données (ce qui peut parfois être contraint par une option du compilateur).

Moyennant quoi, on sait sur une structure que
- l'adresse de début de la structure est l'adresse du premier champ (moyennant un cast convenable)
- les champs sont placés en mémoire dans l'ordre des déclarations
- ils ne sont pas forcément contigüs à cause de l'alignement
- en conséquence, la taille de la structure peut dépendre de l'ordre de déclaration de ses champs.