const vs enum en D

Question

Consultez cette citation sur ici . , vers le bas de la page. (Je crois que le commentaire cité à propos de const s'applique également aux invariants )

  

Les énumérations diffèrent des const en ce qu'elles ne consomment aucun espace.   dans le dernier objet en sortie / bibliothèque / exécutable, alors que consts le font.

Donc, apparemment, valeur1 gonfle l'exécutable, alors que valeur2 est traité comme un littéral et n'apparaît pas dans le fichier objet.

const int value1 = 0xBAD;
enum int value2 = 42;

De retour en C ++, j'ai toujours supposé que c'était pour des raisons d'héritage et d'anciens compilateurs qui ne pouvaient pas optimiser les constantes. Mais si cela est toujours vrai dans D, il doit y avoir une raison plus profonde derrière cela. Quelqu'un sait pourquoi?

Answer 1

Tout comme en C ++, une énumération dans D semble être un "entier littéral conservé". ( modifier : incroyable, D2 prend même en charge les flotteurs et chaînes ). Ses recenseurs n'ont pas d'emplacement. Elles sont immatérielles en tant que valeurs sans identité.

Placer enum est nouveau dans D2. Il définit d'abord une nouvelle variable. Ce n'est pas une valeur (vous ne pouvez donc pas non plus prendre son adresse). Un

enum int a = 10; // new in D2

est comme

enum : int { a = 10 }

Si je peux faire confiance à ma pauvre connaissance de D. Donc, a ici n’est pas une valeur (pas d’emplacement et vous ne pouvez pas prendre son adresse). Un const, cependant, a une adresse. Si vous avez une variable const globale (vous ne savez pas si c'est la bonne terminologie D), le compilateur ne peut généralement pas l'optimiser, car il ne sait pas quels modules peuvent accéder à cette variable ou prendre son adresse. Il doit donc allouer de la mémoire pour cela.

Je pense que si vous avez un agent local, le compilateur peut l’optimiser comme en C ++, car il sait en regardant dans son étendue si son adresse intéresse ou non, ou tout le monde en prend la valeur.

Answer 2

Votre question actuelle; pourquoi enum / const est identique en D et en C ++; semble être sans réponse. Malheureusement, il n’existe aucune raison valable pour ce choix. Je pense qu’il s’agissait d’un effet secondaire non intentionnel en C ++ qui est devenu un modèle de facto. En D, le même schéma était nécessaire, et Walter Bright a décidé que cela devrait être fait comme en C ++, de sorte que ceux qui viennent de cet endroit sachent quoi faire ... En fait, avant cette décision plutôt idiote à mon humble avis, le mot-clé manifest était utilisé au lieu d'enum pour cette cas d'utilisation.

Answer 3

Je pense qu'un bon compilateur / éditeur de liens devrait toujours supprimer la constante. C'est juste qu'avec l'énum, ??c'est garanti dans la spécification. La différence est principalement une question de sémantique. (N'oubliez pas non plus que la version 2.0 n'est pas encore complète)

Answer 4

Le but réel de enum étant développé syntaxiquement pour prendre en charge des constantes de manifeste uniques, d'après ce que je comprends, c'est que Don Clugston, un gourou des modèles D, faisait des choses folles avec des modèles. Il a continué à courir dans des temps de construction longs, à utiliser une mémoire ridicule, etc. parce que le compilateur continuait à créer des structures de données internes pour les variables const. Un élément clé concernant les variables const / immuable par rapport aux énumérations est que les variables const / immuable sont des valeurs et peuvent avoir leur adresse prise. Cela signifie qu'il y a des frais supplémentaires pour le compilateur. Cela n’importe généralement pas, mais lorsque vous exécutez des métaprogrammes très compliqués au moment de la compilation, même si les variables const sont optimisées, cela reste une surcharge importante au moment de la compilation.

Answer 5

Il semble que la valeur enum sera utilisée " inline " dans des expressions où, en tant que const, prendra effectivement de la mémoire et toute expression la référant chargera la valeur à partir de la mémoire.

Ce son est similaire à la différence entre const et lecture seule en C #. La première est une constante au moment de la compilation et la dernière est une constante au moment de l'exécution. Cela a certainement affecté le contrôle de version des assemblys (puisque les assemblys référençant une lecture seule recevraient une copie au moment de la compilation et n'obtiendraient pas de modification de la valeur si l'assembly référencé était reconstruit avec une valeur différente).