[Metaprog] static const vs enum

Salut à tous,
Jme pose une question, c'est plus une histoire de style qu'autre chose mais bon allons y, quand on travaille en compile-time (metaprog etc) on a besoin de compile-time constant (aucune traduction fr me plait), pour ça on a deux choses soit enum soit static const.
Jusque là j'ai toujours préféré les enum, d'un parce que je l'ai plus souvent vu, que je suis plus à l'aise (visuellement parlant) avec, de deux parce que seul l'enum est une vraie constante de compilation. Dans le cas d'un static const y'aura une allocation au run tim, donc histoire d'être purement compile-time => enum. (c'est pas de moi, c'est du C++ template the complete guide).
J'ai toujours vu boost utilisé une macro : BOOST_STATIC_CONSTANT(type, value);
Jusqu'à ce que je sois curieux et que je me demande ce qu'il y'a derrière cette macro, un grep plus tard (c'est dans boost/config/suffix.hpp) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

// BOOST_STATIC_CONSTANT workaround --------------------------------------- // // On compilers which don't allow in-class initialization of static integral // constant members, we must use enums as a workaround if we want the constants // to be available at compile-time. This macro gives us a convenient way to // declare such constants.   # ifdef BOOST_NO_INCLASS_MEMBER_INITIALIZATION # define BOOST_STATIC_CONSTANT(type, assignment) enum { assignment } # else # define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment # endif

---

Donc dans le cas général ils préférent (?) utiliser un static const. Y'a-t-il une raison ou c'est purement et simplement une convention qu'ils ont pris?
Attention, c'est pas parce que boost fait comme ça que je vais changer ma façon de faire hein, à moins que justement y'ai une bonne raison qui mette un au dessus de l'autre.

Question additionnelle : et vous, où va votre préférence?

Salut,

Je crois que la raison principale (bien que n'ayant jamais participé au développement de boost), c'est que les deux possibilités (enum vs static const) ont des raisons d'être différentes, et des utilités également différentes.

Je justifie:

Tu ne peux pas envisager (me semble-t-il) d'avoir un code proche de

Code:

---

1 2 3 4 5

template <int i> struct BlaBla { static const int value=i; };

---

Enfin, si, tu peux envisager de l'avoir (le code est valide), mais l'évaluation ne s'effectue plus en compile time, mais bel et bien à l'exécution...

par contre, tu peux avoir un code (valide) proche de

Code:

---

1 2 3 4 5

template <int i> struct IntToType { enum {value = i}; };

---

qui pourrait très bien être utilisée par une autre structure (en compile time) sous une forme proche de

Code:

---

1 2 3 4 5

template <int i> struct Truc { enum {value = (intToType<I>::value==125 ? 125:0)}; };

---

dont l'évaluation pourra être faite au "compile time".

Autrement dit, si une valeur apparait ailleurs que dans une structure template, le fait d'avoir une énumération ou une valeur statique constante ne changera pas grand chose, hormis la possibilité de s'assurer que toutes les valeurs énumérées ont bel et bien été testées dans le cadre d'un test à choix multiple (switch case)

Par contre, dans le cas d'une structure template, tu n'auras (me semble-t-il, toujours) pas le choix: tu dois utiliser une énumération ;)

Ce genre de code est tout à fait valide :

Code:

---

1 2 3 4 5

template <int i> struct BlaBla { static const int value=i; };

---

Pour le reste tu as tendance à dire qu'il faut se tourner vers les enum, (j'ai pas bien compris pourquoi tu me parlais de constante en dehors des struct, j'ai du m'emmêler les pinceaux) alors que justement, par défaut (ie en dehors des compilos qui supportent pas l'initialisation de static const à l'intérieur de la classe) boost utilise les static const ;).

Et donc non pour te répondre AFAIK les deux fournissent la même chose : une compile-time constant.

edit : j'avais mal lu, tu dis bien que c'est valide mais que y'aura une évaluation au runtime, ça rejoint ce que je disais. Mais sur son utilisation par contre, (avec ta struct Truc par exemple) alors là par contre ça marche dans les deux cas, static const ou enum.

