unittest affects next unittest
Code: http://dpaste.dzfl.pl/51bd62138854 (It was reduced by DustMite.) Have I missed something about structs? Or this simply a bug?
Re: unittest affects next unittest
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/muqgqidlrpoxedhyu...@forum.dlang.org#post-mpcwwjuaxpvwiumlyqls:40forum.dlang.org In other words: private Node * _root = new Node(); looks wrong.
Re: unittest affects next unittest
On Fri, 01 Aug 2014 23:09:37 + sigod via Digitalmars-d-learn 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
Re: unittest affects next unittest
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 + sigod via Digitalmars-d-learn 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?
Re: unittest affects next unittest
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 + sigod via Digitalmars-d-learn 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.
Re: unittest affects next unittest
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 + sigod via Digitalmars-d-learn 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
Re: unittest affects next unittest
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.
Re: unittest affects next unittest
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
Re: unittest affects next unittest
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...
