OVH Cloud OVH Cloud

static const

30 réponses
Avatar
Loïc Joly
Bonjour,

Je me demande pourquoi dans le code suivant :

// a.h

int const i = 42;

class A { static int const i;};

int const A::i = 42;

// a.cpp
#include "a.h"

// b.cpp
#include "a.h"


Pourquoi n'y a-t-il pas de problèmes de définition multiple pour i alors
qu'il y en a pour A::i ?

Je sais que c'est ce que demande le standard :
Static data members of a class in namespace scope have external linkage
(3.5). A local class shall not have static data members.

Mais je ne comprends pas vraiment la motivation de cette différence.

--
Loïc

10 réponses

1 2 3
Avatar
Gabriel Dos Reis
writes:

[...]

| > Après on peut se demander si les cas majoritaires doivent
| > nécessiter la même lourdeur que les autres.
|
| C-à-d qu'on doit rendre les utilisations majoritaires
| systèmatiquement les plus courtes, même au prix de
| l'orthogonalité.

Je serais curieux de connaître les langages de programmation
« mainstream » qui sont « orthogonaux », surtout dans les plus
recents.

[...]

| > Enfin, comme je l'ai déjà fait observé Ni BS ni DMR n'ont
| > jamais aimé ou envisagé que « static » devrait avoir quoi que
| > ce soit vace « linkage > -- en réalité, aucun des deux n'aime
| > ce concept.
|
| Qu'on ne l'aime pas, je conçois bien -- avec plus de vingt ans
| d'expérience en C, puis en C++, j'y suis habité, mais je
| reconnais qu'il m'a un peu choqué aussi, quand j'apprenais le C.

Quand BS avait inventé « const » pour C with Classes, C n'avait pas
encore vingt ans pour comparé ;-p

[...]

| N'empèche que cette innovation-là, tu ne peux pas la mettre sur
| le dos du comité C. C'était bien présent dans les premiers C que
| j'ai vu. Que DMR ne l'aime pas, je veux bien, mais c'est quand
| même lui ou l'un de ses collègues qui l'ont introduit dans le
| langage.

Celui qui a travaillé directement avec lui et a fait évolué C en C++
me laisse entendre que c'est pas DMR l'auteur de cette invention.

Tiens assez curieusement et complètement indépendamment de ce thread,
on dicsutait, il y a trois jours, de quelques innovations récentes de
CWG et il m'a montré un passage du proceeding
of « History of Programming Language », deuxième conference, page 698:

Bill Keeman: Is it possible to define C more clearly than the
standard does?

Dennis Ritchie: Yes, of course. There are several parts that I
don't like much, including [...] and the notion of
"linkage" [...]

-- Gaby
Avatar
Gabriel Dos Reis
writes:

[...]

| > Peut-être que le besoin est réel, mais ça marche pas.
| > (1) il faut quand même donner la définition quelque part dans le
| > programme
|
| Et alors ? Je n'ai jamais dit que c'était élégant.

Le lecteur attentif aura remarqué que je n'ai pas parlé « d'élégance. »

-- Gaby
Avatar
Gabriel Dos Reis
"Michel Michaud" writes:

| Dans le message ,
| > Et alors ? Je n'ai jamais dit que c'était élégant. Je n'aime
| > pas, mais dans la mesure qu'on ne m'offre rien d'autre.
| [...]
| >> (3) en plus il faut que ce soit de type entier.
| >
| > C'est pire que ton point 1), j'en conviens. Mais la réponse en
| > est la même : dans la mesure où on ne m'offre rien d'autre...
|
| Oui, on t'offre et on a depuis longtemps le truc de l'enum.
| Qui évite d'avoir à faire une définition.

Je crois que James sous-estime le point (1) : les choses se voient
souvent prendre leurs adresses à l'insu du plein gré du programmeur.

-- Gaby
Avatar
kanze
Michel Michaud wrote:
Dans le message
,

Et alors ? Je n'ai jamais dit que c'était élégant. Je n'aime
pas, mais dans la mesure qu'on ne m'offre rien d'autre.
[...]

(3) en plus il faut que ce soit de type entier.


C'est pire que ton point 1), j'en conviens. Mais la réponse en
est la même : dans la mesure où on ne m'offre rien d'autre...


Oui, on t'offre et on a depuis longtemps le truc de l'enum.
Qui évite d'avoir à faire une définition.


Mais le type de l'enum n'est pas le bon. Ça peut pose de
problèmes avec la résolution du surcharge ; ça pose probablement
même plus avec des templates.

--
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



Avatar
kanze
Gabriel Dos Reis wrote:
"Michel Michaud" writes:

| Dans le message
,

| > Et alors ? Je n'ai jamais dit que c'était élégant. Je n'aime
| > pas, mais dans la mesure qu'on ne m'offre rien d'autre.
| [...]
| >> (3) en plus il faut que ce soit de type entier.

| > C'est pire que ton point 1), j'en conviens. Mais la
| > réponse en est la même : dans la mesure où on ne m'offre
| > rien d'autre...

