union et struct ? [Résolu]

[FoX_*D i E*]

Bonjour,
J'étudie toujours le même tutorial : http://c.developpez.com/cours/poly-c/?page=page_2

et union me pose un probleme.
Si j'ai bien compris, l'attribut de union qui sera le seul à etre apelé est celui qui occupe le plus d'espace.

Suis-je bon ou tout a fait en dehors de la plaque?

ps : si mon intuition dit juste, a quoi bon utiliser union au lieu de struc?

[Obsidian]

et union me pose un probleme.
Si j'ai bien compris, l'attribut de union qui sera le seul à etre apelé est celui qui occupe le plus d'espace.

Pas tout-à-fait : une union est en fait une « structure » dont tous les membres occuperaient le même espace mémoire. La taille de l'union est donc égale à celle du membre le plus grand (modulo un éventuel bourrage).

ps : si mon intuition dit juste, a quoi bon utiliser union au lieu de struc?

L'idée est que tu n'utilises qu'un seul membre… à la fois ! C'est pratique lorsque, par exemple, une fonction doit retourner un objet dont le type n'est pas toujours le même selon la situation.

Un cas typique est la transmision d'événements dans les interfaces graphiques, par exemple avec la XLib : tu peux définir un type « Event » qui est en fait l'union de tous les types d'événements possibles : MouseEvent, ButtonEvent, KeyboardEvent, etc. Dès lors que tu sais quel genre d'événement tu as reçu, tu peux directement aller chercher les informations qui lui sont propres.

[FoX_*D i E*]

ok c'est plus claie maintenant, je te remercie

comment plusieurs attribut peuvent occuper le meme espace. Un champ de mémoire serait subdivisable? j'arrive pas a m'imaginer ca

[pfeuh]

Salut,

Envoyé par FoX_*D i E*

comment plusieurs attribut peuvent occuper le meme espace. Un champ de mémoire serait subdivisable?

Il n'y a pas plusieurs attributs. Quand tu créées une union, c'est pour un objet d'un type précis choisi par toi dans l'union bien sûr, mais un seul à la fois. Dans un event de type click de souris, il ne faut pas s'attendre à trouver des infos valides sur un event clavier.

A+

Pfeuh

[leternel]

c'est pas clair votre explication.

Un exemple du principe. Supposons l'union suivante:

Code :

1
2
3
4
5
6
7
union U {
int alpha;
long beta;
char gamma;
};
 
union U u;

alors, nous avons les propriétés suivantes.

• u.alpha, u.beta et u.gamma ont la même adresse, qui est d'ailleurs l'adresse de u.
• sizeof(u) = max( sizeof(u.alpha), sizeof(u.beta), sizeof(u.gamma))
• comme les champs ont la même adresse, ils partagent le même contenu binaire

