Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Valeur d'une variable locale non-initialisée

Valeur d'une variable locale non-initialisée

28 réponses
Avatar
Rémi Moyen
Bonjour,

En relisant un bout de code, je suis tomb=E9 sur une classe qui contient
un int comme membre, et bien que cette variable ne soit jamais
initialis=E9e explicitement, elle a toujours la valeur 0 et le code
marche correctement. Ce que je ne comprends pas vraiment, je croyais
que les variables locales n'=E9taient pas initialis=E9es =E0 0
automatiquement...

Si je regarde mon Stroustrup, il me dit (4.9.5) que seules les
variables globales ou statiques locales sont initialis=E9es =E0 0 par
d=E9faut, et qu'une variable non-initialis=E9e locale ou cr=E9=E9e sur le t=
as
a une valeur non-d=E9finie. Les variables membres d'une classe, dans
quelle cat=E9gorie tombent-elles ? J'aurais dit le deuxi=E8me cas, non ?

Bon, je teste avec un petit code tout simple :
#include <iostream>
using namespace std;

int v1; //global, non static var
static int v2; //global, static var

void f() {
int v3; //local, non static
static int v4; //local, static
cout << "f(): " << v3 << " " << v4 << endl;
}

class A {
public:
void f() {cout << "A::f(): " << v5_ << " " << v6_ << endl;}
private:
int v5_; // class, non static
static int v6_; // class, static
};
int A::v6_;

int main() {
cout << "main(): " << v1 << " " << v2 << endl;
f();
A a;
a.f();
return 0;
}

