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...
Y'a un endroit où on peut avoir la liste des erreurs contenues dans cette version?
Vincent Guichard
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...
Y'a un endroit où on peut avoir la liste des erreurs contenues dans
cette version?
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...
Y'a un endroit où on peut avoir la liste des erreurs contenues dans cette version?
Vincent Guichard
drkm
writes:
drkm wrote in message news:...
Fabien LE LEZ writes:
Exemple :
// .h
class Main { static size t const TAILLE TABLEAU= 12; unsigned tableau [TAILLE TABLEAU]; };
// .cpp
size t const Main::TAILLE TABLEAU;
Est-on obligé dans ce cas, celui d'une constante entière initialisée dans un en-tête, de la définire par ailleurs ?
Oui. Ce n'est toujours qu'une declaration, et il faut donc une définition.
En revanche, si tu n'en prends pas l'adresse, c'est possible que le compilateur/éditeur de liens ne remarque pas l'absence de la définition, et que le code marche quand même.
Et que se passe-t-il dans :
// .h
class Main { static size_t const TAILLE TABLEAU= 12; unsigned tableau [TAILLE TABLEAU]; };
// .cpp
size_t const Main::TAILLE TABLEAU = 21 ; // une autre valeur ...
Est-ce explicitement interdit ? Ou est-ce cela se butte de toute manière à une autre restriction ?
--drkm
kanze@gabi-soft.fr writes:
drkm <usenet.fclcxx@fgeorges.org> wrote in message
news:<wk7jvn5cju.fsf@fgeorges.org>...
Fabien LE LEZ <gramster@gramster.com> writes:
Exemple :
// .h
class Main
{
static size t const TAILLE TABLEAU= 12;
unsigned tableau [TAILLE TABLEAU];
};
// .cpp
size t const Main::TAILLE TABLEAU;
Est-on obligé dans ce cas, celui d'une constante entière initialisée
dans un en-tête, de la définire par ailleurs ?
Oui. Ce n'est toujours qu'une declaration, et il faut donc une
définition.
En revanche, si tu n'en prends pas l'adresse, c'est possible que le
compilateur/éditeur de liens ne remarque pas l'absence de la définition,
et que le code marche quand même.
Et que se passe-t-il dans :
// .h
class Main
{
static size_t const TAILLE TABLEAU= 12;
unsigned tableau [TAILLE TABLEAU];
};
// .cpp
size_t const Main::TAILLE TABLEAU = 21 ; // une autre valeur ...
Est-ce explicitement interdit ? Ou est-ce cela se butte de toute
manière à une autre restriction ?
class Main { static size t const TAILLE TABLEAU= 12; unsigned tableau [TAILLE TABLEAU]; };
// .cpp
size t const Main::TAILLE TABLEAU;
Est-on obligé dans ce cas, celui d'une constante entière initialisée dans un en-tête, de la définire par ailleurs ?
Oui. Ce n'est toujours qu'une declaration, et il faut donc une définition.
En revanche, si tu n'en prends pas l'adresse, c'est possible que le compilateur/éditeur de liens ne remarque pas l'absence de la définition, et que le code marche quand même.
Et que se passe-t-il dans :
// .h
class Main { static size_t const TAILLE TABLEAU= 12; unsigned tableau [TAILLE TABLEAU]; };
// .cpp
size_t const Main::TAILLE TABLEAU = 21 ; // une autre valeur ...
Est-ce explicitement interdit ? Ou est-ce cela se butte de toute manière à une autre restriction ?
--drkm
drkm
writes:
drkm wrote in message news:...
J'ai bien dit :
En revanche, le comité C a, je crois, dit que le droit de mettre le ^^^^^^^^^^^
static autre part qu'au début est « deprecated » ; c'est donc que c'est officiellement considéré mauvais style.
Cela m'avait échappé.
C'est donc dans la norme C qu'il faut chercher : §6.11.5 « The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. »
Merci.
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. Et j'avoue que, ayant été amené cette année à délaissé le C++ pour le C, je me retrouve de temps en temps avec cette habitude :~/.
Et maintenant, si le poster original n'est pas complètement perdu, c´est un miracle:-).
:-)
--drkm
kanze@gabi-soft.fr writes:
drkm <usenet.fclcxx@fgeorges.org> wrote in message
news:<wk4qqputmp.fsf@fgeorges.org>...
J'ai bien dit :
En revanche, le comité C a, je crois, dit que le droit de mettre le
^^^^^^^^^^^
static autre part qu'au début est « deprecated » ; c'est donc que
c'est officiellement considéré mauvais style.
Cela m'avait échappé.
C'est donc dans la norme C qu'il faut chercher : §6.11.5 « The placement
of a storage-class specifier other than at the beginning of the
declaration specifiers in a declaration is an obsolescent feature. »
Merci.
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. Et j'avoue que, ayant été amené cette année à
délaissé le C++ pour le C, je me retrouve de temps en temps avec cette
habitude :~/.
Et maintenant, si le poster original n'est pas complètement perdu, c´est
un miracle:-).
En revanche, le comité C a, je crois, dit que le droit de mettre le ^^^^^^^^^^^
static autre part qu'au début est « deprecated » ; c'est donc que c'est officiellement considéré mauvais style.
Cela m'avait échappé.
C'est donc dans la norme C qu'il faut chercher : §6.11.5 « The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. »
Merci.
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. Et j'avoue que, ayant été amené cette année à délaissé le C++ pour le C, je me retrouve de temps en temps avec cette habitude :~/.
Et maintenant, si le poster original n'est pas complètement perdu, c´est un miracle:-).
:-)
--drkm
drkm
Vincent Guichard writes:
Y'a un endroit où on peut avoir la liste des erreurs contenues dans cette version?
Dans la nouvelle version ?-)
--drkm
Vincent Guichard <vg.bleuciel.sa@wanadoo.fr> writes:
Y'a un endroit où on peut avoir la liste des erreurs contenues dans
cette version?
Y'a un endroit où on peut avoir la liste des erreurs contenues dans cette version?
Dans la nouvelle version ?-)
--drkm
Gabriel Dos Reis
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 ».
ouep, mais cela ne change pas grand chose. Les sémantique de la déclaration d'un objet ou d'une fonction à portée de namespace avec « static » sont très proches (sinon presque identiques) et simples à expliquer. Rendre l'une « deprecated » sans l'autre est une bonne recette pour créer de la confusion.
Et comme je l'ai toujours expliqué, ici ou sur le réflecteur du comité ou dans les newsgroups anglophones, l'usage de static pour déclarer les fonctions à portée de namespace affecte la recherche des noms pendant l'instantiation des templates -- en particulier, il empêche qu'un nom de fonction locale à une unité de traduction/instantiation ne fasse des voyages trans-unité de traduction/instantiation, i.e. une telle fonction est vraiment locale à l'unité de traduction. La même chose n'est pas vraie si on utilise des namespace non nommés.
| 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. »
Et vu que la norme ne définit pas ce que veut dire « deprecated », on est bien avancé :-) :-)
-- Gaby
kanze@gabi-soft.fr 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 ».
ouep, mais cela ne change pas grand chose. Les sémantique de la
déclaration d'un objet ou d'une fonction à portée de namespace avec
« static » sont très proches (sinon presque identiques) et simples à
expliquer. Rendre l'une « deprecated » sans l'autre est une bonne
recette pour créer de la confusion.
Et comme je l'ai toujours expliqué, ici ou sur le réflecteur du comité
ou dans les newsgroups anglophones, l'usage de static pour déclarer
les fonctions à portée de namespace affecte la recherche des
noms pendant l'instantiation des templates -- en particulier, il
empêche qu'un nom de fonction locale à une unité de
traduction/instantiation ne fasse des voyages trans-unité de
traduction/instantiation, i.e. une telle fonction est vraiment locale
à l'unité de traduction. La même chose n'est pas vraie si on utilise
des namespace non nommés.
| 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. »
Et vu que la norme ne définit pas ce que veut dire « deprecated », on
est bien avancé :-) :-)
| 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 ».
ouep, mais cela ne change pas grand chose. Les sémantique de la déclaration d'un objet ou d'une fonction à portée de namespace avec « static » sont très proches (sinon presque identiques) et simples à expliquer. Rendre l'une « deprecated » sans l'autre est une bonne recette pour créer de la confusion.
Et comme je l'ai toujours expliqué, ici ou sur le réflecteur du comité ou dans les newsgroups anglophones, l'usage de static pour déclarer les fonctions à portée de namespace affecte la recherche des noms pendant l'instantiation des templates -- en particulier, il empêche qu'un nom de fonction locale à une unité de traduction/instantiation ne fasse des voyages trans-unité de traduction/instantiation, i.e. une telle fonction est vraiment locale à l'unité de traduction. La même chose n'est pas vraie si on utilise des namespace non nommés.
| 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. »
Et vu que la norme ne définit pas ce que veut dire « deprecated », on est bien avancé :-) :-)
-- Gaby
Gabriel Dos Reis
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.
-- Gaby
drkm <usenet.fclcxx@fgeorges.org> 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.
| > 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.
-- Gaby
Gabriel Dos Reis
writes:
| drkm wrote in message | news:... | > Fabien LE LEZ writes: | | > > Exemple : | | > > // .h | | > > class Main | > > { | > > static size t const TAILLE TABLEAU= 12; | > > unsigned tableau [TAILLE TABLEAU]; | > > }; | | > > // .cpp | | > > size t const Main::TAILLE TABLEAU; | | > Est-on obligé dans ce cas, celui d'une constante entière initialisée | > dans un en-tête, de la définire par ailleurs ? | | Oui. Ce n'est toujours qu'une declaration, et il faut donc une | définition. | | En revanche, si tu n'en prends pas l'adresse, c'est possible que le | compilateur/éditeur de liens ne remarque pas l'absence de la définition, | et que le code marche quand même.
À noter que « en prendre » peut prendre plusieurs formes. Il y a l'évident &Main::TAILLE. Mais il y a aussi, par exemple, std::max(Main::TAILLE, 89) puisque std::max prendre ses arguments par référence.
-- Gaby
kanze@gabi-soft.fr writes:
| drkm <usenet.fclcxx@fgeorges.org> wrote in message
| news:<wk7jvn5cju.fsf@fgeorges.org>...
| > Fabien LE LEZ <gramster@gramster.com> writes:
|
| > > Exemple :
|
| > > // .h
|
| > > class Main
| > > {
| > > static size t const TAILLE TABLEAU= 12;
| > > unsigned tableau [TAILLE TABLEAU];
| > > };
|
| > > // .cpp
|
| > > size t const Main::TAILLE TABLEAU;
|
| > Est-on obligé dans ce cas, celui d'une constante entière initialisée
| > dans un en-tête, de la définire par ailleurs ?
|
| Oui. Ce n'est toujours qu'une declaration, et il faut donc une
| définition.
|
| En revanche, si tu n'en prends pas l'adresse, c'est possible que le
| compilateur/éditeur de liens ne remarque pas l'absence de la définition,
| et que le code marche quand même.
À noter que « en prendre » peut prendre plusieurs formes. Il y a
l'évident &Main::TAILLE. Mais il y a aussi, par exemple,
std::max(Main::TAILLE, 89) puisque std::max prendre ses arguments
par référence.
| drkm wrote in message | news:... | > Fabien LE LEZ writes: | | > > Exemple : | | > > // .h | | > > class Main | > > { | > > static size t const TAILLE TABLEAU= 12; | > > unsigned tableau [TAILLE TABLEAU]; | > > }; | | > > // .cpp | | > > size t const Main::TAILLE TABLEAU; | | > Est-on obligé dans ce cas, celui d'une constante entière initialisée | > dans un en-tête, de la définire par ailleurs ? | | Oui. Ce n'est toujours qu'une declaration, et il faut donc une | définition. | | En revanche, si tu n'en prends pas l'adresse, c'est possible que le | compilateur/éditeur de liens ne remarque pas l'absence de la définition, | et que le code marche quand même.
À noter que « en prendre » peut prendre plusieurs formes. Il y a l'évident &Main::TAILLE. Mais il y a aussi, par exemple, std::max(Main::TAILLE, 89) puisque std::max prendre ses arguments par référence.
-- Gaby
Gabriel Dos Reis
drkm writes:
| Et que se passe-t-il dans : | | // .h | | class Main | { | static size_t const TAILLE TABLEAU= 12; | unsigned tableau [TAILLE TABLEAU]; | }; | | // .cpp | | size_t const Main::TAILLE TABLEAU = 21 ; // une autre valeur ...
Invalide.
-- Gaby
drkm <usenet.fclcxx@fgeorges.org> writes:
| Et que se passe-t-il dans :
|
| // .h
|
| class Main
| {
| static size_t const TAILLE TABLEAU= 12;
| unsigned tableau [TAILLE TABLEAU];
| };
|
| // .cpp
|
| size_t const Main::TAILLE TABLEAU = 21 ; // une autre valeur ...
| Et que se passe-t-il dans : | | // .h | | class Main | { | static size_t const TAILLE TABLEAU= 12; | unsigned tableau [TAILLE TABLEAU]; | }; | | // .cpp | | size_t const Main::TAILLE TABLEAU = 21 ; // une autre valeur ...
Invalide.
-- Gaby
Gabriel Dos Reis
writes:
| "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).
Je crois que tout le monde a compris cela.
Le point soulevé par Alain et d'autres est que parle *de* C++ uniquement *en* C++ est très limitatif et n'éclaire pas sur les concepts fondamentaux (qui sont indépendantes de syntaxes particulières). Penses-tu que cela est faux ?
-- Gaby
kanze@gabi-soft.fr writes:
| "Alain Naigeon" <anaigeon@free.fr> wrote in message
| news:<409ea014$0$21078$626a14ce@news.free.fr>...
| > "James Kanze" <kanze@gabi-soft.fr> a écrit dans le message news:
| > 86u0yq7xhb.fsf@lns-th2-1-82-64-2-191.adsl.proxad.net...
| > > drkm <usenet.fclcxx@fgeorges.org> writes:
|
| > > |> "Alain Naigeon" <anaigeon@free.fr> 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).
Je crois que tout le monde a compris cela.
Le point soulevé par Alain et d'autres est que parle *de* C++
uniquement *en* C++ est très limitatif et n'éclaire pas sur les
concepts fondamentaux (qui sont indépendantes de syntaxes
particulières). Penses-tu que cela est faux ?
| "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).
Je crois que tout le monde a compris cela.
Le point soulevé par Alain et d'autres est que parle *de* C++ uniquement *en* C++ est très limitatif et n'éclaire pas sur les concepts fondamentaux (qui sont indépendantes de syntaxes particulières). Penses-tu que cela est faux ?
