Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C++ initialisation et double déclaration de données static d'un objet non instancié

initialisation et double déclaration de données static d'un objet non instancié

119 réponses
Avatar
heinquoi
Bjr,
j'ai un pb de compréhension sur ce code:

class Main
{
public:
static HINSTANCE hInstance;
static HINSTANCE hPrevInstance;
static int nCmdShow;
static int MessageLoop( void );
};

HINSTANCE Main::hInstance = 0; // ici, je devrais avoir une
erreur
HINSTANCE Main::hPrevInstance = 0; // ici, aussi

il y a une double déclaration non ?
Si quelqu'un peut m'éclairer ? Et l'objet n'est meme pas initialisé.
Cordialement
Heinquoi
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
7 8 9 10 11
Avatar
Alain Naigeon
a écrit dans le message news:

"Alain Naigeon" wrote in message
news:<409ff472$0$20757$...
a écrit dans le message news:

"Alain Naigeon" wrote in message
news:<409ea014$0$21078$...
"James Kanze" a écrit dans le message news:

drkm writes:

|> "Alain Naigeon" writes:

|> > Mais je ne comprends pas ce que
|> > tu ne comprends pas ici :-o

|> Je pense qu'il a mal compris ma formulation, et l'a prise
|> dans le sens « fonction membre » ou « variable membre ».

Tout à fait. Le concepte de membre de classe par rapport au
membre d'instance ne fait pas partie de C++. On ne parle que des
« membres de classes », y compris pour ce que dans d'autres
langages, on appelle « membres d'instance ». Et dans l'absence
de l'expression « membres d'instance », j'imaginais la
signification C++, et non la signification qu'il a voulu (qui
est très courante dans d'autres langages orientés objet).


Quand on parle *de* C++, on ne parle pas *en* C++ - comment alors
veux-tu conceptualiser la différence fondamentale entre les deux
cas ?


Quand on parle de C++, on utilise un vocabulaire propre, de même que
quand on parle de n'importe quel autre langage. Donc, quand je parle
de C++, je parle des fonctions (membre ou non), tandis que quand je
parle de Java, je parle des méthodes (qui peuvent aussi être
statiques).


Oui mais : C++ fut créé, alors que les concepts objet, incarnés dans
d'autres langages, commençaient à avoir du succès. Il fut créé de
façon "réaliste" (compatibilité C, etc) pour avoir une bonne chance
d'être adopté en pratique. C'est réussi, bravo. Ceci dit, je ne vois
pas ce qui empêche d'emprunter le vocabulaire utilisé couramment alors
pour ces concepts objet.


Rien n'empêchait. Et en fait, beaucoup de vocabulaire a été emprunté du
langage OO -- on parle bien d'héritage, des classes dérivées, etc.
Stroustrup a décidé de ne pas suivre le nomenclature « membre de
classe@» / « membre d'instance ». Je ne connais pas la raison derrière
cette décision, mais il ne me gène pas outre-mésure.


Ca dépend par quoi on le remplace ; pour moi "storage class"
c'est un peu mettre l'outil avant l'ouvrage.

A propos de la différence de sens entre class dans "class data member"
et dans "membre de classe" (par opposition à membre d'instance), j'ai
comme l'impression que tout s'éclaire si l'on se souvient que dans certains
langages (pas très populaires, il me semble, hélas), les classes sont des
objets.
Alors, bien sûr, ce n'est pas le cas en C++, donc la classe C++, en tant que
type, est, au fond "static". Autrement dit, le membre d'instance est
instancié
avec l'instance-objet, et le membre de classe (static data member) est
instancié avec... la classe ! (*) Personnellement je trouve ça assez
parlant, mais
peut-être que les puristes ou les techniciens de C++ trouveront choquante
cette formulation.

(*) : l'instanciation de la classe C++ n'est certes pas visible depuis le
programme, elle n'est pas accessible, mais elle existe, et la
preuve en est l'existence des static data members qui sont, eux,
accessibles au programme :-) Ceci dit, je concède qu'il s'agit
là d'un point de vue original ;-)

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Strasbourg, France





Avatar
Alain Naigeon
"Gabriel Dos Reis" a écrit dans le message
news:
"Alain Naigeon" writes:


[...]

| A propos de la différence de sens entre class dans "class data member"
| et dans "membre de classe" (par opposition à membre d'instance), j'ai
| comme l'impression que tout s'éclaire si l'on se souvient que dans
certains

| langages (pas très populaires, il me semble, hélas), les classes sont
des

| objets.
| Alors, bien sûr, ce n'est pas le cas en C++, donc la classe C++, en tant
que

| type, est, au fond "static".

Autrement dit, c'est une valeur/objet compile-time, cela ne me choque
pas du tout et je trouve que c'est un point de vue intéressant quand par
exemple, on veut manipuler les types et les templates (qui sont alors
des fonctions vers des types) d'une certaine manière qu'il est convenu
d'appeler, nébuleusement, « méta-programmation. » J'ai expliqué
ce point de vue, par exemple, à la « Association of C and C++ Users
Spring Conference » d'avril 2001. Voir


http://www.cmla.ens-cachan.fr/~dosreis/C++/talks/metaprogramming-in-cxx.pdf


C'est également un point de vue largement adopté chez Boost.
Je n'irai pas cependant jusqu'à prétendre que c'est un point de vue
universellement reconnu. Une preuve est ce thread ;-).
Mais ce qui est sûr, c'est que l'inventeur du langage et des experts
comme Francis Glassborrow comprennent static appliqué aux member d'une
classe de cette manière.

-- Gaby



Argh, avec de tels antécédents, je suis obligé de renoncer à ma publication
:-)

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Strasbourg, France

Avatar
kanze
Gabriel Dos Reis wrote in message
news:...
writes:

| Gabriel Dos Reis wrote in message
| news:...
| > "Alain Naigeon" writes:

| > | Car, ne t'en déplaise, les notions de classe et d'instance ont
| > | un sens général qui n'est pas à mettre à la poubelle simplement
| > | parce qu'un langage en particulier les a adoptés pour nommer ses
| > | propres implémentations particulières. Chacun ses goûts ; pour
| > | moi, "storage class" reflète, hélas (3 fois), une mentalité
| > | "proche de la machine" dont on sait bien d'où elle vient.

| > La notion de « class » en C++ est empruntée à Simula -- et ne
| > désigne pas ce que le comité C et C++ ont décidé d'appeler dans un
| > jargon obscure « storage class ».

| Attention. Il n'y a aucun rapport entre le mot clé class et le
| concepte de classe qu'il incarne, et le « class » dans « storage
| class » (que je traduirais plutôt par « catégorie » en français).

Ce n'est pas ce que j'ai dit ? À quoi dois-je faire attention ?


Je m'adressais plus généralement aux lecteurs du thread. J'avais
l'impression qu'il y avait un peu de confusion.

| Quand j'entends « membre de classe », je ne fais aucun rapprochement
| à « storage class », qui est un mot qu'on a hérité de C.

| Et c'est un mot qui n'a aucune autre signification réele que de
| désigner la liste des mots clé qui en font partie. Certains de ces
| mots clé affectent le « linkage » du symbole, d'autres la durée de
| vie de l'objet qu'il désigne, « static » a une signification tout
| particulière dans une classe, et en C, même « typedef » est un «
| storage class ».

et noté que le comité C dit clairement qu'il prétend que « typedef »
est un « storage class specifier » uniquement pour des raisons de
convenance, et non pas qu'il pense qu'il en est un réellement au sens
classique.


C'est vrai. Mais quel est la signification « classique » d'un « storage
class specifier » ? Déjà en K&R1, le mot clé « static » pouvait affecter
soit le linkage, soit la durée de vie, selon qu'il sert à la portée de
fichier ou dans une fonction ; « extern » n'affectait que le linkage,
« auto » la durée de vie, et « register », quelque chose qui n'avait
rien à voir ni avec l'un ni avec l'autre (sauf dans la mésure que
« register » impliquait « auto »).

Est-ce que tu pourrais me donner une définition de « storage class »,
tel que l'expression sert dans les normes C et C++, autrement que par
une liste exhaustive des mot clés concerné ?

--
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 in message
news:...
writes:


[...]
| Rien n'empêchait. Et en fait, beaucoup de vocabulaire a été emprunté
| du langage OO -- on parle bien d'héritage, des classes dérivées,
| etc. Stroustrup a décidé de ne pas suivre le nomenclature « membre
| de classe » / « membre d'instance ». Je ne connais pas la raison
| derrière cette décision, mais il ne me gène pas outre-mésure. Dans
| d'autres cas, par exemple quand il a décidé de ne pas utiliser «
| subclass » et « superclass », il a expliqué pourquoi. Mais pas ici,
| ou plutôt, je n'ai jamais vu une explication. Peut-être Gaby en
| connaît une (bien que comme j'ai dit, je ne trouve pas qu'une
| explication soit nécessaire).

