www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - enum str = "abc"; vs string str = "abc";

reply Victor Porton <porton narod.ru> writes:
What is more space efficient:

enum str = "safjkdfjksdlfkdsj";

or

string str = "safjkdfjksdlfkdsj";

?

with the first code fragment, won't the string be re-created and 
re-inserted into the object file one time whenever str is used, 
rather than once?

What of the two you would recommend?
Jan 16 2019
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 16, 2019 at 06:21:29PM +0000, Victor Porton via Digitalmars-d wrote:

 What is more space efficient:
 
 enum str = "safjkdfjksdlfkdsj";
 
 or
 
 string str = "safjkdfjksdlfkdsj";
 
 ?
 
 with the first code fragment, won't the string be re-created and
 re-inserted into the object file one time whenever str is used, rather
 than once?


Strings are a bit special, in that the compiler automatically stores
them in a string table and emits them only once.  However, you're quite
right that using enum with arrays in general is not a good idea
space-wise.



 What of the two you would recommend?


Use:
	immutable str = "...";

in module-global scope. Or if this is inside a function,

	static immutable str = "...";

This places it in the data section of the object file and elides the
extra pointer/size pair of `str` if it were mutable.


OTOH, if `str` is only referenced at compile-time, then it's more
efficient to use the enum, because then it won't even appear in the
object file. :-)  Also, you may have no choice but to use an enum if
`str` is referenced by compile-time code, since static globals would not
be readable at compile-time.


T

-- 
Study gravitation, it's a field with a lot of potential.
Jan 16 2019
next sibling parent Victor Porton <porton narod.ru> writes:
On Wednesday, 16 January 2019 at 18:50:51 UTC, H. S. Teoh wrote:

 On Wed, Jan 16, 2019 at 06:21:29PM +0000, Victor Porton via

 What of the two you would recommend?


 Use:
 	immutable str = "...";

 in module-global scope. Or if this is inside a function,

 	static immutable str = "...";

 This places it in the data section of the object file and 
 elides the extra pointer/size pair of `str` if it were mutable.


I haven't got what is your argument pro `immutable str` and so 
against enum.
Jan 16 2019
prev sibling next sibling parent reply Johannes Loher <johannes.loher fg4f.de> writes:
On Wednesday, 16 January 2019 at 18:50:51 UTC, H. S. Teoh wrote:

 Also, you may have no choice but to use an enum if `str` is 
 referenced by compile-time code, since static globals would not 
 be readable at compile-time.


They are, if they are declared immutable (which is no problem if 
using enum would also be ok). The following program outputs "0" 
during compilation:

```
static immutable i = 0;

static if (i == 0)
{
     pragma(msg, i);
}

void main()
{

}
```
Jan 16 2019
parent Johannes Loher <johannes.loher fg4f.de> writes:
On Wednesday, 16 January 2019 at 19:06:18 UTC, Johannes Loher 
wrote:

 On Wednesday, 16 January 2019 at 18:50:51 UTC, H. S. Teoh wrote:

 Also, you may have no choice but to use an enum if `str` is 
 referenced by compile-time code, since static globals would 
 not be readable at compile-time.


 They are, if they are declared immutable (which is no problem 
 if using enum would also be ok). The following program outputs 
 "0" during compilation:

 ```
 static immutable i = 0;

 static if (i == 0)
 {
     pragma(msg, i);
 }

 void main()
 {

 }
 ```


Actually in this case, it can also simply be `immutable i = 0;`, 
the `static` keyword doesn't do anything in this case. This also 
works and also prints "0" during compilation:
```
void main()
{
     static immutable i = 0;

     static if (i == 0)
     {
         pragma(msg, i);
     }
}
```

The argument for using `static immutable` (or `immutable` at 
module level) is that unlike enum, it will only ever use one 
instance. It will not allocate several times. As was mentioned 
before, this is also true for `enum` when used with strings, but 
strings are a special case. For other array types (and 
associative array types), a new instance is allocated whenever 
the `enum` is used.
Jan 16 2019
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/16/19 1:50 PM, H. S. Teoh wrote:

 Also, you may have no choice but to use an enum if
 `str` is referenced by compile-time code, since static globals would not
 be readable at compile-time.


Not sure what you mean, this should work.

Only immutable globals that aren't initialized until runtime can't be used.

e.g.:

immutable string s;
immutable string s2 = "abc";

shared static this()
{
    s = "abc";
}

pragma(msg, s); // error
pragma(msg, s2); // OK


-Steve
Jan 16 2019
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 16, 2019 at 02:10:02PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:

 On 1/16/19 1:50 PM, H. S. Teoh wrote:

 Also, you may have no choice but to use an enum if `str` is
 referenced by compile-time code, since static globals would not be
 readable at compile-time.


 
 Not sure what you mean, this should work.
 
 Only immutable globals that aren't initialized until runtime can't be
 used.


