I often hear it advised to avoid using enum with arrays because they will allocate at the usage point, but does this also apply to strings?
strings are arrays, so naively it seems that they would, but that seems odd to me.
I would imagine string literals end up in the data segment as they are immutable.

As a continuation of this question, I know that string literals have an implicit null delimiter, so it should be correct to pass a "literal".ptr to a function taking a C-string, and presumably this still applies when using enum.
However, if enum implies allocation at the usage point for strings, one would be better served with static, meaning one would need to be explicit: static foo = "bar\0"?

On 03/17/2015 11:21 AM, "岩倉 澪" wrote:
> I often hear it advised to avoid using enum with arrays because they
> will allocate at the usage point, but does this also apply to strings?
> strings are arrays, so naively it seems that they would, but that seems
> odd to me.
> I would imagine string literals end up in the data segment as they are
> immutable.
>
> As a continuation of this question, I know that string literals have an
> implicit null delimiter, so it should be correct to pass a "literal".ptr
> to a function taking a C-string, and presumably this still applies when
> using enum.
> However, if enum implies allocation at the usage point for strings, one
> would be better served with static, meaning one would need to be
> explicit: static foo = "bar\0"?

Strings are fine and fortunately it is very easy to test:

enum arr = [ 1, 2 ];
enum s = "hello";

void main()
{
    assert(arr.ptr !is arr.ptr);
    assert(s.ptr    is s.ptr);
}

Ali

On Tuesday, 17 March 2015 at 18:25:00 UTC, Ali Çehreli wrote:
> Strings are fine and fortunately it is very easy to test:
>
> enum arr = [ 1, 2 ];
> enum s = "hello";
>
> void main()
> {
>     assert(arr.ptr !is arr.ptr);
>     assert(s.ptr    is s.ptr);
> }
>
> Ali

Ah, that is good to know. Thanks!

On Tue, 17 Mar 2015 11:25:00 -0700
Ali Çehreli via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> On 03/17/2015 11:21 AM, "岩倉 澪" wrote:
> > I often hear it advised to avoid using enum with arrays because they
> > will allocate at the usage point, but does this also apply to
> > strings? strings are arrays, so naively it seems that they would,
> > but that seems odd to me.
> > I would imagine string literals end up in the data segment as they
> > are immutable.
> >
> > As a continuation of this question, I know that string literals
> > have an implicit null delimiter, so it should be correct to pass a
> > "literal".ptr to a function taking a C-string, and presumably this
> > still applies when using enum.
> > However, if enum implies allocation at the usage point for strings,
> > one would be better served with static, meaning one would need to be
> > explicit: static foo = "bar\0"?
> 
> Strings are fine and fortunately it is very easy to test:
> 
> enum arr = [ 1, 2 ];
> enum s = "hello";
> 
> void main()
> {
>      assert(arr.ptr !is arr.ptr);
>      assert(s.ptr    is s.ptr);
> }
> 
> Ali
> 

But is it document somewhere by spec? Or it is just an optimalization which could be remove at some point?

On Wednesday, 18 March 2015 at 07:58:58 UTC, Daniel Kozák wrote:
> But is it document somewhere by spec? Or it is just an optimalization
> which could be remove at some point?

I cannot find it in the specification, but it is guaranteed. It's a benefit we get from the immutability of strings. AFAIK the compiler will even merge identical string literals, even when they appear in different modules.

岩倉 澪:

> However, if enum implies allocation at the usage point for strings,

There are two ways to see if something allocates: there is a compiler switch, and an annotation:

void foo() @nogc {
    // Your code here
}

If the compiler doesn't have a bug it will complain if you put something that allocates inside that function.

Bye,
bearophile