Discussion :

[jomeo]

Bonjour, je suis en train de préparer un petit exercice sur les pointeurs, et en faisant des tests sous visual c++, je viens de me rendre compte que je ne comprends pas comment le compilateur répartit les variables dans la mémoire de l'ordinateur.

En effet, voici une partie de mon programme :

Code :

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

1
2
3
4
5
6
7
8
9
10
float a=0.001;
float b=0.003;
float c, *pa, *pb;
 
cout << "Adresses : " << endl;
cout << "&a = " << &a << endl;
cout << "&b = " << &b << endl;
cout << "&c = " << &c << endl;
cout << "&pa = " << &pa << endl;
cout << "&pb = " << &pb << endl;

Le résultat me surprend :

&a = 0012FF64
&b = 0012FF68
&c = 0012FF6C
&pa = 0012FF5C
&pb = 0012FF60

D'une part, je ne comprend pas pourquoi dans la mémoire pa et pb sont placés avant a, b et c, alors qu'ils ont été déclarés après si on suit les instructions du programme.

Par ailleurs, j'ai essayé d'échanger les déclarations de a et b, en mettant float b avant float a, et à ma grande surprise l'affichage est le même : l'adresse de b est celle de a + 4 octets...

L'adresse des variables est-il determiné en fonction de leurs noms ? Au sujet de l'échange a - b, suis victime d'une sorte de cache de Visual Studio (qui ne reconsidère pas la déclaration des variables d'une compilation à une autre... ?)

Enfin, est-ce le même fonctionnement en C ?

Merci de bien vouloir m'éclairer mes chers amis.

[Matthieu Brucher]

Le compilateur fait comme bon lui semble, et ceci en C comme en C++.

[Jean-Marc.Bourguet]

Bonjour, je suis en train de préparer un petit exercice sur les pointeurs, et en faisant des tests sous visual c++, je viens de me rendre compte que je ne comprends pas comment le compilateur répartit les variables dans la mémoire de l'ordinateur.

Il fait ce qu'il veut, tu n'as pas a t'en occuper. Il peut meme ne jamais mettre une variable en memoire s'il le juge bon (ce qu'il ne va pas faire si tu prends l'adresse).

[jomeo]

Mais dans ce cas, pourquoi ai-je subi tous ces exercices sur les pointeurs du type :

Code :

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

1
2
int a= 1, b= 2;
int *pa = &a, *pb = &b:

Sachant que &a = 1130

donnez :
&b, pa, pb, ...

Vous voulez dire que b, pa, pb ne seront pas forcément après a dans la mémoire ?

Merci de vos infos

[Jean-Marc.Bourguet]

Mais dans ce cas, pourquoi ai-je subi tous ces exercices sur les pointeurs du type :

Code :

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

1
2
int a= 1, b= 2;
int *pa = &a, *pb = &b:

Sachant que &a = 1130

donnez :
&b, pa, pb, ...

Vous voulez dire que b, pa, pb ne seront pas forcément après a dans la mémoire ?

Gagne. pa et pb peuvent meme n'exister que dans des registres si on n'en prend jamais l'adresse.

[loufoque]

Si tu veux que ce soit à la suite, utilise une structure.

[jomeo]

Merci de vos précisions.... Bon bah j'oublie les questions sur la position des variables dans la mémoire pour mes exercices :-)

[deeal]

pa et pb sont places avant , car le compilateur commencent toujours des adresses hautes ffffff et apres il fait une decrementation pour le stack

donc si je fais

int a;
int b; ces variables seront sur le stack de ton thread

et donc tu as A avant => A aura une plus grande adresse
disant 1000 , et apres vient b
qui aura une adresse 1000-4 = 996

depuis toujours les compilateur (c, et c++ a ma connaissance) travaillent sur le stack en decrementant

[Ulmo]

depuis toujours les compilateur (c, et c++ a ma connaissance) travaillent sur le stack en decrementant

C'est lié au processeur et pas au compilateur.

[Médinoc]

Et le compilateur est libre de choisir l'ordre dans lequel il met les variables locales.
Sans oublier les histoires d'alignement si on joue avec des variables de tailles différentes...

[deeal]

ah ok, donc ce que j'ai dit, c Visual C++, et Intel processeur
mais est-ce que ca depend vraiment du processeur?

[Médinoc]

Pour être franc, je ne connais pas de processeur avec une pile dont les adresses vont croissant.

[Jean-Marc.Bourguet]

Pour être franc, je ne connais pas de processeur avec une pile dont les adresses vont croissant.

J'en ai deja utilise un. Mais je ne sais plus lequel (MOS 6502? c'etait un 8bits ca je suis certain). Il doit y en avoir d'autres, je suis quasiment certain que le code de alloca de GNU traite le cas. Il y a pire, certains Cray utilisent comme pile une liste chainee. Certains processeurs n'ont pas reellement de notion de pile -- les piles hard sont presque une caracteristique introduite par les micro-processeurs. Avant les ordinateurs stockaient l'adresse de retour a une adresse fixe en memoire, genre adresse du saut moins 1 mot ou dans un registre (ce que font encore des RISC actuels).

[Ulmo]

ah ok, donc ce que j'ai dit, c Visual C++, et Intel processeur
mais est-ce que ca depend vraiment du processeur?

Beaucoup de processeurs ont une gestion de pile pour pouvoir utiliser des sous-programmes. Par exemple pour les x86 il y a les fonctions PUSH/POP et le registre ESP. Le sens de la pile est donc déjà imposé, mais c'est par ailleurs transparent pour le programmeur (sauf quand il réserve de la place/vide la pile sans utiliser de valeur en jouant avec ESP directement). Le compilateur va évidemment utiliser ces possibilités, et donc le sens de fonctionnement lui est imposé.

Je me demande si la pile du 6502 n'était pas "à l'endroit". J'ai juste trouvé le qualificatif "top down", je ne sais pas quel sens ça fait.