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
Version imprimable
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
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)
pour moi non.
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
ou sous une forme proche deCode:#define NULL (void*) 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 :PCode:#define NULL 0
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 ;)
Le grand Bjarne Stroustrup préconise l'emploi de 0 face au problème évoqué par ram_0000.
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.
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 ;)
Ce Bjarne, quel farceur! Il ne connait plus les normes qu'il écrit. :mouarf:Citation:
NULL est garanti être de type entier et de valeur 0 par la norme
'Le Langage C++', Bjarne Stroustrup, page 99 en haut à droite.
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?:cry:
Dans les MégaCours, il y a marqué que parfois, NULL équivaut à -1.
Il ne dit pas ça, et s'il le disait, il se tromperait.
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.Citation:
Envoyé par La norme, annexe C
Dans ce cas, les MégaCours se trompent.
JolyLoic: Alors finalement, la norme C ne garantit pas que if(ptr) équivaut à if(ptr!=NULL) ?
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 :
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) ?Code:
1
2
3
4 #include <cstdio> #undef NULL int a = 3; #define NULL &a
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
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:
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
NULL est un pointeur constant nul (null pointer constant), selon l'annexe C de la norme cité par JolyLoic. La norme dit en outre:
Citation:
Envoyé par Norme C++, 4.10 §1
En C, NULL est aussi une null pointer constant, mais la définition de ce terme est plus étendue:Citation:
Envoyé par Mongaulois
De fait,Citation:
Envoyé par Norme C99, 6.3.2.3 §3
etCode:#define NULL ((void*)0)
Sont des définitions C valides, tandis que la première n'est pas valide en C++.Code:#define NULL 0
Quoi qu'il en soit,
Est invalide, en C comme en C++. Par conséquent, if (ptr) et if (ptr != NULL) sont toujours équivalents.Code:#define NULL (valeur différente de 0)
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.Citation:
Envoyé par JolyLoic