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.

[Pyramidev]

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. [...]
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.

On n'a pas la même perception. Tu présentes ma solution comme vachement plus tordue et compliquée que la tienne alors que, à mes yeux, nos solutions sont de complexités égales, à part que ma solution est plus directe (un callback bien explicite) et la tienne plus étrange (un même fichier inclus plusieurs fois, mais avec un comportement différent à chaque fois).

Dans nos deux solutions, on a des « données cachées ». Les miennes sont cachées dans une macro, les tiennes dans un fichier.

Dans nos deux solutions, on doit « courir à 2 endroits ». Chez moi, c'est dans la définition de POUR_CHAQUE_JOUR_DE_LA_SEMAINE et dans celle de son argument. Chez toi, c'est dans le fichier Enum.inl et dans la définition du moment de la macro ENTRY.

Dans nos deux solutions, on a la complexité d'une fonction qui appelle une fonction. Chez moi, POUR_CHAQUE_JOUR_DE_LA_SEMAINE appelle son paramètre qui change d'un appel à l'autre. Chez toi, Enum.inl appelle ENTRY qui change d'une inclusion à l'autre.

(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 ?).

Non, si j'ai plusieurs énumérations très volumineuses, alors je découpe le code en plusieurs fichiers. Les macros n'obligent pas à écrire tout le code dans le même fichier.

Tout ça pour supprimer un fichier .inl et un #undef ?

À propos du fichier .inl :

À la limite, si ton énumération a beaucoup de valeurs, alors découper le fichier en deux (Enum.hpp et Enum.inl) n'est pas gênant. Par contre, si elle ne contient qu'une dizaine de valeurs, alors c'est dommage de créer un nouveau fichier rien que pour ça.

Si je pars de ta solution et que je ne fais que déplacer le #undef ENTRY puis transformer le fichier Enum.inl en macro, cela donne :

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
#define ENUM_INL_AS_MACRO \
    ENTRY(Value1) \
    ENTRY(Value2)
 
enum Enum {
#define ENTRY(v) v,
ENUM_INL_AS_MACRO
#undef ENTRY
};
inline const char* ToString(Enum val) {
  switch(val) {
  #define ENTRY(v) case v : return #v;
  ENUM_INL_AS_MACRO
  #undef ENTRY
  default: return "<unknown>"; // ou throw std::invalid_argument("Valeur inconnue");
  }
}

On évite un aller-retour d'un fichier à l'autre.

À propos du #undef :

Si je fais une recherche de la chaîne undef dans tout le code source d'un projet, alors je vais tomber sur la liste des macros pour lesquelles la définition peut changer en cours d'exécution du préprocesseur. Par élimination, je saurai que toutes les autres macros seront immuables dans le sens où elles ne changeront pas d'état entre l'initialisation (avec #define) et l'utilisation. L'immuabilité est une garantie qui facilite l'analyse du code, surtout quand il s'agit de macros. Plus il y a d'occurrences de undef, plus ça pollue la recherche.

En fait, je vois les #undef comme assez similaires aux const_cast, mais dans le monde des macros.

[JolyLoic]

Si je fais une recherche de la chaîne undef dans tout le code source d'un projet, alors je vais tomber sur la liste des macros pour lesquelles la définition peut changer en cours d'exécution du préprocesseur. Par élimination, je saurai que toutes les autres macros seront immuables dans le sens où elles ne changeront pas d'état entre l'initialisation (avec #define) et l'utilisation. L'immuabilité est une garantie qui facilite l'analyse du code, surtout quand il s'agit de macros. Plus il y a d'occurrences de undef, plus ça pollue la recherche.

Même si je peux comprendre ton raisonnement, je pense qu'il ne marcherait pas trop dans mon code. En effet, j'utilise très souvent undef dans mon code, mais pas pour changer la définition d'une macro, juste pour m'assurer que ma macro reste locale au fichier où elle se trouve, et n'ira jamais impacter de manière étrange d'autres fichiers ailleurs. Il s'agit typiquement d'un usage de undef qui disparaîtrait avec les modules (là où l'usage pour réutilisation resterait d'actualité).

[Pyramidev]

@JolyLoic : très bonne remarque. Vivement les modules !