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.
drkm <usenet.fclcxx@fgeorges.org> writes:
|> James Kanze <kanze@gabi-soft.fr> 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.
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.
"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 ?
"James Kanze" <kanze@gabi-soft.fr> a écrit dans le message news:
86llk27x17.fsf@lns-th2-1-82-64-2-191.adsl.proxad.net...
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 ?
"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 ?
"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
"Alain Naigeon" <anaigeon@free.fr> writes:
| "James Kanze" <kanze@gabi-soft.fr> a écrit dans le message news:
| 86llk27x17.fsf@lns-th2-1-82-64-2-191.adsl.proxad.net...
| > drkm <usenet.fclcxx@fgeorges.org> writes:
| >
| > |> James Kanze <kanze@gabi-soft.fr> 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
"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
"James Kanze" a écrit dans le message news:drkm writes:
|> James Kanze writes:
|> > drkm writes:
|> [...]
|> > |> Tiens. J'ai toujours trouvé, de manière intuitive, que
|> > |> ces deux concepts étaient fortement apparentés. En fait,
|> > |> je n'y ai jamais vu qu'un unique concept : faire du membre
|> > |> déclaré un membre de classe.
|> > Vue que tout ce qu'on déclare à l'intérieur d'une classe est
|> > membre de la classe, je ne comprends pas la signification de
|> > ta phrase par rapport à static.
|> J'employais « membre de classe » par opposition à « membre
|> d'instance ».
Le problème, c'est que le C++ ne connaît pas le concepte « membre
d'instance ». En C++, un membre d'une classe peut être soit
statique, soit non-statique, c'est tout.
Le problème, c'est qu'en principe une explication ne doit pas être
circulaire ; or "statique" ne veut rien dire (immobile ??) d'autre que
le sens que lui donne... C++.
Alors on est bien avancé ;-)
Dire que C++ ne connaît pas classe et instance, c'est peut-être vrai
au niveau du vocabulaire, mais enfin "new" fait bien quelque chose,
il me semble. Est-ce coupable de mettre un peu de concepts derrière
tout ça ? Et s'il faut les chercher ailleurs, est-ce vraiment un
compliment à l'égard de C++ ?
"James Kanze" <kanze@gabi-soft.fr> a écrit dans le message news:
86pt9e7x9k.fsf@lns-th2-1-82-64-2-191.adsl.proxad.net...
drkm <usenet.fclcxx@fgeorges.org> writes:
|> James Kanze <kanze@gabi-soft.fr> writes:
|> > drkm <usenet.fclcxx@fgeorges.org> writes:
|> [...]
|> > |> Tiens. J'ai toujours trouvé, de manière intuitive, que
|> > |> ces deux concepts étaient fortement apparentés. En fait,
|> > |> je n'y ai jamais vu qu'un unique concept : faire du membre
|> > |> déclaré un membre de classe.
|> > Vue que tout ce qu'on déclare à l'intérieur d'une classe est
|> > membre de la classe, je ne comprends pas la signification de
|> > ta phrase par rapport à static.
|> J'employais « membre de classe » par opposition à « membre
|> d'instance ».
Le problème, c'est que le C++ ne connaît pas le concepte « membre
d'instance ». En C++, un membre d'une classe peut être soit
statique, soit non-statique, c'est tout.
Le problème, c'est qu'en principe une explication ne doit pas être
circulaire ; or "statique" ne veut rien dire (immobile ??) d'autre que
le sens que lui donne... C++.
Alors on est bien avancé ;-)
Dire que C++ ne connaît pas classe et instance, c'est peut-être vrai
au niveau du vocabulaire, mais enfin "new" fait bien quelque chose,
il me semble. Est-ce coupable de mettre un peu de concepts derrière
tout ça ? Et s'il faut les chercher ailleurs, est-ce vraiment un
compliment à l'égard de C++ ?
"James Kanze" a écrit dans le message news:drkm writes:
|> James Kanze writes:
|> > drkm writes:
|> [...]
|> > |> Tiens. J'ai toujours trouvé, de manière intuitive, que
|> > |> ces deux concepts étaient fortement apparentés. En fait,
|> > |> je n'y ai jamais vu qu'un unique concept : faire du membre
|> > |> déclaré un membre de classe.
|> > Vue que tout ce qu'on déclare à l'intérieur d'une classe est
|> > membre de la classe, je ne comprends pas la signification de
|> > ta phrase par rapport à static.
|> J'employais « membre de classe » par opposition à « membre
|> d'instance ».
Le problème, c'est que le C++ ne connaît pas le concepte « membre
d'instance ». En C++, un membre d'une classe peut être soit
statique, soit non-statique, c'est tout.
Le problème, c'est qu'en principe une explication ne doit pas être
circulaire ; or "statique" ne veut rien dire (immobile ??) d'autre que
le sens que lui donne... C++.
Alors on est bien avancé ;-)
Dire que C++ ne connaît pas classe et instance, c'est peut-être vrai
au niveau du vocabulaire, mais enfin "new" fait bien quelque chose,
il me semble. Est-ce coupable de mettre un peu de concepts derrière
tout ça ? Et s'il faut les chercher ailleurs, est-ce vraiment un
compliment à l'égard de C++ ?
"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 ?
Je n'en sais rien, mais quelque chose de seulement dépréciée ne
facilitera jamais la compilation. Quant à interdire tout bonnement cet
usage, cela me semble casser avec beaucoup d'existant, ce qui, je
crois, a toujours été un grand frein au sein du comité.
Personnellement je trouve cela beaucoup plus clair, mais je ne
connais pas l'intention. En fait, je viens de chercher, et je n'ai pas
trouvé que cet usage était déprécié, ni dans 7.1, ni dans l'annexe D.
Je n'ai rien trouvé non plus sur le site du comité (j'ai survolé). Où
cela est-il dit ?
"Alain Naigeon" <anaigeon@free.fr> writes:
"James Kanze" <kanze@gabi-soft.fr> a écrit dans le message news:
86llk27x17.fsf@lns-th2-1-82-64-2-191.adsl.proxad.net...
[...]
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 ?
Je n'en sais rien, mais quelque chose de seulement dépréciée ne
facilitera jamais la compilation. Quant à interdire tout bonnement cet
usage, cela me semble casser avec beaucoup d'existant, ce qui, je
crois, a toujours été un grand frein au sein du comité.
Personnellement je trouve cela beaucoup plus clair, mais je ne
connais pas l'intention. En fait, je viens de chercher, et je n'ai pas
trouvé que cet usage était déprécié, ni dans 7.1, ni dans l'annexe D.
Je n'ai rien trouvé non plus sur le site du comité (j'ai survolé). Où
cela est-il dit ?
"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 ?
Je n'en sais rien, mais quelque chose de seulement dépréciée ne
facilitera jamais la compilation. Quant à interdire tout bonnement cet
usage, cela me semble casser avec beaucoup d'existant, ce qui, je
crois, a toujours été un grand frein au sein du comité.
Personnellement je trouve cela beaucoup plus clair, mais je ne
connais pas l'intention. En fait, je viens de chercher, et je n'ai pas
trouvé que cet usage était déprécié, ni dans 7.1, ni dans l'annexe D.
Je n'ai rien trouvé non plus sur le site du comité (j'ai survolé). Où
cela est-il dit ?
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 ?
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 ?
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 ?
"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 ?
"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 ?
"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 ?