Why i can't do that
class A {
public:
int x = 10;
...
};
and I have to do that ?
class A {
public:
int x;
A(){
x = 10;
...
}
...
};
It's because C++ is trying to be more type safe than languages like C ? There are other reasons ?
This has nothing to do with type safety, both examples are as safe.
When creating a language you need to define what is allowed and what is not. Since writing a blacklist would be a never-ending experience, a language is usually written in a white-list fashion, adding more and more possible things.
However, one should not allow things without clearly weighing the consequences. Whenever you want to allow something new, you need to check:
- the ease of implementation
- the interaction with other existing features and known probable extensions
Furthermore, it also means that there is more to learn for those wishing to use the language.
What you are asking for here is, however, relatively easy. It can be seen as the counterpart, for classes, to functions default arguments. This has been adopted in C++11 because it was the simplest way to guarantee a coherence of the default values when writing multiple constructors.
Personally, when using C++11, I recommend initializing all built-in types this way (if only to 0), much like I recommend initializing them when declaring local variables: this way you cannot forget to initialize them in one of the constructors.
Warning: Speculation follows.
C++ classes were based on C structs, with a number of added features. Members of C structures can't have initializers (because it would require code to be executed every time an object of the structure type is created, something that was considered too complex for early C compilers).
Early C++ (originally called "C with Classes") added constructors, a mechanism that does require code to be executed every time an object of a given type is created. Since a constructor can do everything that a member initializer could do, member initializers were probably seen as unnecessary.
But as you imply in your question, it would be convenient to have member initializers, even if it isn't strictly necessary. And the new 2011 ISO C++ standard has added that feature to the language, so apparently the ISO C++ committee agreed that they're a good idea. This feature increases the complexity of the language (for example, there have to be new rules governing the order in which initializers and constructors are executed, and code that depends on that order will be potentially confusing). The committee decided that the convenience was worth the added complexity. (I think I agree.)
(Bjarne Stroustrup, the inventor of the C++ language, has a book, "The Design and Evolution of C++", that discusses his early design decisions. I haven't (yet) checked it to see whether he mentions this particular issue.)
Summary: Member initializers are convenient but not necessary, and it simply took a while to decide to add them as a language feature.
AFAIK, pure simplicity of the language.
There is certain value in having the language compact. Disallowing your first example, the language is not posing any serious limitations, right? As a result you have thinner book, simpler compiler. These advantages are debatable. Please, do not consider them as something appriory correct. I personally see value in compactness. Exceptional success of C can be partly attributed to its simplicity and compactness.
With introduction of C++11 the situation is moving in the direction that less and less people will know the language significantly deep. This WILL have negative consequences. I am not stating that only negative though.
来源：https://stackoverflow.com/questions/12757501/why-the-iso-c-standard-forbids-the-initialization-for-members