Discussion :

[isoman]

Bonjour,
lors de la création d'un pointeur est ce que il y a une différence si on l'initialise a 0 ou a NULL ?
Merci

[ram-0000]

Dans les faits, je dirai que c'est pareil. Simplement, par habitude, NULL c'est réservé aux pointeurs.

Si je voie "p = NULL", je déduit immediatement que p est un pointeur (de quoi, je n'en sais rien mais pointeur quand même) alors que si je voie "p = 0", je ne sais pas si p est un nombre ou un pointeur.

En plus, on n'est pas à l'abris d'une définition genre "#define NULL (void *)-1" (bien que cela soit peut probable)

[Davidbrcz]

pour moi non.

[koala01]

Salut,

Au final, on peut répondre que non.

Seulement, NULL n'est , le plus souvent, jamais qu'un terme déclaré grâce à 'un macro (dont tu peux t'attendre à trouver une définition dans des fichiers tels que cstddef, cstdio, cstring, ctime, cwchar) sous une forme proche de

Code :

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

#define NULL (void*) 0

ou sous une forme proche de

Code :

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

#define NULL 0

Sauf que, voilà... NULL est la seule adresse dont il soit certifié qu'elle est invalide, et qu'une impléméntation pourrait très bien décider de la faire pointer sur autre chose que 0X00000000

Comme il n'y a, à ma connaissance (bien que je pourrais le vérifier), pas de précision dans la norme autre que "défini une adresse invalide", il n'est pas impossible d'envisager qu'une implémentation particulière puisse définir NULL comme valant ... autre chose que 0.

L'idéal est donc, à mon sens, de toujours préférer l'utilisation de NULL à celle de 0, ne serait ce que parce que, dans l'idée générale, NULL s'applique principalement à un pointeur, et donc, fournit une information intrinsèque que 0 ne fournit pas.

Maintenant, il ne s'agit ici que d'un avis personnel... que je partage, mais tu trouveras surement sur le forum des gens qui ne le partagent pas

[Vespasien]

Le grand Bjarne Stroustrup préconise l'emploi de 0 face au problème évoqué par ram_0000.

[ram-0000]

Le grand Bjarne Stroustrup préconise l'emploi de 0 face au problème évoqué par ram_0000.

Je suis très touché que même le grand Bjarne Stroustrup s'intéresse à mes problèmes

[Sylvain Togni]

NULL est garanti être de type entier et de valeur 0 par la norme.

Ce qui ne signifie pas forcement que le pointeur nul vaut 0x00000000, d'ailleurs. Car lorsqu'on affecte NULL ou 0 à un pointeur il y a une conversion de la valeur entière 0 en pointeur nul qui peut avoir n'importe quelle représentation mémoire.

[Alp]

Le sujet a déjà été abordé à maintes reprises dans le forum. Tu trouveras beaucoup plus d'éléments de réponse grâce à une recherche avancée

[Vespasien]

NULL est garanti être de type entier et de valeur 0 par la norme

Ce Bjarne, quel farceur! Il ne connait plus les normes qu'il écrit.
'Le Langage C++', Bjarne Stroustrup, page 99 en haut à droite.

[Sylvain Togni]

Ce Bjarne, quel farceur! Il ne connait plus les normes qu'il écrit.
'Le Langage C++', Bjarne Stroustrup, page 99 en haut à droite.

Et ? Quel est le problème, je ne voit nul part de contradiction entre ce que j'ai écrit et ce qu'il à écrit.

[Vespasien]

En langage C++, il arivait fréquemment qu'une macro NULL soit définie pour représenter le pointeur 0. En C++, un contrôle plus sérieux impose l'utilisation du 0 normal, plutot que toute macro NULL telle qu'évoquée. Le nombre de problèmes est aini considérablement réduit. Si vous pensez devoir définir NULL, utilisez
const int NULL = 0;
Le qualificatif const évite toute redéfinition accidentelle de NULL et garanti ...

Bjarne dit que NULL n'est pas dans la norme C++ mais fréquemment définie. C'est très différent de "NULL est garanti être de type entier et de valeur 0 par la norme". Aucune garantie que ton compilateur le prenne correctement. Aucune garanti qu'elle ne soit pas redéfinie ensuite.

je ne voit nul part de contradiction entre ce que j'ai écrit et ce qu'il à écrit Moi, si. Fréquemment les histoires d'amour finissent mal revient donc a dire que toutes les histoires d'amour finissent mal?

[ProgVal]

Dans les MégaCours, il y a marqué que parfois, NULL équivaut à -1.

[JolyLoic]

