à quoi sert le nul, par exemple dans une boucle  

#define NULL 0

ok merci

 

 
Si tu fais ca texto, il me semble que ca ne marche pas avec tous les compilos ... (Visual fait la gueule ... )
 
Mais dans le principe, c'est vrai que c'est 0

g++ fait aussi la gueule, en fait je crois que NULL vaut par defaut la valeur 0, j'ai bon ?

 
ouais pe au niveau des conversions de pointeur, mais bon, c t pour l'idee

donc pas besoin du #define

?
 
ben non, c t juste pour te donner une idee de ce qu'est null !

Oups ... Désolé ... Je crois que je sème la confusion avec mes remarques à 2 balles ...
 
Oauis ... NULL, c'est 0 ... Que tu compares à NULL ou que tu compares à 0, ca devrait revenir au même partout. Simplement, NULL est plus parlant pour ceux qui te reliront.
 
NULL signifie que tu pointes sur une zone mémoire factice, qui ne peut pas (et ne DOIT surtout pas) être utilisée pour lire ou écrire des valeurs

 
Quand je débutais, on m'avait dit que c'était :
#define NULL (void *)0
 
Et ca foire aussi ... Pourquoi tout le monde nous ment quand on débute ?
 
 
Edit : correction faute d'orthographe ...

c pire que le principe, c'est la définition canonique

 
Oups ... Un gros désolé et de plates excuses à tout le monde ...
 
 
En fait,
#ifdef NULL
#undef NULL
#endif
#define NULL 0
 
 
ca marche ...
 
J'sais pas ce que j'avais foutu le jour où ca n'a pas marché ...
 
(Edit ... Correction smiley ...)

de toutes façon en C++, je mets un jpli 0 et voilà

un jpli taz ?? c quoi stp ?

j'aime bien savoir ce qui se passe et quand je veux un zero j'écris pas autrechose
de toutes façons le jour où j'écrirai du code en C/C++ sur une machine où on a le droit d'allouer à l'adresse 0...

tu crois quoi? que 0 représente un mot mémoire spécial? etc, que la valeur de pointeur est une vrai adresse en RAM? ce n'est pas le cas. encore une fois, le 0 est une définition canonique. n'importe quel environnment C++ le respecte .|

sur amiga j'ai déjà stocké un mot long (32 bits) à l'adresse 0
le C/C++, quand on met un zero dans un pointeur, n'empêche pas d'y accéder comme si c'était une autre valeur. Simplement sur la plupart des OS, on se fait jeter par la protection mémoire.
Ce que je veux dire, c'est que dans un environnement où l'adresse 0 est utilisable (rare), on aurait intérêt à ce que NULL ait une autre valeur qui ne peut pas exister comme pointeur. Mais à priori ça risque pas d'arriver donc autant mettre 0 à la place de NULL, c'est + lisible.

encore heureux
 
sur x86/MSDOS c'est la table des interruptions à cette adresse.  Seulement je sais pas si c'est spécifique à l'OS ou à la plate-forme x86

je sais pas ce que tu entends par 'canonique'.
mais sur une machine sans mémoire virtuelle, où les pointeurs représentent l'adresse réelle, un pointeur à 0 pointera sur l'adresse physique 0.

 
oui mais malheureusement il n'est pas requis que l'adresse pointée par le pointeur "null" soit une adresse invalide, de même qu'il n'est pas requis que le système trappe les déférencements de pointeurs "null".
Par contre il est requis par le C++ que l'assignement du litteral "zero (0)" à un pointeur, soit considéré comme une initialisation à "null" et que toute comparaison ultérieur de ce pointeur au littéral "zero (0)" retourne true.
 
LeGreg

encore heureux qu'un 0==0 retourne 'true'

est dans le cas d'un pointeur far en mode protégé ?
avec segment::offset en 16:32 bits, si on fait ptr=NULL, ça doit mettre que l'offset à 0 non ?

je sais pas comment ça marche (j'ai pas touché au PC avant que cette mauvaise période soit finie:D).
dans ce mode t'arrives à allouer un bloc de + de 64Ko?
si oui, on peut supposer que le compilo gère pas seulement l'offset, sinon ça doit être juste l'offset.
tu peux tenter un sizeof sur le pointeur, ça peut donner un indice.

nan, je parles pas du mode réel...
 
sous windows, tu peux très bien (enfin il me semble fo demander au kernel) avoir plusieurs segments de donnée, et donc maintenir tes objets par un pointeur far (16:32).