const vs enum em D

Question

Confira esta citação de aqui , para a parte inferior da página. (Eu acredito que o comentário citado sobre consts aplica a invariants também)

Enumerations diferem de consts na medida em que não consomem nenhum espaço na final emitido objeto / biblioteca / arquivo executável, enquanto consts fazer.

Então, aparentemente value1 vai inchar o executável, enquanto value2 é tratado como um literal e não aparece no arquivo do objeto.

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

Para trás em C ++ Eu sempre assumi este foi por razões de legado, e compiladores antigos que não poderia otimizar afastado constantes. Mas se isso ainda é verdade em D, deve haver uma razão mais profunda por trás disso. Alguém sabe por que?

Answer 1

Assim como em C ++, um enum em D parece ser um "conservada inteiro literal" ( Editar : surpresa, D2 ainda suporta bóias e cordas ). Seus entrevistadores não têm localização. Eles são apenas imaterial como valores sem identidade.

Colocar enum é novo em D2. Ele primeiro define uma nova variável. Não é um lvalue (assim você também não pode tomar o seu endereço). Um

enum int a = 10; // new in D2

É como

enum : int { a = 10 }

Se eu posso confiar meu conhecimento pobre D. Então, a aqui não é um lvalue (sem local e você não pode tomar o seu endereço). A const, no entanto, tem um endereço. Se você tem um global (não tenho certeza se essa é a terminologia D direita) variável const, o compilador geralmente não podem otimizá-lo para longe, porque ele não sabe o que os módulos podem acessar essa variável ou poderia tomar o seu endereço. Então isso tem que alocar armazenamento para ele.

Eu acho que se você tem um const local, o compilador ainda pode otimizá-lo afastado apenas como em C ++, porque o compilador sabe, olhando para o seu alcance ou não alguém está interessado em seu endereço ou se todos só tem seu valor.

Answer 2

A sua questão real; por enumeração / const é o mesmo em D como no C ++; parece ser sem resposta. Infelizmente não existe nenhuma boa razão para esta escolha qualquer. Eu acredito que este foi apenas um efeito colateral não intencional em C ++ que se tornou um padrão de facto. Em D era necessário o mesmo padrão, e Walter Bright decidiu que deveria ser feito como em C ++ tal que quem vem de que lugar seria reconhecer o que fazer ... Na verdade, antes desta decisão, em vez IMHO bobo, foi utilizado o manifesto palavra-chave em vez de enum para este usecase.

Answer 3

Eu acho que um bom compilador / vinculador ainda deve remover a constante. É que com a enumeração, é realmente garantido na spec. A diferença é principalmente uma questão de semântica. (Também tenha em mente que 2.0 não está completa ainda)

Answer 4

O propósito real de enum sendo expandida sintaticamente para apoiar constantes visíveis individuais, pelo que eu entendo, é que Don Clugston, um guru modelo D, estava fazendo algumas coisas malucas com modelos. Ele continuou correndo em tempos de construção longos, o uso de memória do compilador ridículo, etc. porque o compilador continuou criando strucutres de dados internos para variáveis ??const. Uma coisa importante sobre const variáveis ??/ imutáveis ??em comparação com enums é que const / variáveis ??imutáveis ??são lvalues ??e pode ter seu endereço tomadas. Isto significa que há alguma sobrecarga extra para o compilador. Isso geralmente não importa, mas quando você está executando realmente complicado metaprogramas em tempo de compilação, mesmo se const variáveis ??são otimizados de distância, este ainda é uma sobrecarga significativa em tempo de compilação.

Answer 5

Parece que o valor de enumeração será usado "inline" em expressões onde, como o const vai realmente tomar armazenamento e qualquer expressão fazendo referência a ele será carregar o valor do armazenamento de memória.

Este som semelhante à diferença entre const vs. somente leitura em C #. O primeiro é uma constante de tempo de compilação e mais tarde é uma constante de tempo de execução. Isso definitivamente afetado versões de conjuntos (desde montagens referência a um readonly receberia uma cópia em tempo de compilação e não iria ficar uma alteração no valor se o assembly referenciado foi reconstruída com um valor diferente).