Discussion :

[nonozor]

Bonjour,

J'ai un code qui ressemble à

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
{
  int NbChaussettes = ...
  blablabla
}
{
  int NbPantalons = ...
  blablabla
}
{
  int NbChemises = ...
  blablabla
}
{
  int NbChaussures = ...
  blablabla
}

Il n'a donc jamais plus d'un int déclaré, visible et utilisable en même temps.

Est ce que quelqu'un saurait si la place utilisée dans la mémoire du programme pour ces variables est de 4 int ou de 1 int?
Merci pour vos réponses!

[Mac LAK]

Est ce que quelqu'un saurait si la place utilisée dans la mémoire du programme pour ces variables est de 4 int ou de 1 int?

Cela peut dépendre du compilateur...

Pour vérifier, dans chaque bloc { }, affiche sur la console l'adresse de la variable. Si les quatre entiers ont la même, c'est que ton compilateur n'alloue qu'un seul entier sur la pile. S'ils sont différents, c'est qu'il alloue séparément chaque variable, même si elles sont dans des portées disjointes.

[3DArchi]

Salut,
Le langage te garantie que le constructeur est appelé à la définition de la variable et le destructeur est appelé lorsque celle-ci sort de son scope.
En revanche, la gestion de la pile dépend du compilateur et de la taille de la variable :

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
25
26
27
28
29
30
#include <iostream>
 
template<int N>
void Dump()
{
   {
     int NbChaussettes[N];
     std::cout<<NbChaussettes<<std::endl;
   }
   {
     int NbPantalons[N];
     std::cout<<NbPantalons<<std::endl;
   }
   {
     int NbChemises[N];
     std::cout<<NbChemises<<std::endl;
   }
   {
     int NbChaussures[N];
     std::cout<<NbChaussures<<std::endl;
   }
}
int main()
{
   std::cout<<"1 : "<<std::endl;
   Dump<1>();
   std::cout<<"1024 : "<<std::endl;
   Dump<1024>();
   return 0;
}

Produit avec Visual C++ :

1 :
0012FF5C
0012FF58
0012FF54
0012FF50
1024 :
0012EF60
0012DF60
0012CF60
0012BF60

-> On voit qu'on a une zone différente sur la pile à chaque fois.
Et avec MinGW :

1 :
0x22ff54
0x22ff50
0x22ff4c
0x22ff48
1024 :
0x22ef58
0x22ef58
0x22ef58
0x22ef58

-> On voit qu'on a une zone différente sur la pile pour 1 et la même pour 1024.

[Mac LAK]

@3DArchi : tu as fait le test en Debug, en Release, les deux ? Juste pour savoir... Parce que ça ne m'étonnerait pas que Visual ne "compacte" les grosses variables qu'en mode Release, à cause notamment des valeurs de remplissages en mode Debug...

[3DArchi]

@3DArchi : tu as fait le test en Debug, en Release, les deux ? Juste pour savoir... Parce que ça ne m'étonnerait pas que Visual ne "compacte" les grosses variables qu'en mode Release, à cause notamment des valeurs de remplissages en mode Debug...

Le test est en debug. Effectivement, il y a peut être un compactage en Release. L'idée est surtout de montrer qu'il s'agit d'un choix d'implémentation et qu'il vaut mieux ne pas spéculer sur la façon dont la pile est gérée.

[Mac LAK]

Le test est en debug. Effectivement, il y a peut être un compactage en Release.

OK, merci.

L'idée est surtout de montrer qu'il s'agit d'un choix d'implémentation et qu'il vaut mieux ne pas spéculer sur la façon dont la pile est gérée.

Ah ça, on est bien d'accord !!!
La seule chose garantie avec les variables locales, c'est ... qu'elles sont sur la pile. Mais la façon dont c'est implémenté ne devrait jamais être une hypothèse de travail.

[gl]

La seule chose garantie avec les variables locales, c'est ... qu'elles sont sur la pile.

Même pas, il n'y a pas de notion de pile dans la norme. La seule chose dont on est certain c'est de la portée des variables locales.

[HS]
J'ai travaillé sur des systèmes où les variables locales étaient mise dans la même page de working data que les variables globales, le compilateur et le linker se débrouillaient pour les organiser correctement et pour recycler les zones mémoires des variables locales (pas assez de place dans la pile).

De même, à fin d'optimisation, certaines variables locales ne peuvent n'être présente que dans les registres du processeurs.
[/HS]