| Oui, on t'offre et on a depuis longtemps le truc de l'enum.
| Qui évite d'avoir à faire une définition.

Je crois que James sous-estime le point (1) : les choses se
voient souvent prendre leurs adresses à l'insu du plein gré du
programmeur.


Mais où en est-ce un problème ? Ou plutôt, quelle solution
proposes-tu ? L'enum marche encore à peu près pour moi, parce
que je n'utilise pas beaucoup les templates. Mais tôt ou tard,
il arrive un moment où on veut que la constante ait le bon type.

Note bien que je n'aime pas la solution actuelle, ne serait-ce
que parce qu'elle implique trop de cas spéciaux : Pourquoi
seulement des types entiers ? Pourquoi une initialisation qui
n'est pas une définition (et une définition qui ne comporte pas
d'initialisation) ? Ça ne facilite pas l'apprentissage. Mais il
y a un véritable problème, et il ne suffit pas à dire que la
solution actuelle n'est pas satisfaite ; il faut en proposer une
meilleur. (D'un certain côté, peut-être ce qu'il faut, c'est une
façon de déclarer des symboles qui sont des rvalues avec un type
bien définis.)

--
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

Avatar
Gabriel Dos Reis
writes:

| Gabriel Dos Reis wrote:
| > "Michel Michaud" writes:
|
| > | Dans le message
| ,
| > | > Et alors ? Je n'ai jamais dit que c'était élégant. Je n'aime
| > | > pas, mais dans la mesure qu'on ne m'offre rien d'autre.
| > | [...]
| > | >> (3) en plus il faut que ce soit de type entier.
|
| > | > C'est pire que ton point 1), j'en conviens. Mais la
| > | > réponse en est la même : dans la mesure où on ne m'offre
| > | > rien d'autre...
|
| > | Oui, on t'offre et on a depuis longtemps le truc de l'enum.
| > | Qui évite d'avoir à faire une définition.
|
| > Je crois que James sous-estime le point (1) : les choses se
| > voient souvent prendre leurs adresses à l'insu du plein gré du
| > programmeur.
|
| Mais où en est-ce un problème ?

La variable devient une lvalue et si tu appeles une fonction prenant
une référence, tu auras besoin de la définition -- ce qui arrive assez
souvent et j'ai vu suffisamment de bug reports pour savoir cela aussi
rare qu'on pourrait le penser.

| Ou plutôt, quelle solution proposes-tu ?

Voire ci-dessous.

| L'enum marche encore à peu près pour moi, parce
| que je n'utilise pas beaucoup les templates. Mais tôt ou tard,
| il arrive un moment où on veut que la constante ait le bon type.
|
| Note bien que je n'aime pas la solution actuelle, ne serait-ce
| que parce qu'elle implique trop de cas spéciaux : Pourquoi
| seulement des types entiers ? Pourquoi une initialisation qui
| n'est pas une définition (et une définition qui ne comporte pas
| d'initialisation) ? Ça ne facilite pas l'apprentissage. Mais il
| y a un véritable problème, et il ne suffit pas à dire que la
| solution actuelle n'est pas satisfaite ; il faut en proposer une
| meilleur.

Groumph.

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1521.pdf
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1511.pdf
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1509.pdf

-- Gaby
Avatar
Gabriel Dos Reis
writes:

| Michel Michaud wrote:
| > Dans le message
| ,
| > > Et alors ? Je n'ai jamais dit que c'était élégant. Je n'aime
| > > pas, mais dans la mesure qu'on ne m'offre rien d'autre.
| > [...]
| > >> (3) en plus il faut que ce soit de type entier.
|
| > > C'est pire que ton point 1), j'en conviens. Mais la réponse en
| > > est la même : dans la mesure où on ne m'offre rien d'autre...
|
| > Oui, on t'offre et on a depuis longtemps le truc de l'enum.
| > Qui évite d'avoir à faire une définition.
|
| Mais le type de l'enum n'est pas le bon. Ça peut pose de
| problèmes avec la résolution du surcharge ; ça pose probablement
| même plus avec des templates.

Bof. D'expérience, cela pose moisn de confusion qu'avec la curiosité
actuelle.

-- Gaby
Avatar
James Kanze
Gabriel Dos Reis wrote:
writes:


| Gabriel Dos Reis wrote:
| > "Michel Michaud" writes:


| > | Dans le message
| ,
| > | > Et alors ? Je n'ai jamais dit que c'était élégant. Je n'aime
| > | > pas, mais dans la mesure qu'on ne m'offre rien d'autre.
| > | [...]
| > | >> (3) en plus il faut que ce soit de type entier.


| > | > C'est pire que ton point 1), j'en conviens. Mais la
| > | > réponse en est la même : dans la mesure où on ne
| > | > m'offre rien d'autre...


| > | Oui, on t'offre et on a depuis longtemps le truc de
| > | l'enum. Qui évite d'avoir à faire une définition.


