Why does the ISO C ++ standard prohibit member initialization?

Question

Why can't I do this?

class A { public: int x = 10; ... }; 

and should i do this?

 class A { public: int x; A(){ x = 10; ... } ... }; 

Is it because C ++ is trying to be more secure in type than languages ​​like C? Are there other reasons?

Answer 1

This has nothing to do with type safety, both examples are safe.

When creating a language, you need to determine what is allowed and what is not. Since writing a blacklist will be an endless experience, the language is usually written in white list style, adding more and more things.

However, things cannot be allowed without a clear weighting of the consequences. Whenever you want to allow something new, you need to check:

• ease of implementation
• interaction with other existing functions and known probable extensions

In addition, this also means that for those who want to use the language, you can learn more.

What you ask for here, however, is relatively easy. It can be thought of as an instance of a class, for default arguments. This was adopted in C ++ 11 because it was the easiest way to ensure that the default values ​​are consistent when writing multiple constructors.

Personally, when using C ++ 11, I recommend initializing all built-in types this way (only to 0 ), just as I recommend initializing them when declaring local variables: this way you cannot forget to initialize them in one of the constructors.

Answer 2

A warning. Following:

C ++ classes were based on C-structures with a number of additional functions. Members of C structures cannot have initializers (because this would require code to be executed every time an object of type structure was created, which was considered too complicated for early C compilers).

Early C ++ (originally called "C with classes") added constructors, a mechanism that required code to be executed every time an object of a certain type was created. Because the constructor can do everything the element initializer could do, member initializers were probably considered unnecessary.

But as you mean in your question, it would be convenient to have member initializers, even if this is not strictly necessary. And the new ISO C ++ 2011 standard added this feature to the language, so it seems that the ISO C ++ committee agreed that this is a good idea. This function increases the complexity of the language (for example, there must be new rules that determine the order in which initializers and constructors are executed, and code that depends on this order will be potentially confusing). The committee decided that convenience was worth the extra complexity. (I think I agree.)

(Bjarne Stroustrup, the inventor of C ++, has a book entitled "Design and Evolution of C ++ " that discusses his earlier ones. I have not tested it yet to see if he mentions this particular problem.)

Summary: element initializers are convenient but not needed, and it just took a while to decide to add them as a language function.

Answer 3

AFAIK, the sheer simplicity of the language.

There is some value in the fact that the language is compact. Without resolving your first example, the language does not pose serious restrictions, right? As a result, you have a thinner book, a simpler compiler. These benefits are controversial. Please do not consider them correct. I personally see the value in compactness. C's exceptional success can be partly explained by its simplicity and compactness.

With the introduction of C ++ 11, the situation is moving in a direction in which less and less people will know the language significantly deep . This WILL has negative consequences. I do not claim to be only negative though.