J'ai bien lu ta phrase entre parenthèses mais je ne comprends pas très
bien tes deux premières phrases. Comme tu le sais,


Ne suppose pas trop en ce qui concerne ce que je sais. Je connais bien
la partie de l'histoire du C++ que j'ai vecu -- à partir de 1992, grosso
modo (mais l'utilisation déjà alors des compilateurs périmés m'en a
exposé un peu de l'histoire postérieure). En ce qui concerne l'histoire
ancienne, avant que le langage ait réelement commencé à se répandre, je
n'en connais que des brides.

C++ emprunte directement à C et Simula.


Ça, j'ai effectivement entendu. Mais ne connaissant rien de Simula, ça
ne me donne qu'une moitié de l'ensemble.

Simula est le premier langage orienté objet et comme Stroustrup
l'explique régulièrement, « C++ borrows its terminology from Simula
rather than from Smalltalk. » En Simula, une classe est une collection
de fonctions et de données, et je trouve naturel d'appeler les
éléments de cette collection les « membres de cette classe. »


OK. Tu me l'apprends -- je ne connaissais pas comment Simula présentait
les choses.

En ce qui concerne la notion de « static » appliqué aux membres d'une
classe, il m'a toujours paru que Stroustrup l'expliquait autrement que
par le circulaire « static en C++ a une définition précise et cela
veut dire exactement ce que la norme C++ veut dire par là. »


Qui a dit le contraire. Moi aussi, j'explique « static » à partir des
effects qu'il a sur ce qu'on déclare static. N'empêche que ces
effects-là dépend de l'utilisation qu'on en fait : à la portée de
namespace (ou de fichier, autrefois), il a une signification bien
différente que dans une fonction. Et ça, depuis C -- la multicité de
significations n'est pas une innovation de C++. J'ai toujours supposé
que le choix de « static » dans les classes était dû à une combinaison
de la volenté d'éviter de nouveaux mots clé, le fait que le mot avait
déjà sa place là dans la syntaxe, et le fait qu'il avait déjà de
multiples significations, alors, une de plus ne ferait pas de mal. Mais
c'était une simple supposition ; je ne me suis jamais soucié de me
renseigner dans quelle mésure il correspondait à ce que pensait
Stroustrup. (À de rares occasions où j'ai rencontré Stroustrup, il y
avait de choses plus importantes ou plus intéressantes à discuter. Si je
l'avais vu plus souvent, peut-être le sujet se serait présenté.)

Certes, cette assertion n'est pas fausse mais cela ne donne pas une
idée de ce que c'est. Comme, je n'arrive pas à trouver sommeil parce
qu'il fait chaud, je me suis occupé à trouver une référence à
l'explication que Stroustrup donne -- mon examplaire d'ARM est
malheureusement au bureau. Donc du D&E, §13.4, page 288

A static data member of a class is a member for which there is only
one copy rather than one per object. Consequently, a static member
can be accessed without referring to any particular object.

Ici, Stroustrup essaie d'expliquer en des termes simples et généraux
la signification de « static » appliqué aux membres d'une classe.
Il commence par rappeler que « static » appliqué à une donnée membre
veut dire qu'il existe exactement une copie de cette donnée dans tout
le programme, au lieu d'avoir une copie (membre) par objet (ou
instance) de cette classe.


Mais je sais tout ça. Je ne dis pas autre chose moi-même.

Cette signification est très proche de la signification originelle de
« static » appliquée à une variable locale -- telle que Dennis Ritchie
l'imaginait,


Stroustrup a travaillé avec Ritchie ; il peut donc savoir ce que Ritchie
imaginait. Moi, non. En C, déjà, le mot avait deux significations bien
distinctes.

avant qu'il décide un jour de réutiliser ce même mot clé pour dire
qu'une donnée/fonction est locale à une unité de traduction (ce dont
il n'est pas fier, et il l'avoue publiquement).


Tu rémontes très loins dans l'histoire de C, là. Déjà en K&R1, static
avait les deux significations. Et c'était surtout celle qui s'appliquait
à la portée de fichier qui primait, qui servait le plus souvent ; les
variables statiques locales, les experts en C les connaissaient, mais
elles n'étaient pas partout, tandis que la règle était de déclarer les
fonctions et les variables à la portée de fichier static par défaut, et
de n'enlever le static que si on voulait explicitement les rendre
visibles dans d'autres unités de compilation. (Si tu régardes le posting
qui a démarré ce thread, c'est bien cette signification-là que
connaissait le poster initial. Et apparamment, seulement cette
signification.)

