const int NULL = 0

Jean-Marc Bourguet <jm@bourguet.org> writes:

[...]

| If you feel you must define _NULL_, use
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| const int NULL = 0;
|
| The _const_ qualifier (5.4) prevents accidental redefinition of _NULL_
| and ensures that _NULL_ can be used where a constant is required.
|
|
| B.S. ne suggere pas que ceux qui utilisent NULL le definissent, mais
| que ceux qui le definissent le fassent comme indique. Perso j'aurais
| quand meme signale que ca pose un probleme des qu'on inclu un entete
| standard.

OK, mais quand il dit « if you feel you must », tu crois que c'est
sans danger ?

Je veux dire, c'est quand même pas un écrit de James, c'est du BS.

-- Gaby

Gabriel Dos Reis <gdr@cs.tamu.edu> writes:

Jean-Marc Bourguet <jm@bourguet.org> writes:

[...]

| If you feel you must define _NULL_, use
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| const int NULL = 0;
|
| The _const_ qualifier (5.4) prevents accidental redefinition of _NULL_
| and ensures that _NULL_ can be used where a constant is required.
|
|
| B.S. ne suggere pas que ceux qui utilisent NULL le definissent,
| mais que ceux qui le definissent le fassent comme indique. Perso
| j'aurais quand meme signale que ca pose un probleme des qu'on
| inclu un entete standard.

OK, mais quand il dit « if you feel you must », tu crois que c'est
sans danger ?

La formulation de BS est beaucoup moins forte que ce que l'OP a ecrit
("Il indique également pour ceux qui voudraient continuer à utiliser
NULL d'en faire la déclaration suivante") mais il laisse quand meme
l'impression que definir NULL est quelque chose de fait generalement
par l'utilisateur et qu'il le deconseille parce que NULL cause des
problemes. Je ne vois pas de bonne raison de definir soi-meme NULL,
meme s'il est possible de le faire en restant conforme. En fait le
seul cas ou je me sentirais l'obligation de le definir, c'est si je me
retrouvais implementeur de la bibliotheque standard. Et alors je ne
suivrais pas le conseil de BS. Hors ce cas, quand on utilise NULL on
inclu cstddef, cstring, ctime, clocale, cstdio ou cwchar (tiens, il
manque clocale dans la table 95, j'ai pas ete voir si c'est deja
corrige).

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Jean-Marc Bourguet <jm@bourguet.org> writes:

| Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|
| > Jean-Marc Bourguet <jm@bourguet.org> writes:
| >
| > [...]
| >
| > | If you feel you must define _NULL_, use
| > ^^^^^^^^^^^^^^^^^^^^^^^^^^^
| > |
| > | const int NULL = 0;
| > |
| > | The _const_ qualifier (5.4) prevents accidental redefinition of _NULL_
| > | and ensures that _NULL_ can be used where a constant is required.
| > |
| > |
| > | B.S. ne suggere pas que ceux qui utilisent NULL le definissent,
| > | mais que ceux qui le definissent le fassent comme indique. Perso
| > | j'aurais quand meme signale que ca pose un probleme des qu'on
| > | inclu un entete standard.
| >
| > OK, mais quand il dit « if you feel you must », tu crois que c'est
| > sans danger ?
|
| La formulation de BS est beaucoup moins forte que ce que l'OP a ecrit
| ("Il indique également pour ceux qui voudraient continuer à utiliser
| NULL d'en faire la déclaration suivante") mais il laisse quand meme
| l'impression que definir NULL est quelque chose de fait generalement
| par l'utilisateur et qu'il le deconseille parce que NULL cause des
| problemes. Je ne vois pas de bonne raison de definir soi-meme NULL,
| meme s'il est possible de le faire en restant conforme. En fait le
| seul cas ou je me sentirais l'obligation de le definir, c'est si je me
| retrouvais implementeur de la bibliotheque standard. Et alors je ne

C'est justement là le point crucial : si tu te retrouves implémenteur
de la bibliothèque standard, tu ne vas pas lire TC++PL3 pour savoir la
sémantique du langage :-). En d'autres termes, TC++PL3 s'adresse au
programmeur C++ (et non l'implémenteur C++), et il y a virtuellement
peu d'occasions où « if you feel you must » se justifie.

| suivrais pas le conseil de BS. Hors ce cas, quand on utilise NULL on
| inclu cstddef, cstring, ctime, clocale, cstdio ou cwchar (tiens, il
| manque clocale dans la table 95, j'ai pas ete voir si c'est deja
| corrige).


-- Gaby

Gabriel Dos Reis wrote:

Jean-Marc Bourguet <jm@bourguet.org> writes:

[...]

| If you feel you must define _NULL_, use
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| const int NULL = 0;
|
| The _const_ qualifier (5.4) prevents accidental redefinition of _NULL_
| and ensures that _NULL_ can be used where a constant is required.
|
|
| B.S. ne suggere pas que ceux qui utilisent NULL le definissent, mais
| que ceux qui le definissent le fassent comme indique. Perso j'aurais
| quand meme signale que ca pose un probleme des qu'on inclu un entete
| standard.

OK, mais quand il dit « if you feel you must », tu crois que c'est
sans danger ?

J'ai l'impression que le mot intéressant est celui juste après la
citation : "If you feel you must _define_".

Ce qui aurait pu être intéressant, pour le débat en cours, c'est ce
qu'il aurait marqué après un : "If you still want to _use_ NULL, ....".

--
Loïc

Gabriel Dos Reis wrote:

kanze@gabi-soft.fr writes:

| Mais l'« intérêt principal » du const, ici ou ailleurs,
| c'est d'empècher qu'on y écrit. Si le but n'était que de
| s'assurer d'un linkage interne, il existe le mot clé static.

C'est là la règle idiote : celle qui consiste à surcharger «
static »

avec la signification que le linkage est interne.

Je n'ai jamais dit que le surcharge de la signification de const
ici était la seule règle idiote dans le C++. Quand on part de C,
on a bien fait le choix du départ de vivre avec un certain
nombre de règles idiotes.

« static » dès le début a toujours voulu dire « au plus une
seule instance dans le programme »,

Ça serait la signification logique, basée sur la signification
du mot anglais.

et non un linkage interne.

Il faut aller bien en arrière pour trouver un époque où static
n'avait pas la signification d'un linkage interne en C. Avant
que j'aie commencé le C, au moins. Avant que Kernighan et Richie
ait publié leur livre.

C++ a maintenu cette signification et étendud cette notion
avec celle de « donnée membre statique », il y a deux
décennies.

Il y a deux décennies, "static" signifiait déjà un linkage
externe aussi.

Mais, certaines personnes ont perverti ce sens en le
surchargeant avec la notion de linkage.

Des noms, des noms. Tu pourrais tranquillement dire que ces
personnes s'appellent Brian Kernighan et Dennis Richie. (Ça ne
veut pas dire que je ne suis pas d'accord avec toi en pensant
que c'est un peu une « perversion », ou au moins que ce n'est
pas très logique. Mais il n'empèche que la « perversion » était
présente dès que le C est échappé de AT&T, et qu'elle fait
partie integrante de C.)

Avec l'inroduction des namespaces, il a été tenté (avc un
succès modéré) de revenir à la signification originelle de «
static » en déclarant que l'utilisation de « static » pour
siginifier linkage interne dans certaines est dépréciée.

