Etat initial déclaration

Bonjour,

Je n'arrive pas à trouver de réponse à cette question toute simple :

Je déclare une structure simple :

Code:

---

1 2 3 4 5

struct maStruct{ uint32 size; void *array; };

---

Si je cré un tableau de maStruct :

Code:

---

1 2	maStruct tab[10];

---

Comment sont les éléments de la structure à l'etat initial ? Est-ce que cela peut prendre n'importe quelle valeur ou est-ce que cela met d'office les "size" à 0 et les *array à NULL ?

MErci :/

Quand on met du code, c'est le bouton # (balises [code][/code] et pas [quote][/quote])

Ceci dit, si tu crées un tableau de structures, comme tu l'as fais, elles ne sont pas initialisées, elles contiennent donc des valeurs aléatoires.

Comme on est en C++, c'est le rôle des constructeurs que d'initialiser la structure.

MErci beaucoup pour la réponse.
Désolé pour les quote :)

Re...

Est-ce que c'est different dans le cas d'un membre static de classe ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

struct DynamicArrayCache{ uint32 size; void *array; };   class DynamicArray{ public: (...) static DynamicArrayCache cacheList[]; };   DynamicArrayCache DynamicArray::cacheList[5000];

---

En parcourant les 5000 éléments j'ai systematiquement 0 pour size et array. Est-ce que je peux y faire confience pour la suite de mon prog ?

Citation:

---

Envoyé par ram-0000

Quand on met du code, c'est le bouton # (balises [code][/code] et pas )

Ceci dit, si tu crées un tableau de structures, comme tu l'as fais, elles ne sont pas initialisées, elles contiennent donc des valeurs aléatoires.

Comme on est en C++, c'est le rôle des constructeurs que d'initialiser la structure.

---

Non.
Ici, il n'y aucun constructeur explicite, donc le compilateur va en définir un et initialiser toutes les variables membres à des valeurs par défaut (0 en général).

Bonsoir,


Ha ok, donc si je decrare un constructeur à ma structure (en gros une classe quoi) mais que j'initialise pas, alors les membres peuvent avoir n'importe quelle valeur ?

Est-ce que l'initialisation automatique dans le cas d'une structure n'a pas tendence à consomer d'avantage de ressources que si s'etait une classe avec un constructeur déclaré mais qui n'initialise rien ?

Citation:

---

Envoyé par Davidbrcz

Non.
Ici, il n'y aucun constructeur explicite, donc le compilateur va en définir un et initialiser toutes les variables membres à des valeurs par défaut (0 en général).

---

Es tu sûr ? Je viens de créer un exemple et j'ai bien un tableau de valeurs non initialisées (qui semble aléatoire)

Code:

---

1 2 3 4 5 6 7 8 9 10 11

struct maStruct{ int size; char t_array; unsigned char t_array2; }; int _tmain(int argc, _TCHAR* argv[]) { maStruct m_tbl[10]; printf("%d %d %d\n", m_tbl[0].size, m_tbl[0].t_array, m_tbl[0].t_array2); return 0; }

---

Le résultat :

Citation:

---

-858993460 -52 204

---

Curieux ça...

J'ai fais le test avec 5000 lignes dans mon exemple precedent avec un tableau static et tout est à 0....

ram-0000, est tu sûr d'avoir compiler en C++ ? Car je vois un beau printf et rien de ++ only.

Ca dépend de l'implémentation. Donc a compilo différent résultats différents, a options différentes résultats différents. J'ai pas la norme sous la main pour vérifier mais il me semble que c'est ce qui a était dit récemment..

Je sais que je vais rester en C++, mais selon si c'est compilé pour du 64bit ou 32, linux ou win32, si j'ai un resultat different cela veut dire que je vais devoir initialiser moi même..

Domage pour l'optimisation :s

ram-0000 >> comme l'a dit hiura, compile en C++ et pour tu auras un constructeur de généré par le compilateur.

Citation:

---

Envoyé par Goten

Ca dépend de l'implémentation. Donc a compilo différent résultats différents, a options différentes résultats différents. J'ai pas la norme sous la main pour vérifier mais il me semble que c'est ce qui a était dit récemment..

---

La flemme de fouiller la norme ce soir mais je suis sûr :aie: .
Edit: le remord me tuait, donc j'ai ca en 12.1:7§

Citation:

---

An implicitly-declared default constructor for a class is implicitly defined when it is used to create an object of its class type (1.8). The implicitly-defined default constructor performs the set of initializations of the class that would be performed by a user-written default constructor for that class with an empty mem-initializer-list (12.6.2) and an empty function body.

