Deep Exploration C + + object Model (i) _ About objects

Original Blog Address: HTTP://WWW.ROADING.ORG//DEVELOP/CPP/C objects. html

Learn C + + should have read a lot about C and C + + saliva paste, as well as on a variety of comparisons C and C + + efficiency of the post, the most influential I am afraid to be a Linus of C + + shelling-"poor programmer's garbage language." But in any case, I am liking such a kind of rubbish, I certainly to Linus full of respect, but this does not prevent me to Kou the rubbish and admires to it.

There is no need to be too concerned about the words of the Giants standing on the hill, and everyone has a different path to pursue the truth. Instead of listening to Linus's hiss, follow Lippman to explore the "inner world" of the C + + object model. If you want to appraise things, you have to understand them first. Only by understanding can there be responsible voice.

--just a few hundred words to remember.

additional cost of C + +

The biggest difference between C + + is no doubt that it is object-oriented. The struct of a class compared to C contains not only data but also operations on the data. At the language level, C + + brings a lot of new object-oriented features, classes, inheritance, polymorphism and so on. The new features make C + + more powerful, but at the same time accompany the extra cost of space layout and access time. As an efficient language, C + + for object-oriented implementation is not, in fact, these additional costs are mainly caused by virtual, including: virtual function mechanism, to support the "implementation phase binding." Virtual base class--Virtual basis class mechanism to implement the subobject of shared virtual base classes.

In addition, C + + does not have much reason to be slower than C.

three kinds of object models

The C + + class contains two data members: static data members and non-static data members, and includes member functions, static functions, and three member functions of virtual functions, which are represented in C + + objects. Here are three models that can be used to represent them-the simple object model, the table-driven object model, and the C + + object model. Maybe you're not interested in understanding there are several ways to implement the C + + object model, just to understand the C + + object model. However, the C + + object model is developed on the first two object models, and even the first two object models are directly used in local.

Assuming there is a point class, we will use three object models to represent it. The point class is as follows:

static int Pointcount ();

Virtual ostream& print (ostream &os) const;

float _x;

};

Simple Object Model

Simple Object Model: A C + + object stores all pointers to members, and the members themselves are not stored in the object. That is, whether a member or a member function, whether this is a normal member function or a virtual function, they are stored outside the object itself, while objects hold pointers to them.

The Simple object model is very simple for the compiler, but at the same time the cost is the efficiency of the space and the execution period. It is obvious that for each member there is an extra space for a pointer size and an indirect layer is added to each member's operation. C + + therefore does not use such an object model, but is used in C + + "pointer to the member" concept.

table-driven object model

The table-driven model is even better, it pulls all the members of the object out of the table, and the object itself stores pointers to the table. As you can see on the right, it pulls all the data members out of the form to build the data member table, extracts all the functions into a function member table, and the object itself keeps a pointer to the data member table.

Hou greatly believed that in the object and member function table should add a virtual arrow, he thought that this is the lippman of omission, should be in the object to hold a pointer to the function member table.

However, I am still here to keep a screenshot of the original book (not the translation), because in my humble opinion, not saving pointers to the table of member functions is not hindered. Because a member function like float point::x () is actually equivalent to a normal function of float x (point*) type, it is superfluous to save a pointer to a member function table.

Of course C + + also does not adopt this kind of object model, but C + + uses this model as a scheme to support virtual function.

C + + object model

All non-static data members are stored in the object itself. All static data members, member functions, both static and non-static, are placed outside the object. In addition, a virtual function table (virtual table) stores all pointers to virtual functions and appends a Type_info object of that class to the table header, holding a pointer to the virtual function table in the object. The following figure:

class and struct

According to Lippman, struct is just giving the C programmer who wants to learn C + + a little less torment. But unfortunately, when I began to learn C + +, this problem brought me more confusion. With my knowledge class and struct are limited to one default permission (the latter is public, the former private). Sometimes I even think that only a little deformity, they should not be so similar, I even think that struct should not be expanded, just to save it in C the original intention is good. 1

an interesting C technique (but not used in C + +)

Placing an array of one element at the end of struct in C enables each struct object to have a mutable array. Look at the code:

struct Mumble {

* Stuff * *

Char pc[1];

};

Grab a string from file or Standardinput

Allocate memory both for struct &string

struct mumble *pmumb1 = (struct mumble*)

malloc (sizeof (struct mumble) +strlen (string) +1);

strcpy (&mumble.pc, String);

This is an interesting little trick, but don't use it in C + +. Because the memory layout of C + + is relatively complex. For example is inherited, has the virtual function ... The problem will inevitably occur.

Object-oriented model of model ADT model for three programming paradigms

The great benefit of simply using a model program is that if mixed with a variety of canonical programming can have unintended consequences, such as assigning objects of inherited classes to base class objects, and delusional polymorphism, this is an example of the serious consequences of a ADT model and mixed programming with object-oriented models.

The memory size of an object of a class includes: the size of all non-static data members. The memory size that is filled by the memory alignment. To support virtual there is an additional burden that is internally created.

The following classes:

Class Zooanimal {

Public

Zooanimal ();

Virtual ~zooanimal ();

virtual void rotate ();

Protected

int Loc;

String name;

};

The memory on a 32-bit computer is 16 bytes: int four bytes, String8 byte (an integer representing the length, a pointer to a string), and a pointer vptr to the virtual function table. For an inheriting class, the memory size of the base class plus the size of its own data member. The memory layout in Cfront is shown in the following illustration: