[débutant] tester un pointeur sur un objet

Version imprimable

26/03/2007, 00h06
hogan

[débutant] tester un pointeur sur un objet

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
26/03/2007, 00h22
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:

1 2 3 4 5 6 Object* obj = 0; obj = truc; delete obj; obj = 0;
26/03/2007, 06h39
vdumont

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

Code:

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:

Citation:

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.
26/03/2007, 08h57
Laurent Gomila

Citation:

Envoyé par vdumont

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

Code:

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 ;)
26/03/2007, 14h11
Neo41

Citation:

Envoyé par Laurent Gomila

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 :mrgreen:

Donc le mieux c'est toujours intialiser les variables, en l'occurence faire MaClasse *obj = NULL;
26/03/2007, 14h26
Ulmo

Et avec un bon réglage du compilateur, ce genre d'erreur ne sera pas permise.
26/03/2007, 14h30
Jean-Marc.Bourguet

Citation:

Envoyé par Ulmo

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).
26/03/2007, 23h03
hogan

Citation:

Envoyé par Neo41

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

> thx, je vais compléter mes constructeurs.

Citation:

Envoyé par NewbiZ

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!

Citation:

Envoyé par Laurent Gomila

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é ?

Citation:

Envoyé par Ulmo

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!
26/03/2007, 23h14
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.
27/03/2007, 00h00
hogan

Citation:

Envoyé par koala01

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

> tu parles de -Wall -ansi ?
27/03/2007, 10h04
Médinoc
Citation:
Envoyé par 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:

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...
27/03/2007, 10h39
Patriarch24

Citation:

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 :

Citation:

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.
27/03/2007, 10h49
Jean-Marc.Bourguet

Citation:

Envoyé par Médinoc

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.
27/03/2007, 11h07
Médinoc

Citation:

Envoyé par Jean-Marc.Bourguet

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... 8O
27/03/2007, 11h12
Jean-Marc.Bourguet

Citation:

Envoyé par Médinoc

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... 8O

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).
27/03/2007, 11h55
Ulmo

Citation:

Envoyé par hogan

> 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.

Citation:

> Dis m'en plus stp.

Pour VS : Project/Properties/C++/General/Warning Level à mettre au niveau 4
Pour gcc : -Wall -W
27/03/2007, 11h56
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...
27/03/2007, 11h59
Ulmo

Tu as raison, ma source parlait plutôt des variables entières.
27/03/2007, 22h10
hogan

Citation:

Envoyé par 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...

> 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!

Citation:

Envoyé par Jean-Marc.Bourguet

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.
28/03/2007, 13h09
NewbiZ

Citation:

> 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 :mrgreen:

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

Code:

#define NULL 0

pour les compilateurs C++, et un

Code:

#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 ^^
29/03/2007, 21h23
hogan

Citation:

Envoyé par NewbiZ

De vieux restes de C surement

> hum je sui pas plus famillié au C je compren pa prkoi tu a fait la remark lol.
En tout cas c bien dommag, jaurai bien aimé garder la mm écriture entre le C# et le C++. Pour info en C# on utilise null ds le but d'initialiser les références.
29/03/2007, 21h38
Médinoc

Et en C++/CLI, on utilise nullptr. :)
29/03/2007, 22h06
MatteX

NULL apartient à C... même en C++ NULL est du domaine C puisqu'il est déclarer dans le préprocesseur

Code:

#define NULL 0

C'est pourquoi plusieurs utilisent 0, c'est autant auto-documenté que NULL.

Code:

Truc *machin = 0;

est autant, sinon plus, lisible que

Code:

Truc *machin = NULL;

ainsi que plusieurs utilisent

Code:

if( !machin )

pour valider que le pointeur est initialisé
sachant que 0 en C++ vaut false et toutes les autres valeurs valent true.

NULL n'est donc plus viable en C++, c'est du C
29/03/2007, 22h40
Médinoc

0 n'est pas "autant auto-documenté" que NULL, car quand on voit 0, on pense "entier".
Quand on voit NULL, on pense "pointeur". Et ce, qu'on vienne de C, C#, ou même Java.
30/03/2007, 01h56
koala01

On ne nie absolument pas que NULL soit un héritage du C...

D'ailleurs, quand tu y regarde d'un peu plus pres, il y a de nombreuses choses dans l'espace de nommage std qui ne sont que des héritages du C... (bien souvent, au mieux, avec un #undef hors de l'espace de nommage, et un #define exactement identique celui du C à l'intérieur :P)

