Discussion :

[oodini]

Hello,

Il y a une légende urbaine qui dit que pou définir une constante entière statique, il vaut mieux utiliser un enum, car ça ne prend pas de mémoire, contrairement au static const.

C'est encore d'actualité, cette différence ? Les compilateurs n'optimisent-ils pas ces static const ?

[bertry]

Salut,

Il semble que tu ne trouves ça que dans du vieux code, et ça s'appelle le "enum hack" . Regardes le chapitre 8.4.2 Constantes de compilation dans les classes du livre dispo sur ce site "Penser en C++" : le paragraphe "Le “enum hack” dans le vieux code"

[oodini]

Cela est différent, bien que lié. Cette astuce concerne l'initialisation de données membre.

Je vois une telle utilisation dans du code récent, au prétexte que ça économise de la mémoire...

[JolyLoic]

Je n'en sais rien, vu que les internes d'un compilateur, à moins d'avoir développé avec... Je sais que si on prend l'adresse d'une telle constante, alors forcément elle doit être en mémoire quelque part. Est-ce que les compilateurs vérifient si une adresses est prise un jour ou pas, je n'en sais rien. Je pense que c'est possible (ça me semble semblable à ce que fait un compilateur avec une fonction inlinée), mais est-ce un enjeu en règle général ?

Tu as tant de constantes que ça que ça ait un rôle mesurable dans ton programme ?

Il faudrait aussi se poser la question de ce que font les compilateurs avec constexpr.

[oodini]

Ben si ça ne dépendait que de moi, je mettrais des static const.

C'est mon chef de projet qui insiste pour mettre des enum. Moi, ça me chagrine.

[bertry]

Euh, je tente ma chance une dernière fois, promis!

Il semble que ces deux méthodes puissent avoir des utilités légèrement différentes ( dixit Koala01 ) : [Metaprog] static const vs enum

[oodini]

Fil très intéressant. Merci !

[koala01]

Salut,

Ceci dit, j'ai trouvé une autre raison pour préférer les valeurs énumérées aux static const...

Bon, on pourra toujours me dire que le problème est marginal, mais quand même:

A priori, les valeurs énumérées prennent place dans la section donnée de l'application, et n'apparaissent donc qu'une seule fois dans l'exécutable final.

Par contre, les variables statiques sont limitées à l'unité de compilation dans laquelle elles sont déclarées / définies.

Si nous arrivons à ne pas inclure le fichier d'en-tête ailleurs que dans un fichier d'implémentation ( *.cpp), et que nous devons utiliser un certain nombre de fois notre classe avec une même valeur dans ces différents fichiers d'implémentation, il me semble que nous nous retrouverions avec... autant de variables, limitées à l'unité de compilation qu'il n'y a de fichiers d'implémentations dans laquelle elle sera utilisée.

Comme je l'ai dit plus haut, le problème reste marginal dans le sens où nous aurions, au pire quelque dizaines de variables de type int (mettons), propres à chaque unité de compilation. Il en faudrait donc beaucoup pour arriver à une différence significative en terme de taille de l'exécutable.

Mais le problème peut malgré tout se poser

[oodini]

Je remets une pièce dans le nourrain :

http://www.augias.org/paercebal/tech...ependancy.html

[3DArchi]

Salut,
Juste une nuance, cela ne s'applique pas pour la méta-prog. Et là, je ne suis pas sur que le compilateur puisse substituer la valeur effective plutôt que d'utiliser une variable dans l'exécutable/bibliothèque cible.