You should read this:

http://en.cppreference.com/w/c...

If no user-defined constructors of any kind are provided for a class type (struct, class, or union), the compiler will always declare a default constructor as an inline public member of its class.

So your Because: it has no ctor!! is definitely wrong. There are no structs, classes, or unions without a constructor. Never. Right is that i in B is not initialized because:

If the implicitly-declared default constructor is not deleted or trivial, it is defined (that is, a function body is generated and compiled) by the compiler, and it has exactly the same effect as a user-defined constructor with empty body and empty initializer list. That is, it calls the default constructors of the bases and of the non-static members of this class.

i is non-static, but a POD type -> no constructor, no default initialization. D has a constructor, which initializes s and calls the implicitly-declared default constructor in B, but this still does nothing for i, since B's default constructor is trivial:

Trivial default constructor

The default constructor for class T is trivial (i.e. performs no action) if all of the following is true:

• 
       
• The constructor is not user-provided (i.e., is implicitly-defined or defaulted)

•      

• T has no virtual member functions

•    

• T has no virtual base classes

•    

  T has no non-static members with brace-or-equal initializers. (since C++11)

         

• Every direct base of T has a trivial default constructor

•      

• Every non-static member of class type has a trivial default constructor

A trivial default constructor is a constructor that performs no action. Objects with trivial default constructors can be created by using reinterpret_cast on any suitably aligned storage, e.g. on memory allocated with std::malloc. All data types compatible with the C language (POD types) are trivially default-constructible.

i is in B as uninitalized as it is in D. No difference.

You did see, that I corrected my answer? Yes, I answered a bit too quickly. But for me the whole problem is irrelevant. From my earliest contacts with computer languages, it was BASIC in the early 80th, I have been taught: You initialize your variables. And this is exactly what I am doing. I have yet to see a problem where the few cycles for a possibly unneeded initialization make a difference. So this initialization problem is nothing I have constantly in my mind, And constructors wrong? You neither defined any of the four possible constructors, nor the destructor... and this means you get the defaults. And this has nothing to do with 'when needed', only with 'did I provide one myself, so the others are compiler generated or not?'.

And initialization of non-static member variables depend on compilation unit? Again, IMHO irrelevant, but please, show me the paragraf in the C++ standard. Please do, I am really interested. AFAIK only static or global variable build-in types get a default initialization. And I don't care for globals. Not only that I don't use them, I have not even seen them used in other ppls code in years.
I still have the nagging feeling, that somehow you mean the 'static initialization order fiasco', which can also happen with globals, and where the translation unit matters... only that this has nothing to do with the code you posted.

But yes, there can be initialization problems in C++, which are relevant and which really can be important.. and I admit, I also don't have constantly in my mind, because it is a rare problem: When deeper hierarchies of multi inheritance (virtual and not virtual) are used. But so what? I know the problem and if needed I look into the specs for a fresh up.

Do you really want to tell me that no other language has less used features, or pitfalls, which are simply irrelevant when good coding styles are used?

Little correction... the i are not initialized at all... This happens only if i is static.... thought this changed with C++11.

Who cares what b.i and d.i are? They are private and in your example inaccessible anyways. If you ignore that than b.i and d.i are both 0. Thats the default initialisation for build-in types when no user defined constructor is available...as in your example. Furthermore class B has no virtual destructor -> You don't inherit from it. It is irrelevant whether B and D are in different compile units or not.

"a constructor for a class is auto generated by the compiler when needed"

What constructor? I know four.

It really is unbelievable how many wannabes bad-mouth C++ here and at the same time show that they don't have the slightest idea what they are talking about. 'Disable RAII' suuuure... I compile my programs always with the -no-crash option so my programs never crash... Never heard of it? Not surprising... it is in pre-standard C++21 and only supported in GCC 7.2 ;-)

Another one ranting about something he understands nothing about. Not only that, but he comes with unbelievable 'facts' to back his story. So, all classes are QObjects? Making copy constructors for them? If what you said is true and you had the slightest amount of knowledge about what you write, you certainly would not have ranted about not performed shallow copies. Shallow copies... deep copies... irrelevant. Even beginners of Qt learn very fast that QObjects are non-copyable by design. Both copy and assignment constructors are disabled in QObjects. Under those circumstances:

As expected, he also stores instances in containers - which means every now and then the program would give incorrect results with seemingly no predictable occurrences. It doesn't crash, mind, just gives incorrect answers.

Ridiculous to assume that the program only now an then give incorrect results. Since QObjects cannot be copied into a container by value, it can never give correct results.

So I can only give the advice: Don't listen to the parent. He is a liar and has no idea what he is talking about. The usual C++ hater. Probably it's just sour grapes on his part.

If she does not get the desired job... whose fault will it be? Probably not $DIETY's and in her eyes most likely not her own. Fortunately people like her have always someone to blame... Nasty, nasty "brogrammers".

i really watched the video

And I thank you for this. I really expected this from the first glance on the article's title and waited for a summary like yours to confirm my suspicion. So no need to waste my time :-)

such as lack of equal opportunity,

Yes, lack of equal opportunity could be a problem. But boys do quite well is this field despite constant discrimination.

teaching girls programming in a segregated environment

Suuure.... and not teaching in a segregated environment = wahhhhh.... our precious snowflakes are disadvantaged by boys.

Troll the heck out of them (the "back at ya" option)

My choice on /. ;-)

Hey, atm it is even 'insightful'. Enjoy it as long it lasts... The SJW scum is slow lately, but they surely will come.

http://en.wikipedia.org/wiki/T...

Feminists spread hatred against men. I spread hatred against women. So what?

Feminazis and their lapdogs. To which group do you belong?

This one looks good:
http://slashdot.org/comments.p...

since programmers are about as easy to get pointed in the same direction as cats.

Idiotic statement. Programmers are easily pointed in the same directions as anyone else: With money. You want to point people, who work for free in an open source project, in the same direction? Yep, a bit more difficult. As it is for any other voluntary working group.