"Michel Michaud" wrote in message news:<dMYKa.7067$...
Il me semble que personne n'a mentionné qu'une fonction statique d'une classe aura la possibilité d'accéder aux données privées d'un objet de la classe (reçu en paramètre ou déclaré autrement, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
car il n'y a pas de this évidemment).
J'avais compris (peut-être à tort) que la comparaison se faisait entre un namespace et une classe dont tous les membres étaient statiques. Dans ce cas-là, il n'y a pas de données privées d'un objet.
J'ai élargi la discussion (voir ci-haut pour être bien sûr que tu as vu :-). En fait, j'aurais dû dire « éléments privés »...
Je me demande s'il y aurait une raison de faire une classe avec seulement des éléments statiques, dont certains seraient privés ?
[...]
À l'opposé, un avantage du namespace est qu'on peut faire un using pour éviter de préfixer tous les emplois...
Avantage ?
Parfois clarté, simplicité, lisibilité (souvent la répétition de std:: suffit à rendre lourd et illisible, alors j'imagine ce que ça donnerait avec GabiCorp:: :-)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:d6652001.0306300049.1412e591@posting.google.com,
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<dMYKa.7067$OE2.841584@news20.bellglobal.com>...
Il me semble que personne n'a mentionné qu'une fonction statique
d'une classe aura la possibilité d'accéder aux données privées
d'un objet de la classe (reçu en paramètre ou déclaré autrement,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
car il n'y a pas de this évidemment).
J'avais compris (peut-être à tort) que la comparaison se faisait
entre un namespace et une classe dont tous les membres étaient
statiques. Dans ce cas-là, il n'y a pas de données privées d'un
objet.
J'ai élargi la discussion (voir ci-haut pour être bien sûr que
tu as vu :-). En fait, j'aurais dû dire « éléments privés »...
Je me demande s'il y aurait une raison de faire une classe avec
seulement des éléments statiques, dont certains seraient privés ?
[...]
À l'opposé, un avantage du namespace est qu'on peut faire un using
pour éviter de préfixer tous les emplois...
Avantage ?
Parfois clarté, simplicité, lisibilité (souvent la répétition de
std:: suffit à rendre lourd et illisible, alors j'imagine ce que
ça donnerait avec GabiCorp:: :-)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
"Michel Michaud" wrote in message news:<dMYKa.7067$...
Il me semble que personne n'a mentionné qu'une fonction statique d'une classe aura la possibilité d'accéder aux données privées d'un objet de la classe (reçu en paramètre ou déclaré autrement, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
car il n'y a pas de this évidemment).
J'avais compris (peut-être à tort) que la comparaison se faisait entre un namespace et une classe dont tous les membres étaient statiques. Dans ce cas-là, il n'y a pas de données privées d'un objet.
J'ai élargi la discussion (voir ci-haut pour être bien sûr que tu as vu :-). En fait, j'aurais dû dire « éléments privés »...
Je me demande s'il y aurait une raison de faire une classe avec seulement des éléments statiques, dont certains seraient privés ?
[...]
À l'opposé, un avantage du namespace est qu'on peut faire un using pour éviter de préfixer tous les emplois...
Avantage ?
Parfois clarté, simplicité, lisibilité (souvent la répétition de std:: suffit à rendre lourd et illisible, alors j'imagine ce que ça donnerait avec GabiCorp:: :-)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