---

seal3 >> pas de raison d'avoir des résultats différents. Le compilateur génère dans tous les cas un constructeur s'il n'y en a pas. Après dès qu'il y en a un, le compilateur n'interfère plus dans ton code et considere que tu mets toutes les variables dans un état correct( comprendre que les variables non expliciements initialisé dans le constructeur sont dans un état aléatoire)

8.5 - Initializers :

Citation:

---

4 To zero-initialize an object of type T means:
— if T is a scalar type (3.9), the object is set to the value 0 (zero), taken as an integral constant expression, converted
to T;94)
— if T is a non-union class type, each non-static data member and each base-class subobject is zero-initialized;
— if T is a union type, the object’s first named data member95) is zero-initialized;
— if T is an array type, each element is zero-initialized;
— if T is a reference type, no initialization is performed.
5 To default-initialize an object of type T means:
— if T is a non-POD class type (clause 9), the default constructor for T is called (and the initialization is ill-formed
if T has no accessible default constructor);
— if T is an array type, each element is default-initialized;
— otherwise, the object is zero-initialized.

---

Hum j'en déduis que tout doit être initiliasé à zéro. puisque : "and the initialization is ill-formed if T has no accessible default constructor" ne s'applique étant donné que le compilo en génére automatiquement un ?

Petite précision ça vient d'un draft, de 2005 pas la norme :).

Par contre je confirme que :

Code:

---

1 2 3 4 5

DynamicArrayCache cacheList[5000]; for(unsigned int i=0;i<5000;i++){ printf("%i %i %i\n",i,cacheList[i].size,cacheList[i].array); }

---

avec une structure :

Code:

---

1 2 3 4 5

struct DynamicArrayCache{ uint32 size; void *array; };

---

Je compile bien en C++ puisque j'ai des classes avec constructeur qui se compilent bien.

Miis j'ai bien vers la fin des valeurs non initialisées...


Par contre ça ne me le fait pas si je declare mon tableau comme etant static depuis une classe :/

Citation:

---

Envoyé par hiura

ram-0000, est tu sûr d'avoir compiler en C++ ? Car je vois un beau printf et rien de ++ only.

---

J'ai repris l'exemple fourni au départ (je reconnais, le printf ne fait pas très c++) mais le source est un fichier cpp compilé sous Visual Studio 2005 (Windows XP SP3)

Cet exemple me fait dire que pour une struct, le constructeur pas défaut (s'il y en a un qui est généré par le compilateur) ne fait rien sur les données membres

Citation:

---

Envoyé par seal3

Curieux ça...

J'ai fais le test avec 5000 lignes dans mon exemple precedent avec un tableau static et tout est à 0....

---

Le cas du static est différent, ton tableau est placé dans un segment mémoire particulier qui lui est initialisé à 0 par le loader du programme. Ce n'est pas tout à fait pareil que pour des variables locales sur la pile

Ha oki :)

Merci pour l'explication. Je vais rester la dessus.

Mea culpa :oops:, mon monde s'écroule :calim2: .