Maintenant, si tu ne considères que la signification de statique à
l'intérieur d'une fonction, j'avoue qu'il y a une très forte apparenté
avec sa signification appliquée à une variable membre d'une classe. Si
tu pars du principe que static a plusieurs significations, en revanche,
et que la plus important concerne le linkage, l'apparenté est moins
immédiatement évidente.

Il faut bien ici voir la différence avec une variable locale qui
aurait une durée de stockage automatique.

Une telle variable locale est conceptuellement « instanciée » à chaque
appel à la fonction qui la contient ou, en jargon technique, à chaque
activation de la structure de calcul de la fonction. Donc, tout comme
les données membres des objets d'une classe donnée, il existe une
copie par activation. L'utilisation de « static », comme Dennis
Ritchie l'a conçu au départ, c'est pour dire qu'une telle donnée
n'appartient pas à une instance particulière de la fonction, mais à
toutes les instances de la fonction. En somme, la notion de donnée
membre statique telle que Stroustrup l'a conçue est une excellente
généralisation de variable locale statique conçue par Ritchie.


Tout à fait. Là, je comprends bien le rapprochement.

Il faut dire que mes expériences avec C ne rémonte pas au delà des
années 80, et le K&R1. Et que déjà alors, la signification primaire de
static concernait le linkage ; son utilisation sur des variables locales
était considérée comme une utilisation sécondaire, de moindre
importance. Du coup, évidemment, le choix du mot paraissait un peu
curieux, mais bien, qui s'attend à ce que tout soit parfaitement
logique. (Logique aurait été, évidemment, qu'il n'y ait pas de linkage
par défaut, et qu'il ait un mot clé global pour signifier que le nom
était visible ailleurs.)

Une fois rappelée cette idée qu'une donnée membre statique est, par
définition, l'idée même qu'il en existe une et une seule copie et
qu'elle n'appartient pas à un objet particulier, Stroustrup poursuit :

A static member function is not associated with any particular
object and need not be called using the special function syntax.

Il me paraît évident que la notion de static appliqué à un membre
d'une classe (que ce soit une donnée ou une fonction) est cohérente.


Disons que si on connaît l'histoire de comment Stroustrup y est arrivé,
on pourrait voir le lien. En régardant le status quo aujourd'hui, je ne
vois qu'une parenté lointain.

Note bien que la façon qu'on voit les choses dépend aussi du point de
vue qu'on prend. Si on considère que static ne doit avoir qu'un seul
sens, et qu'on le cherche, la parenté est apparente. Si on part du
principe que la signification initiale (ou au moins, la plus importante
dans le C) concerne le linkage, et que le mot clé a plusieurs
significations non apparentées, on rémarque tout de suite les
différences.

Il me smeble qu'on l'expliquer en des termes généraux autres que ceux
que la norme C++ utilise, comme Stroustrup le fait, sans en vider la
substance ni la dénaturer.


De l'expliquer en termes historiques, en tout cas, mais tout dans une
autre lumière. Pour moi, et j'imagine pour beaucoup d'autres qui vient
de C, mais qui n'ont jamais connu Ritchie personnellement, static
concerne surtout le linkage (encore qu'à l'époque, on parlait plutôt de
visibilité que de linkage).

Si on commence à enseigner que pour restreindre la visibilité, on se
sert des namespaces anonymes, et qu'il arrive une génération de
programmeurs C++ qui ne connaissent de statique que cette idée
d'indépendance de toute instance, peut-être ils ne resentiront pas
l'ambiguïté du mot static. Encore que je ne suis pas sûr ; je n'ai pas
trop l'habitude d'entendre parler de l'« instance » d'une fonction, en
dehors des compilateurs, au moins.

| Je ne vois pas de problème non plus à utiliser ce vocabulaire ici,
| même

Je ne crois pas que le problème soit l'utilisation du vocabulaire ici,
mais plutôt la question de parler uniquement *de* C++ *en* C++.


Le problème de mécompréhension qu'il y a eu, je te rappelle, c'est que
j'ai interprété l'expression « membre de classe » comme signifiant tout
membre d'une classe, sans le sens que ça a dans la norme C++, et non
comme étant en opposition à « membre d'instance », comme on l'utilise
dans le vocabulaire d'autres langages OO (je crois).

En ce qui concerne la multiplicité des significations du mot clé static,
je l'ai trouvé dans la passé qu'accentuer ces différences, et tirer
l'attention sur la multiplicité des significations, semblaient aider à
la compréhension. Mais c'est mon expérience, et il y a sans doute
d'autres façons de présenter la chose qui marche aussi.

