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
5 6 7 8 9
Avatar
Alain Naigeon
"Gabriel Dos Reis" a écrit dans le message
news:

Concrêtement, même si c'était interdit,


Effectivement, j'avais en idée que "deprecated" était fait
décourager l'utilisation, avec à la clé la menace qu'un
jour ce serait interdit - et je me plaçais donc déjà dans
cette situation d'interdiction.

je ne vois pas très bien ce
que cela facilite puisque les autres spécificateurs de déclaration
(const, unsigned, short, long, ...) sont autorisés à apparaître dans
le « desordre » -- donc le compilateur doit quand même se faire une
liste de ces machines et faire une boucle pour les pêcher et enfin
mettre les choses à « l'endroit ».


Ok, c'est clair.

Qu'on enlève les
storage-class-specifier ne change pas fondamentalement la complexité de
la chose.


Bon, je me disais que savoir où allouer, c'était une info encore
plus vitale (en tout cas préalable) que de savoir combien allouer,
et je pensais donc que c'était "sympa" d'être sûr de trouver ça
en tête. Mais je n'ai jamais démonté un compilateur ;-) donc c'est
juste pour t'expliquer quelle idée tortueuse m'avait amené à penser
cela.
En fait, mon erreur c'est probalement d'oublier que "en-tête", après
analyse, ne veut plus rien dire ; les qualificateurs d'une déclaration
vont peut-être dans une structure, et quand on rencontre const,
ou static, etc, on met un truc à true, et puis à la fin, au moment
d'allouer, on consulte la structure dans l'ordre qu'on veut, donc
rien n'empêche de vérifier en premier si static est à true, même s'il
n'était pas en tête de la déclaration dans le source.


Une préférence est juste ça : une préférence. Je préfère le vin blanc
français au vin blanc texan, je n'ai pas à argumenter. Si je dis que
le vin français est meilleur que le vin texan, alors là oui, il me
faudrait justifier.


Si les deux vins sont sur la carte, mais que le sommelier indique
à chaque table que le vin texan est "deprecated", il exagère
un peu, je trouve. Car, ou bien il laisse les clients libres s'ils ont
déjà leur idée, ou bien il prend ses responsabilités en supprimant
de la carte ce qu'il juge inférieur. Que ce jugement soit personnel,
c'est clair, mais ce n'est pas la question ; c'est plutôt qu'en
exprimant publiquement et systématiquement cette préférence, alors
que son état de sommelier le désigne comme un expert, il glisse
sournoisement vers l'expression d'un pouvoir. Remarque, c'est
fréquent qu'un prix Nobel de physique parle de musique ou de
politique ;-) Naturellement les apparences sont trompeuses,
il semble que dans le cas qui nous occupe ce soit plus légitime.
Eh bien, non (à mes yeux), c'est pourquoi je disais : si un expert
parle sans justification prise dans sa discipline, alors il ne parle
pas en tant qu'expert.

J'en conclus deux choses :
1) évidemment dans un tel cas le lecteur peut prendre du recul
et constater que rien ne l'oblige à adopter cette simple
préférence ;
2) mais aussi : citer le nom de celui qui exprime cette préférence,
c'est déjà une faute, dans la mesure où son nom, pour tous,
renvoie à son expertise, alors qu'en l'occurence il parle sur un
autre mode.

Mr X n'aime pas static ailleurs qu'en-tête.
Mr Stroustrup .... ça fait déjà un autre effet,
car on oublie "n'aime pas" et on pense qu'il
a des arguments.

En plus, quand ce sont des anglophones, c'est encore plus
compliqué : par une exquise délicatesse très typique (je
fréquente certains de leurs NGs), certains diront volontiers
"I wouldn't like...", ou même "I'm not sure I'd like", plutôt
que "je déteste furieusement, avec des arguments qui suivent" :-)

