www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - magically a static member on init?

reply Martin <martin.brzenska googlemail.com> writes:
Hi, i do no know if this is intended - but imo this is weird:
https://run.dlang.io/is/eBje3A

I expected that `c.a.str == ""` (just like `c.str` is). But 
instead `c.a.str` keeps the value of `b.a.str`.

Is this intentional? IMO this feels not consistent and its weird 
when a reference leaks into another instance without having 
declared it static member.

Greetigs
Nov 14 2020
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 14 November 2020 at 23:20:55 UTC, Martin wrote:

 Is this intentional?


In the current language design, yes. For the many users who ask 
this, no.

All static initializers are run at compile time and refer to the 
static data segment - this is consistent across the language.

static x = y; // y is run at compile time

struct A {
     int[] a = [1,2,3]; // array built t compile time
}

so.....

void main() {
    A a;
    a.a[0] = 5;
    A b;
    b.a[0] == 5; // true!!!
}


Because both actually share the same initial array reference.


And with classes again, same deal. *Constructors* are run for 
each instance. But the rest of it is part of the static 
initializer that is shared....


 IMO this feels not consistent and its weird when a reference 
 leaks into another instance without having declared it static 
 member.



Yeah, it is weird and a frequent mistake people make, I almost 
wish it had to be more explicit (I'd be sad if it was removed 
though, I actually use this in places!).

But once you understand it it kinda makes sense.

Note btw that the reference itself is NOT static... just the 
object it refers to. So if you do

obj.a  = new Thing

then it doesn't affect other objects, just this one. But they all 
start off pointing to the same thing.
Nov 14 2020
next sibling parent Martin <martin.brzenska googlemail.com> writes:
On Saturday, 14 November 2020 at 23:30:58 UTC, Adam D. Ruppe 
wrote:

 On Saturday, 14 November 2020 at 23:20:55 UTC, Martin wrote:

 Is this intentional?


 [...]


alright, thank you! :)
Nov 14 2020
prev sibling parent reply Kagamin <spam here.lot> writes:
On Saturday, 14 November 2020 at 23:30:58 UTC, Adam D. Ruppe 
wrote:

 On Saturday, 14 November 2020 at 23:20:55 UTC, Martin wrote:

 Is this intentional?


 In the current language design, yes.


It's a bug, it breaks data sharing guarantees.
Nov 17 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 17 November 2020 at 13:24:03 UTC, Kagamin wrote:

 On Saturday, 14 November 2020 at 23:30:58 UTC, Adam D. Ruppe 
 wrote:

 On Saturday, 14 November 2020 at 23:20:55 UTC, Martin wrote:

 Is this intentional?


 In the current language design, yes.


 It's a bug, it breaks data sharing guarantees.


Hah, yes. Init actually should be thread local for this to work 
out...
Ref shared semantics...
Nov 17 2020
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Nov 14, 2020 at 11:20:55PM +0000, Martin via Digitalmars-d-learn wrote:

 Hi, i do no know if this is intended - but imo this is weird:
 https://run.dlang.io/is/eBje3A
 
 I expected that `c.a.str == ""` (just like `c.str` is). But instead
 `c.a.str` keeps the value of `b.a.str`.
 
 Is this intentional? IMO this feels not consistent and its weird when
 a reference leaks into another instance without having declared it
 static member.


[...]

This is a known "feature".  Using a `new` expression as a field
initializer will initialize it once at program startup, and the
reference is copied thereafter into all instances of the class.

If you want separate instances per class instantiation, move the `new`
into the constructor instead.

Yes, it does feel weird, and IMNSHO it's a misfeature. But it is what it
is; if you don't like the semantics, don't use it; always allocate the
field in the class ctor instead.


T

-- 
The fact that anyone still uses AOL shows that even the presence of options
doesn't stop some people from picking the pessimal one. - Mike Ellis
Nov 14 2020
parent reply Martin <martin.brzenska googlemail.com> writes:
On Sunday, 15 November 2020 at 00:29:41 UTC, H. S. Teoh wrote:

 if you don't like the semantics, don't use it; always allocate 
 the field in the class ctor instead.


Hi, i neither like it nor dislike it - it just caught me by 
surprise because i was under the impression that if i create a 
new instance then all members get initialized according to the 
declared optional default value.

I can see how this is a feature - but it is also of kind "expert 
knowledge" and i would argue that "expert knowladge" is a designs 
arch enemy.
Nov 15 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Nov 15, 2020 at 10:06:55AM +0000, Martin via Digitalmars-d-learn wrote:

 On Sunday, 15 November 2020 at 00:29:41 UTC, H. S. Teoh wrote:

 if you don't like the semantics, don't use it; always allocate the
 field in the class ctor instead.


 
 Hi, i neither like it nor dislike it - it just caught me by surprise
 because i was under the impression that if i create a new instance
 then all members get initialized according to the declared optional
 default value.
 
 I can see how this is a feature - but it is also of kind "expert
 knowledge" and i would argue that "expert knowladge" is a designs arch
 enemy.


Oh, I don't disagree; I think it's a bad design choice, and I don't
think I'd ever use this construct personally.  But it's there, and if
you use it, then you just have to be aware of the gotchas. :-)


T

-- 
Insanity is doing the same thing over and over again and expecting different
results.
Nov 16 2020