[Issue 4378] Array Literals as Default Field Initializers Shared Across Instances.
http://d.puremagic.com/issues/show_bug.cgi?id=4378
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment #6 from yebblies yebbl...@gmail.com 2010-06-25 01:24:21 PDT ---
I can't get dmd to find core.thread atm for some reason, but does the same
thing happen with tls globals?
eg.
import core.thread;
import std.stdio;
int[] x = [1, 2, 3];
void main()
{
writeln(x);
x[0] = 9;
writeln(x);
new Thread(thread2);
}
void thread2()
{
writeln(x);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4378] Array Literals as Default Field Initializers Shared Across Instances.
http://d.puremagic.com/issues/show_bug.cgi?id=4378 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #4 from nfx...@gmail.com 2010-06-24 05:32:46 PDT --- How is this supposed to work correctly? Hidden allocation of an array on the heap every time a struct of that type is constructed? Disallow initializing non-immutable, non-static array members? This is not a bug, it's just D _works_. If you assign an array to a global variable, of course it's shared by everyone. Dynamic arrays are reference types. The variable being a struct initializer doesn't change this. I think this really should be marked as INVALID. (I'm sure it's somewhat confusing for programmers coming from C++ or Java. Especially in Java, the array would be reconstructed every time the constructor is called. Stuff like this _never_ happens in D: structs are always initialized by what boils down to a memcpy.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4378] Array Literals as Default Field Initializers Shared Across Instances.
http://d.puremagic.com/issues/show_bug.cgi?id=4378 --- Comment #5 from Jonathan M Davis jmdavisp...@gmail.com 2010-06-24 10:07:27 PDT --- bar is a member varible _not_ a class variable and should _not_ be global. As such, two independently constructed variables of type Foo should have bars which referenc totally separate arrays. If bar were static, then they'd be shared, but it's not. Now, if the second Foo were constructed by copying the first one, then sure, that's going to result in both bars referencing the same array, and setting an element of one will affect the other. However, in this case, both variables of type Foo were constructed independently, so their bars should not point to the same array. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4378] Array Literals as Default Field Initializers Shared Across Instances.
http://d.puremagic.com/issues/show_bug.cgi?id=4378 Jonathan M Davis jmdavisp...@gmail.com changed: What|Removed |Added CC||jmdavisp...@gmail.com --- Comment #1 from Jonathan M Davis jmdavisp...@gmail.com 2010-06-23 17:17:27 PDT --- I think that you mean writeln(foo2.bar); // 3 2 3 4 5 but regardless, it's definitely a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4378] Array Literals as Default Field Initializers Shared Across Instances.
http://d.puremagic.com/issues/show_bug.cgi?id=4378 --- Comment #2 from David Simcha dsim...@yahoo.com 2010-06-23 17:45:44 PDT --- Yeah, that's just a typo. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4378] Array Literals as Default Field Initializers Shared Across Instances.
http://d.puremagic.com/issues/show_bug.cgi?id=4378 --- Comment #3 from David Simcha dsim...@yahoo.com 2010-06-23 17:46:59 PDT --- Forgot to mention, this also applies to classes, not just structs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