Et pour cause: le C++ revendique de descendre du C... tout en revendiquant une différence par rapport à lui ;)

Cependant, je rejoint fortement l'avis (une fois n'est pas coutume) de médinoc: NULL est à mon sens bien plus autocommenté que 0...

N'oublions jamais que l'on peut décider de remettre un pointeur à 0/NULL à n'importe quel moment (idéalement, apres avoir quand meme pensé à libérer la mémoire vers laquelle il pointait :P) et que, en dehors de tout autre système auto-commenté (tous les noms variables "pointeurs" ne commencent pas forcément par un ptr_ ni meme par un p*), il devient rapidement difficile, parmis, parfois, plusieurs centaines de lignes de code, de se rappeler que telle ou telle variables est un pointeur et non un entier en voyant simplement

Code:

variable=0;

...Ce qui pourrait très bien arriver si la libération de la mémoire est déléguée à une fonction qui aurait été appelée quelques lignes plus tot...

C'est la raison pour laquelle, je préférerai toujours également tester un pointeur sous la forme de

Code:

if(variable !=NULL)

plustot que sous celle de

Code:

if(!variable)

bien qu'en définitive, les deux formes soient effectivement équivalentes...

Je sais que le C et le C++ fournissent énormément de "raccourcis" qui peuvent sembler très intéressant à première vue...

Mais il ne faut jamais oublier que ces raccourcis ont pour la plupart l'énorme inconvéniant de forcer à une réfléxion plus importante lorsque l'on (re)découvre un code inconnu/oublié...

Ces raccourcis datent, pour la plupart (tous serait d'ailleurs plus juste), d'un temps où tout était à faire, y compris dans le domaine des éditeurs de texte...

Ils permettaient de gagner quelques (dizièmes) de seconde à chaque fois qu'ils étaient utilisés, et faisaient, au final, gagner un temps non négligeable sur plusieurs centaines de lignes/instructions...ou sur l'ensemble d'un projet...

L'inconvéniant était que le code fourni perdait en compréhensibilité aux yeux d'une personne qui n'aurait pas participé directement au codage meme ou qui l'aurait laissé de coté pendant un temps plus ou moins long...

Mais, maintenant, avec l'évolution de tous les éditeurs de texte (y compris vim et emacs), et, principalement celles qui ont trait à l'auto-complétion et au copier/coller, on ne perd absolument pas de temps à laisser les raccourcis de coté, mais, par contre, qu'est-ce qu'on gagne, en le faisant, au niveau de la compréhension du code :P...

[EDIT]maintenant, je n'ai fait qu'émettre mon avis strictement personnel... mais je le partage :D
30/03/2007, 09h34
Médinoc

Citation:

Envoyé par koala01

<snip, je suis d'accord>
C'est la raison pour laquelle, je préférerai toujours également tester un pointeur sous la forme de

Code:

if(variable !=NULL)

plustot que sous celle de

Code:

if(!variable)

bien qu'en définitive, les deux formes soient effectivement équivalentes...

Je suis 100% d'accord avec toi sur le fond (d'ailleurs, j'ai tendance à corriger quand je tombe sur un de mes anciens programmes), mais sur la forme, les deux formules ici décrites ne sont PAS équivalentes, mais opposées :p
---> Le premier test est vrai si le pointeur n'est pas null, le second test est vrai s'il l'est...
Enfin, sans doute une faute d'inattention, qui ne change rien à l'argument.
Argument auquel je réponds un gros:
+1

Et +1 aussi pour la suite du post.
30/03/2007, 10h02
Jean-Marc.Bourguet

Citation:

Envoyé par koala01

D'ailleurs, quand tu y regarde d'un peu plus pres, il y a de nombreuses choses dans l'espace de nommage std qui ne sont que des héritages du C... (bien souvent, au mieux, avec un #undef hors de l'espace de nommage, et un #define exactement identique celui du C à l'intérieur :P)

Il ne faut pas exagere: les namespace n'ont aucun rapport sur la portee et la visibilite des macros.

Sur le fond je suis d'accord, mais il faut savoir que l'utilisation de 0 plutot que de NULL, l'elision de la comparaison a 0 de pointeurs ou d'entier est suffisemment repandue pour qu'on doive considere les deux comme idiomatiques.