- soit malloc(0) echoue. - soit malloc(0) reussit,[...]
Par contre, free(0) est parfaitement standard,
Pour reprendre l'éternelle discussion, voici un cas précis où il vaut mieux écrire NULL, histoire de ne pas faire le rapprochement entre malloc(0) [0 est un entier] et free(0) [0 est un pointeur]...
Tiens, c'est vrai. D'ailleurs, n'a-t-il pas existé des implémentations du langage C dans lesquelles NULL valait 0xFFFFFFFF ? Est-ce que ceci est normalisé en C++ ?
Ceci est normalise en C comme en C++. La semantique du 0 est la meme: il designe un pointeur nul dans un contexte ou on a besoin d'un pointeur. Maintenant, un pointeur nul n'est pas forcement represente par une suite d'octets ou tous les bits sont a zero.
Pour ce qui est de NULL, c'est legerement different... La definition du C++ est un peu plus contraignante, et ca en fait un pointeur nul `interessant' (confere gcc, qui a un built-in __null precisement pour lui donner exactement la bonne semantique).
En C, ca se discute. C'est plus affaire de style qu'autre chose. Comme NULL n'est pas garanti etre obligatoirement un pointeur nul en C, je prefere personnellement un 0 tout seul, ca a l'avantage d'etre explicite (et comme ca, on n'oublie pas le cast sur les fonctions varargs comme exec*(...)) (je trouve NULL sournois dans ses promesses non tenues).
En C++, la definition de NULL fait que c'est marginalement plus utile...
In article <469d4898@neottia.net>,
Olivier Miakinen <om+news@miakinen.net> wrote:
- soit malloc(0) echoue.
- soit malloc(0) reussit,[...]
Par contre, free(0) est parfaitement standard,
Pour reprendre l'éternelle discussion, voici un cas précis où il vaut
mieux écrire NULL, histoire de ne pas faire le rapprochement entre
malloc(0) [0 est un entier] et free(0) [0 est un pointeur]...
Tiens, c'est vrai. D'ailleurs, n'a-t-il pas existé des implémentations
du langage C dans lesquelles NULL valait 0xFFFFFFFF ? Est-ce que ceci
est normalisé en C++ ?
Ceci est normalise en C comme en C++. La semantique du 0 est la meme:
il designe un pointeur nul dans un contexte ou on a besoin d'un pointeur.
Maintenant, un pointeur nul n'est pas forcement represente par une suite
d'octets ou tous les bits sont a zero.
Pour ce qui est de NULL, c'est legerement different... La definition du
C++ est un peu plus contraignante, et ca en fait un pointeur nul
`interessant' (confere gcc, qui a un built-in __null precisement pour lui
donner exactement la bonne semantique).
En C, ca se discute. C'est plus affaire de style qu'autre chose. Comme NULL
n'est pas garanti etre obligatoirement un pointeur nul en C, je prefere
personnellement un 0 tout seul, ca a l'avantage d'etre explicite (et
comme ca, on n'oublie pas le cast sur les fonctions varargs comme exec*(...))
(je trouve NULL sournois dans ses promesses non tenues).
En C++, la definition de NULL fait que c'est marginalement plus utile...
- soit malloc(0) echoue. - soit malloc(0) reussit,[...]
Par contre, free(0) est parfaitement standard,
Pour reprendre l'éternelle discussion, voici un cas précis où il vaut mieux écrire NULL, histoire de ne pas faire le rapprochement entre malloc(0) [0 est un entier] et free(0) [0 est un pointeur]...
Tiens, c'est vrai. D'ailleurs, n'a-t-il pas existé des implémentations du langage C dans lesquelles NULL valait 0xFFFFFFFF ? Est-ce que ceci est normalisé en C++ ?
Ceci est normalise en C comme en C++. La semantique du 0 est la meme: il designe un pointeur nul dans un contexte ou on a besoin d'un pointeur. Maintenant, un pointeur nul n'est pas forcement represente par une suite d'octets ou tous les bits sont a zero.
Pour ce qui est de NULL, c'est legerement different... La definition du C++ est un peu plus contraignante, et ca en fait un pointeur nul `interessant' (confere gcc, qui a un built-in __null precisement pour lui donner exactement la bonne semantique).
En C, ca se discute. C'est plus affaire de style qu'autre chose. Comme NULL n'est pas garanti etre obligatoirement un pointeur nul en C, je prefere personnellement un 0 tout seul, ca a l'avantage d'etre explicite (et comme ca, on n'oublie pas le cast sur les fonctions varargs comme exec*(...)) (je trouve NULL sournois dans ses promesses non tenues).
En C++, la definition de NULL fait que c'est marginalement plus utile...
James Kanze
On Jul 18, 1:40 am, (Marc Espie) wrote:
In article , Olivier Miakinen <om+ wrote:
- soit malloc(0) echoue. - soit malloc(0) reussit,[...]
Par contre, free(0) est parfaitement standard,
Pour reprendre l'éternelle discussion, voici un cas précis où il vaut mieux écrire NULL, histoire de ne pas faire le rapprochement entre malloc(0) [0 est un entier] et free(0) [0 est un pointeur]...
Tiens, c'est vrai. D'ailleurs, n'a-t-il pas existé des implémentatio ns du langage C dans lesquelles NULL valait 0xFFFFFFFF ? Est-ce que ceci est normalisé en C++ ?
Il a existé (et peut-être il en existe encore) des machines ou un pointeur nul n'a pas tous ces bits à zéro. Mais il n'y a pas de façon en C ou en C++ pour épeler un pointeur nul ; le « null pointer constant » n'est pas un pointeur, nul ou autrement. (Il y a une tolérance en C qui le permet d'être un pointeur, mais c'est toujours un pointeur qui résulte de la conversion d'un entier.) Le macro NULL doit s'évaluer non à un pointeur nul, mais à un « null pointer constant » ; en C++, un « null pointeur constant » est obligatoirement une expression entière (non un pointeur !) constante dont la valeur est 0.
Ceci est normalise en C comme en C++. La semantique du 0 est la meme: il designe un pointeur nul dans un contexte ou on a besoin d'un pointeur.
Il se convertit en pointeur nul. La sémantique du token 0 ne change pas -- c'est une constante octale avec type int, et valeur zéro.
Maintenant, un pointeur nul n'est pas forcement represente par une suite d'octets ou tous les bits sont a zero.
Pour ce qui est de NULL, c'est legerement different... La definition du C++ est un peu plus contraignante, et ca en fait un pointeur nul `interessant' (confere gcc, qui a un built-in __null precisement pour lui donner exactement la bonne semantique).
Tous les NULL en C++ sont aussi légale en C. Dans les deux langages, NULL doit être un « implementation defined null pointer constant ». C-à-d en C++, une expression entière constante dont la valeur est 0. (Le C permet également une telle expression convertie explicitement en void*. Une innovation du comité de normalisation C, qui n'était pas présente dans le C de K&R.)
Un symbole tel que "__null" a un comportement indéfini. C-à-d que le compilateur est libre de le définir comme il veut, s'il veut. G++ (et gcc ?) le reconnaît comme une expression entière dont la valeur est 0, donc comme un « null pointer constant ». Mais il en profite pour avertir si cette expression particulière n'est pas immédiatement converti en pointeur nul.
En C, ca se discute. C'est plus affaire de style qu'autre chose. Comme NULL n'est pas garanti etre obligatoirement un pointeur nul en C,
D'où est-ce que tu as ça ? La norme C et la norme C++ disent exactement la même chose pour NULL : « [it] expands to an implementation-defined null pointer constant ».
je prefere personnellement un 0 tout seul, ca a l'avantage d'etre explicite (et comme ca, on n'oublie pas le cast sur les fonctions varargs comme exec*(. ..)) (je trouve NULL sournois dans ses promesses non tenues).
C'est le problème de NULL. Le problème de 0, c'est qu'il donne moins d'information au lecteur. Le vrai problème, évidemment, c'est la manque d'une vraie façon de spécifier un pointeur nul. (Lacun que le C++ va combler dans la prochaine version, je crois.)
En C++, la definition de NULL fait que c'est marginalement plus utile...
Je ne comprends pas, vue que la définition est la même dans les deux languages. En C++, je dirais, la risque en ne pas étant explicit est marginalement plus grand : il n'y a pas seulement les varargs ; il y a aussi la façon que ça joue dans la résolution des surcharges et les instantiations de templates.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jul 18, 1:40 am, es...@lain.home (Marc Espie) wrote:
In article <469d4...@neottia.net>,
Olivier Miakinen <om+n...@miakinen.net> wrote:
- soit malloc(0) echoue.
- soit malloc(0) reussit,[...]
Par contre, free(0) est parfaitement standard,
Pour reprendre l'éternelle discussion, voici un cas précis où il vaut
mieux écrire NULL, histoire de ne pas faire le rapprochement entre
malloc(0) [0 est un entier] et free(0) [0 est un pointeur]...
Tiens, c'est vrai. D'ailleurs, n'a-t-il pas existé des implémentatio ns
du langage C dans lesquelles NULL valait 0xFFFFFFFF ? Est-ce que ceci
est normalisé en C++ ?
Il a existé (et peut-être il en existe encore) des machines ou
un pointeur nul n'a pas tous ces bits à zéro. Mais il n'y a pas
de façon en C ou en C++ pour épeler un pointeur nul ; le
« null pointer constant » n'est pas un pointeur, nul ou
autrement. (Il y a une tolérance en C qui le permet d'être un
pointeur, mais c'est toujours un pointeur qui résulte de la
conversion d'un entier.) Le macro NULL doit s'évaluer non à un
pointeur nul, mais à un « null pointer constant » ; en C++,
un « null pointeur constant » est obligatoirement une
expression entière (non un pointeur !) constante dont la valeur
est 0.
Ceci est normalise en C comme en C++. La semantique du 0 est
la meme: il designe un pointeur nul dans un contexte ou on a
besoin d'un pointeur.
Il se convertit en pointeur nul. La sémantique du token 0 ne
change pas -- c'est une constante octale avec type int, et
valeur zéro.
Maintenant, un pointeur nul n'est pas
forcement represente par une suite d'octets ou tous les bits
sont a zero.
Pour ce qui est de NULL, c'est legerement different... La definition du
C++ est un peu plus contraignante, et ca en fait un pointeur nul
`interessant' (confere gcc, qui a un built-in __null precisement pour lui
donner exactement la bonne semantique).
Tous les NULL en C++ sont aussi légale en C. Dans les deux
langages, NULL doit être un « implementation defined null
pointer constant ». C-à-d en C++, une expression entière
constante dont la valeur est 0. (Le C permet également une telle
expression convertie explicitement en void*. Une innovation du
comité de normalisation C, qui n'était pas présente dans le C de
K&R.)
Un symbole tel que "__null" a un comportement indéfini. C-à-d
que le compilateur est libre de le définir comme il veut, s'il
veut. G++ (et gcc ?) le reconnaît comme une expression entière
dont la valeur est 0, donc comme un « null pointer constant ».
Mais il en profite pour avertir si cette expression particulière
n'est pas immédiatement converti en pointeur nul.
En C, ca se discute. C'est plus affaire de style qu'autre
chose. Comme NULL n'est pas garanti etre obligatoirement un
pointeur nul en C,
D'où est-ce que tu as ça ? La norme C et la norme C++ disent
exactement la même chose pour NULL : « [it] expands to an
implementation-defined null pointer constant ».
je prefere
personnellement un 0 tout seul, ca a l'avantage d'etre explicite (et
comme ca, on n'oublie pas le cast sur les fonctions varargs comme exec*(. ..))
(je trouve NULL sournois dans ses promesses non tenues).
C'est le problème de NULL. Le problème de 0, c'est qu'il donne
moins d'information au lecteur. Le vrai problème, évidemment,
c'est la manque d'une vraie façon de spécifier un pointeur nul.
(Lacun que le C++ va combler dans la prochaine version, je
crois.)
En C++, la definition de NULL fait que c'est marginalement
plus utile...
Je ne comprends pas, vue que la définition est la même dans les
deux languages. En C++, je dirais, la risque en ne pas étant
explicit est marginalement plus grand : il n'y a pas seulement
les varargs ; il y a aussi la façon que ça joue dans la
résolution des surcharges et les instantiations de templates.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
- soit malloc(0) echoue. - soit malloc(0) reussit,[...]
Par contre, free(0) est parfaitement standard,
Pour reprendre l'éternelle discussion, voici un cas précis où il vaut mieux écrire NULL, histoire de ne pas faire le rapprochement entre malloc(0) [0 est un entier] et free(0) [0 est un pointeur]...
Tiens, c'est vrai. D'ailleurs, n'a-t-il pas existé des implémentatio ns du langage C dans lesquelles NULL valait 0xFFFFFFFF ? Est-ce que ceci est normalisé en C++ ?
Il a existé (et peut-être il en existe encore) des machines ou un pointeur nul n'a pas tous ces bits à zéro. Mais il n'y a pas de façon en C ou en C++ pour épeler un pointeur nul ; le « null pointer constant » n'est pas un pointeur, nul ou autrement. (Il y a une tolérance en C qui le permet d'être un pointeur, mais c'est toujours un pointeur qui résulte de la conversion d'un entier.) Le macro NULL doit s'évaluer non à un pointeur nul, mais à un « null pointer constant » ; en C++, un « null pointeur constant » est obligatoirement une expression entière (non un pointeur !) constante dont la valeur est 0.
Ceci est normalise en C comme en C++. La semantique du 0 est la meme: il designe un pointeur nul dans un contexte ou on a besoin d'un pointeur.
Il se convertit en pointeur nul. La sémantique du token 0 ne change pas -- c'est une constante octale avec type int, et valeur zéro.
Maintenant, un pointeur nul n'est pas forcement represente par une suite d'octets ou tous les bits sont a zero.
Pour ce qui est de NULL, c'est legerement different... La definition du C++ est un peu plus contraignante, et ca en fait un pointeur nul `interessant' (confere gcc, qui a un built-in __null precisement pour lui donner exactement la bonne semantique).
Tous les NULL en C++ sont aussi légale en C. Dans les deux langages, NULL doit être un « implementation defined null pointer constant ». C-à-d en C++, une expression entière constante dont la valeur est 0. (Le C permet également une telle expression convertie explicitement en void*. Une innovation du comité de normalisation C, qui n'était pas présente dans le C de K&R.)
Un symbole tel que "__null" a un comportement indéfini. C-à-d que le compilateur est libre de le définir comme il veut, s'il veut. G++ (et gcc ?) le reconnaît comme une expression entière dont la valeur est 0, donc comme un « null pointer constant ». Mais il en profite pour avertir si cette expression particulière n'est pas immédiatement converti en pointeur nul.
En C, ca se discute. C'est plus affaire de style qu'autre chose. Comme NULL n'est pas garanti etre obligatoirement un pointeur nul en C,
D'où est-ce que tu as ça ? La norme C et la norme C++ disent exactement la même chose pour NULL : « [it] expands to an implementation-defined null pointer constant ».
je prefere personnellement un 0 tout seul, ca a l'avantage d'etre explicite (et comme ca, on n'oublie pas le cast sur les fonctions varargs comme exec*(. ..)) (je trouve NULL sournois dans ses promesses non tenues).
C'est le problème de NULL. Le problème de 0, c'est qu'il donne moins d'information au lecteur. Le vrai problème, évidemment, c'est la manque d'une vraie façon de spécifier un pointeur nul. (Lacun que le C++ va combler dans la prochaine version, je crois.)
En C++, la definition de NULL fait que c'est marginalement plus utile...
Je ne comprends pas, vue que la définition est la même dans les deux languages. En C++, je dirais, la risque en ne pas étant explicit est marginalement plus grand : il n'y a pas seulement les varargs ; il y a aussi la façon que ça joue dans la résolution des surcharges et les instantiations de templates.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