C'est bien. Mais quel rapport avec le surcharge du const ?

| Un bon programmeur, qui s'intéresse à la lisibilité de ses
| programmes, mettrait systèmatiquement le mot clé static
| aussi ;

Un bon programmeur connaît et utilise les constructions
idiomatiques. Et l'idiome, consacré depuis plus de deux
décennies, est qu'une variable const par défaut implique un
linkage interne, à porté globale (puis namespace plus tard).

Certes. Et alors ? La première signification de const, c'est
bien de rendre la variable const.

Et l'idiome, partout où j'ai travaillé, a été de dire ce qu'on
sait. Ce qui veut dire que si je veux que la variable soit
static, je le dis explicitement.

Le programmeur « qui ne s'intéresse pas à la lisibilité de ses
programmes » et qui a inventé const en C++ il y a plus de deux
décennies a expliqué pourquoi il l'a inventé const et comment
il est arrivé à la règle en question dans D&E.

Je connais l'explication. Elle ne tient pas la route. La règle
spéciale (l'exception) n'a pas de justification ici ; elle coûte
plus qu'elle apporte.

--
James Kanze GABI Software
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

Jean-Marc Bourguet wrote:

TC++PL, 3rd Edition, 4th printing (j'ai pas vu d'errata pour ca).
Les

_xxx_ indiquent de l'italique dans le texte, il n'y a pas d'undescore
dans la partie citee.

5.1.1 Zero

Zero (0) is an _int_. Because of standard conversions
(C.6.2.3), 0 can be used as a constant of any integral
(4.1.1), floating-point, pointer or pointer-to-member type.
The type of zero will be determined by context. Zero will
typically (but not necessarily) be represented by the bit
pattern _all-zeros_ of the appropriate size.

No object is allocated with the address _0_. Consequently, 0
act as pointer literal, indicating that a pointer doesn't
refer to an object.

In C, it has been popular to define a macro _NULL_ to
represent the zero pointer. Because of C++'s tigher type
checking, the use of plain _0_, rather than any suggested
_NULL_ macro, leads to fewer problems. If you feel you must
define _NULL_, use

const int NULL = 0;

The _const_ qualifier (5.4) prevents accidental redefinition
of _NULL_ and ensures that _NULL_ can be used where a constant
is required.

B.S. ne suggere pas que ceux qui utilisent NULL le
definissent, mais que ceux qui le definissent le fassent comme
indique. Perso j'aurais quand meme signale que ca pose un
probleme des qu'on inclu un entete standard.

Au mieux, c'est très mal formulé. Même si la phrase exacte est
«@if you feel you must define », le contexte suggère fort que
c'est la meilleur façon d'obtenir un NULL. Sans parler de
quelque chose comme « In C, it has been popular to define a
macro _NULL_ » -- ce n'est pas que c'est une mode, ça fait
carrément partie de la norme (et C et C++). Tout le paragraphe
est très trompeur, et me deçoit de Stroustrup. (C'est difficile
de couvrir un sujet aussi étendu dans si peu de mots, et il faut
dire que le choix entre 0 et NULL n'est pas assez important pour
justifier des pages. Mais de là à citer NULL sans dire au moins
que la définition fait partie de la norme.)

--
James Kanze GABI Software
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

Loïc Joly wrote:

Gabriel Dos Reis wrote:

Jean-Marc Bourguet <jm@bourguet.org> writes:

[...]

| If you feel you must define _NULL_, use
^^^^^^^^^^^^^^^^^^^^^^^^^^^

| const int NULL = 0;

| The _const_ qualifier (5.4) prevents accidental
| redefinition of _NULL_ and ensures that _NULL_ can be used
| where a constant is required.

| B.S. ne suggere pas que ceux qui utilisent NULL le
| definissent, mais que ceux qui le definissent le fassent
| comme indique. Perso j'aurais quand meme signale que ca
| pose un probleme des qu'on inclu un entete standard.

OK, mais quand il dit « if you feel you must », tu crois que
c'est sans danger ?

J'ai l'impression que le mot intéressant est celui juste après
la citation : "If you feel you must _define_".

Certes, mais régarde la phrase qui le précède. Il parle de
l'habitude de « it has been popular to define a macro
_NULL_ ». Or, ce qui est répandu, c'est de inclure un en-tête
standard, et d'utiliser le NULL qui y est défini. Alors, s'il
considère ça une façon de définir NULL, alors, c'est la façon
qu'il faut faire, et non ce qu'il présente ensuite.

Le paragraphe est assez trompeux dans l'ensemble, et me deçoit
beaucoup.

Ce qui aurait pu être intéressant, pour le débat en cours,
c'est ce qu'il aurait marqué après un : "If you still want to
_use_ NULL, ....".

Dans la mésure qu'il dit « it has been popular to define a macro
NULL », on est amené à croire qu'il entendre par « define »
tout mechanisme qui fait que la définition s'en trouve dans ton
code. (En passant, le « In C, it has been poplular » est un peu
trompeur aussi. Ça suggère d'une part que la mode a passé en C,
ce qui n'est pas du tout le cas, et de l'autre, qu'il n'existe
pas, et n'a pas existé, en C++, or qu'il y a pas mal de règles
de codage C++ qui préconcise NULL.)

--
James Kanze GABI Software
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

Gabriel Dos Reis wrote:

[...]

C'est justement là le point crucial : si tu te retrouves
implémenteur de la bibliothèque standard, tu ne vas pas lire
TC++PL3 pour savoir la sémantique du langage :-). En d'autres
termes, TC++PL3 s'adresse au programmeur C++ (et non
l'implémenteur C++), et il y a virtuellement peu d'occasions
où « if you feel you must » se justifie.

