Généricité void *

Version imprimable

12/12/2014, 21h07
sbill

Généricité void *
Bonsoir,

Pourriez-vous m'expliquer pourquoi ce code compile :
Code:

1 2 3 4 5 6 7 void swap( void * d1 , void * d2 ) { void * tmp; tmp = *(void **)d1; *(void **)d1 = *(void **)d2; *(void **)d2 = tmp; }
Je ne comprend pas le fait que le compilateur accepte de déréférencer un pointeur void en passant par un double pointeur...

Merci.
12/12/2014, 21h56
Bktero

Bonsoir,

Peut-être bien parce que tu castes et que caster ça veut dire "tais-toi je sais ce que je fais".
13/12/2014, 04h25
fearyourself

Et aussi que déréférencer un double pointeur void a un sens or le faire pour un simple pointeur void n'en a aucun :)
13/12/2014, 09h45
Invité

Citation:

Envoyé par fearyourself

Et aussi que déréférencer un double pointeur void a un sens or le faire pour un simple pointeur void n'en a aucun :)

Mais encore ? Peux-tu développer ?
Le sujet m'intéresse, et j'ai du mal je l'avoue à voir le sens du déférencement d'un double pointeur void.
13/12/2014, 13h40
sbill

Citation:

Et aussi que déréférencer un double pointeur void a un sens or le faire pour un simple pointeur void n'en a aucun

Oui, mais pourquoi ? Quoi qu'il en soit à la fin le pointeur générique ne sait pas vers quel type de variable son contenu pointe, d'ou l'impossibilité de déréférencer le pointeur. En quoi passer par un double pointeur résout le problème ?
13/12/2014, 14h43
Sve@r

Bonjour

Citation:

Envoyé par sbill

Oui, mais pourquoi ? Quoi qu'il en soit à la fin le pointeur générique ne sait pas vers quel type de variable son contenu pointe, d'ou l'impossibilité de déréférencer le pointeur. En quoi passer par un double pointeur
résout le problème ?

C'est vrai qu'aller voir le contenu d'un void* n'a pas de sens, on ne sait pas vers quoi on pointe effectivement. En revanche, aller voir le contenu d'un "void **" c'est tout à fait possible et ne pose aucun soucis. Ce qui est au bout d'un "void **", c'est un "void *" et ça c'est quelque chose de tout à fait connu puisque c'est une adresse !!! Et les adresses, tout le monde sait les manipuler...
13/12/2014, 14h55
gerald3d

Citation:

Envoyé par sbill

Oui, mais pourquoi ? Quoi qu'il en soit à la fin le pointeur générique ne sait pas vers quel type de variable son contenu pointe, d'ou l'impossibilité de déréférencer le pointeur. En quoi passer par un double pointeur résout le problème ?

Le fait de parler de "double pointeur" me fait penser que la notion d'adressage n'est pas encore tout à fait claire pour toi.
13/12/2014, 15h11
Obsidian

Bonjour,

Citation:

Envoyé par sbill

Oui, mais pourquoi ? Quoi qu'il en soit à la fin le pointeur générique ne sait pas vers quel type de variable son contenu pointe, d'ou l'impossibilité de déréférencer le pointeur. En quoi passer par un double pointeur résout le problème ?

Parce qu'un « double pointeur void » est en réalité « un pointeur vers un pointeur vers void ». Quand tu le déréférences une fois, tu tombes sur le pointeur suivant qui, lui, a toujours (en pratique) le même format, même s'il pointe quelque chose d'indéfini.

Par ailleurs, les pointeurs « void * » passés à ta fonction sont transmis depuis une autre fonction qui lui passe probablement l'adresse d'objets existants, donc même si c'est incorrect, tu éviteras probablement la segfault et ne t'apercevra pas de l'erreur sans avoir le nez dessus. Ta fonction a donc l'impression de permuter des pointeurs, ce qui lui suffit même si ce n'est pas le cas en réalité. S'il se trouve que les données pointées ont le même format que les pointeurs de ta machine cible, ce sera complètement transparent et le bug risque de rester latent un bon bout de temps. Si en revanche, elles ont des longueurs différentes, spécialement si elles sont plus courtes, alors la permutation va entraîner avec elle un morceau des variables à côté, voire un fragment du cadre de pile, et tu risques d'être confronté à un comportement très étrange qui sera difficile à localiser : le plantage risque de se produire a posteriori, dans une partie du code qui n'a rien à voir avec celle réellement incriminée.

Citation:

Envoyé par Obsidian

Ta fonction a donc l'impression de permuter des pointeurs, ce qui lui suffit même si ce n'est pas le cas en réalité.

Moi aussi j'ai pensé que ça permutait les adresses des variables. Un simple affichage des adresses avant et après m'a montré que ce n'était pas le cas

Citation:

Envoyé par Obsidian

S'il se trouve que les données pointées ont le même format que les pointeurs de ta machine cible, ce sera complètement transparent et le bug risque de rester latent un bon bout de temps. Si en revanche, elles ont des longueurs différentes, spécialement si elles sont plus courtes, alors la permutation va entraîner avec elle un morceau des variables à côté, voire un fragment du cadre de pile, et tu risques d'être confronté à un comportement très étrange qui sera difficile à localiser

