C ++ object model-Data Member binding (Chapter 3), object model member

C ++ object model-Data Member binding (Chapter 3), object model member
3.1 The Binding of a Data Member considers The following code:

// A foo. h header file, containing extern float x somewhere; // programmer's Point3d. h file class Point3d {public: Point3d (float, float, float); // question: which one is the x that is returned and set? Float X () const {return x;} void X (float new_x) const {x = new_x;} private: float x, y, z ;};

Point3d: Which X does x () return? Is the x in the class or the x in the external (extern? The answer is internal, but not in the past.
In the earliest C ++ compiler, If you perform the reference operation on X in the two function instances of Point3d: x (), this operation will point to global x object. such binding results are almost universal, and therefore the two Defensive Programming styles of early C ++ are exported:
1. Place all data members at the beginning of the class declaration to ensure correct binding:

Class Pointed {// defensive programming style #1 // put all data members float x, y, z; public: float X () at the beginning of the class declaration () const {return x ;}//... etc ...};

2. Put all inline functions, regardless of the size, outside the class declaration:

Class Point3d {public: // defensive programming style #2 // move all inlines out of class Pointed (); float X () const; void X (float) const; //... etc ...}; inline float POint3d: X () const {return x ;}

These programming styles actually exist today. This old language rule is called "member rewriting rule" to the effect of being "an inline function entity. Before the entire class declaration is completely invisible, is not evaluated (evaluated ". C ++ Standard Uses "member scope resolution rules" to refine this "rewriting rule". The effect is that if an inline function is defined immediately after the class declaration, then it will evaluate the value (evaluated ). that is to say, if you write the following code:

Extern int x; class Point3d {public: // The analysis of the function itself will be delayed until the right parenthesis of the class declaration appears before float X () const {return x;} private: float x ;};

The Analysis of member functions itself will not begin until the entire class declaration appears. therefore, a data member binding operation in an inline member function will occur only after the entire class declaration is complete.

3.2 Data Member Layout:

class Point3d {public:    // ...private:    float x;    static List<Point3d *> *freeList;    float y;    static const int chunkSize = 250;    float z;};

Nonstatic data members are arranged in the same order as declared in class object. static data members such as freeList and chunkSize involved in the middle are not put into the object layout. in the preceding example, each Point3d object is composed of three float objects in the order of x, y, and z. static data members is stored in the data segment of the program and has nothing to do with some class objects..
C ++ Standard requires that, in the same access section (that is, private, public, protected, and so on, the arrangement of members only needs to meet the condition that "members that appear later have a higher address in class object. that is to say, each members is not necessarily arranged consecutively. What may be involved in the declared members? The alignment of members may need to fill in some bytes. this is true for C and C ++. It is true for the current implementation of the C ++ compiler.
The compiler may also synthesize some internally used data members to support the entire object model. vptr is like this, at present, all compilers insert it into every "object containing the virtual function class". Where will the vptr be placed? Traditionally, it is placed at the end of all clearly stated members, but now some compilers put vptr at the front end of a class object. C ++ Standard is laissez-faire to the layout, allowing the compiler to place the internally generated members freely anywhere, or even between those members declared by programmers.
C ++ Standard also allows the compiler to arrange data members in multiple access sections freely without having to care about the order they appear in the class declaration. That is to say, the following declaration:

class Point3d {public:    // ...private:    float x;    static List<Point3d *> *freeList;private:    float y;    static const int chunkSize = 250;private:    float z;};

The size and composition of the class object are the same as those previously declared, but the order of members is determined by the compiler.
At present, the compiler chain more than one access sections together to form a continuous block in the declared order. the number of Access sections does not cause extra burden. For example, 8 members are declared in a section, or 8 members are declared in 8 sections, and the object size is the same.
The following template function accepts two data members and then judges who first exists in the class object. if both members are the first ones declared in different access sections, this function can be used to determine which section appears first:

template <class class_type1, class class_type2, class class_type3>char * access_order(data_type1 class_type::*mem1, data_type2 class_type::*mem2) {    assert(mem1 != mem2);    return mem1 < mem2 ? "member 1 occurs first" : "member 2 occurs first";}

The preceding functions can be called as follows:

access_order(&Point3d::z, &Point3d::y);

Therefore, class_type is bound to Point3d, while data_type1 and data_type2 are bound to float.

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.