Citation:

---

Envoyé par Goten

Ce genre de code est tout à fait valide :

Code:

---

1 2 3 4 5

template <int i> struct BlaBla { static const int value=i; };

---

---

Oui, j'ai corrigé mon message entre temps :P

Citation:

---

Pour le reste tu as tendance à dire qu'il faut se tourner vers les enum, (j'ai pas bien compris pourquoi tu me parlais de constante en dehors des struct, j'ai du m'emmêler les pinceaux) alors que justement, par défaut (ie en dehors des compilos qui supportent pas l'initialisation de static const à l'intérieur de la classe) boost utilise les static const ;).

---

Je récapetete depuis de bedu...

l'énorme avantage des énumérations par rapport aux constantes statiques tient au fait que le compilateur peut s'assurer que toutes les valeurs énumérées ont bien été testées lors d'un "switch ... case".

Par exemple, un compilateur bien réglé te sortira un avertissement avec un code proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

enum MyEnum { val1, val2, val3, val4 };   void foo(MyEnum arg) { switch(arg) { case val1: /*blabla*/ break; case val2: /*blabla*/ break; case val3: /*blabla*/ break; /* val4 n'est pas testé */ } }

---

parce que, justement, toutes les valeurs ne sont pas testées (val4 ne l'est pas ;))

D'autre part, je sais que le résultat d'un test ternaire peut être évalué en compile time sur les énumérations, mais je ne suis pas sur du tout que ce soit le cas lorsque le test se base sur une valeur statique constante...

Et ce, d'autant plus que les valeurs statiques constantes ont, dans mon esprit du moins, la facheuse manie de vouloir être constantes... indépendemment du type réellement implémenté.

Je m'explique: je trouve "normal" que npos soit une valeur statique constante dans string_base parce que, que l'on travaille avec la std::string ou avec la std::wstring, la valeur n'a, a priori, pas besoin d'être différente.

Par contre, dans le cas de la structure IntToType que j'ai présentée plus haut, je trouve "normal" que value soit une valeur énumérée parcequ'elle... varie au gré de la valeur de i...

Ouai, dans le fond, jsuis d'accord avec toi. Mais le problème c'est que, ça va à contre sens de ce que fait boost, (on est d'accord je prends pas tout ce que fait boost comme le code parfait, qu'il faut suivre à tout pris...) puique eux utilise des static const partout.
Ce que j'en retiens pour l'instant c'est que finalement le comportement est identique (là où tu dis que c'est pas logique d'utiliser static const avec l'op ternaire, ça marche que même) donc, c'est plus un choix empirique qu'autre chose. Un jour j'aimerais quand même ce qui a poussé les dev de boost à faire celui là.

Citation:

---

Envoyé par Goten

Ouai, dans le fond, jsuis d'accord avec toi. Mais le problème c'est que, ça va à l'encontre de ce que fait boost. (on est d'accord je prends pas tout ce que fait boost comme le code parfait, qu'il faut suivre à tout pris...)

---

Attention...

Ce n'est pas parce que l'énumération est utilisée si un symbole est défini qu'il faut estimer que, d'office, le symbole ne l'est pas par défaut...

Sur base des cinq lignes de codes dont on dispose, il est difficile de savoir si BOOST_NO_INCLASS_MEMBER_INITIALIZATION est défini par défaut ou non (il faudrait sans doute aller voir dans un config.h quelconque, voir dans les jamfiles ;))

Peut être fais tu, justement, erreur, et remarque-t-on que, par défaut, c'est l'énumération qui sera mise en oeuvre :D

[EDIT]Et encore, s'agissant d'une compilation conditionnelle, on peut tout aussi bien estimer qu'il sera défini pour un compilateur ou une version de compilateur particulière et non défini pour un(e) autre, voire, défini pour une majorité et non défini pour une minorité (ou l'inverse)....