Bjarne dit que NULL n'est pas dans la norme C++ mais fréquemment définie. C'est très différent de "NULL est garanti être de type entier et de valeur 0 par la norme". Aucune garantie que ton compilateur le prenne correctement.

Il ne dit pas ça, et s'il le disait, il se tromperait.

C.2.2.3 Macro NULL [diff.null]
1 The macro NULL, defined in any of <clocale>, <cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, or <cwchar>, is an implementationdefined
C++ null pointer constant in this International Standard (18.1).

La question de savoir si NULL est préférable ou pas à 0 est loin de faire l'unanimité entre les experts C++, au point que dans la prochaine norme, un nouveau mot clef (null_ptr) est défini qui devrait résoudre ces problèmes.

Dans les MégaCours, il y a marqué que parfois, NULL équivaut à -1.

Dans ce cas, les MégaCours se trompent.

[Médinoc]

JolyLoic: Alors finalement, la norme C ne garantit pas que if(ptr) équivaut à if(ptr!=NULL) ?

[JolyLoic]

Je ne connais pas la norme C, mais je ne vois pas ce qui dans l'extrait de la norme C++ que j'ai posté te fait dire ça.

Il est bien sur possible de n'avoir inclus aucun header spécifié, auquel cas NULL ne sera pas compris. Il est aussi possible de faire :

Code :

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

1
2
3
4
#include <cstdio>
#undef NULL
int a = 3;
#define NULL &a

Mais n'importe quel développeur faisant ça passerait en court martiale, et donc dans les cas courants, pratiques, de tous le jours, if(ptr) équivaut à if(ptr!=NULL) ?

[yan]

Dans un des ancien thread, il est expliqué que NULL représente la conversion de 0 en pointeur void. Ce qui as un sens en C et pas trop en C++.
Et que c'est pour cela qu'il faut mieux utiliser 0 plustôt que NULL pour initialiser un pointeur en C++, car (void*)0 ne garantie pas que cela corresponde à un pointeur == 0

[JolyLoic]

Je ne suis pas trop ce que tu veux dire...

En C++, sauf manipulation douteuse, NULL signifie 0, et rien d'autre.

Maintenant, 0, dans les contextes appropriés(1), est interprété comme une "null pointer constant" (dont la représentation en bits est non spécifiée), différente de toutes les valeurs de pointeurs valides.


(1) Ce qui peut poser problème, le fameux :

Code :

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

1
2
3
4
5
void f(int i); //1
void f(int *j); //2
int *pi = NULL; // Ou =0, c'est pareil
 
f(pi); // C'est 1 qui est choisi

[Emmanuel Deloget]

JolyLoic: Alors finalement, la norme C ne garantit pas que if(ptr) équivaut à if(ptr!=NULL) ?

NULL est un pointeur constant nul (null pointer constant), selon l'annexe C de la norme cité par JolyLoic. La norme dit en outre:

A null pointer constant is an integral constant expression rvalue of integer type that evaluates to zero.

Dans un des ancien thread, il est expliqué que NULL représente la conversion de 0 en pointeur void. Ce qui as un sens en C et pas trop en C++.

Et que c'est pour cela qu'il faut mieux utiliser 0 plustôt que NULL pour initialiser un pointeur en C++, car (void*)0 ne garantie pas que cela corresponde à un pointeur == 0

En C, NULL est aussi une null pointer constant, mais la définition de ce terme est plus étendue:

An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.

De fait,

Code :

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

#define NULL ((void*)0)

et

Code :

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

#define NULL 0

Sont des définitions C valides, tandis que la première n'est pas valide en C++.

Quoi qu'il en soit,

Code :

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

#define NULL (valeur différente de 0)

Est invalide, en C comme en C++. Par conséquent, if (ptr) et if (ptr != NULL) sont toujours équivalents.

(1) Ce qui peut poser problème, le fameux :

C'est surtout f(NULL) qui appelle le premier overload, malgré la formulation choisie par le programmeur. pi est du type int*, donc le second overload sera appelé - quelque soit la valeur de pi, y compris si pi == NULL, puisque la décision se fait sur le type du paramètre.

[yan]

De fait,

Code :

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

#define NULL ((void*)0)

et

Code :

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

#define NULL 0

Sont des définitions C valides, tandis que la première n'est pas valide en C++.

C'est de ça que je parlais. Mais je n'avais plus l'explication.

[JolyLoic]

C'est surtout f(NULL) qui appelle le premier overload, malgré la formulation choisie par le programmeur. pi est du type int*, donc le second overload sera appelé - quelque soit la valeur de pi, y compris si pi == NULL, puisque la décision se fait sur le type du paramètre.

Oui, effectivement, à force de vouloir détailler, on dit parfois des bêtises...