Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
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
4 5 6 7 8
Avatar
drkm
Gabriel Dos Reis writes:

Et vu que la norme ne définit pas ce que veut dire « deprecated », on
est bien avancé :-) :-)


Hihi. J'ai été étonné de voir une issue pour changer la définition
de ce mot dans la norme :-).

--drkm

Avatar
drkm
Gabriel Dos Reis writes:

Mon impression est que c'est le résultat d'un enthousiasme débordant
et que de toute façon, ce serait de l'incompatibitlité gratuite si
static était effectivement enlevé (ce que je doute fort). Je ne
serais pas étonné que des versions futures de C++ remettent les
choses à l'endroit.


En même temps, avec la définition de « deprecated » dans la norme,
le comité ne s'engage pas beaucoup en marquant quelque chose comme
déprécié. Comme le dit l'issue sur le sujet, il s'engage plutôt en ne
désignat pas le reste comme déprécié :-).

--drkm

Avatar
Gabriel Dos Reis
James Kanze writes:

| Gabriel Dos Reis writes:
|
| |> drkm writes:
|
| |> [...]
|
| |> | > Quand à l'autre déprécation dont j'ai parlé,
| |> | > l'utilisation de « static » au portée de namespace,
| |> | > comme j'ai dit : « c'est ` deprecated ', ou au moins mal vu
| |> | > des experts ». Je n'étais pas sûr de la position
| |> | > officielle du comité, mais j'avais beaucoup entendu dire que
| |> | > c'est pas du C++ moderne à le faire. Mais enfin, §D.2 :
| |> | > « The use of the static keyword is deprecated when declaring
| |> | > objects in namespace scope. »
|
| |> | Yep. J'étais également tombé dessus. Cela m'avait un
| |> | peu supris, de prime abord, puisqu'il s'agit si je ne m'abuse du
| |> | seul moyen de faire la chose en C.
|
| |> Mon impression est que c'est le résultat d'un enthousiasme
| |> débordant et que de toute façon, ce serait de
| |> l'incompatibitlité gratuite si static était effectivement
| |> enlevé (ce que je doute fort). Je ne serais pas étonné que
| |> des versions futures de C++ remettent les choses à l'endroit.
|
| Déprécié ne veut pas dire enlever.

Oui mais alors quel est le but de passer des heures à arguer
pour/contre déprécier un machin de la norme (au lieu de travailler sur
un autre point de la norme) si c'est pour dire que de toute façon on
ne va pas l'enlever. Je veux dire, pour le programmeur C++, quelle est
la portée pratique d'une telle décision? Clairement, à
l'interssection de C et C++, si on enlève static, il faudra au moins
donner une bonne raison et une autre manière d'exprimer la même chose
(ou équivalente avec un coût moindre).

| Dans la pratique, je crois
| que tu as bien raison -- après tout, je crois qu'il y a des choses
| qui ont été déprécié en Fortran 66 mais qui font encore

Plus proche de nous, des choses ont été dépréciées dans une version de
Java, puis totalement rehabiblitée dans la version d'après.

| partie de la norme Fortran aujourd'hui. Toujours déprécié, mais
| toujours là.
|
| --
| James Kanze
| 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

Avatar
James Kanze
Gabriel Dos Reis writes:

|> drkm writes:

|> [...]

|> | > Quand à l'autre déprécation dont j'ai parlé,
|> | > l'utilisation de « static » au portée de namespace,
|> | > comme j'ai dit : « c'est ` deprecated ', ou au moins mal vu
|> | > des experts ». Je n'étais pas sûr de la position
|> | > officielle du comité, mais j'avais beaucoup entendu dire que
|> | > c'est pas du C++ moderne à le faire. Mais enfin, §D.2 :
|> | > « The use of the static keyword is deprecated when declaring
|> | > objects in namespace scope. »

|> | Yep. J'étais également tombé dessus. Cela m'avait un
|> | peu supris, de prime abord, puisqu'il s'agit si je ne m'abuse du
|> | seul moyen de faire la chose en C.

|> Mon impression est que c'est le résultat d'un enthousiasme
|> débordant et que de toute façon, ce serait de
|> l'incompatibitlité gratuite si static était effectivement
|> enlevé (ce que je doute fort). Je ne serais pas étonné que
|> des versions futures de C++ remettent les choses à l'endroit.

Déprécié ne veut pas dire enlever. Dans la pratique, je crois
que tu as bien raison -- après tout, je crois qu'il y a des choses
qui ont été déprécié en Fortran 66 mais qui font encore
partie de la norme Fortran aujourd'hui. Toujours déprécié, mais
toujours là.

--
James Kanze
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
James Kanze
Gabriel Dos Reis writes:

|> Et vu que la norme ne définit pas ce que veut dire « deprecated », on
|> est bien avancé :-) :-)

Tout à fait:-).

En fait, tout ce qu'on peut dire avec certitude, c'est qu'il y a
certains experts qui ne l'aiment pas.

--
James Kanze
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
"Alain Naigeon" writes:

| "Gabriel Dos Reis" a écrit dans le message
| news:
| > "Alain Naigeon" writes:
| >
| > | "James Kanze" a écrit dans le message news:
| > |
| > | > drkm writes:
| > | >
| > | > |> James Kanze writes:
| > | >
| > | > |> > Quelque petits détails : d'abord, la tradition veut que le mot
| clé
| > | > |> > const précède tout ce qui concerne le type.
| > | > |> ^^^^^
| > | >
| > | > |> Sans doute voulais-tu dire "static" ? Je vois mal sinon comment
| > | > |> respecter cette tradition.
| > | >
| > | > Tout à fait.
| > | >
| > | > J'ai hésité à parler de « storage class », parce que je
| > | > ne suis pas sur qu'un débuttant (qui se débat avec static) se
| > | > trouve à l'aise avec l'expression, mais la tradition veut que les
| > | > « storage class » (« static », « extern », « auto », « register »,
| > | > et en C, « typedef ») viennent en première position.
| > |
| > | A tout hasard : est-ce que "deprecated" en une autre position
| > | que la première, ce ne serait pas parce que cela facilite la
| > | compilation ?
| >
| > Comment ? Le compilateur doit toujours le supporter.
| >
| > -- Gaby
|
| Ok, bien sûr, mais je pensais que la position en tête pouvait
| faciliter les choses.
| Dans ce cas, pourquoi est-ce mauvais ?

Je ne dis pas que c'est mauvais. Je dis que si ce n'est que
« deprecated », le compilateur *doit quand même supporter* les deux
variantes. Au final, ou bien le compilateur

(1) s'en fout -- plus courant
(2) a deux codes pour parser une même déclaration abstraite.

Je ne vois pas ce que cela facilite.

Concrêtement, même si c'était interdit, 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 ». Qu'on enlève les
storage-class-specifier ne change pas fondamentalement la complexité de
la chose.

| Que représente
| exactement "tradition" dans le message de James un peu
| plus haut, juste la préférence de quelques personnes ?

La meilleure personne pour répondre à cette question est probablement
James lui-même.

Mais, je suppose qu'il veut dire par là le code « normal » que
les gens écrivent depuis un bon bout de temps -- si ce n'est le style
consacré par les inventeurs de C ou C++.

| Ce sont des experts, mais une préférence d'expert non
| argumentée, ça n'est plus celle d'un expert ;-)

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.

| (car expert n'est pas gourou)

non, mais quand l'expert dit qu'il « préfère », il se comporte en
gourou :-)

-- Gaby
Avatar
Gabriel Dos Reis
"Alain Naigeon" writes:

| Oui mais : C++ fut créé, alors que les concepts objet, incarnés dans
| d'autres langages, commençaient à avoir du succès.

C++ dérive directement de C et de Simula. Simula a crée le concept
d'orientation objet -- même si d'autres personnes qui reçoivent des
Turing award clament le contraire. Simula a été inventé dans les
années 60 (je crois 67).

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

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

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

| Dans un cas, la variable est partagée par tous les objets,
| dans l'autre elle ne l'est pas, c'est conceptuellement clair, et c'est
| tout ce qu'un programmeur demande de savoir. A la limite, comment
| ça marche, on s'en fout.

jusqu'au jour où il a des problèmes et doit communiquer avec un expert :-).

-- Gaby
Avatar
Alain Naigeon
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. 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. Dans un cas, la variable est partagée par tous les objets,
dans l'autre elle ne l'est pas, c'est conceptuellement clair, et c'est
tout ce qu'un programmeur demande de savoir. A la limite, comment
ça marche, on s'en fout.

--

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
"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.
(En plus ils doivent s'assurer que certaines combinaisons sont
invalides).

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

Oui, mais dans la pratique n'est pas vraiment ce qui se passe ?

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

À quand une réglémentation pour mettre « const », « volatile »,
« const volatile » comme préfixe des types ?

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

Je ne crois pas : un expert peut livrer une analyse et des assertions,
et il doit les justifier. Mais quand il avance une préférence ou un
croyance, par définition, il n'est pas requis de les justifier.
C'est dans dire que quand on parle de sa discipline, on fait la part
de la croyance et du fait. être expert ne veut pas dire qu'on n'a pas
de croyance. Et si on devait demander aux experts de ne pas avoir de
croyance, ce ne serait plus intéressant :-).

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

yep, sauf la « courtoisie. »

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

je crois qu'on appelle cela « argument par autorité. »

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

non, on pense à son « autorité » ;-)

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

je crois que nous sommes en voilent accord avec ça. Maintenant que je
travaille avec Mr X (même s'il n'est pas exactement anglo-saxon) tous
les jours, je crois que j'ai une autre lecture de ses écrits -- et je
crois que je me trompe moins maintenant sur ce qu'il a voulu dire ;
c'est fou comment il est délicat :-)

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

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#223


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

:-)

-- Gaby
Avatar
Gabriel Dos Reis
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" :-)

-- Gaby
4 5 6 7 8