Dans mes premiers tests, à base de int, ça fonctionnait. Mais quand j'ai voulu permuter des trucs divers et variés et un peu plus complexe c'est complètement parti en torche...
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 38 39 40 41 42 43 44 45 46 47 48 49 50 51 #include <stdio.h> void swap(void * d1 , void * d2) { void * tmp; tmp = *(void **)d1; *(void **)d1 = *(void **)d2; *(void **)d2 = tmp; } void essai1() { int x=5; int y=0; printf("x=%d, y=%d, &x=%p, &y=%p\n", x, y, &x, &y); swap(&x, &y); printf("x=%d, y=%d, &x=%p, &y=%p\n", x, y, &x, &y); } void essai2() { char x='a'; char y='z'; printf("x=%c, y=%c, &x=%p, &y=%p\n", x, y, &x, &y); swap(&x, &y); printf("x=%c, y=%c, &x=%p, &y=%p\n", x, y, &x, &y); } void essai3() { typedef struct { char *txt; int i; double d; } t_xxx; t_xxx x={"toto", 5, 3.1416}; t_xxx y={"titi", 7, 2.71828}; printf("x=%s,%d,%f, y=%s,%d,%f, &x=%p, &y=%p\n", x.txt, x.i, x.d, y.txt, y.i, y.d, &x, &y); swap(&x, &y); printf("x=%s,%d,%f, y=%s,%d,%f, &x=%p, &y=%p\n", x.txt, x.i, x.d, y.txt, y.i, y.d, &x, &y); } int main() { essai1(); essai2(); essai3(); }
Résultat
Code:

1 2 3 4 5 6 7 8 9 10 11 $ make essai cc essai.c -o essai $ ./essai x=5, y=0, &x=0x7fff61b929ac, &y=0x7fff61b929a8 x=1639524800, y=5, &x=0x7fff61b929ac, &y=0x7fff61b929a8 x=a, y=z, &x=0x7fff61b929af, &y=0x7fff61b929ae x=, y=a, &x=0x7fff61b929af, &y=0x7fff61b929ae x=toto,5,3.141600, y=titi,7,2.718280, &x=0x7fff61b92990, &y=0x7fff61b92970 x=titi,5,3.141600, y=toto,7,2.718280, &x=0x7fff61b92990, &y=0x7fff61b92970

13/12/2014, 17h28
Obsidian

Hello,

Citation:

Envoyé par Sve@r

Moi aussi j'ai pensé que ça permutait les adresses des variables. Un simple affichage des adresses avant et après m'a montré que ce n'était pas le cas

Pas les adresses des variables de la fonction appelante, qui sont de toutes façons définies à la compilation et ne peuvent donc pas varier au cours du programme. Mais les adresses de ces variables sont passés en tant que pointeur à la fonction swap qui, elle, par le bias des casts, finit par penser que ce sont des pointeurs « void * » qui se trouvent à ces emplacement, ce qui n'est pas forcément le cas.

Citation:

Dans mes premiers tests, à base de int, ça fonctionnait. Mais quand j'ai voulu permuter des trucs divers et variés et un peu plus complexe c'est complètement parti en torche...

Tout-à-fait. J'imagine que tu compiles sur une plateforme 64 bits, sur laquelle les pointeurs occupent 8 octets au lieu de quatre, ce qui pourrit l'essai 1. Chose encore plus flagrante avec l'essai 2 où ce sont deux caractères consécutifs que l'on manipule. Même avec du padding, il est probable que celui aligne les données sur des adresses multiples de 4 plutôt que 8.

Par contre, dans le troisième essai, tu déplaces des structures (plus longues que 4 ou 8 en principe) mais qui commencent par un pointeur sur une chaîne ! Ces pointeurs ont exactement la même longueur qu'un « void * » et se retrouvent proprement intervertis. Tes structures voient donc leurs chaînes permutées alors que le reste des données a conservé sa place.
13/12/2014, 18h51
sbill

C'est compris ! merci :)

D'un autre côté, j'imagine bien un truc à base de macro pour faire un tel swap (mais ça aurait l'inconvénient d'évaluer chaque argument deux fois):

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#define swap(x, y) realswap((x), (y), sizeof (x), sizeof (y))
 
void realswap(void* x, void* y, size_t sizeX, size_t sizeY)
{
	if(sizeX != sizeY)
	{
		fprintf(stderr, "realswap: Size mismatch (%llu, %llu)\n", (unsigned long long)sizeX, (unsigned long long)sizeY);
		abort();
	}
	else
	{
		size_t i;
		char * xc = x;
		char * yc = y;
		for(i=0 ; i<sizeX ; i++)
		{
			char temp = xc[i];
			xc[i] = yc[i];
			yc[i] = temp;
		}
	}
}

16/12/2014, 08h44
Sve@r

Citation:

Envoyé par Médinoc

D'un autre côté, j'imagine bien un truc à base de macro pour faire un tel swap (mais ça aurait l'inconvénient d'évaluer chaque argument deux fois):

Code:

#define swap(x, y) realswap((x), (y), sizeof (x), sizeof (y))

Ca fonctionne (je viens de le tester sur mon code précédent) mais avec une petite correction: #define swap(x, y) realswap((x), (y), sizeof *(x), sizeof *(y)). En effet, on passe les adresses des choses à swapper...

Accessoirement ne vaut-il pas mieux sortir la déclaration de temp de la boucle ?
16/12/2014, 10h21
Médinoc

Citation:

Envoyé par Sve@r

Accessoirement ne vaut-il pas mieux sortir la déclaration de temp de la boucle ?

Franchement j'ignore si ça change grand-chose: seul un compilo vraiment primitif décalerait deux fois le pointeur de pile à chaque itération...

Et puis, si on est à ce point-là dans la micro-optimisation, autant en profiter pour remplacer les indexages par des incrémentations de pointeur. Au détriment de la lisibilité, bien entendu.