Anthony Fleury wrote:Le C++ définit ce qu'est un "null pointer constant", et il
le définit comme étant une valeur entière constante
comparée égale à 0. Donc une bonne définition de NULL en
C++ est celle donnée en dessous. (4.10 dans la norme)
Sauf que l'utilisateur n'a pas le droit de le faire, dès
qu'il a inclu un parmi un certain nombre d'en-têtes.
Ca ne me paraissait pas trivial dans la norme. En fait, la
définition apparait dans des en-tête qui sont à un moment
appelés "C++ Headers for C Library Facilities" [ les cstddef &
co ] J'ai toujours considéré ces headers comme étant fait
simplement pour la compatibilité avec le C. Mais apparement
c'est bien plus. Quel est leur statut ??
D'ailleurs, j'ai commencé le C++ en lisant TC++PL, et il y est
explicitement dit :
"En langage C, il arrivait fréquemment qu'une macro NULL soit définie
pour représenter le pointeur 0. En C++, un contrôle de type plus sérieux
rend moins problématique l'utilisation du 0 normal, plutôt que de toute
macro NULL. Le nombre de problèmes est ainsi considérablement réduit. Si
vous pensez devoir définir NULL, utilisez
const int NULL = 0;
Le qualificatif const (§5.4) évite toute redéfinition accidentelle de
NULL et permet l'utilisation dans tous les cas où une constante est
requise. "
N'est ce dont pas une grosse erreur dans TC++PL ?
[ En fait, d'après la norme et le paragraphe en question,
on peut mettre const int NULL = 0; ou const int NULL = 0L;
si j'ai tout bien compris ].
Selon la norme, NULL doit être 1) un macro, 2) défini dans
des en-têtes standard, et 3) évalué à une constante de
pointeur nul (qui malgré son nom, doit avoir un type entier,
et non un type pointeur).
Comme dit plus haut, comme cette définition n'apparaissait que
dans les en-tête <cX> avec X un nom d'en-tête C, je pensais
pas que le fait que ce soit une macro était obligatoire en
C++. Pour moi la norme du C++ ne définissait pas NULL.
est interdite du fait que la conversion de void* -> T*
doit être explicitement demandée, tout utilisateur de
malloc() & co en C++ l'aura remarqué.
Je ne comprends pas trop ta phrase, ni son rapport avec NULL.
Sauf en ce qui concerne les formes permises, la définition de
NULL et des constantes de pointeur nul est identique en C et
en C++.
Ce que je voulais dire, c'est que certains compilateurs C
définissent NULL comme (void*)0. (ca fait même l'objet d'une
note dans la norme C++). Et cette forme est interdite en C++,
qui a des règles de conversions plus fortes sur ce point que
le C.
En effet, le code :
#include <stdlib.h>
int main(void) {
int *a = malloc(sizeof *a);
free(a);
return 0;
}
est valable en C mais pas en C++. Le C++ requiert un cast
explicite pour caster void* -> T* que ne requiert pas le C.
Deux choses :
- d'une part en C++ je pense qu'il est préférable de
mettre 0 partout. (c'est une question de gout, un long
débat sur les groupes anglophones, et ca fait aussi une
ligne dans TC++PL)
Ça dépend de ton style de programmation et du compilateur
dont tu te sers. Fais-toi la règle que si le code ne se
compile pas avec g++ sans avertissements, il est incorrect,
et NULL n'a que des avantages par rapport à zéro.
Pour ma part j'ai pris l'habitude en C++ d'utiliser 0, mais
c'est vrai que NULL peut être plus lisible. Ca dépend en effet
du style de programmation. [ pour ma part comme dit plus haut
ca a surtout été conditionné par la lecture de TC++PL, et ca
fait une différence par rapport au C où j'utilise tout le
temps NULL. ]
- Cette version devrait compiler sans problème et sans
warning.
Ça dépend de ce qu'il a inclu avant. Si après l'expansion du
macro, le compilateur voit :
const int 0 = 0 ;
il risque de ne pas être content. Je ne crois pas que ça
explique le comportement qu'il a vu, mais il reste que sa
déclaration donne un comportement indéfini dès qu'il inclut
certains en-têtes.
En effet ca n'explique pas son problème car cette ligne
provoquerait une erreur de syntaxe, car en gros il trouve un
entier là où un identifiant est attendu. C'est donc
incorrecte. Mais en effet après inclusion de certains en-tête,
cette définition de NULL poserait des problèmes. Je ne savais
par contre pas que ca provoquait un comportement indéfinit de
redéfinir NULL.
Sans voir le contexte complet de ton problème, c'est
difficile à dire. La solution préférée, c'est d'inclure
<stddef.h> en tête, et de se servir du NULL défini là (ou de
s'en passer complètement, et écrire 0 -- selon le
compilateur, ton style de programmation, et les conventions
en vigueur où tu travailles).
Et en entreprise ca doit aussi dépendre du style de la boîte
non ? dans la coordination d'un projet ca doit faire partie
des styles de programmation qui sont définis je suppose ?
Anthony Fleury wrote:
Le C++ définit ce qu'est un "null pointer constant", et il
le définit comme étant une valeur entière constante
comparée égale à 0. Donc une bonne définition de NULL en
C++ est celle donnée en dessous. (4.10 dans la norme)
Sauf que l'utilisateur n'a pas le droit de le faire, dès
qu'il a inclu un parmi un certain nombre d'en-têtes.
Ca ne me paraissait pas trivial dans la norme. En fait, la
définition apparait dans des en-tête qui sont à un moment
appelés "C++ Headers for C Library Facilities" [ les cstddef &
co ] J'ai toujours considéré ces headers comme étant fait
simplement pour la compatibilité avec le C. Mais apparement
c'est bien plus. Quel est leur statut ??
D'ailleurs, j'ai commencé le C++ en lisant TC++PL, et il y est
explicitement dit :
"En langage C, il arrivait fréquemment qu'une macro NULL soit définie
pour représenter le pointeur 0. En C++, un contrôle de type plus sérieux
rend moins problématique l'utilisation du 0 normal, plutôt que de toute
macro NULL. Le nombre de problèmes est ainsi considérablement réduit. Si
vous pensez devoir définir NULL, utilisez
const int NULL = 0;
Le qualificatif const (§5.4) évite toute redéfinition accidentelle de
NULL et permet l'utilisation dans tous les cas où une constante est
requise. "
N'est ce dont pas une grosse erreur dans TC++PL ?
[ En fait, d'après la norme et le paragraphe en question,
on peut mettre const int NULL = 0; ou const int NULL = 0L;
si j'ai tout bien compris ].
Selon la norme, NULL doit être 1) un macro, 2) défini dans
des en-têtes standard, et 3) évalué à une constante de
pointeur nul (qui malgré son nom, doit avoir un type entier,
et non un type pointeur).
Comme dit plus haut, comme cette définition n'apparaissait que
dans les en-tête <cX> avec X un nom d'en-tête C, je pensais
pas que le fait que ce soit une macro était obligatoire en
C++. Pour moi la norme du C++ ne définissait pas NULL.
est interdite du fait que la conversion de void* -> T*
doit être explicitement demandée, tout utilisateur de
malloc() & co en C++ l'aura remarqué.
Je ne comprends pas trop ta phrase, ni son rapport avec NULL.
Sauf en ce qui concerne les formes permises, la définition de
NULL et des constantes de pointeur nul est identique en C et
en C++.
Ce que je voulais dire, c'est que certains compilateurs C
définissent NULL comme (void*)0. (ca fait même l'objet d'une
note dans la norme C++). Et cette forme est interdite en C++,
qui a des règles de conversions plus fortes sur ce point que
le C.
En effet, le code :
#include <stdlib.h>
int main(void) {
int *a = malloc(sizeof *a);
free(a);
return 0;
}
est valable en C mais pas en C++. Le C++ requiert un cast
explicite pour caster void* -> T* que ne requiert pas le C.
Deux choses :
- d'une part en C++ je pense qu'il est préférable de
mettre 0 partout. (c'est une question de gout, un long
débat sur les groupes anglophones, et ca fait aussi une
ligne dans TC++PL)
Ça dépend de ton style de programmation et du compilateur
dont tu te sers. Fais-toi la règle que si le code ne se
compile pas avec g++ sans avertissements, il est incorrect,
et NULL n'a que des avantages par rapport à zéro.
Pour ma part j'ai pris l'habitude en C++ d'utiliser 0, mais
c'est vrai que NULL peut être plus lisible. Ca dépend en effet
du style de programmation. [ pour ma part comme dit plus haut
ca a surtout été conditionné par la lecture de TC++PL, et ca
fait une différence par rapport au C où j'utilise tout le
temps NULL. ]
- Cette version devrait compiler sans problème et sans
warning.
Ça dépend de ce qu'il a inclu avant. Si après l'expansion du
macro, le compilateur voit :
const int 0 = 0 ;
il risque de ne pas être content. Je ne crois pas que ça
explique le comportement qu'il a vu, mais il reste que sa
déclaration donne un comportement indéfini dès qu'il inclut
certains en-têtes.
En effet ca n'explique pas son problème car cette ligne
provoquerait une erreur de syntaxe, car en gros il trouve un
entier là où un identifiant est attendu. C'est donc
incorrecte. Mais en effet après inclusion de certains en-tête,
cette définition de NULL poserait des problèmes. Je ne savais
par contre pas que ca provoquait un comportement indéfinit de
redéfinir NULL.
Sans voir le contexte complet de ton problème, c'est
difficile à dire. La solution préférée, c'est d'inclure
<stddef.h> en tête, et de se servir du NULL défini là (ou de
s'en passer complètement, et écrire 0 -- selon le
compilateur, ton style de programmation, et les conventions
en vigueur où tu travailles).
Et en entreprise ca doit aussi dépendre du style de la boîte
non ? dans la coordination d'un projet ca doit faire partie
des styles de programmation qui sont définis je suppose ?
Anthony Fleury wrote:Le C++ définit ce qu'est un "null pointer constant", et il
le définit comme étant une valeur entière constante
comparée égale à 0. Donc une bonne définition de NULL en
C++ est celle donnée en dessous. (4.10 dans la norme)
Sauf que l'utilisateur n'a pas le droit de le faire, dès
qu'il a inclu un parmi un certain nombre d'en-têtes.
Ca ne me paraissait pas trivial dans la norme. En fait, la
définition apparait dans des en-tête qui sont à un moment
appelés "C++ Headers for C Library Facilities" [ les cstddef &
co ] J'ai toujours considéré ces headers comme étant fait
simplement pour la compatibilité avec le C. Mais apparement
c'est bien plus. Quel est leur statut ??
D'ailleurs, j'ai commencé le C++ en lisant TC++PL, et il y est
explicitement dit :
"En langage C, il arrivait fréquemment qu'une macro NULL soit définie
pour représenter le pointeur 0. En C++, un contrôle de type plus sérieux
rend moins problématique l'utilisation du 0 normal, plutôt que de toute
macro NULL. Le nombre de problèmes est ainsi considérablement réduit. Si
vous pensez devoir définir NULL, utilisez
const int NULL = 0;
Le qualificatif const (§5.4) évite toute redéfinition accidentelle de
NULL et permet l'utilisation dans tous les cas où une constante est
requise. "
N'est ce dont pas une grosse erreur dans TC++PL ?
[ En fait, d'après la norme et le paragraphe en question,
on peut mettre const int NULL = 0; ou const int NULL = 0L;
si j'ai tout bien compris ].
Selon la norme, NULL doit être 1) un macro, 2) défini dans
des en-têtes standard, et 3) évalué à une constante de
pointeur nul (qui malgré son nom, doit avoir un type entier,
et non un type pointeur).
Comme dit plus haut, comme cette définition n'apparaissait que
dans les en-tête <cX> avec X un nom d'en-tête C, je pensais
pas que le fait que ce soit une macro était obligatoire en
C++. Pour moi la norme du C++ ne définissait pas NULL.
est interdite du fait que la conversion de void* -> T*
doit être explicitement demandée, tout utilisateur de
malloc() & co en C++ l'aura remarqué.
Je ne comprends pas trop ta phrase, ni son rapport avec NULL.
Sauf en ce qui concerne les formes permises, la définition de
NULL et des constantes de pointeur nul est identique en C et
en C++.
Ce que je voulais dire, c'est que certains compilateurs C
définissent NULL comme (void*)0. (ca fait même l'objet d'une
note dans la norme C++). Et cette forme est interdite en C++,
qui a des règles de conversions plus fortes sur ce point que
le C.
En effet, le code :
#include <stdlib.h>
int main(void) {
int *a = malloc(sizeof *a);
free(a);
return 0;
}
est valable en C mais pas en C++. Le C++ requiert un cast
explicite pour caster void* -> T* que ne requiert pas le C.
Deux choses :
- d'une part en C++ je pense qu'il est préférable de
mettre 0 partout. (c'est une question de gout, un long
débat sur les groupes anglophones, et ca fait aussi une
ligne dans TC++PL)
Ça dépend de ton style de programmation et du compilateur
dont tu te sers. Fais-toi la règle que si le code ne se
compile pas avec g++ sans avertissements, il est incorrect,
et NULL n'a que des avantages par rapport à zéro.
Pour ma part j'ai pris l'habitude en C++ d'utiliser 0, mais
c'est vrai que NULL peut être plus lisible. Ca dépend en effet
du style de programmation. [ pour ma part comme dit plus haut
ca a surtout été conditionné par la lecture de TC++PL, et ca
fait une différence par rapport au C où j'utilise tout le
temps NULL. ]
- Cette version devrait compiler sans problème et sans
warning.
Ça dépend de ce qu'il a inclu avant. Si après l'expansion du
macro, le compilateur voit :
const int 0 = 0 ;
il risque de ne pas être content. Je ne crois pas que ça
explique le comportement qu'il a vu, mais il reste que sa
déclaration donne un comportement indéfini dès qu'il inclut
certains en-têtes.
En effet ca n'explique pas son problème car cette ligne
provoquerait une erreur de syntaxe, car en gros il trouve un
entier là où un identifiant est attendu. C'est donc
incorrecte. Mais en effet après inclusion de certains en-tête,
cette définition de NULL poserait des problèmes. Je ne savais
par contre pas que ca provoquait un comportement indéfinit de
redéfinir NULL.
Sans voir le contexte complet de ton problème, c'est
difficile à dire. La solution préférée, c'est d'inclure
<stddef.h> en tête, et de se servir du NULL défini là (ou de
s'en passer complètement, et écrire 0 -- selon le
compilateur, ton style de programmation, et les conventions
en vigueur où tu travailles).
Et en entreprise ca doit aussi dépendre du style de la boîte
non ? dans la coordination d'un projet ca doit faire partie
des styles de programmation qui sont définis je suppose ?
"En langage C, il arrivait fréquemment qu'une macro NULL soit
définie pour représenter le pointeur 0. En C++, un contrôle de
type plus sérieux rend moins problématique l'utilisation du 0
normal, plutôt que de toute macro NULL. Le nombre de problèmes
est ainsi considérablement réduit. Si vous pensez devoir
définir NULL, utilisez
const int NULL = 0;
Le qualificatif const (§5.4) évite toute redéfinition
accidentelle de NULL et permet l'utilisation dans tous les cas
où une constante est requise. "
N'est ce dont pas une grosse erreur dans TC++PL ?
Non, tout est dans le "Si vous pensez devoir définir", qui
suppose que l'on veut se passer des entêtes et définir NULL
soi-même.
"En langage C, il arrivait fréquemment qu'une macro NULL soit
définie pour représenter le pointeur 0. En C++, un contrôle de
type plus sérieux rend moins problématique l'utilisation du 0
normal, plutôt que de toute macro NULL. Le nombre de problèmes
est ainsi considérablement réduit. Si vous pensez devoir
définir NULL, utilisez
const int NULL = 0;
Le qualificatif const (§5.4) évite toute redéfinition
accidentelle de NULL et permet l'utilisation dans tous les cas
où une constante est requise. "
N'est ce dont pas une grosse erreur dans TC++PL ?
Non, tout est dans le "Si vous pensez devoir définir", qui
suppose que l'on veut se passer des entêtes et définir NULL
soi-même.
"En langage C, il arrivait fréquemment qu'une macro NULL soit
définie pour représenter le pointeur 0. En C++, un contrôle de
type plus sérieux rend moins problématique l'utilisation du 0
normal, plutôt que de toute macro NULL. Le nombre de problèmes
est ainsi considérablement réduit. Si vous pensez devoir
définir NULL, utilisez
const int NULL = 0;
Le qualificatif const (§5.4) évite toute redéfinition
accidentelle de NULL et permet l'utilisation dans tous les cas
où une constante est requise. "
N'est ce dont pas une grosse erreur dans TC++PL ?
Non, tout est dans le "Si vous pensez devoir définir", qui
suppose que l'on veut se passer des entêtes et définir NULL
soi-même.
PS: je viens de JAVA et cela me choque :(
Sauf qu'en Java, le mot-clé null n'a rien à voir avec les
pointeurs, et pour cause : il n'y a pas de pointeur en Java,
mais des /références/ sur des objets. Et le mot-clé null sert
en Java à dire qu'une variable ne fait référence à aucun
objet.
PS: je viens de JAVA et cela me choque :(
Sauf qu'en Java, le mot-clé null n'a rien à voir avec les
pointeurs, et pour cause : il n'y a pas de pointeur en Java,
mais des /références/ sur des objets. Et le mot-clé null sert
en Java à dire qu'une variable ne fait référence à aucun
objet.
PS: je viens de JAVA et cela me choque :(
Sauf qu'en Java, le mot-clé null n'a rien à voir avec les
pointeurs, et pour cause : il n'y a pas de pointeur en Java,
mais des /références/ sur des objets. Et le mot-clé null sert
en Java à dire qu'une variable ne fait référence à aucun
objet.
-- Les pointeurs de Java ne sont pas des objets en soi -- en ne
peut pas en prendre l'adresse, par exemple.
-- Le Java ne supporte pas l'arithmétique sur des pointeurs.
-- Les pointeurs de Java ne sont pas des objets en soi -- en ne
peut pas en prendre l'adresse, par exemple.
-- Le Java ne supporte pas l'arithmétique sur des pointeurs.
-- Les pointeurs de Java ne sont pas des objets en soi -- en ne
peut pas en prendre l'adresse, par exemple.
-- Le Java ne supporte pas l'arithmétique sur des pointeurs.
C'est ce qu'on appelle "référence" en C++, non ?
--
Le grand site de la philosophie animale :
<http://perso.edulang.com/philo/>
C'est ce qu'on appelle "référence" en C++, non ?
--
Le grand site de la philosophie animale :
<http://perso.edulang.com/philo/>
C'est ce qu'on appelle "référence" en C++, non ?
--
Le grand site de la philosophie animale :
<http://perso.edulang.com/philo/>
C'est ce qu'on appelle "référence" en C++, non ?
pas vraiment puisqu'en java il faut appeler new pour créer une variable...
C'est ce qu'on appelle "référence" en C++, non ?
pas vraiment puisqu'en java il faut appeler new pour créer une variable...
C'est ce qu'on appelle "référence" en C++, non ?
pas vraiment puisqu'en java il faut appeler new pour créer une variable...
Bon, on va dire que la notion de pointeur en Java est à mi-chemin
entre les pointeurs et les références en C++ ;-)
Bon, on va dire que la notion de pointeur en Java est à mi-chemin
entre les pointeurs et les références en C++ ;-)
Bon, on va dire que la notion de pointeur en Java est à mi-chemin
entre les pointeurs et les références en C++ ;-)
est-ce qu'on pourrait écrire un glaneur de cellules en Java ?
est-ce qu'on pourrait écrire un glaneur de cellules en Java ?
est-ce qu'on pourrait écrire un glaneur de cellules en Java ?
"Java est Turing-complete"
"Java est Turing-complete"
"Java est Turing-complete"
Anthony Fleury wrote:Anthony Fleury wrote:
Ca ne me paraissait pas trivial dans la norme. En fait, la
définition apparait dans des en-tête qui sont à un moment
appelés "C++ Headers for C Library Facilities" [ les cstddef &
co ] J'ai toujours considéré ces headers comme étant fait
simplement pour la compatibilité avec le C. Mais apparement
c'est bien plus. Quel est leur statut ??
Les en-têtes du genre <cstddef> font partie de la norme, à même
titre de <ostream> ou <vector>. Si pour certains, comme
<cstdio>, on préfèrerait les fonctionalités pûrement C++,
définies dans <istream>, <ostream>, etc., pour d'autres, comme
<ctime>, il n'existe pas d'alternatif. En tout cas, ils font
tous partie integrante de C++.
On en a déjà parlé ici, il me semble. En tout cas, le conseil
d'utiliser « const int NULL = 0 » ne peut être qu'une erreur,
étant donné que c'est illégal.
N'est ce dont pas une grosse erreur dans TC++PL ?
Il y a deux partie de l'énoncé. Le conseil de définir soi-même
NULL est une grosse erreur, certainement. Le conseil de préférer
0, en revanche, relève de l'opinion personnelle ; on peut
regretter que Stroustrup n'a pas présenté d'autres avis aussi,
mais on ne peut pas lui nier le droit à son opinion.
Comme dit plus haut, comme cette définition n'apparaissait que
dans les en-tête <cX> avec X un nom d'en-tête C, je pensais
pas que le fait que ce soit une macro était obligatoire en
C++. Pour moi la norme du C++ ne définissait pas NULL.
Et qu'en fais-tu de §18.1 ?
Alors, dans la pratique, si tu inclus un en-tête de
la STL, tu as de fortes chances d'avoir aussi la définition
officielle de NULL.
Ce que je voulais dire, c'est que certains compilateurs C
définissent NULL comme (void*)0. (ca fait même l'objet d'une
note dans la norme C++). Et cette forme est interdite en C++,
qui a des règles de conversions plus fortes sur ce point que
le C.
Les règles de conversions sont effectivement différentes dans
les deux langages. Mais pas en ce qui concerne les conversions
d'une « null pointer constant », et donc pas en ce qui concerne
NULL. (Le C donne une liberté de plus en ce qui est une
constante de pointeur nul, mais ça ne joue en rien ici -- il y a
dans les deux langages une conversion très spéciale en ce qui
concerne des constantes de pointeur nul.)
Je crois qu'il y a un consensus pour dire que cette situation
est lamentable, ou au moins, moins d'idéale. Pas, en revanche,
sur ce qu'il faut faire en consequence. (Je crois qu'il y a une
proposition devant le gremium C++ pour une véritable solution --
Gaby pourrait peut-être en donner plus de détails. Je serais
pour, ne serait-ce que pour arrêter toutes ces discussions
interminables:-).)
Personnellement, et ça n'engage que moi, je trouve qu'on
pourrait bien introduire une catégorie supplémentaire des
erreurs, entre un comportement indéfini et un diagnostique
obligatoire, qui délimite les dégats possibles à la phase de
compilation -- si le compilateur ne râle pas, ça doit marcher.
Parce que ce genre de cas n'est pas rare dans la norme. (Mais ce
n'est pas si évident que ça -- si ensuite d'une inclusion
« cachée » d'un en-tête, tu vois plus ou moins d'un ensemble de
fonctions surchargées, la résolution du surcharge peut bien être
différente, sans pour autant provoquer une erreur de
compilation.)
Tout à fait. Encore que je dois dire que chaque fois que j'ai vu
oùla question s'est posée, la décision s'est faite pour NULL,
plutôt que 0.
Anthony Fleury wrote:
Anthony Fleury wrote:
Ca ne me paraissait pas trivial dans la norme. En fait, la
définition apparait dans des en-tête qui sont à un moment
appelés "C++ Headers for C Library Facilities" [ les cstddef &
co ] J'ai toujours considéré ces headers comme étant fait
simplement pour la compatibilité avec le C. Mais apparement
c'est bien plus. Quel est leur statut ??
Les en-têtes du genre <cstddef> font partie de la norme, à même
titre de <ostream> ou <vector>. Si pour certains, comme
<cstdio>, on préfèrerait les fonctionalités pûrement C++,
définies dans <istream>, <ostream>, etc., pour d'autres, comme
<ctime>, il n'existe pas d'alternatif. En tout cas, ils font
tous partie integrante de C++.
On en a déjà parlé ici, il me semble. En tout cas, le conseil
d'utiliser « const int NULL = 0 » ne peut être qu'une erreur,
étant donné que c'est illégal.
N'est ce dont pas une grosse erreur dans TC++PL ?
Il y a deux partie de l'énoncé. Le conseil de définir soi-même
NULL est une grosse erreur, certainement. Le conseil de préférer
0, en revanche, relève de l'opinion personnelle ; on peut
regretter que Stroustrup n'a pas présenté d'autres avis aussi,
mais on ne peut pas lui nier le droit à son opinion.
Comme dit plus haut, comme cette définition n'apparaissait que
dans les en-tête <cX> avec X un nom d'en-tête C, je pensais
pas que le fait que ce soit une macro était obligatoire en
C++. Pour moi la norme du C++ ne définissait pas NULL.
Et qu'en fais-tu de §18.1 ?
Alors, dans la pratique, si tu inclus un en-tête de
la STL, tu as de fortes chances d'avoir aussi la définition
officielle de NULL.
Ce que je voulais dire, c'est que certains compilateurs C
définissent NULL comme (void*)0. (ca fait même l'objet d'une
note dans la norme C++). Et cette forme est interdite en C++,
qui a des règles de conversions plus fortes sur ce point que
le C.
Les règles de conversions sont effectivement différentes dans
les deux langages. Mais pas en ce qui concerne les conversions
d'une « null pointer constant », et donc pas en ce qui concerne
NULL. (Le C donne une liberté de plus en ce qui est une
constante de pointeur nul, mais ça ne joue en rien ici -- il y a
dans les deux langages une conversion très spéciale en ce qui
concerne des constantes de pointeur nul.)
Je crois qu'il y a un consensus pour dire que cette situation
est lamentable, ou au moins, moins d'idéale. Pas, en revanche,
sur ce qu'il faut faire en consequence. (Je crois qu'il y a une
proposition devant le gremium C++ pour une véritable solution --
Gaby pourrait peut-être en donner plus de détails. Je serais
pour, ne serait-ce que pour arrêter toutes ces discussions
interminables:-).)
Personnellement, et ça n'engage que moi, je trouve qu'on
pourrait bien introduire une catégorie supplémentaire des
erreurs, entre un comportement indéfini et un diagnostique
obligatoire, qui délimite les dégats possibles à la phase de
compilation -- si le compilateur ne râle pas, ça doit marcher.
Parce que ce genre de cas n'est pas rare dans la norme. (Mais ce
n'est pas si évident que ça -- si ensuite d'une inclusion
« cachée » d'un en-tête, tu vois plus ou moins d'un ensemble de
fonctions surchargées, la résolution du surcharge peut bien être
différente, sans pour autant provoquer une erreur de
compilation.)
Tout à fait. Encore que je dois dire que chaque fois que j'ai vu
oùla question s'est posée, la décision s'est faite pour NULL,
plutôt que 0.
Anthony Fleury wrote:Anthony Fleury wrote:
Ca ne me paraissait pas trivial dans la norme. En fait, la
définition apparait dans des en-tête qui sont à un moment
appelés "C++ Headers for C Library Facilities" [ les cstddef &
co ] J'ai toujours considéré ces headers comme étant fait
simplement pour la compatibilité avec le C. Mais apparement
c'est bien plus. Quel est leur statut ??
Les en-têtes du genre <cstddef> font partie de la norme, à même
titre de <ostream> ou <vector>. Si pour certains, comme
<cstdio>, on préfèrerait les fonctionalités pûrement C++,
définies dans <istream>, <ostream>, etc., pour d'autres, comme
<ctime>, il n'existe pas d'alternatif. En tout cas, ils font
tous partie integrante de C++.
On en a déjà parlé ici, il me semble. En tout cas, le conseil
d'utiliser « const int NULL = 0 » ne peut être qu'une erreur,
étant donné que c'est illégal.
N'est ce dont pas une grosse erreur dans TC++PL ?
Il y a deux partie de l'énoncé. Le conseil de définir soi-même
NULL est une grosse erreur, certainement. Le conseil de préférer
0, en revanche, relève de l'opinion personnelle ; on peut
regretter que Stroustrup n'a pas présenté d'autres avis aussi,
mais on ne peut pas lui nier le droit à son opinion.
Comme dit plus haut, comme cette définition n'apparaissait que
dans les en-tête <cX> avec X un nom d'en-tête C, je pensais
pas que le fait que ce soit une macro était obligatoire en
C++. Pour moi la norme du C++ ne définissait pas NULL.
Et qu'en fais-tu de §18.1 ?
Alors, dans la pratique, si tu inclus un en-tête de
la STL, tu as de fortes chances d'avoir aussi la définition
officielle de NULL.
Ce que je voulais dire, c'est que certains compilateurs C
définissent NULL comme (void*)0. (ca fait même l'objet d'une
note dans la norme C++). Et cette forme est interdite en C++,
qui a des règles de conversions plus fortes sur ce point que
le C.
Les règles de conversions sont effectivement différentes dans
les deux langages. Mais pas en ce qui concerne les conversions
d'une « null pointer constant », et donc pas en ce qui concerne
NULL. (Le C donne une liberté de plus en ce qui est une
constante de pointeur nul, mais ça ne joue en rien ici -- il y a
dans les deux langages une conversion très spéciale en ce qui
concerne des constantes de pointeur nul.)
Je crois qu'il y a un consensus pour dire que cette situation
est lamentable, ou au moins, moins d'idéale. Pas, en revanche,
sur ce qu'il faut faire en consequence. (Je crois qu'il y a une
proposition devant le gremium C++ pour une véritable solution --
Gaby pourrait peut-être en donner plus de détails. Je serais
pour, ne serait-ce que pour arrêter toutes ces discussions
interminables:-).)
Personnellement, et ça n'engage que moi, je trouve qu'on
pourrait bien introduire une catégorie supplémentaire des
erreurs, entre un comportement indéfini et un diagnostique
obligatoire, qui délimite les dégats possibles à la phase de
compilation -- si le compilateur ne râle pas, ça doit marcher.
Parce que ce genre de cas n'est pas rare dans la norme. (Mais ce
n'est pas si évident que ça -- si ensuite d'une inclusion
« cachée » d'un en-tête, tu vois plus ou moins d'un ensemble de
fonctions surchargées, la résolution du surcharge peut bien être
différente, sans pour autant provoquer une erreur de
compilation.)
Tout à fait. Encore que je dois dire que chaque fois que j'ai vu
oùla question s'est posée, la décision s'est faite pour NULL,
plutôt que 0.