Le compilateur générè bien un constructeur mais totalement vide (aucune liste d'initialisation et de corps vide (cf ma première citation)).

De ce fait, aucune variable n'est initialisée.

Encore mea culpa pour les betises que j'ai dites et la sureté avec laquelle je les ai dites.

Citation:

---

Envoyé par Davidbrcz

Mea culpa :oops:, mon monde s'écroule :calim2: .

Le compilateur générè bien un constructeur mais totalement vide (aucune liste d'initialisation et de corps vide (cf ma première citation)).

De ce fait, aucune variable n'est initialisée.

Encore mea culpa pour les betises que j'ai dites et la sureté avec laquelle je les ai dites.

---

Oui mais non puisque :

Citation:

---

5 To default-initialize an object of type T means:
— if T is a non-POD class type (clause 9), the default constructor for T is called (and the initialization is ill-formed
if T has no accessible default constructor);
— if T is an array type, each element is default-initialized;
— otherwise, the object is zero-initialized.

---

Donc les variables sont bien zero initialized dans le cas d'une structure sans constructeur et donc on applique ça :

Citation:

---

4 To zero-initialize an object of type T means:
— if T is a scalar type (3.9), the object is set to the value 0 (zero), taken as an integral constant expression, converted
to T;94)

---

D'un autre côté, j'ai passé 3 heures à réviser du cisco, donc jsuis un peu éclaté et je peux mal interprété la norme.

Citation:

---

Envoyé par Goten

Donc les variables sont bien zero initialized dans le cas d'une structure sans constructeur et donc on applique ça :

---

C'est dingue, pourtant un simple test sur une structure n'initialise pas à zéro visiblement :/

Citation:

---

Mea culpa , mon monde s'écroule .
Encore mea culpa pour les betises que j'ai dites et la sureté avec laquelle je les ai dites.

---

Pô grave, c'est quand même tres gentil à toi de m'avoir répondu :P

J'ai un souvenir de Koenig, Moo ou Stroustrup qui disait que les variables étaient initialisé par défaut à 0. P-ê est-ce le compilo' qui n'est pas bon ?

En tout cas ce n'est pas le cas avec MinGW. :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

struct maStruct{ int size; char t_array; unsigned char t_array2; }; void testStructInit(void) { int tot(0); for (int k(0); k < 1000; ++k) { maStruct m_tbl[1000]; for (int i(0); i < 1000; ++i) { if ( m_tbl[i].size != 0 || m_tbl[1].t_array != 0 || m_tbl[i].t_array2 != 0) { // std::cout << "i : " << i << "\n"; ++tot; } }   //std::cout << "tot : " << tot << std::endl; } std::cout << tot/1000.f/1000.f*100.f << "% non 0 initialised." << std::endl; }

---

Avec à peu près 60%. Toujours la même proportion ( sans redémarrage ) .

Citation:

---

Envoyé par Goten

Citation:

---

5 To default-initialize an object of type T means:
— if T is a non-POD class type (clause 9), the default constructor for T is called (and the initialization is ill-formed
if T has no accessible default constructor);
— if T is an array type, each element is default-initialized;
— otherwise, the object is zero-initialized.

---

Donc les variables sont bien zero initialized dans le cas d'une structure sans constructeur et donc on applique ça :

---

Si je comprends bien ce passage, il explique comment est réalisée l'initialisation par défaut, pas quand.
En particulier rien ne dit qu'un objet non static et sans initialiseur doit subir la "default-initialize".

Par contre ceci :

Citation:

---

9 If no initializer is specified for an object, and the object is of (possibly cv-qualified) non-POD class type (or array thereof), the object shall be default-initialized; if the object is of const-qualified type, the underlying
class type shall have a user-declared default constructor. Otherwise, if no initializer is specified for a non-static object, the object and its subobjects, if any, have an indeterminate initial value; if the object or any
of its subobjects are of const-qualified type, the program is ill-formed.

---

dit bien que dans le cas de figure évoqué il n'y a pas d'initialisation par défaut de faite.

Ben alors !?

Vous n'avez jamais perdu deux jours à debugger un programme qui crash mystérieusement parce qu'un put%!*$ de programmeur à oublier de coder un constructeur par défaut à sa structure S{truc* p;}, qui initialiserait le pointeur membre p à NULL, ce qui fait que le test "if(p)" renvoie true, donc le programme s'engage dans la mauvaise branche un peu trop tôt, appelle tout un tas d'autres fonctions et tout se termine lamentablement en race condition deux threads plus loin !? :aie:

Il faut toujours initialiser les variables d'une structure, classe, tableau ou quoi que soit en C++ ! Ça doit être un réflex pavlovien :

Ce code :

Code:

---

1 2 3 4 5

struct S { int i; unsigned char* c; };

---

est MAL


Ce code :

Code:

---

1 2 3 4 5 6

struct S { S():i(0),c(NULL){} int i; unsigned char* c; };

---

est BIEN

Bon d'accord, il existe une exception concernant les variables statiques, mais les règles sont trop subtiles et compliquées à retenir à mon gout, je préfère me souvenir de : une déclaration = une initialisation :mrgreen:

@gl : en effet j'ai pris default-initializer au premier sens, ie j'avais compris que c'était le comportement par défaut quand rien n'est précisé, mais non.
Avec

Citation:

---

Otherwise, if no initializer is specified for a non-static object, the object and its subobjects, if any, have an indeterminate initial value;

---

Tout est plus clair et surtout plus sensé. Car en effet je repensais au bête exemple (cité par arzar) qui fait bugué un calcul pour une variable non initialisé.

Bon la conclusion que j'en tirerais : cisco est brain-damage :)

edit : tu pourrais préciser le paragraphe cité gl?

Oui je suis bien dans ce cas la ou je test un pointeur comme etant NULL :/

Par contre dans mon cas, le programme va tourner sur plusieurs serveurs à 16 coeurs l'un... Dans ce cas la, la moindre optimisation prend tout son sens et fait economiser pas mal d'euros.

Alors d'un côté il ya le risque de crash dur à debugger mais de l'autre si je peux eviter d'initialiser des millions d'objets par secondes qui sont deja initialisés à la base, je pense que ca serait pas un mal :s

Citation:

---

Envoyé par seal3

Alors d'un côté il ya le risque de crash dur à debugger mais de l'autre si je peux eviter d'initialiser des millions d'objets par secondes qui sont deja initialisés à la base, je pense que ca serait pas un mal :s

---

J'aurais tendance à dire que le compilo se charge de ce genre d'optimisation ( -> avec la liste d'initialisation tu ne perds pas de temps ) . Est-ce que la norme précise qqch la dessus ?

Sur? Ce qu'est sur c'est qu'il faut pas laissez tes variables dans un état inconnue 'juste' pour des considérations de performances.

Citation:

---

Sur? Ce qu'est sur c'est qu'il faut pas laissez tes variables dans un état inconnue 'juste' pour des considérations de performances.

---

Du moins, pas avant d'avoir mesuré et établi clairement que c'était ça qui te faisait perdre du temps.

Et tu as même des variantes amusantes !!!

Sous Visual, en Release, une variable locale est initialisée à zéro. En Debug, elle est remplie par des octets 0xCC : mauvaise pioche si on présuppose qu'elles sont "nulles" par défaut...

On a alors un programme qui crashe en Debug et qui fonctionne en Release, toujours un vrai bonheur à débugger, ça. :calim2:

Citation:

---

Envoyé par Goten

edit : tu pourrais préciser le paragraphe cité gl?

---

Dans la version du document que j'ai, c'est le point 9 du paragraphe d'où tu as tiré ton extrait.

Citation:

---

Envoyé par Mac LAK

Sous Visual, en Release, une variable locale est initialisée à zéro. En Debug, elle est remplie par des octets 0xCC : mauvaise pioche si on présuppose qu'elles sont "nulles" par défaut...

---

L'initialisation en mode debug des variables non initialisée à une valeur spécifique et non nulle est une fonctionnalité que j'ai toujours apprécié dans Visual.
En effet :

• Puisque c'est en debug, la perte de temps éventuellement induite n'a aucune importance.
• Cela permet très vite de détecter des erreurs sur des variables non initialisées (particulièrement agréable lors de la reprise d'un code existant).
• C'est une aide assez sympa pour débuger les débordements de buffer.

Citation:

---

Envoyé par Mac LAK

Sous Visual, en Release, une variable locale est initialisée à zéro.

---

C'est sûr ce truc ?
J'émet un doute. Pour l'avoir souvent vécu, en release, une variable locale est non initialisée (je ne parle pas des classes, je parle des variables genre int et autres)

Ça dépend des options de compilation (donc, des options du projet).

Dans tous les cas, ça me semble très mal de faire du code qui se base là-dessus. Soit l'initialisation fait partie de l'algorithme (ie, l'algorithme a besoin que la variable soit initialisée à 0), auquel cas, il faut l'expliciter dans le code, soit elle n'en fait pas partie, et il n'y a pas besoin de la faire, et il faut mettre un petit commentaire précisant qu'on n'initialise pas *exprès* et que ce n'est pas un oubli.

Citation:

---

Envoyé par ram-0000

C'est sûr ce truc ?
J'émet un doute. Pour l'avoir souvent vécu, en release, une variable locale est non initialisée (je ne parle pas des classes, je parle des variables genre int et autres)

---

Cela ne concerne QUE les variables locales (et les globales, mais ce n'est pas le même mécanisme). Cela ne touche pas les variables allouées, ce qui met le plus souvent les objets dans le lot.

Je crois qu'en optimisation maximale, cette fonction saute, je t'avoue que je n'ai jamais poussé très loin cette recherche. En tout cas, c'est certain que c'est le cas avec un mode Release "gentil", c'est à dire pas trop optimisé, et il me semble bien que le réglage par défaut Release implique un vidage à zéro des locales. Ça n'existe par contre jamais ni en Debug, ni en Release optimisé à mort.

Dans tous les cas, je pense qu'on est tous d'accord : se baser sur une initialisation "automatique", qu'elle soit au chargement de l'EXE (globales) ou induite par le compilateur (locales, dynamiques), c'est franchement super crade et c'est une source de bugs parfois pénible à retrouver.

Persiste et signe :

Avec Visual Studio 2005

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#ifndef _WIN32_WINNT #define _WIN32_WINNT 0x0501 #endif   #include <stdio.h> #include <tchar.h>     int _tmain(int argc, _TCHAR* argv[]) { int toto; printf("Toto=%d\n", toto); return 0; }

---

Warning à la compilation :

Citation:

---

console.cpp(15) : warning C4700: variable locale 'toto' non initialisée utilisée

---

Exécution de la version release (avec les options par défaut d'un projet console standard)

Citation:

---

release>Console.exe
Toto=2015115244

---

La variable toto n'est pas initialisée

Étrange, je suis pourtant sûr et certain de cette initialisation à zéro, j'ai eu la farce avec un projet justement qui crashait en Debug et fonctionnait en Release.
Et je ne crois pas aux coïncidences qui feraient qu'un programme tombe "par hasard" sur un zéro en mémoire non-initialisée à chaque exécution, quelle que soit la machine qui le lance...

Comme dit :

Citation:

---

Ça dépend des options de compilation (donc, des options du projet).

---

Indépendant de debug/release, donc, c'est bien une option à part.

Mais je crois vraiment que par défaut, sous visual, c'est zéro-initialisation en debug (ie, la configuration générée pour le mode debug inclut cette option) et pas d'initialisation en release (ce qui est à mon avis une erreur, mieux vaudrait ne jamais initialiser à zéro).

Citation:

---

Envoyé par Mac LAK

Étrange, je suis pourtant sûr et certain de cette initialisation à zéro, j'ai eu la farce avec un projet justement qui crashait en Debug et fonctionnait en Release.
Et je ne crois pas aux coïncidences qui feraient qu'un programme tombe "par hasard" sur un zéro en mémoire non-initialisée à chaque exécution, quelle que soit la machine qui le lance...

---

J'ai déjà vu un programme fonctionner comme ça. Deux appels à des fonctions différentes se suivaient; la première fonction initialisait correctement les variables locales pour la seconde. Ça fonctionnait plus en changeant d'architecture; un optimiseur jouant différemment avec les registres aurait aussi causé des problèmes.

Citation:

---

Envoyé par Jean-Marc.Bourguet

J'ai déjà vu un programme fonctionner comme ça. Deux appels à des fonctions différentes se suivaient; la première fonction initialisait correctement les variables locales pour la seconde. Ça fonctionnait plus en changeant d'architecture; un optimiseur jouant différemment avec les registres aurait aussi causé des problèmes.

---

OK, mais là, c'était sur des dizaines et dizaines de variables, toutes étaient à zéro quoi qu'il arrive... Problème similaire sur un programme annexe, là aussi : tout à zéro en Release, valeurs 0xCC en Debug => problème constant et récurrent.

Pour ça que je dis "étrange"...

Salut,

Le problème vient peut être aussi, tout bêtement, de la version du compilateur que vous utilisez...

En effet, vous êtes là à vous chamailler sur le comportement propre au compilateur (mais non standard) sans même avoir pensé à vérifier que vous étiez bien occupés à comparer ce qui est comparable, donc, par défaut, que vous utilisiez bel et bien la même version du compilateur ;)

C'est le plus embêtant quand on se base sur une expérience personnelle pour essayer de déduire le comportement du compilo: trois situations peuvent se présenter:

• Le compilateur suit scrupuleusement la norme, et, dans ce cas, l'exemple que vous donnez devrait être reproductible sur n'importe quel autre compilateur qui la respecte sur ce point particulier.
• Le compilateur ne suit pas scrupuleusement la norme, mais a gardé un comportement similaire au fil des différentes versions (et il ne faut quand même pas oublier que VC++ sort en moyenne tous les deux ans, et que la philosophie de microsoft vis à vis des normes a fortement évolué depuis 2005...)
• Le compilateur ne suis pas scrupuleusement la norme sur un point précis, et ses concepteurs ont décidé de modifier le comportement, soit pour faire en sorte que la version suivante suive la norme, soit, simplement, parce qu'ils ont considéré qu'une valeur particulière (dans le cas qui nous occupe ici) était sommes toutes plus "cohérente" qu'une autre.

D'ailleurs, je ne serais même pas surpris si, en lisant la liste des changements par rapport à la version précédente de VC++, vous trouviez justement un passage concernant l'initialisation par défaut des variables ;) (mais bon, qui prend régulièrement la peine d'étudier un tout petit peu attentivement les changements apporté :question::aie:)