Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

initialisation des variables membres par défaut

73 réponses
Avatar
Richard Delorme
// ---------8<----------------------------
#include <iostream>

class A {
private:
int x;

public:
A() {};
~A() {};
void print() {
std::cout << x << std::endl;
}
};


int main() {
A t;
int y;


t.print();
std::cout << y << std::endl;

return 0;
}
// ---------8<----------------------------

Dans l'exemple ci-dessus, ni x, membre de la classe A, ni la variable
locale y ne sont initialisées.
gcc détecte le cas de la variable locale :
attention : ‘y’ may be used uninitialized in this function
mais reste silencieux sur la variable membre.
Valgrind signale les deux cas (de manière guère compréhensible d'ailleurs).

Personnellement je pensais comme Valgrind que la variable x devait être
initialisé explicitement dans le constructeur, par exemple en écrivant :
A() : x() {};
à la place du constructeur ci-dessus.

Néanmoins la lecture de blogs sur internet me laisse dans le doute. Par
exemple ici :
http://discuss.joelonsoftware.com/default.asp?joel.3.489111.50

On lit tout et son contraire. Qu'en est il en pratique ? (et en théorie
aussi d'ailleurs).

--
Richard

10 réponses

1 2 3 4 5
Avatar
Stan
On 24 jan, 17:36, Richard Delorme wrote:

On lit tout et son contraire. Qu'en est il en pratique ? (et en théorie
aussi d'ailleurs).




La pratique, la bonne, consiste à toujours initialiser
les variables avant de les utiliser.
Les règles qui décrivent quand l'initialisation
de l'objet est garantie ou pas,sont, à mon goût,
trop compliquées pour être appliquée sans risque d'erreur.

--
-Stan
Avatar
Fabien LE LEZ
On Sun, 24 Jan 2010 17:36:53 +0100, Richard Delorme
:

Personnellement je pensais comme Valgrind que la variable x devait être
initialisé explicitement dans le constructeur, par exemple en écrivant :
A() : x() {};



Par défaut, x, étant d'un type de base, existe bien, mais sa valeur
n'est pas prévisible. Note que ce ne serait pas vrai si le type de x
était une classe.

Ta ligne
A() : x() {};


initialise x à une valeur par défaut, qui se trouve être 0 si mes
souvenirs sont bons. Ça ne me paraît pas excessivement utile.
(HS : En prime, tu as rajouté un point-virgule inutile. Si mes
souvenirs sont bons, certains compilos n'aiment pas trop.)

Si tu veux initialiser x explicitement, donne-lui une valeur :

A() : x (0) {}
ou
A() : x (42) {}

Si tu ne sais pas quelle valeur lui donner, je ne vois pas bien
l'intérêt de l'initialiser explicitement.
Avatar
Stan
On 24 jan, 23:37, Fabien LE LEZ wrote:


Ta ligne>A() : x() {};

initialise x une valeur par d faut, qui se trouve tre 0 si mes
souvenirs sont bons. a ne me para t pas excessivement utile.



Je pense que ça dépend de l'architecture matériel parce que,
si la classe est instanciée en globale , x vaudra zéro,
mais sur la pile, elle sera indéfinie ( VC sur x86 ).

--
-Stan
Avatar
espie
In article ,
Stan wrote:
On 24 jan, 23:37, Fabien LE LEZ wrote:


Ta ligne>A() : x() {};

initialise x une valeur par d faut, qui se trouve tre 0 si mes
souvenirs sont bons. a ne me para t pas excessivement utile.





Je pense que ça dépend de l'architecture matériel parce que,
si la classe est instanciée en globale , x vaudra zéro,
mais sur la pile, elle sera indéfinie ( VC sur x86 ).



Non, ca ne depend pas. C'est parfaitement defini par la norme. Les
globales/static sont initialisees a 0 (que des bits a zero), et ca
fait effectivement 0 pour des valeurs numeriques entieres, independamment
de l'archi materielle. Et les automatiques ne sont pas initialisees, s'en
servir avant de leur donner une valeur EST une erreur.
Avatar
pasdespam
Marc Espie wrote:

Et les automatiques ne sont pas initialisees, s'en
servir avant de leur donner une valeur EST une erreur.



oui, mais doivent elles etre initialisées dans le constructeur comme le
laisse suposer Valgrind?
Avatar
Stan
On 25 jan, 18:09, (Bruno Causse) wrote:
Marc Espie wrote:
> Et les automatiques ne sont pas initialisees, s'en
> servir avant de leur donner une valeur EST une erreur.

oui, mais doivent elles etre initialisées dans le constructeur comme le
laisse suposer Valgrind?



Oui mais pas avec cette forme : A() : x() { } !

--
-Stan
Avatar
espie
In article <1jcvzpe.gc7981kl8f1wN%,
Bruno Causse wrote:
Marc Espie wrote:

Et les automatiques ne sont pas initialisees, s'en
servir avant de leur donner une valeur EST une erreur.



oui, mais doivent elles etre initialisées dans le constructeur comme le
laisse suposer Valgrind?



Non, elles ne *doivent* pas etre initialisees dans le constructeur.
Il suffit qu'elles soient initialisees avant d'utiliser leur valeur.
(et dans beaucoup de cas, la seule facon d'en etre sur, c'est de les
initialiser dans le constructeur).
Avatar
Wykaaa
Marc Espie a écrit :
In article <1jcvzpe.gc7981kl8f1wN%,
Bruno Causse wrote:
Marc Espie wrote:

Et les automatiques ne sont pas initialisees, s'en
servir avant de leur donner une valeur EST une erreur.


oui, mais doivent elles etre initialisées dans le constructeur comme le
laisse suposer Valgrind?



Non, elles ne *doivent* pas etre initialisees dans le constructeur.
Il suffit qu'elles soient initialisees avant d'utiliser leur valeur.
(et dans beaucoup de cas, la seule facon d'en etre sur, c'est de les
initialiser dans le constructeur).



Une recommandation de "bonne programmation" est d'initialiser les
variables le plus tôt possible :
- sur leur définition pour les variables "classiques"
- dans le constructeur pour les variables d'instances de classe

De nombreuses études ont montré que l'erreur de programmation la plus
fréquente est d'utiliser ou de tester une variable non initialisée, ce
qui donne des défauts souvent difficilement reproductibles car le
comportement du programme dépend alors de la valeur contenue dans la
mémoire qui correspond à la variable au moment de l'exécution.
Avatar
Fabien LE LEZ
On Tue, 26 Jan 2010 11:27:12 +0100, Wykaaa :

Une recommandation de "bonne programmation" est d'initialiser les
variables le plus tôt possible :



Avec un bémol : pour initialiser une variable d'un type de base, il
faut connaître la valeur à lui assigner.
Pour une variable numérique, on peut toujours utiliser 42, mais bon...
Avatar
Alain Ketterlin
Stan writes:

On 25 jan, 18:09, (Bruno Causse) wrote:
Marc Espie wrote:
> Et les automatiques ne sont pas initialisees, s'en
> servir avant de leur donner une valeur EST une erreur.

oui, mais doivent elles etre initialisées dans le constructeur comm e le
laisse suposer Valgrind?



Oui mais pas avec cette forme : A() : x() { } !



Si si. Ca s'appelle "default initialization". Un exemple au hasard:

http://www.devx.com/tips/Tip/13681

ou encore

http://msdn.microsoft.com/en-us/library/s0wk5dy9.aspx

-- Alain.
1 2 3 4 5