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
6 7 8 9 10
Avatar
kanze
"Alain Naigeon" wrote in message
news:<409ff3f7$0$13076$...
"Gabriel Dos Reis" a écrit dans le
message news:
"Alain Naigeon" writes:

| "James Kanze" a écrit dans le message news:
|



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


Ok, bien sûr, mais je pensais que la position en tête pouvait
faciliter les choses.


Du moment qu'il faut le supporter, ça ne change rien. Ou plutôt, ça rend
les choses légèrement plus complexes -- je fais exactement comme avant,
sauf qu'en plus, si le « storage class » n'est pas en tête, j'émets un
avertissement.

Dans ce cas, pourquoi est-ce mauvais ? Que représente
exactement "tradition" dans le message de James un peu
plus haut, juste la préférence de quelques personnes ?


La tradition dont je faisais référence, c'est surtout le K&R1:-). Sinon,
ça fait partie de plusieurs règles de codage que j'ai vues, aussi bien
en C qu'en C++. Et que je n'ai jamais vu un auteur ou une règle de
codage prends une position contraire (mais beaucoup n'en parlent pas).

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


Dans ce cas-ci, la préférence de l'expert a un certain poids, parce que
les experts ont réussi à incorporer leur préférence dans la norme C.

En fait, il y a deux significations distinctes de « expert ».
Normalement, ici, on a l'habitude de considérer Gaby un expert, parce
qu'on constate qu'il connaît la matière très bien. Mais il y a un autre
sens qu'il est aussi expert : c'est écrit qu'il est expert dans les
comptes-rendus des réunions ISO. Dans ce cas-ci, ce qui est clair, c'est
que la majorité des experts C, le mot expert étant pris dans ce deuxième
sens, préfère que les storage class vient en tête.

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


Ce n'est pas moi qui peut te le dire. Ce n'est pas moi qui a voulu une
déprécation quelconque.

On pourrait aussi démander quel est le but de passer des heurse à arguer
pour/contre n'importe quoi, dans la mésure que les implémentations ne
prète de toute façon pas d'attention à ce qu'on décide (voir export).
Malheureusement, je n'ai pas de réponse à ce problème.

(Logiquement, il n'y en a une que j'aimerais voir : la déprécation des
conversions implicites à perte de valeur. Avec l'idée de les supprimer
réelement un jour ou l'autre. Dans la pratique, en revanche, je ne crois
pas que c'est possible, et que c'est une tare avec laquelle il faut
vivre.)

Je veux dire, pour le programmeur C++, quelle est la portée pratique
d'une telle décision?


Je crois que l'intention, c'est de stimuler les implémentations à
émettre un avertissement. Au moins, c'est ce qu'on a dit quand il a été
question de déprécier les conversions des pointeurs en bool.

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.


Oui, mais je ne sais pas si je prendrais la normalisation de Java comme
(bon) exemple:-). Tandis que Fortran... quoiqu'on dise, c'est un langage
qui a survecu, qui est normalisé par ISO, et dont la norme a eu une
influence réele sur l'évolution du langage.

| partie de la norme Fortran aujourd'hui. Toujours déprécié, mais
| toujours là.


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


Ce n'est pas moi qui peut te le dire. Ce n'est pas moi qui a voulu une
déprécation quelconque.

On pourrait aussi démander quel est le but de passer des heurse à arguer
pour/contre n'importe quoi, dans la mésure que les implémentations ne
prète de toute façon pas d'attention à ce qu'on décide (voir export).
Malheureusement, je n'ai pas de réponse à ce problème.

(Logiquement, il n'y en a une que j'aimerais voir : la déprécation des
conversions implicites à perte de valeur. Avec l'idée de les supprimer
réelement un jour ou l'autre. Dans la pratique, en revanche, je ne crois
pas que c'est possible, et que c'est une tare avec laquelle il faut
vivre.)

Je veux dire, pour le programmeur C++, quelle est la portée pratique
d'une telle décision?


Je crois que l'intention, c'est de stimuler les implémentations à
émettre un avertissement. Au moins, c'est ce qu'on a dit quand il a été
question de déprécier les conversions des pointeurs en bool.

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.


Oui, mais je ne sais pas si je prendrais la normalisation de Java comme
(bon) exemple:-). Tandis que Fortran... quoiqu'on dise, c'est un langage
qui a survecu, qui est normalisé par ISO, et dont la norme a eu une
influence réele sur l'évolution du langage.

| partie de la norme Fortran aujourd'hui. Toujours déprécié, mais
| toujours là.


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

Je ne vois pas de problème non plus à utiliser ce vocabulaire ici, même
si Stroustrup et la norme ne s'en sert pas. Seulement, il ne faut pas
perdre de vue que « membre de classe » a déjà une signification dans le
vocabulaire C++. Si tu veux t'en servir avec une autre signification, il
faut qu'il y ait quelque chose pour le signaler -- comme j'ai dit
ailleurs, une présence explicite de l'expression « membre d'instance »
suffirait.

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.


Je n'en dis pas le contraire, mais l'expression « membre de classe » a
une signification bien précise en C++, et faute d'autre chose, c'est
cette signification qu'on suppose ici.

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.


