www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - unittest affects next unittest

reply "sigod" <sigod.mail gmail.com> writes:
Code: http://dpaste.dzfl.pl/51bd62138854
(It was reduced by DustMite.)

Have I missed something about structs? Or this simply a bug?
Aug 01 2014
next sibling parent "safety0ff" <safety0ff.dev gmail.com> writes:
On Friday, 1 August 2014 at 23:09:39 UTC, sigod wrote:
 Code: http://dpaste.dzfl.pl/51bd62138854
 (It was reduced by DustMite.)

 Have I missed something about structs? Or this simply a bug?
Isn't this the same mistake as: http://forum.dlang.org/thread/muqgqidlrpoxedhyuaec forum.dlang.org#post-mpcwwjuaxpvwiumlyqls:40forum.dlang.org In other words: private Node * _root = new Node(); looks wrong.
Aug 01 2014
prev sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Fri, 01 Aug 2014 23:09:37 +0000
sigod via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:

 Code: http://dpaste.dzfl.pl/51bd62138854
 (It was reduced by DustMite.)

 Have I missed something about structs? Or this simply a bug?
Don't do this with a member variable: private Node * _root = new Node(); Directly initializing it like that sets the init value for that struct, and that means that every struct of that type will have exactly the same value for _root, so they will all share the same root rather than having different copies. You need to initialize _root in the constructor. - Jonathan M Davis
Aug 01 2014
parent reply "sigod" <sigod.mail gmail.com> writes:
On Saturday, 2 August 2014 at 06:46:04 UTC, Jonathan M Davis via 
Digitalmars-d-learn wrote:
 On Fri, 01 Aug 2014 23:09:37 +0000
 sigod via Digitalmars-d-learn 
 <digitalmars-d-learn puremagic.com> wrote:

 Code: http://dpaste.dzfl.pl/51bd62138854
 (It was reduced by DustMite.)

 Have I missed something about structs? Or this simply a bug?
Don't do this with a member variable: private Node * _root = new Node(); Directly initializing it like that sets the init value for that struct, and that means that every struct of that type will have exactly the same value for _root, so they will all share the same root rather than having different copies. You need to initialize _root in the constructor. - Jonathan M Davis
So, it's a static initialization? Documentation didn't mention it. (In class' section only 2 sentences about it and none in struct's section.) This is different from many languages (C#, Java... don't know about C and C++). What was the reason to make this initialization static?
Aug 05 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 5 August 2014 at 15:39:55 UTC, sigod wrote:
 On Saturday, 2 August 2014 at 06:46:04 UTC, Jonathan M Davis 
 via Digitalmars-d-learn wrote:
 On Fri, 01 Aug 2014 23:09:37 +0000
 sigod via Digitalmars-d-learn 
 <digitalmars-d-learn puremagic.com> wrote:

 Code: http://dpaste.dzfl.pl/51bd62138854
 (It was reduced by DustMite.)

 Have I missed something about structs? Or this simply a bug?
Don't do this with a member variable: private Node * _root = new Node(); Directly initializing it like that sets the init value for that struct, and that means that every struct of that type will have exactly the same value for _root, so they will all share the same root rather than having different copies. You need to initialize _root in the constructor. - Jonathan M Davis
So, it's a static initialization? Documentation didn't mention it. (In class' section only 2 sentences about it and none in struct's section.) This is different from many languages (C#, Java... don't know about C and C++). What was the reason to make this initialization static?
It's a consequence of the fact that every type in D has a default initializer which is known at compile time.
Aug 05 2014
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, 5 August 2014 at 17:41:06 UTC, Marc Schütz wrote:
 On Tuesday, 5 August 2014 at 15:39:55 UTC, sigod wrote:
 On Saturday, 2 August 2014 at 06:46:04 UTC, Jonathan M Davis 
 via Digitalmars-d-learn wrote:
 On Fri, 01 Aug 2014 23:09:37 +0000
 sigod via Digitalmars-d-learn 
 <digitalmars-d-learn puremagic.com> wrote:

 Code: http://dpaste.dzfl.pl/51bd62138854
 (It was reduced by DustMite.)

 Have I missed something about structs? Or this simply a bug?
Don't do this with a member variable: private Node * _root = new Node(); Directly initializing it like that sets the init value for that struct, and that means that every struct of that type will have exactly the same value for _root, so they will all share the same root rather than having different copies. You need to initialize _root in the constructor. - Jonathan M Davis
So, it's a static initialization? Documentation didn't mention it. (In class' section only 2 sentences about it and none in struct's section.) This is different from many languages (C#, Java... don't know about C and C++). What was the reason to make this initialization static?
It's a consequence of the fact that every type in D has a default initializer which is known at compile time.
That and it solves a lot of problems with undefined behavior (this is particularly true when talking about module-level variables). static initialization ordering problems are hell in other languages (especially in C++). By making it so that all direct initializations of variables other than local variables are done statically, all kinds of nasty, subtle bugs go away. The one nasty, subtle issue that it causes that I'm aware of is that if you directly initialize any member variables which are reference types, then all instances of that type end up referring to the same object - and that's what you ran into. But fortunately, that's easy to fix, whereas the static initialization problems that were fixed by making all of those variables have to be initialized at compile time are much harder to fix. - Jonathan M Davis
Aug 05 2014
prev sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Tuesday, 5 August 2014 at 17:41:06 UTC, Marc Schütz wrote:
 It's a consequence of the fact that every type in D has a 
 default initializer which is known at compile time.
Then doesn't this mean it should pop out a warning in case that's the behavior you wanted, perhaps a reference to the D specs? Beyond that it would be easy to forget it does that, since class initializes things different than structs because of the 'known at compile time' logic.
Aug 05 2014
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, 6 August 2014 at 02:12:16 UTC, Era Scarecrow wrote:
 On Tuesday, 5 August 2014 at 17:41:06 UTC, Marc Schütz wrote:
 It's a consequence of the fact that every type in D has a 
 default initializer which is known at compile time.
Then doesn't this mean it should pop out a warning in case that's the behavior you wanted, perhaps a reference to the D specs? Beyond that it would be easy to forget it does that, since class initializes things different than structs because of the 'known at compile time' logic.
It wouldn't make sense to warn about that, because it could be very legitimately be what the programmer wants to do. We can't warn about anything that would be legitimate to have, because it would force programmers to change their code to get rid of the warning, even when the code was valid. So, while in most cases, it might be a problem, we can't warn about it. But I do think that the spec should be clearer about it. - Jonathan M Davis
Aug 06 2014
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Wednesday, 6 August 2014 at 17:42:02 UTC, Jonathan M Davis 
wrote:
 It wouldn't make sense to warn about that, because it could be 
 very legitimately be what the programmer wants to do. We can't 
 warn about anything that would be legitimate to have, because 
 it would force programmers to change their code to get rid of 
 the warning, even when the code was valid. So, while in most 
 cases, it might be a problem, we can't warn about it. But I do 
 think that the spec should be clearer about it.
This is the similar problem to assignment inside if statements where it's easy to mistake and can cause problems later. I think it should warn, because the behavior although proper is a jarring difference from a class version of it. However to make the warning go away with 'yeah this is what i want so don't complain' a simple tag confirms while doubling as documentation for behavior would probably be enough. A short simple word probably wouldn't be enough for specific cases but something short... Maybe shared_init or propagates_statically, static_assignment or something. Of course i don't want to litter the language with tags that aren't relevant except in certain obscure cases...
Aug 06 2014