Bon , je me suis éloigné du propos, mais en fait, j'ai toujours
pensé que "deprecated" voulait dire "attention, ne sera plus
supporté un jour".
En fait je te comprends (si j'ai bien saisi) : définir une syntaxe
relativement souple (ordre des qualificateurs), pour ensuite
déconseiller arbitrairement l'un des degrés de liberté, c'est
bizare et, tu l'as souligné, c'est inutilement bizare !

--

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

Avatar
drkm
"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"


Heu, je ne te suis pas. Tu parles toujours de « classes », là ? Ce
qui n'a rien avoir avec les « storage class specifiers ».

--drkm

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

C++ dérive directement de C et de Simula.
[...]

je crois que l'inventeur de C++ refuse de s'enfermer dans un discours
autiste et insiste beaucoup sur les concept généraux pour expliquer la
sémantique de C++.
[...]


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 ».
[...]


Merci, c'est très clair (et argumenté).

--

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
"drkm" a écrit dans le 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"


Heu, je ne te suis pas. Tu parles toujours de « classes », là ? Ce
qui n'a rien avoir avec les « storage class specifiers ».


Ben, on parlait de static, appliqué à une variable membre,
je crois ?!


Sous 3.7 (dans ma version un peu ancienne) :

The storage class specifiers static and auto are related to storage duration
as described below.

Et, justement, below, on voit sous 3.7.1 :

The keyword static applied to a class data member in a class definition
gives the data member static
storage duration.

Donc "storage class specifier" peut bien être employé à propos
du cas qui nous occupe.

--

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


Avatar
drkm
"Alain Naigeon" writes:

"drkm" a écrit dans le message news:


Heu, je ne te suis pas. Tu parles toujours de « classes », là ? Ce
qui n'a rien avoir avec les « storage class specifiers ».


Ben, on parlait de static, appliqué à une variable membre,
je crois ?!


Yep. Mais d'après ce que tu avais écrit, je n'étais pas sûr que tu
ne voulais pas parler de « classes ».

Donc "storage class specifier" peut bien être employé à propos
du cas qui nous occupe.


Tout à fait. « static » est un tel specifier (en français,
spécificateur ?). 7.1.1/1 :

`storage-class-specifier':
auto
register
static
extern
mutable

--drkm


Avatar
drkm
"Alain Naigeon" writes:

Effectivement, j'avais en idée que "deprecated" était fait
décourager l'utilisation, avec à la clé la menace qu'un
jour ce serait interdit - et je me plaçais donc déjà dans
cette situation d'interdiction.


D/2 :

[...] where /deprecated/ is defined as: Normative for the current
edition of the Standard, but not guaranteed to be part of the
standard in future revisions.

J'aime bien l'issue 223
<URL:http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#223> :

However, this definition would appear to say that any
non-deprecated feature is "guaranteed to be part of the Standard
in future revisions." It's not clear that that implication was
intended, so this definition may need to be amended.

--drkm

Avatar
drkm
Gabriel Dos Reis writes:

drkm writes:

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

| Heu, je ne te suis pas. Tu parles toujours de « classes », là ? Ce
| qui n'a rien avoir avec les « storage class specifiers ».

il a une intersection non vide : "classe" :-)


J'avoue que c'est ce qui m'a fait douter de son intention ;-p

--drkm

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

[...]

| analyse, ne veut plus rien dire ; les qualificateurs d'une déclaration
| vont peut-être dans une structure, et quand on rencontre const,
| ou static, etc, on met un truc à true, et puis à la fin, au moment
| d'allouer, on consulte la structure dans l'ordre qu'on veut, donc
| rien n'empêche de vérifier en premier si static est à true, même s'il
| n'était pas en tête de la déclaration dans le source.

C'est à peu près comme cela que les compilateurs parsent les
spécificateurs de déclaration -- parce qu'aucun ordre n'est prescrit.


C'est assez fascinant, finalement : le temps s'écoule pendant
le parcours du source, c'est à dire qu'il est lu, forcément, dans
un certain ordre. Et après, tout est mis "à plat", temporellement,
et l'on peut prélever les infos dans un autre ordre. Je n'avais
jamais explicité (conscientisé) cette propriété des structures
de données ! On pense toujours que conserver l'ordre est une
qualité, mais parfois sa destruction en est une ! Je rapproche
ça d'un autre truc qui m'avait fasciné : si je veux parler d'un
couple (x,y) non ordonné, je n'ai aucune façon de le noter
qui rende visible ce non ordre ; dans toute notation humaine
il y a toujours un "premier lu", soit gauche puis droite, soit
haut puis bas. Autrement dit, il faut un "collapsus" de la
variable "temps" pour arriver à détruire l'ordre. Bigre, il
vaut mieux que je me couche plutôt que de méditer ça
encore cette nuit :-)

Merci pour le lien sur deprecated, j'irai voir... demain.

--

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

Avatar
Michel Michaud
Dans news:c7ndlv$3oo$, Vincent
Edition 2002: tres complet 1100 pages. Mais pas toujours tres
clair. Et consernant static, les explication y sont en
plusieurs endroits.



Et j'ai fait plus de 1000 corrections à cette version, qui
contient beaucoup d'erreurs, des choses farfelues, du
vocabulaire incorrect, des bouts incompréhensibles, etc.

Vraiment tu ne peux pas t'y fier. C'est dommage... Si tu l'as
acheté récemment, fais-toi rembourser et achète la plus
récente version...

Arghh... J'ai cette même version... et comme on me l'a donnée,

je serais bien en peine de me la faire remboursée...


Alors il faut apprendre à l'utiliser en ayant un doute : si
quelque chose semble douteux , en particulier quand ce qu'il
y a d'écrit tout autour semble dire le contraire, il faut vérifier à une
autre source...

Et il faut remplacer « opérateur d'itération » par itérateur,
si tu veux te faire comprendre des autres !

Y'a un endroit où on peut avoir la liste des erreurs contenues
dans cette version?


Non. (en fait, oui, dans ma copie du livre où je les ai
corrigées ! Je le garde en souvenir...)

On avait parlé de quelques erreurs ici, vers le mois de
septembre 2002... Par exemple :

http://minilien.com/?mNuRspWNRR

Ça te donnera une idée...

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



Avatar
Gabriel Dos Reis
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 ?


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

-- Gaby
5 6 7 8 9