On the layout of C + + non-polymorphic single inheritance data

Recently, looking at the "Deep Exploration of C + + object Model", I intend to summarize the data layout in C + +, this article briefly first discuss the situation of non-polymorphic (non-polymorphic) Single inheritance:

In general, when we talk about inheritance and polymorphism in C + +, it goes into its object-oriented context by default. Encapsulation is the basis, and public inheritance is the means, and then the elasticity of runtime polymorphism (Run-time polymorphism) is supported by the phrase " base class pointers or references that can transparently point to any derived class object " to support the object-oriented architecture of C + +. The goal is nothing more than simplifying the use logic of the user (the user here refers to the class), i.e. normalization . Normalization is to use simple, unified external interface to obtain a variety of internal execution logic, and in the exposed unified interface behind the fact that there is a wide range of intrinsic execution logic, processing these is the task of the producers of the class, they are transparent to the user, there is no need to pay attention to.

In fact, this point in real life also has a lot of living examples can be analogous: Plug and socket, regardless of which manufacturer of sockets and plugs, no matter how complex the circuit behind, for the user, want to connect, just need to plug into the jack into the hole so simple. What is normalization, which is normalization.

There is a common connotation behind the terms of normalization, elasticity and polymorphism, simplifying the use of logic . There are also remote control, regardless of the air-conditioning remote control, refrigerator remote control or TV remote control, to the user, simply click the corresponding function of the button can be used. Think about it if it is not so big trouble, I every home to buy a new electrical appliances are trained for a period of time to use that no trouble to die. Because the underlying logic behind these is encapsulated, only simple, unified interfaces are exposed to the user, which greatly reduces the threshold for user use.

The benefit of object-oriented is nothing more than this: users can get different intrinsic logic by using simple, unified interfaces . Of course, there is no free lunch, any thing to get its benefits at the same time must pay the corresponding price, both in the real world and the Code of the world, so the tradeoff is always the theme. Object-oriented is also the same, to obtain the elasticity of object-oriented, it is necessary to pay the cost of time and space, this will be discussed later.

Exaggerated so much, let's get back to the point, first look at an example:

1 classconcrete1{2 Private:3     intvalue;4     CharC1;5 };6 7 classConcrete2: Publicconcrete1{8 Private:9     CharC2;Ten }; One  A classConcrete3: Publicconcrete2{ - Private: -     CharC3; the }; -  - intMain () { -  + Concrete1 Con1; - Concrete2 Con2; + Concrete3 Con3; A  atcout<<sizeof(Con1) <<Endl; -cout<<sizeof(Con2) <<Endl; -cout<<sizeof(Con3) <<Endl; -  - GetChar (); -     return 0; in}

Above we defined three classes, these three classes are single-inheritance relationships, but not polymorphism, because there is no use of virtual (virtual) mechanism, here just to illustrate the problem, of course, there is no such trivial class. OK, what is the above output? In my 32-bit machine, the result of using the visual Studio 2010 compiler output is as follows:

In general, the result 1 should be well understood, because the Concrete1 object contains 4bytes int plus 1Bytes char is 5bytes, but in order to improve bus transport efficiency, the CPU will secretly adjust the data size to a number of integer multiples, on 32-bit machines, Alignment is 4bytes, then 8bytes is now 5bytes aligned, where 3bytes is the result of the CPU's own padding, in order for the object to conform to the machine's word-length boundary.

But even so, according to common sense, the size of the Concrete2 object should not be 4+1+1+ filled 2 bytes=8bytes and Concrete3 object size should not be 4+1+1+1 fill 1 bytes=8bytes it? As we can see, this is not the case because C + + guarantees that the base class sub-object that appears in the derived class object has its full intact nature.

Well now understand, in the Concrete2 object, the Concrete1 sub-object is left intact, that is, 8 bytes, although 3 bytes is completely wasted, then the size of the Concrete2 object should be 8+1+3 (filled) = 12bytes, accord with the experimental result; Similarly, the size of the Concrete3 object should be 12+1+3 (filled) =16bytes, which is consistent with the experimental results.

See here people will certainly confuse C + + This is not a waste of space, Concrete3 object size can be abruptly than expected one times!

C + + Of course there is his reason, let us think about it, if not to do so, what will happen? If you do not preserve the integrity of the base class sub-object in the derived class object, the layout of the objects in memory for the above three classes should look like this:

So when we execute *P2=*P1 (where p1,p2 are pointers of type Concrete1, but P1 point to Concrete1 type objects, P2 to Concrete2 type objects), A copy of the Concrete1 child object will break the C2 member of Concrete2, and this bug will be difficult to find.

The above is the data layout in the case of non-polymorphic (non-polymorphic) Single inheritance.

On the layout of C + + non-polymorphic single inheritance data