Fan FENG: Also on the meaning of Bjarne stroustrup's "Object-based", B4 master

This articleArticleAfter I read the original article, I think it is a misunderstanding. When I watch it, there is something in it, but it is of little value and cannot be taken seriously! The key to understanding this article is to confirm the content contained in "determining the Compilation Time:

In this article, "determining the Compilation Time" includes determining the object creation logic. According to the context understanding of Bjarne stroustrup, this does not include determining the object creation logic.
 
If anyone who has read this article has caused misunderstanding, I would like to make a sincere apology here and ensure that this is the only article I am so cautious about; in the future, I would rather not write it Than mislead me. As a new author of a blog Park, this has given me a very important lesson and I would like to learn from it later. for the meaning of the original master text, please refer to my second article of the day:

Rebound and Addendum: on the meaning of Bjarne stroustrup's "Object-based"

The other explanation in the above article is that there will not be too much deviation between understanding and the master's original intention. The part involved in this article can be skipped. Read and discuss other parts with confidence.

The following is the original part of the article.

In the C ++ programming language 3rd (Bjarne stroustrup, 1997:
Page 1:
Objects of some user-defined types contain type information.
Such objects can be used conveniently and safely in contexts in which their type cannot be deter-mined at compile time. programs using objects of such types are often called object based.

Some user-defined type objects contain the type information (Cause).
These objects can be conveniently and securely applied to the context, and their types cannot be determined during compilation (Consequence).ProgramThe use of these types of objects is often called object-based.

To be honest, the translation is poor, because the master's English is really not so deep. However, many people are absolutely wrong in translation and understanding, including deerchao's mistake of compile time as run time and translation of determined into resolution; it also includes Xu shaoxia's understanding of this passage. The premise of this passage should first be clarified: C ++ is a static object-oriented language, so there is basically no question about the type of runtime decisions. NaturallyThe contradiction points to: the object type is fixed before compilation, or determined at compilation.. Deerchao does not have to give up this sentence as the basis of his argument because the original post of deerchao is basically centered on this sentence, natural ammunition is sufficient.

The following describes in detail.

Object O;
If (Case ){
O = New Book ();
}
If (Case B ){
O = new dog ();

}
O. tostring ();

In the above process, the actual type of the object referred to by variable O is determined during compilation. The actual type of this object is book in case a, and dog in another case.

Book B;
If (Case ){
B = new textbook ();
}
If (Case B ){
B = new graphbook ();
}
B. Open ();
B. dosomething ();
The above process is the same.

The type of B is limited to the base class Book (when the book is defined), but the actual type of the object it refers to is textbook or graphbook, although there are some changes in this process, these changes are determined at the time of compilation (just to decide-compared to dynamic languages or some later practices, it is determined that the compilation result contains the logic or information for creating the referenced object of different actual types. At the same time, because B is declared as book, assuming B is public, then what is the actual type of the object referred to by B is also limited to the Child class of book. If another new module (such as another DLL) contains a process related to creating the module, call B and assign a value to B. This process is implemented in the new module.CompilingIs determined, andConfirmObjectIn the processActual type.

Obviously, the practice of book B makes the actual type of the object referred to by B not fixed during compilation (but according to the ability of the static language itself, it cannot be fixed in other compilation processes ),The compilation result is used to determine what is in this case and what is in that case. This is called determining the Compilation Time.However, if textbook B Assumes that textbook is the last class on the inheritance chainThe actual type cannot be changed because it is declared as dead. That is to say, it does not have the ability to push back to any compilation process to determine the type. This is called that it cannot be determined at the Compilation Time.One of the methods we often use to embrace changes is to put the actual type of the object referred to by B in other separately compiled modules, let other compilation results determine the actual type of the program object we are writing.

So where does this misunderstanding come from? The key lies in the popularity of the following practices:

Module 1:
Book B = bookfactory. instance. Create (parameters determined by the end user );
B. Open ();
B. dosomthing ();

Public class bookfatory {
Public static bookfatory instance {
Return (bookfactory) according to the Instance obtained by the configuration file. // Note: It is determined not during compilation, but during runtime. It will be explained later!
}

Public abstract book create (string PARAM );
}

Module 2:
public special bookfactory: bookfactory {
Public override book create (string PARAM) {
switch (PARAM) {
case "parameter a":
return New Textbook ();
case "parameter B":
return New graphbook ();
default:
return New defaultbook ();
}< BR >}

In Module 2, the types of returned objects are determined at the Compilation Time. however, for Module 1, there is a conflict with what I call (the exact type of bookfactory is determined), which is why many people understand it as a reason for changing the type at runtime. this misunderstanding only occurs because activitor is obfuscated. createinstance (type. for static object-oriented languages such as C ++ and C #, it does not have the ability to change types at runtime. it lacks other capabilities, so we need activitor and reflection to help us. however, when the master discusses this issue, there is no additional non-verbal ability.

In our discussion, we also need to eliminate interference from other factors.Code:
First:
Textbook B;
If (Case ){
B = new textbook ();
B. Open ();
}
B. dosomething ();
If (Case B ){
B = new graphbook (); // No
}

Second:
Textbook B = bookfactory. instance. Create (user input parameter); // No

Why not? Because the object definition type contains too many type information! This is the essential meaning that cannot be determined at the time of Compilation: the master said that the object of the User-Defined type (referred to by B Here) contains the usage of the type information (Textbook B, relative to (book B) in some cases, the object referred to by B is that textbook is determined by graphbook at the Compilation Time of the process (not as many people imagine) the former is called "Object-based ".

Deerchao's intention to grasp the master is correct. The problem is that he gave up the master easily due to the original translation error. however, I found that, based on the misunderstanding of the first article, the discussion is not conducive to the development of deerchao. I would like to clarify the following points for the purposes of stirring up the wind and stirring up the rain:

1. The static language cannot be "confirmed during runtime", but can"Determined during compilation"(It is textbook/graphbook/textbook or graphbook, which varies according to the information obtained during compilation). This is relative to the user statement" include type information "(a special book ), therefore, the actual type cannot be postponed until "confirmed at compilation" because it is already inIt is fixed before compilation..
2. what is the root cause of deerchao's misunderstanding (obfuscation of compile time and Run Time): introducing features not included in the static object-oriented language itself, this is also one of the ways in which many frameworks provide tools to expand static language capabilities.
3. For the usage of textbook B rather than book B, the master did say "they are often called object-based", but please note that there is a "often" here ".

Next, let's talk about Xu shaoxia's remarks:

"For example
Javascript is not object-oriented
Although the variables in it are actually typed at runtime, they cannot know what type it is during non-runtime.
Similarly, many scripting languages use this.
Therefore, because the language supports the use of objects, but there are such defects, these scripting languages are called object-based languages"

This is purely a misunderstanding. the static object-oriented language is equivalent to the original object-oriented language. in fact, similar to the Javascript scripting language, it has been widely recognized at home and abroad. we still deny the features and even the essence of these language's object-oriented features from the perspective of non-static object-oriented languages, so we can say that the knowledge is somewhat outdated. on the contrary, it is now more discussed that the static object-oriented language misinterprets the object-oriented language and, due to its own limitations, brings us the trouble of developing software. moving closer to the advantages of dynamic languages is also the reason why activitor, reflection, and even emit are popular. but it cannot be said that it is neither static nor object-oriented, which is inconsistent with the original object-oriented concept 20 years ago.

At the same time, because these languages can determine their types at runtime, not to mention their more advantages, only corresponds to "the Compilation Time determines its type (or its range and the Creation logic of this object)", according to the concept of Bjarne stroustrup, it is also impossible to say that they are based on objects ....

What I should not say is, the feeling of my colleagues in the blog garden over the past few days. To tell the truth, what should I say, just like what I said, it looks like "Trainer ".., I think this kind of feeling is not consistent with my cognition of "teacher. when you are a teacher, you should be responsible for others (such as me). You are responsible for understanding the knowledge of many people. If you are not familiar with it, you cannot take it for granted .... if there is a misunderstanding, I apologize here first.

Finally, b4: Bjarne stroustrup's language expression ability, over.