[Captain'Flam]

Si je puis me permettre d'en rajouter une couche,
voici un petit code qui permet de regarder à quoi ressemble un double :

Code :

1
2
3
4
5
6
7
8
9
10
11
union U 
    {
    double d ;
    unsigned char b [sizeof( double )] ;
    };
 
int i ;
U u ;
u.d = 3.1415927 ;
for ( i = 0 ; i < sizeof( double ) ; ++i )
    printf(" %02X",u.b[i] ) ;

Bien sûr, tu pourrais faire

Code :

1
2
3
4
double x = 3.1415927 ;
unsigned char * b = (unsigned char*)&x ;
for ( i = 0 ; i < sizeof( double ) ; ++i )
    printf(" %02X",b[i] ) ;

mais c'est moins classe !

Une union, outre le gain de place, permet de faire des transtypages un peu moins crades.
Mais attention, en règle générale, les unions sont dangereuses et à proscrire !
Avoir 2 (ou +) variables au même emplacement mémoire, c'est un peu casse-gueule !
Personnellement, depuis que la mémoire n'est plus une denrée rare, je ne m'en sers plus jamais.

[FoX_*D i E*]

ok, je n'ai plus qu'a étudier ce qu'est une adresse mémoire en C, et j'aurais compris à 100%

je vous remercie pour vos réponses

[Médinoc]

En gros, il y a deux usages principaux des unions:

L'un est le "union-cast" montré par Captain'Flam, où l'on écrit en tant qu'un membre et on lit en tant qu'un autre. Il n'y a pas grand-chose ici qui soit garanti portable.

L'autre usage est pour économiser de l'espace, ou un paramètre de fonction. Imagine une fonction qui peut prendre en paramètre soit un entier, soit une chaîne de caractères.

Code C :

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
38
39
40
/*
Exemple de "tagged union"
*/
#include <stdio.h>
 
enum union_type
{
	U_STRING,
	U_NUMBER
};
 
/* La structure contient deux membres:
Une union et une valeur indiquant quel membre a été réglé. */
typedef struct tagged_union
{
	enum union_type type;
	union
	{
		char const * string;
		int number;
	} u;
} TAGGED_UNION;
 
void Afficher(TAGGED_UNION tu)
{
	switch(tu.type)
	{
	case U_STRING: puts(tu.u.string); break;
	case U_NUMBER: printf("%d\n", tu.u.number); break;
	}
}
 
int main(void)
{
	TAGGED_UNION tu;
	tu.type = U_STRING;
	tu.u.string = "Bonjour!";
	Afficher(tu);
	return 0;
}

Normalement, ce code devrait être safe et portable, vu qu'on lit toujours l'union par le même membre qu'à son écriture.

[FoX_*D i E*]

Ah, la je comprend moins bien ^^

Est ce que ce que a dit leternel est correcte?

Je viens de finir le tuto sur C, et je commence celui de C++
Alors vous pourrez observer mes postes sur le forum C++ débuter à l'occasion.

ciao bonsoir

[Obsidian]

Comme on te l'a dit plus haut, il s'agit simplement de faire en sorte que tous les membres d'une union partagent le même espace mémoire. Donc, quand tu remplis l'un d'eux, tu écrases forcément les autres.

Une union est utile lorsque le type d'un paramètre à transmettre ou à renvoyer peut varier d'une situation à l'autre. Ça donne la possibilité au programme de choisir le champ adéquat en fonction des circonstances tout en permettant au compilateur de maintenir la contrainte de type, plutôt que de recourir à un transtypage « (void *) » jamais très propre.

C'est déjà pratique en soi lorsqu'il s'agit de types natifs tels que float, int ou pointeurs, mais ça devient crucial lorsque les membres sont eux-mêmes d'autres structures ou unions : il est alors nécessaire qu'ils soient définis comme tels pour que le programme puisse se référer à leurs champs.

[FoX_*D i E*]

ok, I understand now,

Je vous remercie de vos réponses.
Je vais essayer de placer quelque union dans mes ancien projet, pour voir ce que ca donne.

je vous souhaite de bonne fêtes

[leternel]

merci, toi aussi!

Par contre, la démarche "le C d'abord, le C++ après" n'est pas forcément la meilleure idée.
Il y a des choses obligatoires en C qui sont à bannir en C++ (notamment dans la gestion de la mémoire).

Cependant, oui, il vaut mieux comprendre les outils de bases en premier.

A part la syntaxe, l'apport de l'objet en C++ fait de ce dernier un langage fondamentalement différent du C

[FoX_*D i E*]

Bin en fait dans le cours de C++ que voici :
http://cpp.developpez.com/cours/polyCpp/

L'auteur dit explicitement que le C doit etre acqui avant de se plonger dans son tuto, alors les tuto que j'étudie sont:

Le langage C
Le langage C++
Le C++ pour les pros

[Médinoc]

Ça dépend des cours. Un cours basé sur le C te fera prendre/gardr des mauvaises habitudes s'il n'est pas exceptionnellement bon et exceptionnellement clair sur les pratiques C à oublier en C++.

[leternel]

Quand, dans le cours, il parle du C, j'imagine qu'il parle des bases (que j'étudierais dans cet ordre):

• syntaxe
• types de base
• compréhension du processus de compilation
• la virgule flottante et son imprécision inhérente (pourquoi 1.0+0.1!=1.1)
• fonctions
• tableaux
• le cas particulier de la chaîne de caractères
• structures
• pointeurs
• un aperçu du préprocesseur
• unions

Les subtilités du C ne sont pas utiles, voire contre-productives, pour le C++.
Je pense par exemple à toutes les fonctions de manipulation de chaînes (str...).