Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1250 connectés 

  FORUM HardWare.fr
  Programmation
  C++

  [C++] Variables globales non initialisées ?

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[C++] Variables globales non initialisées ?

n°1728679
freewol
Ceci n'est pas une citation
Posté le 05-05-2008 à 16:46:02  profilanswer
 

Bonjour,
 
d'après quelques pages lues sur le web, il semblerait que les variables globales en C/C++ se décomposent en deux catégories :

  • les variables non initialisées, ou les variables initialisées à 0, qui seront stockées dans la partie .bss du programme, et seront initialisées à 0 avant l'appel du main()
  • les variables initialisées à une valeur différente de 0, qui seront stockées accompagnées de leur valeur d'origine dans la partie .data du programme.


D'abord j'aimerais savoir si ce comportement est le même pour tous les compilateurs C/C++ ?
Ensuite est-il possible d'avoir un comportement différent qui consisterait à mettre les variables initialisées (même à 0) dans .data, et les autres dans .bss, permettant ainsi de zapper la partie qui met à 0 la partie .bss ?
En effet il me semble avoir lu que la norme C/C++ n'impose pas au compilateur d'initialiser à 0 les variables (globales ou non) qui ne le sont pas par le programmeur.
 
J'espère avoir été suffisamment clair. Ma question est plus sur la compréhension du langage / des compilateurs que pratique pour l'instant.
 
Merci d'avance :)

mood
Publicité
Posté le 05-05-2008 à 16:46:02  profilanswer
 

n°1728722
Taz
bisounours-codeur
Posté le 05-05-2008 à 17:33:27  profilanswer
 

pour les globales si c'est imposé.
L'emplacement .data ou .bss, c'est historique: le .bss map sur de la mémoire initialisée à 0 au chargement du programme, donc ça prend pas de place au niveau du binaire. Alors qu'en .data, tu as à la définition des données

 

[tmp]$ cat data.cpp
char global[1 << 20] = "";

 

[ltmp]$ g++ -c data.cpp && size data.o && ls -lh data.o
   text    data     bss     dec     hex filename
      0 1048576       0 1048576  100000 data.o
-rw-r--r--  1 luser group 1,1M mai  5 17:32 data.o


vs.

[tmp]$ cat data.cpp
char global[1 << 20];

 

[tmp]$ g++ -c data.cpp && size data.o && ls -lh data.o
   text    data     bss     dec     hex filename
      0       0 1048576 1048576  100000 data.o
-rw-r--r--  1 luser group 969 mai  5 17:32 data.o


Message édité par Taz le 05-05-2008 à 17:34:18
n°1728726
freewol
Ceci n'est pas une citation
Posté le 05-05-2008 à 17:39:57  profilanswer
 

Ok merci :)
Je suppose donc que la partie qui met à 0 la section .bss est considérée comme à la fois suffisamment petite en taille de code, et en temps d'exécution au démarrage du programme.

n°1728852
Taz
bisounours-codeur
Posté le 06-05-2008 à 00:08:30  profilanswer
 

ça ne fait pas de vrai différence au niveau du temps de démarrage bss et data. ça a été fait pour la taille du binaire c'est tout. Il n'y a pas vraiment à y réfléchir. Pas la peine d'initialiser quelque chose à 0 si c'est déjà le cas implicitement.

n°1730446
jesus_chri​st
votre nouveau dieu
Posté le 10-05-2008 à 10:31:08  profilanswer
 

juste pour savoir, si tu refais la même chose avec un gcc -O3, tu obtient les mêmes résultats ? Parce que ton tableau de caractères initialisé à "", il a toutes les chances de ne contenir que des zeros.
 
Ca m'emmerderais qu'écrire :
 
static int n = 0;
 
soit moins optimisé que :
 
static int n;
 
même si ça revient au même, car le 1er est plus lisible, surtout pour ceux qui ne connaissent pas la règle des static initilisées à zero.

n°1730468
gilou
Modérateur
Modzilla
Posté le 10-05-2008 à 12:43:27  profilanswer
 

Tiens ca me rappelle une anecdote: Sur DEC Station, le compilo C (meme pas ++) initialisait certains types de variable pas initialisée au moment de la déclaration (a 0 pour les types numériques, NULL pour les pointeurs, ...) même si elles n'étaient pas déclarées statiques.
Ca évitait certains plantages certes, mais le jour ou le code était porté sur une station SUN, bonjour les dégats.
A+,


---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --  AngularJS c'est un framework d'engulé!  --
n°1730470
dap++
Script kiddie
Posté le 10-05-2008 à 12:58:25  profilanswer
 

Sous Windows le contenu de .bss est souvent ajouté à la fin de .data.


---------------
dap.developpez.com
n°1730546
jesus_chri​st
votre nouveau dieu
Posté le 10-05-2008 à 20:21:23  profilanswer
 

gilou : Windows noyau NT (donc NT4, 2000, Xp...) fait pareil, mais à l'exécution (il floode la pile et le heap avec des zeros avant qu'ils soient utilisés).
Alors au retour sous Win98, même problème.

n°1730579
cricri_
Posté le 11-05-2008 à 08:46:34  profilanswer
 

Avec VS c'est vrai en release mais pas en debug.

n°1730587
gilou
Modérateur
Modzilla
Posté le 11-05-2008 à 11:08:23  profilanswer
 

De toute façon, sous windows, j'ai longtemps utilisé les compilos Metaware, alors... :D
A+,


---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --  AngularJS c'est un framework d'engulé!  --
mood
Publicité
Posté le 11-05-2008 à 11:08:23  profilanswer
 

n°1730592
jesus_chri​st
votre nouveau dieu
Posté le 11-05-2008 à 12:08:25  profilanswer
 

cricri_ a écrit :

Avec VS c'est vrai en release mais pas en debug.


oui (et encore heureux...), l'OS remplit avec des 0 et VS flood avec des 0xCC par dessus en debug.
En release il ne fait rien (et c'est normal), c'est l'OS noyau NT qui remplit avec des 0.


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C++

  [C++] Variables globales non initialisées ?

 

Sujets relatifs
Générer des mail sous borland C++Pile rapide en C++
créer un echiquier en C[PIC] Problème de mise en place I²C
[C] lire un fichier......mon dieu aidez moi !!Problème avec Visual C++
Extraire des variables à partir d'une chaine de caractèreBinding entre un schéma XSD et un ensemble de classes C++
Vector en C++ - Optimisation de la recherche[C/C++] Copie d'un std::vector
Plus de sujets relatifs à : [C++] Variables globales non initialisées ?


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR