unittest affects next unittest

Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue Aug 5 18:22:51 PDT 2014


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 at 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


More information about the Digitalmars-d-learn mailing list