| si Stroustrup et la norme ne s'en sert pas. Seulement, il ne faut
| pas

Il me semble que Stroustrup n'hésite pas une seconde à aller au delà
du sous-ensemble très restreint de vocabulaire utilisé par la norme.


On ne parle pas en général. Quand Stroustrup distingue entre les
variables membre statiques, et les variables membres non statiques, je
ne crois pas qu'il parle de variables de classe et de variables
d'instance.

En fait, ici, le problème n'est pas que l'expression n'est pas celle de
la norme. Le problème, c'est que la norme, et Stroustrup (dans TC++PL)
utilise exactement la même expression (« membre de classe ») avec une
autre signification.

Je ne pense pas que la question soit de savoir si le vocabulaire de la
norme C++ est interdit ici. Je crois qu'il est plutôt possible et
utile d'expliquer les concepts de C++ autrement que par le vocabulaire
limité utilisé par la norme.


Tout à fait. Seulement, si on veut utiliser une expression consacrée
dans les descriptions de C++, il ne fait pas s'étonner à ce que les gens
l'interprètent avec la signification qu'elle a dans la norme et dans C++
en général. Au moins qu'on précise qu'on l'utilise dans un autre sens,
ou que le contexte (par exemple, une opposition à membre d'instance) le
rend clair.

--
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
"Alain Naigeon" wrote in message
news:<40a15338$0$18306$...

[...]
Rien n'empêchait. Et en fait, beaucoup de vocabulaire a été emprunté
du langage OO -- on parle bien d'héritage, des classes dérivées,
etc. Stroustrup a décidé de ne pas suivre le nomenclature « membre
de classe » / « membre d'instance ». Je ne connais pas la raison
derrière cette décision, mais il ne me gène pas outre-mésure.


Ca dépend par quoi on le remplace ; pour moi "storage class" c'est un
peu mettre l'outil avant l'ouvrage.


C'est un peu pourquoi j'ai évité l'expression dans ma première
explination des différentes significations de static. C'est un mot
technique, qui n'a pas vraiment d'intérêt en dehors de la norme.
D'autant plus qu'on dévinera jamais la signification qu'elle a dans la
norme à partir des significations des mots anglais dont elle est
composée. (« extern » et « static » sont des « storage class », alors
qu'ils affectent surtout la visibilité.)

A propos de la différence de sens entre class dans "class data member"
et dans "membre de classe" (par opposition à membre d'instance), j'ai
comme l'impression que tout s'éclaire si l'on se souvient que dans
certains langages (pas très populaires, il me semble, hélas), les
classes sont des objets.


Tout à fait. C'est à peu près mon impression aussi.

C'est intéressant à voir l'ambiguïté de Java à cet égard, dont la
spécification utilise parfois les expressions « membre de classe » et
« membre d'instance », et d'autrefois « membre statique » et « membre
non-statique ». Et qui se situe en fait à peu près à mi-chemin -- la
classe même n'est pas un objet, mais il existe un objet de type Class
pour chaque classe. (Selon qu'on aime Java ou on le déseste, c'est le
meilleur des deux mondes, ou le pire. Mais bien que je n'aime pas Java
en général, je trouve que c'est une chose où j'ai l'impression qu'ils
ont trouvé une bonne compromise.)

Enfin, selon Gaby, C++ tire son vocabulaire ici de Simula. Est-ce que
dans Simula, la classe est un objet aussi ?

Alors, bien sûr, ce n'est pas le cas en C++, donc la classe C++, en
tant que type, est, au fond "static". Autrement dit, le membre
d'instance est instancié avec l'instance-objet, et le membre de classe
(static data member) est instancié avec... la classe ! (*)
Personnellement je trouve ça assez parlant, mais peut-être que les
puristes ou les techniciens de C++ trouveront choquante cette
formulation.


Pas choquant, mais pas habituel. Mais surtout, je ne crois pas qu'il dit
grand chose à quelqu'un qui apprend le langage.

J'ai une assez bonne expérience avec des débuttants en expliquant static
en accentuant les différences des diverses utilisations. Ça marche pour
moi. Mais ça ne veut pas dire que c'est la seule façon de les expliquer,
ou que d'autres façons ne peut pas donner d'aussi bons résultats.

(*) : l'instanciation de la classe C++ n'est certes pas visible depuis le
programme, elle n'est pas accessible, mais elle existe, et la
preuve en est l'existence des static data members qui sont, eux,
accessibles au programme :-) Ceci dit, je concède qu'il s'agit
là d'un point de vue original ;-)


Ce ne serait pas un peu circulaire comme raisonnement ? On définit les
membres statiques en termes d'instance de classe, et puis, on s'en sert
pour démontrer l'existance de l'instance.

--
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
Michel Michaud
Dans news:,
Ça, j'ai effectivement entendu. Mais ne connaissant rien de
Simula, ça ne me donne qu'une moitié de l'ensemble.


Tiens, pour compléter ta culture, en quelques minutes :

http://www.iro.umontreal.ca/~vaucher/Simula/Simula.intro.html

Ou pour aller au coeur du sujet :

http://www.iro.umontreal.ca/~vaucher/Simula/Simula.intro.html#s11

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Avatar
Franck Branjonneau
Gabriel Dos Reis écrivait:

"Alain Naigeon" writes:


[...]

| A propos de la différence de sens entre class dans "class data member"
| et dans "membre de classe" (par opposition à membre d'instance), j'ai
| comme l'impression que tout s'éclaire si l'on se souvient que dans certains
| langages (pas très populaires, il me semble, hélas), les classes sont des
| objets.
| Alors, bien sûr, ce n'est pas le cas en C++, donc la classe C++, en tant que
| type, est, au fond "static".

Autrement dit, c'est une valeur/objet compile-time, cela ne me choque
pas du tout et je trouve que c'est un point de vue intéressant quand par
exemple, on veut manipuler les types et les templates (qui sont alors
des fonctions vers des types) d'une certaine manière qu'il est convenu
d'appeler, nébuleusement, « méta-programmation. »


Cet amalgame : classe C++, entité compile-time et statique n'est-il
pas inscrit dans le langage ? Une des formes de coercition s'écrit
static_cast< Class >().
--
Franck Branjonneau

Avatar
Alain Naigeon
a écrit dans le message news:

"Alain Naigeon" wrote in message
news:<40a15338$0$18306$...

(*) : l'instanciation de la classe C++ n'est certes pas visible depuis
le


programme, elle n'est pas accessible, mais elle existe, et la
preuve en est l'existence des static data members qui sont, eux,
accessibles au programme :-) Ceci dit, je concède qu'il s'agit
là d'un point de vue original ;-)


Ce ne serait pas un peu circulaire comme raisonnement ? On définit les
membres statiques en termes d'instance de classe, et puis, on s'en sert
pour démontrer l'existance de l'instance.


Tu as probablement raison, mais je distinguerais entre une définition,
qui ne doit pas être circulaire, et une explication pédagogique (je ne
sais pas trop comment appeler ça). Moi ça sécurise ma compréhension
quand j'ai quelque chose qui ressemble à une signification, plutôt que
simplement de savoir comment ça marche.

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Strasbourg, France


Avatar
Gabriel Dos Reis
writes:

[...]

| > | Quand j'entends « membre de classe », je ne fais aucun rapprochement
| > | à « storage class », qui est un mot qu'on a hérité de C.
|
| > | Et c'est un mot qui n'a aucune autre signification réele que de
| > | désigner la liste des mots clé qui en font partie. Certains de ces
| > | mots clé affectent le « linkage » du symbole, d'autres la durée de
| > | vie de l'objet qu'il désigne, « static » a une signification tout
| > | particulière dans une classe, et en C, même « typedef » est un «
| > | storage class ».
|
| > et noté que le comité C dit clairement qu'il prétend que « typedef »
| > est un « storage class specifier » uniquement pour des raisons de
| > convenance, et non pas qu'il pense qu'il en est un réellement au sens
| > classique.
|
| C'est vrai. Mais quel est la signification « classique » d'un « storage
| class specifier » ? Déjà en K&R1, le mot clé « static » pouvait affecter
| soit le linkage, soit la durée de vie, selon qu'il sert à la portée de
| fichier ou dans une fonction ; « extern » n'affectait que le linkage,

Comme je l'ai expliqué à plusieurs reprises, mais c'est peut-être
perdu dans le vacarme, le fait que « static » modifie le linkage est
l'accident que Dennis Ritchie lui même regrette. C'est également cela
que les gens qui ont proposéde « déprécier » static ont essayé de
corriger. Le reste de la signification de « static » (en C++) cadre
avec le concept initial de quand tu l'utilises pour une variable locale.

| « auto » la durée de vie,

« auto » en tant que machin-rage truc-specifer est le dual de static:
au lieu d'avoir une seule copie on a une copie à chaque appel.

| et « register », quelque chose qui n'avait
| rien à voir ni avec l'un ni avec l'autre (sauf dans la mésure que
| « register » impliquait « auto »).

En C, il disait qu'on ne peut pas adresser la mémoire de l'objet ainsi
désigné : tu y vois quelque chose qui n'a rien à avoir avec la classe
de stockage toi ?

| Est-ce que tu pourrais me donner une définition de « storage class »,
| tel que l'expression sert dans les normes C et C++, autrement que par
| une liste exhaustive des mot clés concerné ?

Puisque je ne peux rien supposr sur ce que tu sais, dis-mois ce que tu
sais et je te dirai ce que tu veux savoir.

-- Gaby
Avatar
Gabriel Dos Reis
writes:

| Gabriel Dos Reis wrote in message
| news:...
| > writes:
|
| [...]
| > | Rien n'empêchait. Et en fait, beaucoup de vocabulaire a été emprunté
| > | du langage OO -- on parle bien d'héritage, des classes dérivées,
| > | etc. Stroustrup a décidé de ne pas suivre le nomenclature « membre
| > | de classe » / « membre d'instance ». Je ne connais pas la raison
| > | derrière cette décision, mais il ne me gène pas outre-mésure. Dans
| > | d'autres cas, par exemple quand il a décidé de ne pas utiliser «
| > | subclass » et « superclass », il a expliqué pourquoi. Mais pas ici,
| > | ou plutôt, je n'ai jamais vu une explication. Peut-être Gaby en
| > | connaît une (bien que comme j'ai dit, je ne trouve pas qu'une
| > | explication soit nécessaire).
|
| > J'ai bien lu ta phrase entre parenthèses mais je ne comprends pas très
| > bien tes deux premières phrases. Comme tu le sais,
|
| Ne suppose pas trop en ce qui concerne ce que je sais. Je connais bien

J'ai trouvé plus courtois de penser que quelqu'un qui se vante de
commencer à programmer en C++ lorsque j'étais encore dans la brousse
s'est renseigné sur son outil et connait un bon bout de son histoire,
que de croire qu'il fait simplement du vacarme relevant de la vantardise
sans fond.

| la partie de l'histoire du C++ que j'ai vecu -- à partir de 1992, grosso
| modo (mais l'utilisation déjà alors des compilateurs périmés m'en a
| exposé un peu de l'histoire postérieure). En ce qui concerne l'histoire
| ancienne, avant que le langage ait réelement commencé à se répandre, je
| n'en connais que des brides.

J'avais également supposé que quelqu'un qui utilise C++ comme un outil
professionnel et qui discute des détails et les concepts de C++
a lu D&E. Bien sûr, on peut arguer que c'est une histoire écrite avec
des « coloured glasses », mais au moins c'est une source d'information
assez fiable -- à défaut d'en avoir d'autres.

| > C++ emprunte directement à C et Simula.
|
| Ça, j'ai effectivement entendu. Mais ne connaissant rien de Simula, ça
| ne me donne qu'une moitié de l'ensemble.

Je crois qu'un simple google donne beaucoup de réponses dont les
premières contiennent des liens que Michel a postés.

[...]

| > Certes, cette assertion n'est pas fausse mais cela ne donne pas une
| > idée de ce que c'est. Comme, je n'arrive pas à trouver sommeil parce
| > qu'il fait chaud, je me suis occupé à trouver une référence à
| > l'explication que Stroustrup donne -- mon examplaire d'ARM est
| > malheureusement au bureau. Donc du D&E, §13.4, page 288
|
| > A static data member of a class is a member for which there is only
| > one copy rather than one per object. Consequently, a static member
| > can be accessed without referring to any particular object.
|
| > Ici, Stroustrup essaie d'expliquer en des termes simples et généraux
| > la signification de « static » appliqué aux membres d'une classe.
| > Il commence par rappeler que « static » appliqué à une donnée membre
| > veut dire qu'il existe exactement une copie de cette donnée dans tout
| > le programme, au lieu d'avoir une copie (membre) par objet (ou
| > instance) de cette classe.
|
| Mais je sais tout ça.

J'avais pris la peine en introduction de dire « comme tu le sais ».
Tu me fais remarquer que que je ne dois as trop supposer sur ce que tu
sais et tu me ddis que sur sais déjà. Ahem.

| Je ne dis pas autre chose moi-même.
|
| > Cette signification est très proche de la signification originelle de
| > « static » appliquée à une variable locale -- telle que Dennis Ritchie
| > l'imaginait,
|
| Stroustrup a travaillé avec Ritchie ; il peut donc savoir ce que Ritchie
| imaginait. Moi, non.

Tout cela est vrai. Mais Stroustrup aussi a pris la peine d'écrire un
bouquin pour expliquer nombre de choses qu'il sait et qui sont utiles
pour comprendre comment C++ a évolué pour contenir ce qu'il contient
grosso modo en 1994. Ce n'est pas comme s'il n'avait pas pris la peine
d'offrir cela à quiconque considère C++ sérieusement.

| En C, déjà, le mot avait deux significations bien distinctes.

Oui. Et Stroustrup a encore pris la peine d'offrir l'opinon de Dennis
Ritchie très récemment dans le message c++std-all-2789.

[...]

| Maintenant, si tu ne considères que la signification de statique à
| l'intérieur d'une fonction, j'avoue qu'il y a une très forte apparenté
| avec sa signification appliquée à une variable membre d'une classe. Si
| tu pars du principe que static a plusieurs significations, en revanche,
| et que la plus important concerne le linkage, l'apparenté est moins
| immédiatement évidente.

Tu peux douter de ce que je dis. Tu peux aussi lire D&E. Ou aussi
demander à Stroustrup. (L'excuse qu'il a probablement autre chose à
faire est irrecevable).

| > Il faut bien ici voir la différence avec une variable locale qui
| > aurait une durée de stockage automatique.
|
| > Une telle variable locale est conceptuellement « instanciée » à chaque
| > appel à la fonction qui la contient ou, en jargon technique, à chaque
| > activation de la structure de calcul de la fonction. Donc, tout comme
| > les données membres des objets d'une classe donnée, il existe une
| > copie par activation. L'utilisation de « static », comme Dennis
| > Ritchie l'a conçu au départ, c'est pour dire qu'une telle donnée
| > n'appartient pas à une instance particulière de la fonction, mais à
| > toutes les instances de la fonction. En somme, la notion de donnée
| > membre statique telle que Stroustrup l'a conçue est une excellente
| > généralisation de variable locale statique conçue par Ritchie.
|
| Tout à fait. Là, je comprends bien le rapprochement.
|
| Il faut dire que mes expériences avec C ne rémonte pas au delà des
| années 80, et le K&R1. Et que déjà alors, la signification primaire de
| static concernait le linkage ; son utilisation sur des variables locales
| était considérée comme une utilisation sécondaire, de moindre
| importance. Du coup, évidemment, le choix du mot paraissait un peu
| curieux, mais bien, qui s'attend à ce que tout soit parfaitement
| logique. (Logique aurait été, évidemment, qu'il n'y ait pas de linkage
| par défaut, et qu'il ait un mot clé global pour signifier que le nom
| était visible ailleurs.)

La « dépcréiation » de static est dans ce sens. D'ailleurs D&E le
souligne.

| > Une fois rappelée cette idée qu'une donnée membre statique est, par
| > définition, l'idée même qu'il en existe une et une seule copie et
| > qu'elle n'appartient pas à un objet particulier, Stroustrup poursuit :
|
| > A static member function is not associated with any particular
| > object and need not be called using the special function syntax.
|
| > Il me paraît évident que la notion de static appliqué à un membre
| > d'une classe (que ce soit une donnée ou une fonction) est cohérente.
|
| Disons que si on connaît l'histoire de comment Stroustrup y est arrivé,
| on pourrait voir le lien. En régardant le status quo aujourd'hui, je ne
| vois qu'une parenté lointain.

Il y a au moins une source d'histoire pour qui se pose ces genres de
question : D&E.

| Note bien que la façon qu'on voit les choses dépend aussi du point de
| vue qu'on prend. Si on considère que static ne doit avoir qu'un seul
| sens, et qu'on le cherche, la parenté est apparente. Si on part du
| principe que la signification initiale (ou au moins, la plus importante
| dans le C) concerne le linkage, et que le mot clé a plusieurs

Oui, mais la signification initiale n'a jamais été le linkage.

| significations non apparentées, on rémarque tout de suite les
| différences.

C'est sûr que quand on a les mauvaises prémisses, on voit que ça
marche pas ;-p

[...]

| Si on commence à enseigner que pour restreindre la visibilité, on se
| sert des namespaces anonymes, et qu'il arrive une génération de

Ce qui serait une erreur : les namespace non nommés ne restreingnent
pas la visibilité.

[...]

-- Gaby
7 8 9 10 11