Discussion :

[hogan]

J'aimerais savoir comment tester si un pointeur sur un objet a bien été initialisé ?

MaClasse *obj;
if(obj != NULL) // c'est toujours vrai apparement

[NewbiZ]

Dans le doute, pars du posulat que tu ne peux pas prévoir ce qui se trouve dans la zone mémoire que tu viens d'allouer. Il est donc vivement conseillé d'assigner la valeur 0 à ton pointeur lors de sa déclaration, et juste après sa desallocation.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Object* obj = 0;
 
obj = truc;
 
delete obj;
obj = 0;

[vdumont]

Ton 'if' est toujours vrai car lorsque tu fais seulement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Object *obj;

Tu n'as pas allouer de mémoire pour ton pointeur (donc il ne pointe nul part). Il est donc égal à NULL.

Si tu fais:

Object *obj = new Object;

Tu alloues dynamiquement de la mémoire pour ton pointeur et donc s'il n'y a pas eu un manque de mémoire (ou autre problème d'allocation de mémoire), ton pointeur ne sera plus égal à NULL.

Bonne continuation.

[Laurent Gomila]

Ton 'if' est toujours vrai car lorsque tu fais seulement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Object *obj;

Tu n'as pas allouer de mémoire pour ton pointeur (donc il ne pointe nul part). Il est donc égal à NULL.

Une variable d'un type primitif non initialisée reste non initialisée, sauf options du compilo paticulières ; elle contient donc n'importe quoi.
Donc dire qu'ici le pointeur est égal à NULL est une grosse erreur, qui se payera au mieux immédiatement, au pire lorsque tu livreras ton appli au client

[Neo41]

Une variable d'un type primitif non initialisée reste non initialisée, sauf options du compilo paticulières ; elle contient donc n'importe quoi.
Donc dire qu'ici le pointeur est égal à NULL est une grosse erreur, qui se payera au mieux immédiatement, au pire lorsque tu livreras ton appli au client

C'est le genre de trucs que tu t'en rends jamais compte avant d'avoir livré, parce qu'en debug ca passe alors qu'en release ca explose

Donc le mieux c'est toujours intialiser les variables, en l'occurence faire MaClasse *obj = NULL;

[Ulmo]

Et avec un bon réglage du compilateur, ce genre d'erreur ne sera pas permise.

[Jean-Marc.Bourguet]

Et avec un bon réglage du compilateur, ce genre d'erreur ne sera pas permise.

Le problème de savoir si une variable est initialisée ou non est indécidable dans sa generalite. Le compilateur peut avertir sur des cas particuliers (ou accepter d'avertir de donner des faux positifs).

[hogan]

Donc le mieux c'est toujours intialiser les variables, en l'occurence faire MaClasse *obj = NULL;

> thx, je vais compléter mes constructeurs.

Object* obj = 0;
obj = truc;
delete obj;
obj = 0;

> J'achete!

vdumont, si mon test est vrai c bien que le pointeur n'est pas NULL!

Une variable d'un type primitif non initialisée reste non initialisée, sauf options du compilo paticulières ; elle contient donc n'importe quoi.

> Option du compilo! Hey ça m'interesse. Est ce qu'on peut forcer le compilo à donner la valeur NULL a 1 objet non initialisé ?

Et avec un bon réglage du compilateur, ce genre d'erreur ne sera pas permise.

> Dis m'en plus stp.

Jean-Marc.Bourguet tu peux reformuler stp, jai pas bien saisi!

[koala01]

Salut,

Ce que jean marc voulait dire, c'est que si tu choisi les bonnes options de compilation (que tu le regle en mode "paranoïaque", par exemple), ton compilateur criera au scandale chaque fois que tu feras l'erreur...

S'il accepte de continuer la compilation, tu auras au moins un avertissement, dont il t'appartiendra de le prendre en compte.

[hogan]

ton compilateur criera au scandale chaque fois que tu feras l'erreur...

> tu parles de -Wall -ansi ?

[Médinoc]

Dans le doute, pars du posulat que tu ne peux pas prévoir ce qui se trouve dans la zone mémoire que tu viens d'allouer. Il est donc vivement conseillé d'assigner la valeur 0 à ton pointeur lors de sa déclaration, et juste après sa desallocation.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Object* obj = 0;
 
obj = truc;
 
delete obj;
obj = 0;

Tu connais la différence entre NULL et 0 ?
L'un a une valeur documentaire qui dit "en théorie, on m'emploie sur des pointeurs, et m'affecter à un entier relève de la volonté de nuire". Généralement, sur les pointeurs, c'est celui-là qu'on emploie...

[Patriarch24]

Tu connais la différence entre NULL et 0 ?
L'un a une valeur documentaire qui dit "en théorie, on m'emploie sur des pointeurs, et m'affecter à un entier relève de la volonté de nuire". Généralement, sur les pointeurs, c'est celui-là qu'on emploie...

Personnellement, ça ne me choque pas de voir un 0 au lieu d'un NULL (je fais pareil). Juste un petit quote à ce sujet :

If you have to name the null pointer, call it nullptr; that's what it's going to be called in C++0x. Then, "nullptr" will be a keyword.

[Jean-Marc.Bourguet]

Tu connais la différence entre NULL et 0 ?
L'un a une valeur documentaire qui dit "en théorie, on m'emploie sur des pointeurs, et m'affecter à un entier relève de la volonté de nuire". Généralement, sur les pointeurs, c'est celui-là qu'on emploie...

Les opinions sont assez divergentes sur le sujet. De bons auteurs (Stroustrup en tete si j'ai bonne memoire) preconisent l'utilisation de 0.

Personnellement, j'utilise NULL.

[Médinoc]

De bons auteurs (Stroustrup en tete si j'ai bonne memoire) preconisent l'utilisation de 0.

Là, je suis sur le cul.
Pour moi, c'est mélanger les torchons et les serviettes, ce qu'un langage fortement typé est justement censé aider à éviter...

[Jean-Marc.Bourguet]

Là, je suis sur le cul.
Pour moi, c'est mélanger les torchons et les serviettes, ce qu'un langage fortement typé est justement censé aider à éviter...

Le probleme c'est que NULL n'est en rien different de 0 (en C++, en C c'est pire, ce peut etre mais pas obligatoirement (void*)0). Donc l'utilisation de NULL n'a qu'une valeur de commentaire et a un comportement bizarre en cas de surcharge et de resolution de template si on pense a lui comme un pointeur. Ils le trouvent donc dangereux. (Et certains ont ete brules dans le passe avec le partage d'entete avec C faisant que NULL etait defini comme (void*)0, ce qui ne doit plus arriver depuis un quinzaine d'annees).

[Ulmo]

> Option du compilo! Hey ça m'interesse. Est ce qu'on peut forcer le compilo à donner la valeur NULL a 1 objet non initialisé ?

Je sais que par défaut, le mode Debug de VS le fait alors que le mode release ne le fait pas (d'où certain bug qui n'apparaissent qu'en release) (source). C'est lié au optimisations. Il reste que compter sur le compilateur n'est pas la bonne solution.

Pour GCC je ne sais pas commen ça se passe. Donc pareil, il ne faut pas compter dessus.

> Dis m'en plus stp.

Pour VS : Project/Properties/C++/General/Warning Level à mettre au niveau 4
Pour gcc : -Wall -W

[Médinoc]

Il me semble que le debugger de VS initialise au contraire les variables à une valeur forcément invalide (0xCCCCCCCC pour les variables sur la pile) histoire d'aider au débogage...

[Ulmo]

Tu as raison, ma source parlait plutôt des variables entières.

[hogan]

Il me semble que le debugger de VS initialise au contraire les variables à une valeur forcément invalide (0xCCCCCCCC pour les variables sur la pile) histoire d'aider au débogage...

> pas mal! Mais mieux vaut s'en passer si on veut pouvoir porter son code. Puis en initialisant les variables avec 1 valeur par défaut on gagne en lisibilité n'est ce pas!

Les opinions sont assez divergentes sur le sujet. De bons auteurs (Stroustrup en tete si j'ai bonne memoire) preconisent l'utilisation de 0.

> effectivement on retrouve bien 0 comme valeur par défaut dans beaucoup de source du c++ mais le NULL y est tt aussi répendu. A mon sens c'est plus un pb de conformité par rapport à l'écriture adoptée...il vaut mieux utiliser 1 seul représentation pour rester cohérent. L'idéal serait peut être de faire un typedef de façon à pouvoir switcher facilement de l'un vers l'autre.

[NewbiZ]

> effectivement on retrouve bien 0 comme valeur par défaut dans beaucoup de source du c++ mais le NULL y est tt aussi répendu. A mon sens c'est plus un pb de conformité par rapport à l'écriture adoptée...il vaut mieux utiliser 1 seul représentation pour rester cohérent. L'idéal serait peut être de faire un typedef de façon à pouvoir switcher facilement de l'un vers l'autre.

De vieux restes de C surement

En vérité tu trouvera typiquement dans tes fichiers include un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define NULL 0

pour les compilateurs C++, et un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#define NULL ((void*)0)

pour les compilateurs C.

Il y a donc stricte équivalence entre les 2 du point de vue technique. Pour ce qui est de la théorie, Jean-Marc.Bourguet a très bien résumé la situation ^^