Re: Do strings with enum allocate at usage point?
岩倉 澪:
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
Re: Do strings with enum allocate at usage 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.
Re: Do strings with enum allocate at usage point?
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.ptris s.ptr);
}
Ali
But is it document somewhere by spec? Or it is just an optimalization
which could be remove at some point?
Re: Do strings with enum allocate at usage point?
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.ptris s.ptr);
}
Ali
Ah, that is good to know. Thanks!
Re: Do strings with enum allocate at usage point?
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.ptris s.ptr);
}
Ali
Do strings with enum allocate at usage point?
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?