Je compile avec :
g++ -ovariable -O1 -Wuninitialized main.cpp
main.cpp: In function `void f()':
main.cpp:12: warning: 'v3' might be used uninitialized in this
function

Et j'execute :
main(): 0 0
f(): 0 0
A::f(): 0 0

Donc clairement, toutes les variables ont =E9t=E9 mises =E0 0. Pour v1 et
v2, c'est normal. v4 et v6_ aussi, elles sont statiques. Mais pour v3
et v5_ ? g++ m'informe bien pour v3, mais pourquoi ne m'informe-t-il
pas aussi pour v5_ ? Est-ce qu'elles sont =E0 0 par hasard (apr=E8s tout,
une valeur "non-d=E9finie" par le standard peut tr=E8s bien =EAtre 0) ? Est=
-
ce une particularit=E9 de g++ (v3.4.5, sur Linux RHEL 4.3) ? Est-ce
normal et j'ai mal compris le bouquin ?

Si quelqu'un pouvait m'expliquer, =E7a m'aiderait pas mal... Merci
d'avance !
--
R=E9mi Moyen
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Rémi Moyen
On 6 juil, 11:53, Fabien LE LEZ wrote:

>si quelqu'un
>arrive à mettre des accents dans un identifiant ?

Je crois avoir lu quelque part que la norme l'autorise. Mais je ne
sais pas s'il existe des implémentations de cette mauvaise idée.



J'avoue avoir essayé, avant de poster le message précédent. J'ai ét é
quelque peu soulagé de voir que g++ m'insultait sauvagement (en
m'accusant d'avoir laissé un "stray '195' in program"), parce que
franchement, oui, quel bazar ça serait, sinon...
--
Rémi Moyen
Avatar
Jean-Marc Bourguet
Rémi Moyen writes:

Merci ! Y'a juste une petite faute de frappe, la fonction devrait
s'appeler mainRemi(), pas mainRemy()



Oops, desole. (Je connais un Remy ce qui explique mais n'excuse pas).

(ou mainRémi(), si quelqu'un arrive à mettre des accents dans un
identifiant ?) ;-)



Ma comprehension, c'est que c'est conforme. Mais je ne me suis jamais
amuse a voir si c'etait supporte par un compilateur.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
Fabien LE LEZ
On Mon, 6 Jul 2009 03:59:35 -0700 (PDT), Rémi Moyen
:

franchement, oui, quel bazar ça serait, sinon...



Des noms de variables écrits en kanjis, et des noms de fonctions
écrits en arabe (dans quel sens, au fait ?), le pied... :-)
Avatar
loic.actarus.joly
On 6 juil, 13:07, Jean-Marc Bourguet wrote:
Rémi Moyen writes:
> (ou mainRémi(), si quelqu'un arrive à mettre des accents dans un
> identifiant ?) ;-)

Ma comprehension, c'est que c'est conforme.  Mais je ne me suis jamais
amuse a voir si c'etait supporte par un compilateur.



C'est aussi ma compréhension. Là où j'ai plus de doute, c'est si un
compilateur qui accepte les accents, par exemple dans les littéraux de
chaînes de caractères, a le droit de les refuser dans les
identificateurs.

J'ai testé les accents et autres caractères internationaux avec Visual
C++, et ils avaient l'air d'être parfaitement pris en compte. Et à
choisir, si un jour on m'impose de développer en Français, je pense
que j'utiliserai volontiers ces accents.

--
Loïc
Avatar
James Kanze
On Jul 6, 12:53 pm, Fabien LE LEZ wrote:
On Mon, 6 Jul 2009 03:39:00 -0700 (PDT), Rémi Moyen
:



>si quelqu'un arrive à mettre des accents dans un identifiant
>?



Je crois avoir lu quelque part que la norme l'autorise. Mais
je ne sais pas s'il existe des implémentations de cette
mauvaise idée.



VC++ le permet, et les gère correctement (autant que je puisse
déterminer). G++ et Sun CC non. (Le message d'erreur de Sun CC
est même assez bizarre. On dirait qu'ils se servent du bit 7
comme indicateur spécial quelque part.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
James Kanze
On Jul 6, 1:16 pm, Fabien LE LEZ wrote:
On Mon, 6 Jul 2009 03:59:35 -0700 (PDT), Rémi Moyen
:



>franchement, oui, quel bazar ça serait, sinon...



Des noms de variables écrits en kanjis, et des noms de
fonctions écrits en arabe (dans quel sens, au fait ?), le
pied... :-)



Je l'ai déjà vu, il y a fort longtemps (comme une extension de
C, avant sa normalisation). Effectivement, le programme était
assez déroutant. Pour moi ; pour les personnes qui l'avaient
écrit et qui devaient le maintenir, c'était certainement moins
déroutant que s'ils l'avait écrit en caractères latins. Et même
en caractères latins, je crois que ça m'aurait dérouter, avec
les noms de variables et les commentaires en japonais.

En somme, si tu écris pour une audience internationale, il faut
tout faire en anglais (qui utilise aussi des accents pour
quelque mots exceptionnels). Sinon, si tu utilises la langue
locale, autant l'utiliser correctement : avec des accents, s'il
s'agit du français, et avec des kanji, s'il s'agit du japonais.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
James Kanze
On Jul 6, 6:24 pm, ""
wrote:
On 6 juil, 13:07, Jean-Marc Bourguet wrote:



> Rémi Moyen writes:
> > (ou mainRémi(), si quelqu'un arrive à mettre des accents dans un
> > identifiant ?) ;-)



> Ma comprehension, c'est que c'est conforme. Mais je ne me
> suis jamais amuse a voir si c'etait supporte par un
> compilateur.



C'est aussi ma compréhension. Là où j'ai plus de doute, c'est
si un compilateur qui accepte les accents, par exemple dans
les littéraux de chaînes de caractères, a le droit de les
refuser dans les identificateurs.



J'ai testé les accents et autres caractères internationaux
avec Visual C++, et ils avaient l'air d'être parfaitement pris
en compte. Et à choisir, si un jour on m'impose de développer
en Français, je pense que j'utiliserai volontiers ces accents.



Si j'ai bien compris l'intention de ta question, la réponse est
non. Selon la norme, un compilateur n'a pas droit à les refuser
dans les identificateurs, pas plus qu'ailleurs (voir §2.10 et
Annex E). En revanche, dans la toute première phase de
traduction «  Physical source file characters are mapped, in an
implementation-defined manner, to the *basic* character set
(introducing new-line characters for end-of-line indicators) if
necessary. » L'encodage d'entrée est donc défini par
l'implémentation, et ne comprend pas forcément des caractères
accentués. En revanche, c'est toujours possible de spécifier des
caractères accentués au moyen des « universal character
names » -- u00C9tu00C9 est un identificateur parfaitement
légal, et un compilateur qui ne l'accepte pas n'est pas
conforme. En fait, la norme décrivent la traduction comme si la
seule source possible des caractères autres que les caractères
de base été les noms universels de caractère ; selon la norme,
une implémentation qui lirait un fichier en Unicode convertira
tous les caractères non ASCII en noms universels de caractère.
Sauf qu'évidemment, il y a la règle « as if », et la norme dit
aussi explicitement que « An implementation may use any internal
encoding, so long as an actual extended character encountered in
the source file, and the same extended character expressed in
the source file as a universal-character-name (i.e. using the
uXXXX notation), are handled equivalently. » (Cette phrase est
en parenthèses dans la norme, parce qu'en fait elle ne dit rien
de nouveau, mais ne sert qu'à éclairer l'intention des règles
qui précèdent.)

Enfin, pour revenir à ta question : tout ça, c'est la tout
première phase de traduction, bien avant même la tokenisation.
Il s'ensuit qu'un compilateur ne peut pas faire de distinction
entre les caractères dans les identificateurs, dans les
litéraux, et même dans les commentaires. Un compilateur qui
accepte « été » dans un commentaire, dans un encodage
quelconque, doit l'accepter aussi comme identificateur dans le
même encodage ; formellement, ce que le compilateur voit après
la première phase de traduction, c'est u00C9tu00C9 (ou quelque
chose qu'il est obligé à traiter de façon identique). Où
qu'apparaissent cette chaîne de caractères.

Dans la pratique, ce n'est pas si simple. Tant qu'on ne se
sert que des caractères dans l'ensemble de base, prèsque tous
les systèmes les encodent de la même façon, et ceux qui ne le
font pas ont des programmes de transcodage qui feront bien
l'affaire lors d'un portage. Dès que je m'en sors, en revanche,
c'est un peu le bordel en ce qui concerne l'encodage, et deux
utilisateurs sur la même machine pourraient très bien utiliser
des encodages différents (UTF-8 et ISO 8859-1, par exemple). Du
coup, une implémentation de qualité doit s'adresser au problème
qu'un fichier d'include pourrait avoir un encodage différent que
le fichier qui l'inclut. Ce qui suggère qu'il faut plus que
simplement une option de compilation ou le locale de
l'environement pour choisir l'encodage.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
James Kanze
On Jul 6, 12:19 pm, Michel Decima wrote:
Rémi Moyen a écrit :



> On 6 juil, 10:26, Fabien LE LEZ wrote:



> [snip l'exemple, merci de confirmer que les 0 dans v3 et
> A::v5_ ne sont pas imposés]



>> Si le standard n'indique pas de valeur par défaut,
>> l'implémentation est libre d'assigner la valeur qu'elle
>> veut. Ça peut être 0, ou la suite d'octets qui se trouvait
>> là en mémoire, ou 42.
> 2) l'OS ou le compilateur mettent toujours systématiquement
> à 0, c'est un choix d'implémentation (idem, c'est pas comme
> ça que ça marche) ;



Je crois que j'ai déjà rencontré un compilateur idiot qui
mettait systématiquement les variables à 0 en mode debug, et
ne le faisait pas en mode release (pour le jeu de parametre
par defaut de debug/release). Evidemment, ca donne des
resultats interessants, un programme qui fonctionne comme
attendu en mode debug peut faire n'importe quoi une fois
optimise...



C'est souvent le cas, dès qu'il y a le moindre comportement
indéfini, ou même un comportement qui dépend de l'ordre
d'évaluation des sous-expressions. C'est pourquoi on ne livre
jamais que la version qu'on a testé : il n'y a pas de modes
« debug » et « release ».

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Avatar
Michel Decima
James Kanze a écrit :
On Jul 6, 12:19 pm, Michel Decima wrote:



Je crois que j'ai déjà rencontré un compilateur idiot qui
mettait systématiquement les variables à 0 en mode debug, et
ne le faisait pas en mode release (pour le jeu de parametre
par defaut de debug/release). Evidemment, ca donne des
resultats interessants, un programme qui fonctionne comme
attendu en mode debug peut faire n'importe quoi une fois
optimise...



C'est souvent le cas, dès qu'il y a le moindre comportement
indéfini, ou même un comportement qui dépend de l'ordre
d'évaluation des sous-expressions. C'est pourquoi on ne livre
jamais que la version qu'on a testé : il n'y a pas de modes
« debug » et « release ».



Oui, c'est ce que m'a appris l'usage de ce compilateur ;)
Avatar
loic.actarus.joly
On 7 juil, 10:02, James Kanze wrote:

Enfin, pour revenir à ta question : tout ça, c'est la tout
première phase de traduction, bien avant même la tokenisation.
Il s'ensuit qu'un compilateur ne peut pas faire de distinction
entre les caractères dans les identificateurs, dans les
litéraux, et même dans les commentaires. Un compilateur qui
accepte « été » dans un commentaire, dans un encodage
quelconque, doit l'accepter aussi comme identificateur dans le
même encodage ; formellement, ce que le compilateur voit après
la première phase de traduction, c'est u00C9tu00C9 (ou quelque
chose qu'il est obligé à traiter de façon identique). Où
qu'apparaissent cette chaîne de caractères.



D'accord, nous avons donc eu la même compréhension du texte. J'hésite
à saisir un bug report à gcc.
1 2 3