Constantes internes à une classe

Fabien SK wrote:

Bonjour,

Il m'arrive souvent d'avoir à définir des constantes qui ne seront
utilisées que de manière privée dans une classe. Par exemple, si j'écris
une classe gérant une connexion POP3, je vais mettre dans une constante
le code de retour du serveur "+OK".
Si je mets toutes ses constantes (il peut y en avoir un paquet) comme
membres privés de la classe, la déclaration de celle-ci va vite devenir
lourde:
- ça allonge la déclaration de la classe elle-même
- il faut tout dupliquer dans le .cpp car ce sont des membres "static"

Alors pourquoi ne pas les mettre le .cpp de ma classe, comme ceci par
exemple:

namespace
{
const std::string POP_OK("+OK");
}

Le seul problème que je vois est la collision de noms: si un autre
symbole "POP_OK" existe, y a pas bon. Par contre, si on utilise des
membres "static", le compilateur cherche d'abord les membres de la
classe, on n'a donc pas ce problème.

Qu'en pensez-vous ? Que faites-vous dans tel cas ?
Merci de votre attention

Moi j'aurais plutôt tendance à mettre les options dans des maps si ce

sont toutes de chaines de caractères, alors ça pourrait être la même
chose dans ton cas :
map< string, string > constantes;

Il n'y aura plus de problèmes de 'collisions'...


--
--------------------------------------------
Benoît Rousseau : roussebe at spray dot se
Jouez en programmant : http://realtimebattle.sourceforge.net/

namespace
{
const std::string POP_OK("+OK");
}

Pourquoi ne pas donner un nom à ton namespace ? ça éviterait les
collisions...

Le seul problème que je vois est la collision de noms: si un autre
symbole "POP_OK" existe, y a pas bon. Par contre, si on utilise des
membres "static", le compilateur cherche d'abord les membres de la
classe, on n'a donc pas ce problème.

Qu'en pensez-vous ? Que faites-vous dans tel cas ?

Un espace de nom... nommé.

Merci de votre attention

On Mon, 13 Oct 2003 20:32:35 +0200, Alexandre wrote:

namespace
{
const std::string POP_OK("+OK");
}

Pourquoi ne pas donner un nom à ton namespace ? ça éviterait les
collisions...

Le seul problème que je vois est la collision de noms: si un autre
symbole "POP_OK" existe, y a pas bon. Par contre, si on utilise des
membres "static", le compilateur cherche d'abord les membres de la
classe, on n'a donc pas ce problème.

Qu'en pensez-vous ? Que faites-vous dans tel cas ?

Un espace de nom... nommé.

Oui, mais je dois être sûr de trouver un nom différent pour chaque fichier
.cpp. Ou alors faire un truc du style:

namespace
{
namespace cst{
const std::string POP_OK("+OK");
}
}

Ça marche ça ?

Fabien SK wrote:

On Mon, 13 Oct 2003 20:32:35 +0200, Alexandre wrote:
Oui, mais je dois être sûr de trouver un nom différent pour chaque fichier
.cpp. Ou alors faire un truc du style:

Pourquoi ne pas faire un espace de nom base sur le nom de ta classe,
puisque se sont des constantes associees a ta classe ?

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Fabien SK <fabsk+news@free.fr> wrote in message
news:<3f8aab33$0$13289$626a54ce@news.free.fr>...

Il m'arrive souvent d'avoir à définir des constantes qui ne seront
utilisées que de manière privée dans une classe. Par exemple, si
j'écris une classe gérant une connexion POP3, je vais mettre dans une
constante le code de retour du serveur "+OK".

Si je mets toutes ses constantes (il peut y en avoir un paquet) comme
membres privés de la classe, la déclaration de celle-ci va vite
devenir lourde:

- ça allonge la déclaration de la classe elle-même
- il faut tout dupliquer dans le .cpp car ce sont des membres "static"

Alors pourquoi ne pas les mettre le .cpp de ma classe, comme ceci par
exemple:

namespace
{
const std::string POP_OK("+OK");
}

Le seul problème que je vois est la collision de noms: si un autre
symbole "POP_OK" existe, y a pas bon.

