Je ne suis pas : on l'appelle avec toto::fonction(); Vu ta signature, tu dois connaitre le C++, donc je comprend pas que tu poses cette question sur les membres statiques d'une classe.
Mmm ma question était mal posée, désolé. Je me suis emmêlé les pinceaux. class MaClasse { bool StaticMember; }; MaClasse::StaticMember=true; Est-ce possible ?
Malgres son nom StaticMember n'est pas un attribut statique donc on va corriger :
class MaClasse { static bool StaticMember; };
///...
MaClasse::StaticMember=true;
Maintenant une autre erreur : en C++ les attributs et methodes sont par defaut private donc tu ne peux acceder a StaticMember de l'exterieur a moins d'etre friend de MaClasse
Donc non tu ne peux le faire. par contre avec ca :
class MaClasse { public: static bool StaticMember; };
///...
MaClasse::StaticMember=true;
C'est valide mais j'ai toujours tendance a 'proteger' les membres static d'une classe modifiables considerant que - generalement c'est une partie du fonctionnement _interne_ de celle-ci. Mais ceci est un autre debat
Frédéri MIAILLE wrote:
Je ne suis pas : on l'appelle avec toto::fonction();
Vu ta signature, tu dois connaitre le C++, donc je comprend pas que tu
poses cette question sur les membres statiques d'une classe.
Mmm ma question était mal posée, désolé. Je me suis emmêlé les pinceaux.
class MaClasse
{
bool StaticMember;
};
MaClasse::StaticMember=true;
Est-ce possible ?
Malgres son nom StaticMember n'est pas un attribut statique donc on va
corriger :
class MaClasse {
static bool StaticMember;
};
///...
MaClasse::StaticMember=true;
Maintenant une autre erreur : en C++ les attributs et methodes sont par
defaut private donc tu ne peux acceder a StaticMember de l'exterieur a
moins d'etre friend de MaClasse
Donc non tu ne peux le faire. par contre avec ca :
class MaClasse {
public:
static bool StaticMember;
};
///...
MaClasse::StaticMember=true;
C'est valide mais j'ai toujours tendance a 'proteger' les membres static
d'une classe modifiables considerant que - generalement c'est une partie
du fonctionnement _interne_ de celle-ci. Mais ceci est un autre debat
Je ne suis pas : on l'appelle avec toto::fonction(); Vu ta signature, tu dois connaitre le C++, donc je comprend pas que tu poses cette question sur les membres statiques d'une classe.
Mmm ma question était mal posée, désolé. Je me suis emmêlé les pinceaux. class MaClasse { bool StaticMember; }; MaClasse::StaticMember=true; Est-ce possible ?
Malgres son nom StaticMember n'est pas un attribut statique donc on va corriger :
class MaClasse { static bool StaticMember; };
///...
MaClasse::StaticMember=true;
Maintenant une autre erreur : en C++ les attributs et methodes sont par defaut private donc tu ne peux acceder a StaticMember de l'exterieur a moins d'etre friend de MaClasse
Donc non tu ne peux le faire. par contre avec ca :
class MaClasse { public: static bool StaticMember; };
///...
MaClasse::StaticMember=true;
C'est valide mais j'ai toujours tendance a 'proteger' les membres static d'une classe modifiables considerant que - generalement c'est une partie du fonctionnement _interne_ de celle-ci. Mais ceci est un autre debat
Frederic Py
Arnaud Meurgues wrote:
Martinez Jerome wrote:
namespace toto { int fonction(); } class toto { static int fonction(); };
Pour l'utilisateur, c'est pareil : toto::fonction();
Pas tout à fait. Une classe est un espace de nom fermé (on ne peut rien y rajouter en dehors du fichier où elle est définie), alors qu'un namespace est un espace ouvert (on peut rajouter des symbols dans un namespace dans n'importe quelle unité de compilation).
On peut ajouter en plus que les namespace n'ont pas de controle d'acces -- tout est public -- alors que les classes ont plusieurs niveau d'acces
Fred
Arnaud Meurgues wrote:
Martinez Jerome wrote:
namespace toto { int fonction(); }
class toto { static int fonction(); };
Pour l'utilisateur, c'est pareil :
toto::fonction();
Pas tout à fait. Une classe est un espace de nom fermé (on ne peut rien
y rajouter en dehors du fichier où elle est définie), alors qu'un
namespace est un espace ouvert (on peut rajouter des symbols dans un
namespace dans n'importe quelle unité de compilation).
On peut ajouter en plus que les namespace n'ont pas de controle d'acces
-- tout est public -- alors que les classes ont plusieurs niveau d'acces
namespace toto { int fonction(); } class toto { static int fonction(); };
Pour l'utilisateur, c'est pareil : toto::fonction();
Pas tout à fait. Une classe est un espace de nom fermé (on ne peut rien y rajouter en dehors du fichier où elle est définie), alors qu'un namespace est un espace ouvert (on peut rajouter des symbols dans un namespace dans n'importe quelle unité de compilation).
On peut ajouter en plus que les namespace n'ont pas de controle d'acces -- tout est public -- alors que les classes ont plusieurs niveau d'acces
Fred
Christophe Lephay
"Arnaud Meurgues" a écrit dans le message de news:3efc4a79$0$24004$
Martinez Jerome wrote:
namespace toto { int fonction(); } class toto { static int fonction(); };
Pour l'utilisateur, c'est pareil : toto::fonction();
Pas tout à fait. Une classe est un espace de nom fermé (on ne peut rien y rajouter en dehors du fichier où elle est définie), alors qu'un namespace est un espace ouvert (on peut rajouter des symbols dans un namespace dans n'importe quelle unité de compilation).
La contrepartie étant qu'on peut hériter d'une classe...
Chris
"Arnaud Meurgues" <arnaud@meurgues.non.fr.invalid> a écrit dans le message
de news:3efc4a79$0$24004$626a54ce@news.free.fr...
Martinez Jerome wrote:
namespace toto { int fonction(); }
class toto { static int fonction(); };
Pour l'utilisateur, c'est pareil :
toto::fonction();
Pas tout à fait. Une classe est un espace de nom fermé (on ne peut rien
y rajouter en dehors du fichier où elle est définie), alors qu'un
namespace est un espace ouvert (on peut rajouter des symbols dans un
namespace dans n'importe quelle unité de compilation).
La contrepartie étant qu'on peut hériter d'une classe...
"Arnaud Meurgues" a écrit dans le message de news:3efc4a79$0$24004$
Martinez Jerome wrote:
namespace toto { int fonction(); } class toto { static int fonction(); };
Pour l'utilisateur, c'est pareil : toto::fonction();
Pas tout à fait. Une classe est un espace de nom fermé (on ne peut rien y rajouter en dehors du fichier où elle est définie), alors qu'un namespace est un espace ouvert (on peut rajouter des symbols dans un namespace dans n'importe quelle unité de compilation).
La contrepartie étant qu'on peut hériter d'une classe...
Chris
Christophe Lephay
"Martinez Jerome" a écrit dans le message de news:bdhikb$
Arnaud Meurgues wrote:
Pas tout à fait. Une classe est un espace de nom fermé (on ne peut rien y rajouter en dehors du fichier où elle est définie), alors qu'un namespace est un espace ouvert (on peut rajouter des symbols dans un namespace dans n'importe quelle unité de compilation).
Quelle est la difference pour l'utilisateur?
Si les fonctions (dans le namespace) ou la classe ont été compilés et que seul le header et le fichier objet sont fournis, l'utilisateur peut y ajouter les fonctions qu'il veut dans le cas d'un namespace, alors qu'il ne le peut pas dans le cas d'une classe (dans ce dernier cas, il est obliger de créer une nouvelle classe dérivée de la première pour y ajouter des fonctions).
Chris
"Martinez Jerome" <jerome.martinez@aenlever-orangefrance.com> a écrit dans
le message de news:bdhikb$a6p1@news.rd.francetelecom.fr...
Arnaud Meurgues wrote:
Pas tout à fait. Une classe est un espace de nom fermé (on ne peut rien
y rajouter en dehors du fichier où elle est définie), alors qu'un
namespace est un espace ouvert (on peut rajouter des symbols dans un
namespace dans n'importe quelle unité de compilation).
Quelle est la difference pour l'utilisateur?
Si les fonctions (dans le namespace) ou la classe ont été compilés et que
seul le header et le fichier objet sont fournis, l'utilisateur peut y
ajouter les fonctions qu'il veut dans le cas d'un namespace, alors qu'il ne
le peut pas dans le cas d'une classe (dans ce dernier cas, il est obliger de
créer une nouvelle classe dérivée de la première pour y ajouter des
fonctions).
"Martinez Jerome" a écrit dans le message de news:bdhikb$
Arnaud Meurgues wrote:
Pas tout à fait. Une classe est un espace de nom fermé (on ne peut rien y rajouter en dehors du fichier où elle est définie), alors qu'un namespace est un espace ouvert (on peut rajouter des symbols dans un namespace dans n'importe quelle unité de compilation).
Quelle est la difference pour l'utilisateur?
Si les fonctions (dans le namespace) ou la classe ont été compilés et que seul le header et le fichier objet sont fournis, l'utilisateur peut y ajouter les fonctions qu'il veut dans le cas d'un namespace, alors qu'il ne le peut pas dans le cas d'une classe (dans ce dernier cas, il est obliger de créer une nouvelle classe dérivée de la première pour y ajouter des fonctions).
Chris
Frédéri MIAILLE
"Frederic Py" a écrit dans le message news: bdhut8$pem$
Frédéri MIAILLE wrote:
Je ne suis pas : on l'appelle avec toto::fonction(); Vu ta signature, tu dois connaitre le C++, donc je comprend pas que tu poses cette question sur les membres statiques d'une classe.
Mmm ma question était mal posée, désolé. Je me suis emmêlé les pinceaux. class MaClasse { bool StaticMember; }; MaClasse::StaticMember=true; Est-ce possible ?
Malgres son nom StaticMember n'est pas un attribut statique donc on va corriger :
class MaClasse { static bool StaticMember; };
///...
MaClasse::StaticMember=true;
Maintenant une autre erreur : en C++ les attributs et methodes sont par defaut private donc tu ne peux acceder a StaticMember de l'exterieur a moins d'etre friend de MaClasse
Donc non tu ne peux le faire. par contre avec ca :
class MaClasse { public: static bool StaticMember; };
///...
MaClasse::StaticMember=true;
C'est valide mais j'ai toujours tendance a 'proteger' les membres static d'une classe modifiables considerant que - generalement c'est une partie du fonctionnement _interne_ de celle-ci. Mais ceci est un autre debat
Ok merci. Donc il faut qu'il soit statique et public. Logique.
"Frederic Py" <fpy.sospam@laas.rf> a écrit dans le message news:
bdhut8$pem$1@kane.laas.fr...
Frédéri MIAILLE wrote:
Je ne suis pas : on l'appelle avec toto::fonction();
Vu ta signature, tu dois connaitre le C++, donc je comprend pas que tu
poses cette question sur les membres statiques d'une classe.
Mmm ma question était mal posée, désolé. Je me suis emmêlé les pinceaux.
class MaClasse
{
bool StaticMember;
};
MaClasse::StaticMember=true;
Est-ce possible ?
Malgres son nom StaticMember n'est pas un attribut statique donc on va
corriger :
class MaClasse {
static bool StaticMember;
};
///...
MaClasse::StaticMember=true;
Maintenant une autre erreur : en C++ les attributs et methodes sont par
defaut private donc tu ne peux acceder a StaticMember de l'exterieur a
moins d'etre friend de MaClasse
Donc non tu ne peux le faire. par contre avec ca :
class MaClasse {
public:
static bool StaticMember;
};
///...
MaClasse::StaticMember=true;
C'est valide mais j'ai toujours tendance a 'proteger' les membres static
d'une classe modifiables considerant que - generalement c'est une partie
du fonctionnement _interne_ de celle-ci. Mais ceci est un autre debat
Ok merci.
Donc il faut qu'il soit statique et public. Logique.
"Frederic Py" a écrit dans le message news: bdhut8$pem$
Frédéri MIAILLE wrote:
Je ne suis pas : on l'appelle avec toto::fonction(); Vu ta signature, tu dois connaitre le C++, donc je comprend pas que tu poses cette question sur les membres statiques d'une classe.
Mmm ma question était mal posée, désolé. Je me suis emmêlé les pinceaux. class MaClasse { bool StaticMember; }; MaClasse::StaticMember=true; Est-ce possible ?
Malgres son nom StaticMember n'est pas un attribut statique donc on va corriger :
class MaClasse { static bool StaticMember; };
///...
MaClasse::StaticMember=true;
Maintenant une autre erreur : en C++ les attributs et methodes sont par defaut private donc tu ne peux acceder a StaticMember de l'exterieur a moins d'etre friend de MaClasse
Donc non tu ne peux le faire. par contre avec ca :
class MaClasse { public: static bool StaticMember; };
///...
MaClasse::StaticMember=true;
C'est valide mais j'ai toujours tendance a 'proteger' les membres static d'une classe modifiables considerant que - generalement c'est une partie du fonctionnement _interne_ de celle-ci. Mais ceci est un autre debat
Ok merci. Donc il faut qu'il soit statique et public. Logique.
Et les membres statiques alors, on peut les modifier sans avoir déclaré d'instance de la classe ? Avec par exemple un truc dans le genre : MaClasse::StaticMember=true;
Oui Même si StaticMember n'est pas static ?
Et tous les objets de cette classe MaClasse auraient cette donnée membre à
true dès leur instanciation ?
Oui car les données statiques sont communes à toutes les instances de la classe...
Autre question (c'est la série) Si ma classe à une donnée membre statique, si je change cette donnée membre,
il se passe quoi ? toutes les instances de cette classe ont la donnée membre
statique qui change en conséquence ?
Oui car les données statiques sont communes à toutes les instances de la classe... ;) Oui pardon, ça c'est bon, je le savais mais j'ai foiré sur mes
copiers/coller. La question était donc mal tournée, mais je l'ai dit un peu plus haut.
Merci en tout cas. -- Frédéri MIAILLE fr.comp.lang.c fr.comp.lang.c++ fr.comp.os.ms-windows.programmation
Et les membres statiques alors, on peut les modifier sans avoir déclaré
d'instance de la classe ?
Avec par exemple un truc dans le genre :
MaClasse::StaticMember=true;
Oui
Même si StaticMember n'est pas static ?
Et tous les objets de cette classe MaClasse auraient cette donnée membre
à
true dès leur instanciation ?
Oui car les données statiques sont communes à toutes les instances de la
classe...
Autre question (c'est la série)
Si ma classe à une donnée membre statique, si je change cette donnée
membre,
il se passe quoi ? toutes les instances de cette classe ont la donnée
membre
statique qui change en conséquence ?
Oui car les données statiques sont communes à toutes les instances de la
classe... ;)
Oui pardon, ça c'est bon, je le savais mais j'ai foiré sur mes
copiers/coller.
La question était donc mal tournée, mais je l'ai dit un peu plus haut.
Merci en tout cas.
--
Frédéri MIAILLE
fr.comp.lang.c
fr.comp.lang.c++
fr.comp.os.ms-windows.programmation
Et les membres statiques alors, on peut les modifier sans avoir déclaré d'instance de la classe ? Avec par exemple un truc dans le genre : MaClasse::StaticMember=true;
Oui Même si StaticMember n'est pas static ?
Et tous les objets de cette classe MaClasse auraient cette donnée membre à
true dès leur instanciation ?
Oui car les données statiques sont communes à toutes les instances de la classe...
Autre question (c'est la série) Si ma classe à une donnée membre statique, si je change cette donnée membre,
il se passe quoi ? toutes les instances de cette classe ont la donnée membre
statique qui change en conséquence ?
Oui car les données statiques sont communes à toutes les instances de la classe... ;) Oui pardon, ça c'est bon, je le savais mais j'ai foiré sur mes
copiers/coller. La question était donc mal tournée, mais je l'ai dit un peu plus haut.
Merci en tout cas. -- Frédéri MIAILLE fr.comp.lang.c fr.comp.lang.c++ fr.comp.os.ms-windows.programmation
Christophe Lephay
"Frédéri MIAILLE" a écrit dans le message de news:bdidja$bun$
Et les membres statiques alors, on peut les modifier sans avoir déclaré
d'instance de la classe ? Avec par exemple un truc dans le genre : MaClasse::StaticMember=true;
Oui Même si StaticMember n'est pas static ?
Ben non, les membres non statiques n'ont pas d'existence en dehors de l'instance à laquelle ils appartiennent. Pas d'instance, pas de membre...
class toto { int a; void fonction() { a = 10; } };
le code a; ci-dessus équivaut à this->a; Si tu n'as pas d'instance, tu n'as pas de this, et tu n'as pas de a.
Chris
"Frédéri MIAILLE" <bobranger@wanadoo.fr> a écrit dans le message de
news:bdidja$bun$1@news-reader2.wanadoo.fr...
Et les membres statiques alors, on peut les modifier sans avoir
déclaré
d'instance de la classe ?
Avec par exemple un truc dans le genre :
MaClasse::StaticMember=true;
Oui
Même si StaticMember n'est pas static ?
Ben non, les membres non statiques n'ont pas d'existence en dehors de
l'instance à laquelle ils appartiennent. Pas d'instance, pas de membre...
class toto
{
int a;
void fonction()
{
a = 10;
}
};
le code a; ci-dessus équivaut à this->a;
Si tu n'as pas d'instance, tu n'as pas de this, et tu n'as pas de a.
"Frédéri MIAILLE" a écrit dans le message de news:bdidja$bun$
Et les membres statiques alors, on peut les modifier sans avoir déclaré
d'instance de la classe ? Avec par exemple un truc dans le genre : MaClasse::StaticMember=true;
Oui Même si StaticMember n'est pas static ?
Ben non, les membres non statiques n'ont pas d'existence en dehors de l'instance à laquelle ils appartiennent. Pas d'instance, pas de membre...
class toto { int a; void fonction() { a = 10; } };
le code a; ci-dessus équivaut à this->a; Si tu n'as pas d'instance, tu n'as pas de this, et tu n'as pas de a.
Chris
James Kanze
Martinez Jerome writes:
|> Bon voila, en lisant du code, je retrouve deux type d'ecriture, |> qui reviennent au meme a l'utilisateur final :
|> namespace toto |> { |> int fonction(); |> }
|> ou |> class toto |> { |> static int fonction(); |> };
|> Pour l'utilisateur, c'est pareil : |> toto::fonction();
|> Quelle est la "meilleure" methode pour programmer?
Ça dépend de ce qu'on veut faire, mais j'imagine que la plupart des classes avec *tous* les membres statiques se trouvent dans du code ancien, d'un époque avant les namespaces.
|> avantage de l'un ou l'autre?
L'avantage de la classe, c'est que c'est fermée -- personne ne peut y ajouter quoique ce soit.
L'avantage du namespace, c'est que c'est ouvert -- on peut y ajouter ce qu'on veut, quand on veut.
Il y a aussi des différences en ce qui concerne la recherche des noms. Ces différences jouent surtout quand on a affaire à des opérateurs surchargés ou des templates -- si j'écris « a + b », et le type de a ou de b est définit dans un namespace, le compilateur va chercher l'opérateur dans ce namespace. Il n'y a rien d'équivalent pour chercher un operator+ statique dans une classe.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France Tel. +33 1 41 89 80 93
|> Bon voila, en lisant du code, je retrouve deux type d'ecriture,
|> qui reviennent au meme a l'utilisateur final :
|> namespace toto
|> {
|> int fonction();
|> }
|> ou
|> class toto
|> {
|> static int fonction();
|> };
|> Pour l'utilisateur, c'est pareil :
|> toto::fonction();
|> Quelle est la "meilleure" methode pour programmer?
Ça dépend de ce qu'on veut faire, mais j'imagine que la plupart
des classes avec *tous* les membres statiques se trouvent dans du code
ancien, d'un époque avant les namespaces.
|> avantage de l'un ou l'autre?
L'avantage de la classe, c'est que c'est fermée -- personne ne peut
y ajouter quoique ce soit.
L'avantage du namespace, c'est que c'est ouvert -- on peut y ajouter
ce qu'on veut, quand on veut.
Il y a aussi des différences en ce qui concerne la recherche des
noms. Ces différences jouent surtout quand on a affaire à des
opérateurs surchargés ou des templates -- si j'écris
« a + b », et le type de a ou de b est définit dans un
namespace, le compilateur va chercher l'opérateur dans ce
namespace. Il n'y a rien d'équivalent pour chercher un operator+
statique dans une classe.
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France Tel. +33 1 41 89 80 93
|> Bon voila, en lisant du code, je retrouve deux type d'ecriture, |> qui reviennent au meme a l'utilisateur final :
|> namespace toto |> { |> int fonction(); |> }
|> ou |> class toto |> { |> static int fonction(); |> };
|> Pour l'utilisateur, c'est pareil : |> toto::fonction();
|> Quelle est la "meilleure" methode pour programmer?
Ça dépend de ce qu'on veut faire, mais j'imagine que la plupart des classes avec *tous* les membres statiques se trouvent dans du code ancien, d'un époque avant les namespaces.
|> avantage de l'un ou l'autre?
L'avantage de la classe, c'est que c'est fermée -- personne ne peut y ajouter quoique ce soit.
L'avantage du namespace, c'est que c'est ouvert -- on peut y ajouter ce qu'on veut, quand on veut.
Il y a aussi des différences en ce qui concerne la recherche des noms. Ces différences jouent surtout quand on a affaire à des opérateurs surchargés ou des templates -- si j'écris « a + b », et le type de a ou de b est définit dans un namespace, le compilateur va chercher l'opérateur dans ce namespace. Il n'y a rien d'équivalent pour chercher un operator+ statique dans une classe.
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France Tel. +33 1 41 89 80 93
kanze
"Michel Michaud" wrote in message news:<dMYKa.7067$...
Dans news:bdhad6$, Martinez
Bon voila, en lisant du code, je retrouve deux type d'ecriture, qui reviennent au meme a l'utilisateur final :
namespace toto { int fonction(); }
ou class toto { static int fonction(); };
Pour l'utilisateur, c'est pareil : toto::fonction();
Quelle est la "meilleure" methode pour programmer? avantage de l'un ou l'autre?
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.
Dans le cas d'une classe, je peux déclarer des fonctions ou des données privées, auxquelles seulement les fonctions membres peuvent accéder. Avec un namespace, je peux ajouter des membres dans mon .cc, de façon à ce qu'ils ne soient pas visible à l'utilisateur. Si l'utilisateur s'amuse à ajouter également des noms dans le namespace, il y a risque de conflit, mais je dirais franchement que dans ce cas-là, tant pis pour lui.
Ça explique parfois le choix obligatoire d'une fonction statique au lieu de celle d'un namespace.
En plus, il faut bien ajouter que créer une autre portée avec un namespace quand on a déjà une classe sur le même « sujet » est souvent une nuisance. Par exemple, si j'ai une classe Date et que je veux une fonction Date Aujourdhui(), ça pourrait paraître plus logique de faire tout simplement une fonction membre statique.
D'autre part, mettre un opérateur (sur des types membres) dans une classe ne marche pas particulièrement bien.
À l'opposé, un avantage du namespace est qu'on peut faire un using pour éviter de préfixer tous les emplois...
Avantage ?
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<dMYKa.7067$OE2.841584@news20.bellglobal.com>...
Dans news:bdhad6$a1v1@news.rd.francetelecom.fr, Martinez
Bon voila, en lisant du code, je retrouve deux type d'ecriture, qui
reviennent au meme a l'utilisateur final :
namespace toto
{
int fonction();
}
ou
class toto
{
static int fonction();
};
Pour l'utilisateur, c'est pareil :
toto::fonction();
Quelle est la "meilleure" methode pour programmer? avantage de l'un
ou l'autre?
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.
Dans le cas d'une classe, je peux déclarer des fonctions ou des données
privées, auxquelles seulement les fonctions membres peuvent accéder.
Avec un namespace, je peux ajouter des membres dans mon .cc, de façon à
ce qu'ils ne soient pas visible à l'utilisateur. Si l'utilisateur
s'amuse à ajouter également des noms dans le namespace, il y a risque de
conflit, mais je dirais franchement que dans ce cas-là, tant pis pour
lui.
Ça explique parfois le choix obligatoire d'une fonction statique au
lieu de celle d'un namespace.
En plus, il faut bien ajouter que créer une autre portée avec un
namespace quand on a déjà une classe sur le même « sujet » est souvent
une nuisance. Par exemple, si j'ai une classe Date et que je veux une
fonction Date Aujourdhui(), ça pourrait paraître plus logique de faire
tout simplement une fonction membre statique.
D'autre part, mettre un opérateur (sur des types membres) dans une
classe ne marche pas particulièrement bien.
À l'opposé, un avantage du namespace est qu'on peut faire un using
pour éviter de préfixer tous les emplois...
Avantage ?
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16
"Michel Michaud" wrote in message news:<dMYKa.7067$...
Dans news:bdhad6$, Martinez
Bon voila, en lisant du code, je retrouve deux type d'ecriture, qui reviennent au meme a l'utilisateur final :
namespace toto { int fonction(); }
ou class toto { static int fonction(); };
Pour l'utilisateur, c'est pareil : toto::fonction();
Quelle est la "meilleure" methode pour programmer? avantage de l'un ou l'autre?
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.
Dans le cas d'une classe, je peux déclarer des fonctions ou des données privées, auxquelles seulement les fonctions membres peuvent accéder. Avec un namespace, je peux ajouter des membres dans mon .cc, de façon à ce qu'ils ne soient pas visible à l'utilisateur. Si l'utilisateur s'amuse à ajouter également des noms dans le namespace, il y a risque de conflit, mais je dirais franchement que dans ce cas-là, tant pis pour lui.
Ça explique parfois le choix obligatoire d'une fonction statique au lieu de celle d'un namespace.
En plus, il faut bien ajouter que créer une autre portée avec un namespace quand on a déjà une classe sur le même « sujet » est souvent une nuisance. Par exemple, si j'ai une classe Date et que je veux une fonction Date Aujourdhui(), ça pourrait paraître plus logique de faire tout simplement une fonction membre statique.
D'autre part, mettre un opérateur (sur des types membres) dans une classe ne marche pas particulièrement bien.
À l'opposé, un avantage du namespace est qu'on peut faire un using pour éviter de préfixer tous les emplois...
Avantage ?
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16
Martinez Jerome
wrote:
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.
Dans mon cas, a raison :)
kanze@gabi-soft.fr wrote:
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'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.
