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.)


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.)


 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.)


 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