Alors, pourquoi est-ce qu'il en parle ?

Ça aurait été simple à dire que certains utilisent le macro
standard NULL (et donc qu'il ne faut pas s'étonnait si on le
voit), mais que lui il trouve 0 convient mieux. Parler de NULL,
sans dire que c'est standard, et proposer une définition
inutilisable dans la réalité, c'est un peu trompeur à mon sens.

--
James Kanze GABI Software
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

kanze@gabi-soft.fr writes:

| Gabriel Dos Reis wrote:
| > kanze@gabi-soft.fr writes:
|
| > | Mais l'« intérêt principal » du const, ici ou ailleurs,
| > | c'est d'empècher qu'on y écrit. Si le but n'était que de
| > | s'assurer d'un linkage interne, il existe le mot clé static.
|
| > C'est là la règle idiote : celle qui consiste à surcharger «
| static »
| > avec la signification que le linkage est interne.
|
| Je n'ai jamais dit que le surcharge de la signification de const
| ici était la seule règle idiote dans le C++.


# Je connais bien les règles en ce qui concerne const. Y compris
# la règle idiote qui lui donne un autre linkage que des
# non-const. (C'est encore surcharger des choses qui n'ont rien à
# voir.)

Et c'est à ça que je faisais directement allusion, si tu prends la
peine de lire le message auquel je répondais.