Ahh, I see.  I stand corrected. :-)


T

-- 
Verbing weirds language. -- Calvin (& Hobbes)
Jan 16 2019
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/16/2019 10:21 AM, Victor Porton wrote:

 What is more space efficient:
 
 enum str = "safjkdfjksdlfkdsj";
 
 or
 
 string str = "safjkdfjksdlfkdsj";
 
 ?


You can find this out by:

     dmd -c test.d
     obj2asm test.obj

Also,

     enum s = "hello";
     size_t i = s.length;

The string "hello" does not appear in the object file.

     immutable string s = "hello";
     size_t i = s.length;

The string "hello" does appear in the object file.

     immutable string s = "hello";
     immutable string t = "hello";

The string "hello" appears only once in the object file.
Jan 16 2019
prev sibling parent reply Mathias Lang <pro.mathias.lang gmail.com> writes:
On Wednesday, 16 January 2019 at 18:21:29 UTC, Victor Porton 
wrote:

 What is more space efficient:

 enum str = "safjkdfjksdlfkdsj";

 or

 string str = "safjkdfjksdlfkdsj";

 ?

 with the first code fragment, won't the string be re-created 
 and re-inserted into the object file one time whenever str is 
 used, rather than once?

 What of the two you would recommend?


I've seen people using mostly `enum` over `(static) immutable`, 
but...

When we ported our code from D1 to D2 in Sociomantic, we created 
a small fixup tool 
(https://github.com/sociomantic-tsunami/d1to2fix) and one of its 
job was to convert D1-style manifest constant (`const X = 
initializer;`) into "D2 style" (`enum X = initializer;`). And 
allocations started to show up where they would not before. After 
we got a rather complete and insightful explanation of the 
difference between `enum` and `static immutable` by Don Clugston, 
we switched to `static immutable` (almost) everywhere, and that 
was definitely a win.

You can see `enum` as a `#define`. It will get "copy-pasted" 
everywhere, and thus, it's a rvalue (you can't take the address 
of an enum). On the other hand, `static immutable` are actual 
variable that will live in the binary. They are a symbol you can 
take the address of. They behave exactly like you would want a 
manifest constant to behave. There is only one corner case I know 
of where enum is more practical, it's the following code:

```D
static immutable INITIALIZER = [1, 2, 3, 4]; // Does not work 
because it tries to do immutable -> mutable
enum INITIALIZER = [1, 2, 3, 4]; // Works because every time it 
is used, it allocates a new array
void foo (int[] value = INITIALIZER) { ... }
```

That being said, the DMD frontend is clever enough to avoid 
pointless allocations in the most obvious cases. So for example 
an array literal indexed by a compile-time known index will not 
allocate (`enum ARR = [0, 1, 2]; int i = ARR[0];`). However, if 
the index is not known at compile time, it will allocate every 
time with `enum`, never with `static immutable`.


TL;DR: Use `static immutable` by default, `enum` if you want a 
`#define`.
Jan 16 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
That's true for arrays, but for strings the compiler will emit only one string, 
and everything else will refer to that.
Jan 16 2019
parent reply Meta <jared771 gmail.com> writes:
On Thursday, 17 January 2019 at 06:00:09 UTC, Walter Bright wrote:

 That's true for arrays, but for strings the compiler will emit 
 only one string, and everything else will refer to that.


While we have your ear, Walter, what about an enum that is an 
array of strings? Will an enum array of strings with length N 
behave the same way as a single string and only emit those N 
strings once, or will a new array be allocated each time the enum 
is used?
Jan 17 2019
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 17, 2019 at 03:16:16PM +0000, Meta via Digitalmars-d wrote:

 On Thursday, 17 January 2019 at 06:00:09 UTC, Walter Bright wrote:

 That's true for arrays, but for strings the compiler will emit only
 one string, and everything else will refer to that.


 
 While we have your ear, Walter, what about an enum that is an array of
 strings? Will an enum array of strings with length N behave the same
 way as a single string and only emit those N strings once, or will a
 new array be allocated each time the enum is used?


You could just check the disassembly yourself.  On my system, I found
that the strings themselves are only stored once. But the outer array is
allocated and repopulated each time, each time by a call to a druntime
function _d_arrayliteralTX.


T

-- 
Genius may have its limitations, but stupidity is not thus handicapped. --
Elbert Hubbard
Jan 17 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/17/2019 7:32 AM, H. S. Teoh wrote:

 You could just check the disassembly yourself.


It's a good practice to follow. I don't always remember what it does exactly,
as 
it changes over time, and multiple people have contributed to it. I check the 
assembler output myself just to be sure.
Jan 17 2019