Quand même, j'ai vérifié avant de venir poster ;).
Un coup de grep montre que seul :
Visual Age (ibm) C++
mpw
visual C++
sunpro C++
ne supporte pas l'in-class member-initialization. Et encore pour la plus part c'est que pour des versions anciennes. Donc oui par défaut c'est les static const qui sont préférées.

Salut,
J'avoue ne pas avoir d'idée pourquoi préférer un static const int à un enum anonyme. En revanche, je ne serais pas étonné que le compilateur 'inline' le static const int dans l'exécutable en release surtout s'il n'est utilisé que dans des paramètres de template. En gros, que ça ne génère pas plus de code que l'enum.

Ceci dit, en y réfléchissant bien...

L'avantage que j'ai mis en avant au sujet des énumérations disparait en méta programmation car il s'agit d'énumérations anonymes.

De plus, l'inconvénient des valeurs énumérées est que, hormis si on prend soin de les définir, les opérateurs arithmétiques (+, -, * / ), logiques (&, |, ^) et de rotation de bits (<<, >>) sont inutilisables avec elles, alors que, pour autant que l'on récupère une valeur constante dans une nouvelle variable non constante, ces opérateurs sont naturellement présents pour les types primitifs.

Et comme il encore une fois d'énumérations anonymes, il est hors de question d'envisager de définir les opérateurs ;)

Enfin, le problème des valeurs énumérées est que, si l'on peut déterminer assez facilement la taille minimale qu'elles utilisent en mémoire (normalement, elles n'utilisent pas moins de place qu'un int), elles peuvent utiliser une place plus importante, selon la valeur réellement représentée (tu peux tout à fait trouver une valeur énumérée utilisant la taille d'un long ou d'un long long)...

Or, il n'y a rien à faire, si on regarde une architecture donnée, la taille d'un int sera toujours identique.

De là à envisager la possibilité de un masque pour représenter des valeurs invalide, il y a peut être un intérêt plus grand que celui que peut représenter la possibilité de disposer d'une plage de valeurs plus étendue ;)

Ces arguments ne valent rien (désolé :aie:) dans la plupart (> 99%) des cas d'utilisation des enums en métaprogrammation.
Les deux grandes branches de la métaprogrammation en C++ sont :
- le "calcul sur les types", cf enable_if & compagnie mais aussi les 2 ou 3 sujets sur la restriction des classes templates et fonctions templates à des paramètres respectant certains critères
- l'optimisation & compagnie, avec les expression templates généralement, comme Todd Veldhuizen les a introduit dans ses papiers sur le sujet. Le genre de truc qui te permet lorsque tu as une addition de 400 matrices, de faire une seule boucle qui va additionner les 400 coefficients, plutôt que d'appliquer "bêtement" l'opérateur + sur chaque paire de matrice

Dans ces deux cas, si l'on a besoin d'enums, on n'aura pas besoin de stocker des valeurs très grandes dessus, ni d'avoir des opérateurs & fonctions définis dessus.

Toujours est-il que je n'ai aucune idée du pourquoi static const plutôt qu'enum dans Boost :koi: (en dehors du support par les compilos) -- je ne suis pas sûr qu'il y ait une autre raison en fait.

Tu as du mal comprendre...

Justement, j'essayais de dire que, au final, il n'y a plus tant d'argument ne faveur de l'énum et que le type static constant se révélait plus intéressant par certains points ;)

Citation:

---

Envoyé par koala01

Justement, j'essayais de dire que, au final, il n'y a plus tant d'argument ne faveur de l'énum

---

Et moi je te disais justement qu'on n'en a pas plus contre l'enum. Un éventuel avantage des static : on peut typer statiquement un bool. Sinon, je ne vois toujours pas :aie:

ca ne fait pas avancer le schmilblick mais moi je mets des enums car a part le code que tu viens de montrer, j'ai toujours vu faire ainsi.
Si ces deux macros sont equivalentes je ne vois pas l'interet de faire un IFDEF dessus en plus, autant toujours prendre les enums.

En gros il y a une couche de compatibilité qui doit décider si on prend des enums ou des statics consts ca doit bien servir a quelque chose :calim2:

Citation:

---

En gros il y a une couche de compatibilité qui doit décider si on prend des enums ou des statics consts ca doit bien servir a quelque chose

---

C'est assez évident en regardant la macro : dans l'implémentation à base d'enum, le paramètre type est ignoré -- le type entier correspondant à l'enum sera déterminé par le compilo. Donc cette implémentation n'est qu'une solution de secours partielle.

En pratique on a rarement besoin de contraindre le type des constantes entières, mais toujours est-il que "constante entière" ça se traduit par "const int" et non par "enum" ;)

si le type est perdu mais que le code fonctionne, c'est que l'on ne s'en sert pas. a partir du moment ou il y a eu une perte d'information, ca veut dire que... boost n'est plus portable si quelqu'un s'en sert. c'est une mauvaise idée, je trouve

Citation:

---

si le type est perdu mais que le code fonctionne, c'est que l'on ne s'en sert pas

---

Oui c'est ce que je disais, en pratique le type exact n'importe que très rarement.

Citation:

---

a partir du moment ou il y a eu une perte d'information, ca veut dire que... boost n'est plus portable si quelqu'un s'en sert. c'est une mauvaise idée, je trouve

---

Effectivement, quelqu'un qui s'attend à avoir un type particulier et qui n'aurait pas connaissance de la solution de secours à base d'enum, pourrait avoir des surprises, donc il vaut mieux que ce soit bien documenté dans boost (je ne doute pas que ce soit le cas).
Mais note que dans ce cas ce sera la faute du compilo et celle de boost ; en fait sans utiliser boost cet utilisateur n'aurait pas pu faire mieux et serait de toute façon tombé sur ce problème de support des const int. Donc boost fournit une solution qui est tout de même meilleure dans tous les cas.
D'autant plus que le type entier d'un enum sera déterminé de façon à ce qu'il puisse encoder toutes les valeurs de l'enum, donc dans la plupart des cas on peut parier que ça collera avec le type choisi par l'utilisateur.

je ne suis pas d'accord, je trouve que c'est un bug de boost de proposer une implémentation incomplète par rapport a l'interface
si l'interface permet d'effectuer l'opération, et qu'elle fonctionne sur mon ordi avec mon compilo, et que quelqu'un essaye sur un autre compilo, et que ca compile pas, je me sens un peu floué par cette couche de compatibilité

Ben ça compilera toujours, le but de la macro est là. De cacher les détails selon les compilos.
Donc si chez toi ton compilo supporte l'initialisation in-class de membre static alors ça utilisera les statics (mais au final tu le sauras pas).
Dans l'autre cas c'est une enum d'utilisé.
Reste que niveau sémantique grâce à la macro le type est là. (pour l'humain qui vient lire en tout cas).

Code:

---

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

#include <cstdio>   #define BOOST_STATIC_CONSTANT(type, assignment) enum { assignment }   class Constants { public: BOOST_STATIC_CONSTANT(unsigned short, value = -1); };   #undef BOOST_STATIC_CONSTANT #define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment   class Constants2 { public: BOOST_STATIC_CONSTANT(unsigned short, value = -1); };   int main() { printf("%d\n", Constants::value); printf("%d\n", Constants2::value); return 0; }

---

Mon point, c'est que si ca ne marche pas, ca ne doit pas etre caché par une couche de compatibilité qui va cacher la misère sous le tapis et changer le comportement du programme.

Je vois où tu veux en venir. Néanmoins il faut replacer ça dans le contexte :
cette macro est utilisé dans un contexte de metaprog. En général pour représenter un booléen dans le cas de traits etc. Donc si je lis :

Code:

---

BOOST_STATIC_CONSTANT(bool, value = false);

---

Ca a du sens, que derrière false soit 0 et true soit n'importe quoi d'autre à la limite je m'en fiche.

Là où je veux en venir c'est que c'est rare en metaprog (ça m'est jamais arrivé il me semble) de se trimballer des valeurs autres que des int. (ou convertible en int, bool etc)