Discussion :

[Guillaume1701]

Bonjour,

Je suis à la recherche de la méthode la plus simple de réaliser une enum class en c++11 qui possède une méthode to_string.
Après plusieurs recherches sur internet je tombe sur plein de code qui sont plus ou moins simple. J'aimerai avoir votre avis.

Voici ce que j'ai trouvé :
https://stackoverflow.com/questions/...and-future-c20
https://codereview.stackexchange.com...c-class-header

Il y a plein de sujet mais aucunes méthodes semblent sortir du lot.

Avez-vous un avis sur la question ?

Personnellement je suis encore sur du C et j'aimerai faire quelque chose orienté C++ avec (enum class au moins)

Code :

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

1
2
3
4
5
6
7
enum MyEnum {
    VALUE_1, VALUE_2, NB_MY_ENUM
};
static const char* MyEnumString[] = {
    "VALUE_1", "VALUE_2"
};
static_assert(sizeof(MyEnumString)/sizeof(char*) == NB_MY_ENUM, "MyEnumString array error");

[jo_link_noir]

La solution la plus simple de mon point de vue est d'utiliser une macro qui s'occupe de générer enum + correspondance valeur <-> string. C'est très simple lorsque l'enum est une suite continue de 0 à N (ce qui est le cas ici), et vraiment galère de faire une implémentation efficace avec des valeurs aléatoires (lorsque qu'on initialise les valeurs de l'enum) ou lorsqu'on veut "renommer" certaines correspondances. Perso, j'ai un truc qui le fait un peu près (sans valeur aléatoire, mais cela supporte plusieurs patterns d'incrémentation) et il y en a pour 500 lignes de macros bien dégoulinantes (alors que j'utilise BOOST_PP_* pour me simplifier la vie).

Après il y a un moyen simple qui consiste à générer un switch (pas très dur avec boost.preprocessor). Mais sinon bettern-enums me semble un bon candidat pour une solution clef en main.

Mais si l'enum existe déjà, alors il n'y a que la solution manuelle (ou avec un programme externe) en attendant des évolutions du langage (qui parle de méta-classe ?).

[Bousk]

https://www.developpez.net/forums/d1.../#post10289452

[Pyramidev]

Bonjour,

Voici une solution qui s'inspire beaucoup de la technique de Bousk, mais sans mettre l'énumération dans un fichier à part et sans faire de #undef :

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
45
46
47
48
49
50
51
52
53
 
#include <iostream>
#include <stdexcept>
 
 
#ifdef POUR_CHAQUE_JOUR_DE_LA_SEMAINE
# error POUR_CHAQUE_JOUR_DE_LA_SEMAINE est déjà définie.
#endif
#define POUR_CHAQUE_JOUR_DE_LA_SEMAINE(callback) \
	callback(Lundi)    \
	callback(Mardi)    \
	callback(Mercredi) \
	callback(Jeudi)    \
	callback(Vendredi) \
	callback(Samedi)   \
	callback(Dimanche)
 
 
#ifdef EXPR_PUIS_VIRGULE
# error EXPR_PUIS_VIRGULE est déjà définie.
#endif
#define EXPR_PUIS_VIRGULE(expr) expr,
 
enum class JourDeLaSemaine {
	POUR_CHAQUE_JOUR_DE_LA_SEMAINE(EXPR_PUIS_VIRGULE)
};
 
 
#ifdef IMPL_ToString_JourDeLaSemaine
# error IMPL_ToString_JourDeLaSemaine est déjà définie.
#endif
#define IMPL_ToString_JourDeLaSemaine(expr) \
	case JourDeLaSemaine::expr: return #expr;
 
constexpr char const* ToString(JourDeLaSemaine param) {
	switch(param) {
		POUR_CHAQUE_JOUR_DE_LA_SEMAINE(IMPL_ToString_JourDeLaSemaine)
		default: throw std::invalid_argument("Jour de la semaine invalide.");
	}
}
 
 
#ifdef AFFICHER_JOUR_DE_LA_SEMAINE
# error AFFICHER_JOUR_DE_LA_SEMAINE est déjà définie.
#endif
#define AFFICHER_JOUR_DE_LA_SEMAINE(expr) \
	std::cout << ToString(JourDeLaSemaine::expr) << '\n';
 
int main()
{
	POUR_CHAQUE_JOUR_DE_LA_SEMAINE(AFFICHER_JOUR_DE_LA_SEMAINE)
	return 0;
}

[Pyramidev]

Pourquoi est-ce que je viens de me ramasser un -1 ?

Dans la version de Bousk, conceptuellement, ENTRY est une variable globale muable. Au début, c'est une fonction qui prend un paramètre v et qui produit le code v,. Après, c'est une fonction qui prend un paramètre v et qui produit le code case v : return #v;.
Conceptuellement, le fichier Enum.inl est une fonction sans paramètre qui produit du code. Le comportement de la fonction Enum.inl dépend de la variable globale ENTRY.

Dans ma version, je suis partie de la solution de Bousk et j'ai éliminé la variable globale ENTRY. Pour cela, j'ai transformé Enum.inl en une fonction à un paramètre : POUR_CHAQUE_JOUR_DE_LA_SEMAINE(callback).

Au niveau de l'architecture, c'est un peu plus propre.

[Bousk]

Plus propre en quoi ?
Tu transformes un fichier très nettement identifiable comme une liste d'entrées et parfaitement lisible en un truc tordu. Les noms choisis n'aident en rien mais ça c'est à la limite pas le plus gros problème (je suis tout de même curieux de savoir comment tu ferais une liste d'une centaine d'entrées plus abstraite, disons de simples Actions. Et si tu as en plus plusieurs enums tu te retrouves avec un fichier de 1000 lignes de macro pour ça ?).
Le code produit est bien plus long, moins lisible, avec les données cachées dans une macro dont le nom fait penser à une boucle for each et plus dans une liste lisible et aisément modifiable, et un système de callback qui fait un double dispatch qui rend le tout encore moins lisible parce que tu dois courir à 2 endroits chaque fois que tu veux comprendre ce qu'il se passe.
Tout ça pour supprimer un fichier .inl et un #undef ? Bel exercice mais bof non merci je passe.