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
