> Primarily, there are two kinds of initialization of concern: default-initialization and value-initialization. The rules given in the standard look roughly like this:
> * For any type T, T t; performs default-initialization on t as follows: ...
As GP mentions, the article's descriptions of default and value initialization are both incorrect for classes that do not have default constructors, as that code will simply not compile.
But... all of the classes in the article -do- have default constructors. And all of the examples in the article do compile. So I'm confused at what point you guys are making.
- If T is a class type and there is a default constructor, run it.
- If T is an array type, default-initialize each element.
- Otherwise, do nothing.
That decision tree should read: "If T is a class type: it will invoke the default constructor. It is a compile-time error to write this if T does not have a default constructor." Not "if there is a default constructor, run it; otherwise, fall back to doing nothing."
The "do nothing" applies to scalar types such as ints, and indirectly to scalar member variables that aren't explicitly initialized one way or another. Not to classes that have deleted the default constructor.
Yes, this. It appears these commenters are claiming that the author said something they did not say. Rather, there is a corner case that the author has not spoken about in this article.
... Which is not surprising, given that we're talking about a language with a spec that dwarfs most works of human literature for sheer mass.
> Primarily, there are two kinds of initialization of concern: default-initialization and value-initialization. The rules given in the standard look roughly like this:
> * For any type T, T t; performs default-initialization on t as follows: ...
As GP mentions, the article's descriptions of default and value initialization are both incorrect for classes that do not have default constructors, as that code will simply not compile.