Discussion :

[r0d]

Bonjour à tous,

voilà, je travaille sur une application qui commence à prendre du poid, et je suis confronté au problème suivant:
J'utilise tout un tas d'enum, car c'est extrêmement pratique pour la manipulation des données (pour les maps notamment). Mais j'aimerais avoir des enum dans lesquels je puisse déclarer les mêmes noms. Un exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
enum R_GroundType
{
	DEFAULT,
	GRASS,
	MUD,
	WALL
};
 
enum R_UnitType
{
	DEFAULT, // interdit: redéfinition de DEFAULT
	DEFAULT_ALIEN,
	DEFAULT_ALIEN_SEL
};

J'aimerais trouver un moyen qui me permette de déclarer DEFAULT dans plusieurs enum différents.

J'ai pensé à plusieurs solutions, et pour l'instant, je déclare mes enums dans des espace de nommage différents, mais cette solution est trés lourde et peu élégante.

Avez-vous des idées concernant ce problème?

[la drogue c'est mal]

ormis les namespace, pas trop

[Sylvain Togni]

Perso, je prefixe les valeurs des enum par leur type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
enum GroundType
{
	groundDefault,
	groundGrass,
	groundMud,
	groundWall
};
 
enum UnitType
{
	unitDefault,
	unitDefaultAlien,
	unitDefaultAlienSel
};

(aussi, je reserve les identifiants tout en majuscules au préprocesseur).

[bigboomshakala]

Perso, je prefixe les valeurs des enum par leur type
(aussi, je reserve les identifiants tout en majuscules au préprocesseur).

~pareil

e pour enum
initiales du type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
enum GroundType
{
	eGT_Default,
	eGT_Grass,
	eGT_Mud,
	eGT_Wall
};

[ZaaN]

j aime bien definir des types en plus de nommer mes enum un peu comme Sylvain Togni.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
	typedef enum {	enPVIStateNoInit,
			enPVIStateInit,
			enPVIStateConnected,
			enPVIStateDisconnected}
enPVIState;

[JolyLoic]

Je défini souvent des énums dans la classe qui en est le principal utilisateur, ce qui évite les conflits de nom. Je m'étais aussi amusé à définir chaque enum dans une classe faite pour l'occasion (qui faisait d'autres choses aussi, comme associer des chaines de caractère aux valeurs de l'enum), afin de forcer un préfixage de la valeur de l'énum par le nom de cette classe.

[Luc Hermitte]

De plus en plus, je pars vers la seconde solution évoquée par Loïc.

Aujourd'hui j'ai dû casser une application de la première utilisation car l'énuméré devait être utilisé dans la signature d'une tierce fonction, et que je ne voulais pas sacrifier la déclaration anticipé de la classe où était déclarée l'énum.

En gros, je me retrouve avec ce genre de choses:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
// TotoTitiFwd.h
#ifndef TOTO_TITI_FWD_H_
#define TOTO_TITI_FWD_H_
namespace Toto {
    struct State {
        // si je me souviens bien, je crois que j'avais choisi une classe plutôt
        // qu'un espace de noms pour méta-programmer de temps à autres
        enum type { FIRST__=42, active=FIRST__, closed, END__ };
        // tous mes énumérés ont ce END__/LAST__/NBMAX__/...
    };
    std::string toString(State::type eState);
    State::type toEnum(std::string const& sState);
 
    class Titi; // la déclaration anticipée
}
#endif
// endif TOTO_TITI_FWD_H_
 
 
// TotoTiti.h
#ifndef TOTO_TITI_H_
#define TOTO_TITI_H_
#include "TotoTitiFwd.h"
namespace Toto {
    class Titi{ // la définition
        ...
        State::type getState() const;
        void setState(State::type eState);
    };
}
#endif
// endif TOTO_TITI_H_
 
 
// Tutu.h
....
#include "TotoTitiFwd.h"
// Ici, pas besoin de la définition de Toto::Titi, 
// contrairement à la définition de l'enum
void propagate(Toto::Titi & titi, Toto::State::type eState);
...
 
// tata.cpp
propagate(titi, Toto::State::active);

Vous avez compris, je préfère préfixer par une portée (namespace + éventuellement classe) plutôt que par une série de caractères qui polluent, à mon goût, identifiants et types.


Mais ...dernièrement, j'ai croisé un projet expérimental chez boost qui permettait de faire des choses super clean avec les enumérés. Je me demande si ce n'est pas loufoque qui en avait fait la pub ici.

[r0d]

Ok. Merci pour votre participation. J'ai commencé à modifier mon code et à mettre le plus possible les enum dans les classes. En plus, c'est souvent logique de procéder ainsi.

[Luc Hermitte]

Attention au détail des déclarations en avant.


Et sinon, je suis tombé sur un article hier au sujet d'une évolution des énumérés pour le C++09.
C'était très succinct, du coup je ne sais pas s'il y aura quoique ce soit pour itérer. De mémoire, cela ressemblait à ceci.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
enum class Type {
   val1, val2 
};
 
void f(Type);
 
f(Type::val1);

-> portée
-> pas de convertion implicite vers int
-> utilisation du mot clé "class" pour distinguer des "futurs anciens" énumérés
-> je ne sais plus si il y aura des spéc précises au sujet de la taille

[JolyLoic]

J'ai lu quelques papiers dans ce sens. Je n'ai pas eu l'impression qu'il y ait eu un consensus sur ce sujet, mais le document http://www.open-std.org/jtc1/sc22/wg...2006/n2122.htm semble indiquer le contraire.

La proposition est très proche du C++/CLI, moins les fonctionnalités d'introspection, que je trouve pourtant très pratiques.

Autrement, j'avais il y a quelque temps écrit du code pour avoir des enums typées fortement, et avec des possibilités d'itération et de conversion en chaînes. Je n'ai pas eu l'occasion de l'utiliser dans du vrai code, donc je ne sais pas à quel point ça tient la route, sachant que le but était aussi de m'amuser avec boost::preprocessor : RichEnum.h

Ca s'utilisait comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
DECLARE_RICH_ENUM(Range, (Self)(Touch)(Range10Feet)(Range50Feet)(Range100Feet));
Range listAll = Range::begin();
do
{
    std::cout << listAll++ << std::endl;
} while(listAll != Range::end());

Et en test unitaire, j'avais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Range r = Range::Touch;
BOOST_CHECK_EQUAL(r, Range::Touch);
r = Range::begin();
BOOST_CHECK_EQUAL(r, Range::Self);
BOOST_CHECK_EQUAL(++r, Range::Touch);
BOOST_CHECK_EQUAL(r++, Range::Touch);
BOOST_CHECK_EQUAL(++r, Range::Range50Feet);
BOOST_CHECK_EQUAL(++r, Range::Range100Feet);
BOOST_CHECK_EQUAL(++r, Range::end());
BOOST_CHECK_EQUAL(++r, Range::end());
BOOST_CHECK_EQUAL(--r, Range::Range100Feet);
BOOST_CHECK_EQUAL(--r, Range::Range50Feet);
BOOST_CHECK_EQUAL(--r, Range::Range10Feet);
BOOST_CHECK_EQUAL(r--, Range::Range10Feet);
BOOST_CHECK_EQUAL(--r, Range::Self);
BOOST_CHECK_EQUAL(--r, Range::Self);
 
r = Range::Touch;
BOOST_CHECK_EQUAL(boost::lexical_cast<std::string>(r), "Touch");

Ca résout les
- problèmes de scope,
- les problèmes d'introspection (itérer, convertir en chaîne compréhensible (mais pas la conversion dans l'autre sens, même si elle peut s'ajouter))
- ceux de conversion implicite :pas de conversion vers int (je ne m'en sert jamais, donc même la conversion explicite me semblait de trop, on peut évidemment l'ajouter)

Ca n'a même pas tenté de résoudre
- les problèmes de taille, ce n'est pas ce qui m'intéressait, et je ne vois pas forcément comment le faire trivialement à partir de ce code.

On ne sait jamais, si ça plaît à quelqu'un...