Je ne dis pas le contraire. C'est aussi une expression précise, qui ne
me servira que pour parler de C ou de C++ (avec une signification
différente dans les deux cas -- en C, typedef est un « 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.


Tout à fait. Je n'ai rien contre. N'empêche que l'expression « membre de
class » a une signification bien précise en C++, et je trouve normal que
quand on l'entend dans un contexte C++, c'est cette signification qui
vient automatiquement à l'ésprit.

Note qu'ici, comme partout, le langage condition la façon de penser. Si
on parle de l'opposition entre les membres d'instance et les membres de
classe, on trouve intuitivement que le mot clé static a à peu près la
même signification appliqué aux fonctions membres qu'appliqué aux
membres données -- moi, en partant de la définition des deux dans la
spécification de C++, je les vois comme deux choses distinctes, liées
principalement par le fait qu'il se déclare au moyen du même mot clé
(qui lui sert pour bien d'autres choses aussi -- j'étais donc préparé,
voire préconditionné, à voir des significations différentes). Mais
enfin, je reconnais bien que les conceptes ne sont ni 100% identiques,
ni 100% étrangers. Que les similitudes ou les différences importe dans
ton ésprit, en fin de compte, c'est une question d'opinion. J'ai une
tendance à accentuer les différences. C'est peut-être parce que j'ai
beaucoup travaillé au bas niveau. Ou c'est peut-être parce que j'étais
préconditionné à voir des différences, étant donné que je m'attends à ce
que static soit surchargé. Ou c'est peut-être simplement que je suis
comme ça.

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

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

| "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. 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, C++ emprunte
directement à C et Simula. 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. »

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à. »
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. Cette signification est très proche de la
signification originelle de « static » appliquée à une variable locale
-- telle que Dennis Ritchie l'imaginait, 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).

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.

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

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

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

[...]

| Note qu'ici, comme partout, le langage condition la façon de penser. Si
| on parle de l'opposition entre les membres d'instance et les membres de
| classe, on trouve intuitivement que le mot clé static a à peu près la
| même signification appliqué aux fonctions membres qu'appliqué aux
| membres données

Et c'est ce qu'explique l'auteur de C++ dans son bouquin « The Design
and Evolution of C++. »

| -- moi, en partant de la définition des deux dans la
| spécification de C++, je les vois comme deux choses distinctes, liées
| principalement par le fait qu'il se déclare au moyen du même mot clé
| (qui lui sert pour bien d'autres choses aussi -- j'étais donc préparé,
| voire préconditionné, à voir des significations différentes). Mais
| enfin, je reconnais bien que les conceptes ne sont ni 100% identiques,
| ni 100% étrangers. Que les similitudes ou les différences importe dans
| ton ésprit, en fin de compte, c'est une question d'opinion. J'ai une
| tendance à accentuer les différences. C'est peut-être parce que j'ai
| beaucoup travaillé au bas niveau. Ou c'est peut-être parce que j'étais
| préconditionné à voir des différences, étant donné que je m'attends à ce
| que static soit surchargé. Ou c'est peut-être simplement que je suis
| comme ça.

Je vais aller rapporter à Bjarne qu'il n'a pas assez travaillé bas
niveau ou qu'il n'était pas préconditionné à voir des différences ;->

-- Gaby
Avatar
Luc Hermitte
James Kanze wrote in news:
62-147-205-199.adsl.proxad.net:

|> > je vais m'en faire un copie et les conserver, si cela ne dérange
|> > pesonne.

|> Usenet est publique, libre à toi. Mais dans ce cas, je
|> préfère conserver un lien vers <URL:groups.google.com>, cela permet
|> de relire la discussion plus facilement, je trouve.

C'est lourd : le URL risque d'être fort long, et qu'est-ce qui se
passera dans le cas (bien peu probable, je l'avoue) que Google fait
faillite ?

Il ne serait pas le premier à faire une petite collection des
postings avec des tips qu'il a trouvés intéressants. Les news sont
là pour ça aussi.


J'ai carrément fclc++ et quelques autres groupes (clc++m, ...) dans mon
cache (Merci Hamster) depuis 3-4 ans. C'est assez pratique.
C'est un bon moyen de tout garder ; et pour les "montrer" aux autres,
avec le message-id, tant que google-groups existe toujours, les messages
seront "montrables".


--
Luc Hermitte <hermitte at free.fr>
FAQ de <news:fr.comp.lang.c++> :
<http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/>
Dejanews : <http://groups.google.com/advanced_group_search>

Avatar
Loïc Joly
Gabriel Dos Reis wrote:
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.


Au sens class-ique ? ;)

--
Loïc

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

"Alain Naigeon" wrote in message
news:<409ff3f7$0$13076$...
"Gabriel Dos Reis" a écrit dans le
message news:
"Alain Naigeon" writes:

| "James Kanze" a écrit dans le message news:
|



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


Ok, bien sûr, mais je pensais que la position en tête pouvait
faciliter les choses.


Du moment qu'il faut le supporter, ça ne change rien. Ou plutôt, ça rend
les choses légèrement plus complexes -- je fais exactement comme avant,
sauf qu'en plus, si le « storage class » n'est pas en tête, j'émets un
avertissement.

Dans ce cas, pourquoi est-ce mauvais ? Que représente
exactement "tradition" dans le message de James un peu
plus haut, juste la préférence de quelques personnes ?


La tradition dont je faisais référence, c'est surtout le K&R1:-). Sinon,
ça fait partie de plusieurs règles de codage que j'ai vues, aussi bien
en C qu'en C++. Et que je n'ai jamais vu un auteur ou une règle de
codage prends une position contraire (mais beaucoup n'en parlent pas).



Merci James !

--

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


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


Dans ce cas-ci, la préférence de l'expert a un certain poids, parce que
les experts ont réussi à incorporer leur préférence dans la norme C.

En fait, il y a deux significations distinctes de « expert ».
Normalement, ici, on a l'habitude de considérer Gaby un expert, parce
qu'on constate qu'il connaît la matière très bien. Mais il y a un autre
sens qu'il est aussi expert : c'est écrit qu'il est expert dans les
comptes-rendus des réunions ISO. Dans ce cas-ci, ce qui est clair, c'est
que la majorité des experts C, le mot expert étant pris dans ce deuxième
sens, préfère que les storage class vient en tête.

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




6 7 8 9 10