Discussion :

[stoner]

Bonjour à tous,

suite à quelques observations je suis quelque peu dérouté...

Voici le test effectué:

Code :

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

1
2
3
4
5
6
char tab[8][8];
tab[3][7]='A';
tab[4][0]='B';
printf("tab[3][7] = %c \nSon adresse = %p\n", tab[3][7], &tab[3][7]); // Adresse en %p = ffbffa87 | en %d = -4195705
 
printf("tab[4][0] = %c \nSon adresse = %p\n", tab[4][0], &tab[4][0]); // Adresse = en %p = ffbffa88 | en %d = -4195704

Si l'on regarde les adresses de plus près:
le résultat en héxa indique 4 bits de différence entre les 2 adresses alors qu'il y a un char à chacune des adresses (qui s'affichent correctement).

Plus étonnant encore, l'adresse renvoyée en %d indique un seul bit de différence.

Est-ce possible ?

Merci de m'avoir lu.

[kwariz]

Bonjour,

Une précision sur le vocabulaire, il ne s'agit pas de bit mais de byte (=octet).
Quand tu déclares un tableau comme char tab[8][8] il y aura 8 fois 8 = 64 char de réservés et ces char seront contigus. Donc oui c'est normal que tab[3][7] soit juste 'avant' tab[4][0].
C'est comme si tu avais un char tab[8*8] et que tab[ligne][colonne] te renvoie la valeur tab[ligne*8+colonne].

[Metalman]

Et il me semble : une adresse contient un mot... donc pas nécessairement 1 octet...
Après, je n'ai jamais vraiment testé ni regardé en pratique comment le C alloue des char[][]

EDIT : oui bah pour le coup c'est logique...
32bits = 4o
64bits = 8o

Donc entre [x][7] et [x + 1][0], on arrive au "bout" de ce que contient l'adresse... donc +1 dessus....

[Kirilenko]

Bonsoir,

le résultat en héxa indique 4 bits de différence entre les 2 adresses alors qu'il y a un char à chacune des adresses (qui s'affichent correctement).

Où est-ce que tu vois 4 bits de différence ? 0xffbffa88 - 0xffbffa87 = 0x1, hein ? Le compilateur ne peut pas ajouter de bits de padding entre les éléments d'un tableau, donc les adresses sont, en toute logique, contiguës.

Plus étonnant encore, l'adresse renvoyée en %d indique un seul bit de différence.

De toute manière, tu n'as aucune garantie que ton pointeur aura une représentation identique à celle d'un entier (ce n'est d'ailleurs pas le cas sur un grand nombre d'architectures). En théorie, tu ne devrais donc pas te reposer sur ces résultats... Bien qu'ils soient paradoxalement « logiques », ici. Par ailleurs, on notera que, pour être parfaitement standard, il faudrait transtyper l'argument du format %pen void *, car printf est une fonction à nombre variable d'arguments.

Bonne soirée !

[Sve@r]

Salut

Code c :

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

1
2
printf("tab[3][7] = %c \nSon adresse = %p\n", tab[3][7], &tab[3][7]); // Adresse en %p = ffbffa87 | en %d = -4195705
printf("tab[4][0] = %c \nSon adresse = %p\n", tab[4][0], &tab[4][0]); // Adresse = en %p = ffbffa88 | en %d = -4195704

Moi j'aime bien ceux qui mettent des valeurs négatives pour des adresses. Tu habites où ? Moi j'habite au -128 de la rue Truc !!!

Code c :

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

1
2
printf("tab[3][7] = %c \nSon adresse = %p\n", tab[3][7], &tab[3][7]); // Adresse en %p = ffbffa87 | en %u = 4 290 771 591
printf("tab[4][0] = %c \nSon adresse = %p\n", tab[4][0], &tab[4][0]); // Adresse = en %p = ffbffa88 | en %u = 4 290 771 592

Sinon pour le reste tout le monde t'a déjà répondu. Les deux adresses de tes deux cases contiguës sont exactement à une unité l'une de l'autre ce qui est demandé par la norme...

[stoner]

D'accord merci à vous je le retiendrai!

Je ne sais vraiment pas comment j'ai fait mon compte...

Soit, c'est résolu merci bien.