| > Je crois que James sous-estime le point (1) : les choses
| > se voient souvent prendre leurs adresses à l'insu du plein
| > gré du programmeur.


| Mais où en est-ce un problème ?


La variable devient une lvalue et si tu appeles une fonction
prenant une référence, tu auras besoin de la définition -- ce
qui arrive assez souvent et j'ai vu suffisamment de bug
reports pour savoir cela aussi rare qu'on pourrait le penser.


Je ne dis pas le contraire. Il faut une définition. Et alors ?
Ou est-ce que je suis le seul à fournir la définition
systèmatiquement ?

| Ou plutôt, quelle solution proposes-tu ?


Voire ci-dessous.


| L'enum marche encore à peu près pour moi, parce que je
| n'utilise pas beaucoup les templates. Mais tôt ou tard, il
| arrive un moment où on veut que la constante ait le bon
| type.


| Note bien que je n'aime pas la solution actuelle, ne
| serait-ce que parce qu'elle implique trop de cas spéciaux :
| Pourquoi seulement des types entiers ? Pourquoi une
| initialisation qui n'est pas une définition (et une
| définition qui ne comporte pas d'initialisation) ? Ça ne
| facilite pas l'apprentissage. Mais il y a un véritable
| problème, et il ne suffit pas à dire que la solution
| actuelle n'est pas satisfaite ; il faut en proposer une
| meilleur.


Groumph.


http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1521.pdf
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1511.pdf
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1509.pdf


Je n'en démandais pas autant :-).

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Avatar
Gabriel Dos Reis
James Kanze writes:

| Gabriel Dos Reis wrote:
| > writes:
|
| > | Gabriel Dos Reis wrote:
| > | > "Michel Michaud" writes:
|
| > | > | Dans le message
| > | ,
| > | > | > Et alors ? Je n'ai jamais dit que c'était élégant. Je n'aime
| > | > | > pas, mais dans la mesure qu'on ne m'offre rien d'autre.
| > | > | [...]
| > | > | >> (3) en plus il faut que ce soit de type entier.
|
| > | > | > C'est pire que ton point 1), j'en conviens. Mais la
| > | > | > réponse en est la même : dans la mesure où on ne
| > | > | > m'offre rien d'autre...
|
| > | > | Oui, on t'offre et on a depuis longtemps le truc de
| > | > | l'enum. Qui évite d'avoir à faire une définition.
|
| > | > Je crois que James sous-estime le point (1) : les choses
| > | > se voient souvent prendre leurs adresses à l'insu du plein
| > | > gré du programmeur.
|
| > | Mais où en est-ce un problème ?
|
| > La variable devient une lvalue et si tu appeles une fonction
| > prenant une référence, tu auras besoin de la définition -- ce
| > qui arrive assez souvent et j'ai vu suffisamment de bug
| > reports pour savoir cela aussi rare qu'on pourrait le penser.
|
| Je ne dis pas le contraire. Il faut une définition. Et alors ?
| Ou est-ce que je suis le seul à fournir la définition
| systèmatiquement ?

Tu es visiblement parmi les espèces rares, oui :-)

| > | Ou plutôt, quelle solution proposes-tu ?
|
| > Voire ci-dessous.
|
| > | L'enum marche encore à peu près pour moi, parce que je
| > | n'utilise pas beaucoup les templates. Mais tôt ou tard, il
| > | arrive un moment où on veut que la constante ait le bon
| > | type.
|
| > | Note bien que je n'aime pas la solution actuelle, ne
| > | serait-ce que parce qu'elle implique trop de cas spéciaux :
| > | Pourquoi seulement des types entiers ? Pourquoi une
| > | initialisation qui n'est pas une définition (et une
| > | définition qui ne comporte pas d'initialisation) ? Ça ne
| > | facilite pas l'apprentissage. Mais il y a un véritable
| > | problème, et il ne suffit pas à dire que la solution
| > | actuelle n'est pas satisfaite ; il faut en proposer une
| > | meilleur.
|
| > Groumph.
|
| > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1521.pdf
| > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1511.pdf
| > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1509.pdf
|
| Je n'en démandais pas autant :-).

Tu as avais l'air d'insinuer que je ne fais que parler du problème
sans proposer de solution.

-- Gaby
Avatar
kanze
Gabriel Dos Reis wrote:

[...]
Tu as avais l'air d'insinuer que je ne fais que parler du
problème sans proposer de solution.


Parce que je ne savais pas que tu proposais une solution.
J'avais l'impression que tu voulais nier le problème. (En fait,
je connaissais vaguement une partie de ces propositions, mais je
n'avais pas fait le reprochement.)

Alors, on est d'accord. Il y avait un problème, mais la solution
adoptée n'en est pas une (ou n'en est pas une bonne). Et je
reconnais, en y pensant, que le problème, tel que je l'ai
présenté, n'est qu'un symptome d'un problème plus général, de la
définition et de l'écriture des constantes. (J'aime beaucoup,
par exemple, ta suggestion d'étendre les expressions constante
pour permettre certaines fonctions.)

--
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

1 2 3