I thought the new one was FF3+N.
I thought the new one was FF3+N.
but neither mythbusters nor breaking bad is going to tell us (probably some mix of acids, paying attention to the molar concentrations)
But I do:
Coming from Disney I really was surprised that it wasn't Ant Woman. And not black. And not lesbian.
Meeting once a month. It is free. Roughly 10-20 members. I learned plenty there. It is very interesting since the members come from all kinds of backgrounds. The techniques an methods of C++ developers vary tremendously. What has this to do with this article? Simple, in all my years in this group I did not see a single parasite there.
You should read this:
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.
Adding manpower to a late software project makes it later. -- F. Brooks, "The Mythical Man-Month"