C'est toi qui écrit la classe, non ? C'est toi qui est maître des
symboles qu'il y a. Je ne vois pas où c'est le problème.

C'est la solution que j'utilise moi-même quand la portabilité n'est pas
un problème (code expériemental, etc.).

Sinon, pourquoi pas utiliser une déclaration anticipée d'une classe
embriquée, dont la définition de la classe (qui contient les constantes)
se trouve dans ton .cpp. Quelque chose du genre :

dans pop3.hh :

class POP3
{
class Constantes ;
// ...
} ;

dans pop3.cc

class POP3::Constantes
{
static std::string const POP_OK ;
// ...
} ;

Par contre, si on utilise des membres "static", le compilateur cherche
d'abord les membres de la classe, on n'a donc pas ce problème.

Qu'en pensez-vous ? Que faites-vous dans tel cas ?

Tout dépend des questions de portabilité. Dans le code expériemental,
j'utilise le namespace anonyme, comme tu proposes. Dans le code
portable, j'utilise la plupart du temps simplement static:-) :

static std::string const POP_OK( "+OK" ) ;

Il m'est aussi arrivé une ou deux fois d'utiliser la classe embriquée,
comme ci-dessus.

--
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, +33 (0)1 30 23 45 16

C'est toi qui écrit la classe, non ? C'est toi qui est maître des
symboles qu'il y a. Je ne vois pas où c'est le problème.

Et bien il faut que mon espace de nom, ou ma classe "traits" n'entre pas
en collision avec une autre bibliothèque. Par exemple, faire un
namespace local "Constants" risque de poser des problèmes.

Sinon, pourquoi pas utiliser une déclaration anticipée d'une classe
embriquée, dont la définition de la classe (qui contient les constantes)
se trouve dans ton .cpp. Quelque chose du genre :

dans pop3.hh :

class POP3
{
class Constantes ;
// ...
} ;

Je ne savais pas qu'on pouvait faire ça. Ca me convient parfaitement.

Tout dépend des questions de portabilité. Dans le code expériemental,

On n'a qu'une famille de compilateur: Visual C++

Merci beaucoup pour ta réponse (et merci aux autres aussi)

Fabien SK <fabsk+news@free.fr> wrote in message
news:<3f8bd708$0$27571$626a54ce@news.free.fr>...

C'est toi qui écrit la classe, non ? C'est toi qui est maître des
symboles qu'il y a. Je ne vois pas où c'est le problème.

Et bien il faut que mon espace de nom, ou ma classe "traits" n'entre
pas en collision avec une autre bibliothèque. Par exemple, faire un
namespace local "Constants" risque de poser des problèmes.

Normalement, dans n'importe quelle application, on a des règles pour
gerer des conflits de noms. Alors, ou bien, vous vous en servez des
éspaces référentiels, il n'aurait rien dans un en-tête qui n'est pas
dans un éspace référentiel, et donc, pas de conflit possible avec ton
éspace anonym, ou bien, vous ne vous êtes pas encore passés aux éspaces
référentiels (peut-être à cause d'un vieux compilateur dans un coins
quelque part), et vous avez des conventions de préfixe pour des noms
visibles globalement -- éviter d'être conforme aux préfixes, et tu
n'auras pas de problème.

Sinon, pourquoi pas utiliser une déclaration anticipée d'une classe
embriquée, dont la définition de la classe (qui contient les
constantes) se trouve dans ton .cpp. Quelque chose du genre :

dans pop3.hh :

class POP3
{
class Constantes ;
// ...
} ;

Je ne savais pas qu'on pouvait faire ça. Ca me convient parfaitement.

J'avoue que j'ai appris moi-même assez tardivement que c'était permis.
Mais je n'ai jamais encore rencontré un compilateur où ça pose de
problèmes. (Et j'en ai, d'anciens compilateurs.)

Tout dépend des questions de portabilité. Dans le code
expériemental,

On n'a qu'une famille de compilateur: Visual C++

Qui supporte les espaces référentiels d'une façon tout à fait
convenable, au moins dépuis la version 5.0. (C'est quand même plus
simple que les templates:-).)

--
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, +33 (0)1 30 23 45 16