Re: Question about @nogc in D 2.066
On Friday, 11 July 2014 at 21:02:30 UTC, Timon Gehr wrote:
He is allocating an immutable(int)[] here. There is no reason
why it should allocate unless providing different addresses for
different runs of the code is considered a feature, as the
literal has a compile-time known value. It's just that the
frontend does not actually elide the allocation, and this would
be a valid extension to ask for.
In any case, the allocation can be manually elided as follows:
void main(string[] args)@nogc{
auto s1 = "hello";
static immutable _a1 = [1, 2];
auto a1 = _a1;
}
(Not actually tested, because I am having trouble downloading
the beta for some reason.)
Sure, no objections here - it just happened that doing so for
string literals was more obvious because literals themselves are
immutable. And doing so for arrays requires tiny bit of
semantical analysis (probably not really difficult too, I don't
know)
Re: Question about @nogc in D 2.066
http://forum.dlang.org/thread/pxotrowaqcenrpnnw...@forum.dlang.org
Re: Question about @nogc in D 2.066
On 07/11/2014 10:39 PM, Dicebot wrote:
Key difference is that type of string literal is immutable(char)[] so it
is perfectly legal to keep it in binary text segment. Type of array
literal is just T[] (int[] here) and you can possibly mutate their
elements. Because of this each assignment of array literal needs to
allocate a new copy contrary to immutable strings which can all
reference same memory chunk.
He is allocating an immutable(int)[] here. There is no reason why it
should allocate unless providing different addresses for different runs
of the code is considered a feature, as the literal has a compile-time
known value. It's just that the frontend does not actually elide the
allocation, and this would be a valid extension to ask for.
In any case, the allocation can be manually elided as follows:
void main(string[] args)@nogc{
auto s1 = "hello";
static immutable _a1 = [1, 2];
auto a1 = _a1;
}
(Not actually tested, because I am having trouble downloading the beta
for some reason.)
Re: Question about @nogc in D 2.066
Key difference is that type of string literal is immutable(char)[] so it is perfectly legal to keep it in binary text segment. Type of array literal is just T[] (int[] here) and you can possibly mutate their elements. Because of this each assignment of array literal needs to allocate a new copy contrary to immutable strings which can all reference same memory chunk.
Re: Question about @nogc in D 2.066
On Friday, 11 July 2014 at 20:02:32 UTC, Weasel wrote: Why does the s1 not throw an error, but the a1 does? Strings don't allocate upon use whereas all other arrays do unless you specifically mark it as static - immutability isn't considered here (I think because the part of the compiler that looks at the array literal doesn't look at the type on the left hand side so it just doesn't know but i'm not sure about why). But if you make the immutable other array static it shouldn't GC allocate.
Question about @nogc in D 2.066
@nogc
void main(string[] args)
{
immutable(char)[] s1 = "hello";
immutable(int)[] a1 = [1, 2];
}
Why does the s1 not throw an error, but the a1 does? As far as I
can tell, they're both immutable arrays.
Error is: "Error: array literal @nogc function main may cause GC
allocation"
It compiles fine if I comment out the second line in main.