| Quand on part de C,
| on a bien fait le choix du départ de vivre avec un certain
| nombre de règles idiotes.
|
| > « static » dès le début a toujours voulu dire « au plus une
| > seule instance dans le programme »,
|
| Ça serait la signification logique, basée sur la signification
| du mot anglais.
|
| > et non un linkage interne.
|
| Il faut aller bien en arrière pour trouver un époque où static
| n'avait pas la signification d'un linkage interne en C.

1978-79 suffit.
L'inventeur de C with Classes discuter directement avec les inventeus
de C et avait de première main, l'essence de chaque notion de C --
avant que le comité ANSI C mutile nombre d'entre elles.

[...]

| > C++ a maintenu cette signification et étendud cette notion
| > avec celle de « donnée membre statique », il y a deux
| > décennies.
|
| Il y a deux décennies, "static" signifiait déjà un linkage
| externe aussi.

ce qui ne fait qu'apporter de l'eau à mon moulain : « static » n'a pas
été inventé pour affecter le linkage, mais pour spécifier
« une seule instance dans ce programme », et le nom pour désigner
cette seule instantce peut avoir un linkage externe, cela ne rentre
pas en contradiction.

| > Mais, certaines personnes ont perverti ce sens en le
| > surchargeant avec la notion de linkage.
|
| Des noms, des noms. Tu pourrais tranquillement dire que ces
| personnes s'appellent Brian Kernighan et Dennis Richie. (Ça ne

Uniquement si c'est le cas. Mais cela ne l'est pas.

| veut pas dire que je ne suis pas d'accord avec toi en pensant
| que c'est un peu une « perversion », ou au moins que ce n'est
| pas très logique. Mais il n'empèche que la « perversion » était
| présente dès que le C est échappé de AT&T, et qu'elle fait
| partie integrante de C.)

il y avait beaucoup de choses qui étaient présentes dans le C échappé
de Bell Labs, un certain nombre d'entre eux n'étaient pas vraiment
l'invention de Kernighan et Ritchie, qui si j'en juge par les sources
que j'ai ici, font plutôt dans la cohérence, la clarté et la
simplicité.
Ce que je sais de seconde main (puique je l'ai eue de quelqu'un qui l'a
eu de première main), c'est que « static » n'a pas été inventé par
K&R pour affecter le linkage, mais pour dire « une seule instance dans
le programme ». Et c'est aussi, ce qui est à la base de la
« deprecation « de static dans certaines de ses utilisations pour dire
spécifier linkage interne.

| > Avec l'inroduction des namespaces, il a été tenté (avc un
| > succès modéré) de revenir à la signification originelle de «
| > static » en déclarant que l'utilisation de « static » pour
| > siginifier linkage interne dans certaines est dépréciée.
|
| C'est bien. Mais quel rapport avec le surcharge du const ?

Le rapport est avec ton commentaire, mais c'est vrai, tu ne lis pas
les messages auquels tu réponds.

[...]

| > Le programmeur « qui ne s'intéresse pas à la lisibilité de ses
| > programmes » et qui a inventé const en C++ il y a plus de deux
| > décennies a expliqué pourquoi il l'a inventé const et comment
| > il est arrivé à la règle en question dans D&E.
|
| Je connais l'explication. Elle ne tient pas la route.

Exactement quelle explication ? Je ne doute pas que tu saches beaucoup
de choses ; mais souvent il s'avère qu'il y a un décalage entre ce que
tu penses savoir et la réalité. Merci d'expliciter. Après on verra
pourquoi tu affirmes qu'elle ne tien pas la route.

-- Gaby

kanze@gabi-soft.fr writes:

| Gabriel Dos Reis wrote:
|
| [...]
| > C'est justement là le point crucial : si tu te retrouves
| > implémenteur de la bibliothèque standard, tu ne vas pas lire
| > TC++PL3 pour savoir la sémantique du langage :-). En d'autres
| > termes, TC++PL3 s'adresse au programmeur C++ (et non
| > l'implémenteur C++), et il y a virtuellement peu d'occasions
| > où « if you feel you must » se justifie.
|
| Alors, pourquoi est-ce qu'il en parle ?

Tu connais son adresse : bs at research dot att dot com.
Je ne doute pas qu'il est en train de suivre la discussion, mais il
aussi probable que tu aies une réoonse rapide si tu le luis demande
directement.

Ah, une chose qu'il te faut avoir en tête : ce ne sera que la n+1-ième
fois qu'il sera questionné sur NULL.

-- Gaby