www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why are multiple instances of the single enum created?

reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
An enum only exists at compile-time, and does not occupy any
space. Each time it's referenced, a new instance of the value
is created. Why is that? Seems like a waste of resources to the 
compiler.
Feb 01 2021
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On Monday, 1 February 2021 at 09:40:20 UTC, Per Nordlöw wrote:

 An enum only exists at compile-time, and does not occupy any
 space. Each time it's referenced, a new instance of the value
 is created. Why is that? Seems like a waste of resources to the 
 compiler.


It makes perfect sense for numeric values, strings, characters 
and similar values. Why waste extra space on a variable if it's 
not needed?

If you don't want a new instance, then don't use `enum`. Use 
`immutable` instead.

--
/Jacob Carlborg
Feb 01 2021
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 1 February 2021 at 09:52:07 UTC, Jacob Carlborg wrote:

 If you don't want a new instance, then don't use `enum`. Use 
 `immutable` instead.


Agreed. My question is why does an `enum` require an extra 
instance from a compiler architecture point of view? Do all 
compilers handle compile-time enum instances in that way?
Feb 01 2021
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 1 February 2021 at 10:08:21 UTC, Per Nordlöw wrote:


 Agreed. My question is why does an `enum` require an extra 
 instance from a compiler architecture point of view? Do all 
 compilers handle compile-time enum instances in that way?


There is no "extra" instance because there's no single instance 
of an enum value. They have no address. When you use one, it's 
just as if you were writing the literal instead of the enum name. 
In other words:

enum ea = [1, 2, 3];
auto a0 = ea;
auto a1 = ea;

is identical to this:

auto a0 = [1, 2, 3];
auto a1 = [1, 2, 3];

It's purely a compile-time construct. Essentially just an alias 
for a literal.
Feb 01 2021
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 1 February 2021 at 10:24:59 UTC, Mike Parker wrote:

 There is no "extra" instance because there's no single instance 
 of an enum value. They have no address. When you use one, it's 
 just as if you were writing the literal instead of the enum 
 name. In other words:

 enum ea = [1, 2, 3];
 auto a0 = ea;
 auto a1 = ea;

 is identical to this:

 auto a0 = [1, 2, 3];
 auto a1 = [1, 2, 3];


Ok, so then my follow-up question becomes, does the right hand 
sides of these two assignment share the same AST node? If not, 
why?
Feb 01 2021
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 1 February 2021 at 11:37:49 UTC, Per Nordlöw wrote:

 Ok, so then my follow-up question becomes, does the right hand 
 sides of these two assignment share the same AST node? If not, 
 why?


Because such a shared AST node could be potentially mutated in 
different ways in different contexts during its passes?
Feb 01 2021
parent Q. Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 1 February 2021 at 11:39:26 UTC, Per Nordlöw wrote:

 On Monday, 1 February 2021 at 11:37:49 UTC, Per Nordlöw wrote:

 Ok, so then my follow-up question becomes, does the right hand 
 sides of these two assignment share the same AST node? If not, 
 why?


 Because such a shared AST node could be potentially mutated in 
 different ways in different contexts during its passes?


The spec says nothing about AST nodes. You can ask what DMD does 
(I don't know), but technically speaking, ASTs are an 
implementation detail of a compiler. A compiler need not have 
ASTs at all to follow the spec (unless the spec demands ASTs to 
exist, which I think it does not do). A compiler can change its 
AST nodes to a different yet equivalent representation without 
issue (unless the spec demands ASTs to exist and be of a certain 
form, which I think it does not do).
Feb 01 2021
prev sibling parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 1 February 2021 at 09:40:20 UTC, Per Nordlöw wrote:

 An enum only exists at compile-time, and does not occupy any
 space. Each time it's referenced, a new instance of the value
 is created. Why is that?


Short answer: An enum is a literal you can refer to by name. 
That's my mind-model for an enum.

Long answer: If you use the literal "abc" twice, because it's 
underlying type is immutable (string == immutable(char)[]), the 
compiler can elide multiple allocations. But ['a','b','c'] has to 
be allocated each use. Basically, it lowers to a `new char[](3)` 
plus initialization.
It is completely irrelevant how the value has been determined.
Feb 01 2021
parent Q. Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 1 February 2021 at 20:00:26 UTC, Q. Schroll wrote:

 On Monday, 1 February 2021 at 09:40:20 UTC, Per Nordlöw wrote:

 An enum only exists at compile-time, and does not occupy any
 space. Each time it's referenced, a new instance of the value
 is created. Why is that?


 Short answer: An enum is a literal you can refer to by name. 
 That's my mind-model for an enum.


I forgot to mention: An enum can have a precise type. As a stupid 
example, there are no first-class literals of type short or byte. 
But you can easily have short or byte enums. Also, the empty 
slice [] is typed void[] if you ask typeof([]); but an empty enum 
can be typed as any T[].
Feb 01 2021