5.4 The efficiency of objects (object efficiency) in the following efficiency test, the cost of object construction and copying is based on the Point3D class declaration, from simple form to complex form, including plain Ol ' data, abstract data type (A DT), single inheritance, multiple inheritance, virtual inheritance, the following function is the test lead:
Point3D lots_of_copies (Point3D A, Point3D b) { Point3D PC = A; PC = b; 1 b = A; 2 return PC;}
It has four memberwise initialization operations, contains two parameters, a return value, and a local object PC, which also has two memberwise copy operations, respectively 1 and 2 pc and B.main () functions such as the following:
Main () { Point3D PA (1.725, 0.875, 0.478); Point3D PB (0.315, 0.317, 0.838); Point3D PC; for (int iters = 0; iters < 10000000; iters++) PC = Lots_of_copies (PA, PB); return 0;}
In the first two programs, the data type is a struct and a class with public data;
struct Point3D {float x, y, z;};
Class Point3D {public:float x, y, z;};
The initialization of PA and PB is done through the explicit initialization list:
Point3D PA = {1.725, 0.875, 0.478};
Point3D PB = {0.315, 0.317, 0.838};
these two operations exhibit bitwise copy semantics, so it should be possible to expect their operation to be as efficient as possible.
"Memberwise" initialization operation and copy operation (initialization and copy): Public Data members and bitwise copy semantics.
the efficiency of CC is better because of the six additional assembly language instructions produced in the NCC cycle. This additional burden does not reflect the fact that the "intermediate C output" of the two compilers is roughly equal, regardless of the specific C + + semantics.
5.5 Deconstruction Semantics (semantics of destruction)
Assuming class does not define destructor, then there is only member object in class(or class's own base class)
If you have destructor, the compiler will make one of its own. Otherwise, destructor will be considered not necessary and will not need to be synthesized.(no need to be called, of course). For example, point, by default, is not synthesized by the compiler a destructor--although it has a virtual function:
Class Point {public: Point (float x = 0.0, float y = 0.0); Point (const Point &); Virtual float Z ();p rivate: float _x, _y;};
Similarly, suppose you combine two point objects into a line class:
Class Line {public: line (const point &, const point &); Virtual Draw ();p rotected: Point _begin, _end;};
Line also does not have a synthesized destructor, because point does not have destructor.
When a Point3D is derived from point (that is, a virtual derivation association), it is assumed that a destructor is not declared and the compiler does not need to synthesize a destructor.
Regardless of point or Point3D, all
There is no need for destructor to provide them with a destructor instead of efficiency. The idea of a "symmetric strategy" should be rejected: "A constructor has been defined, so it feels obliged to provide a destructor". In fact, we should "need" rather than "feel" to provide destructor, not to be unsure whether a destructor is needed, and then provide it.
To determine if class needs a program-level destructor (or constructor), consider aWhere does the life of class object End (Start)?
What operational talent is required to ensure the integrity of the object?
This is a more important thing to know when knocking the code. This is the key to when constructor and destructor are working. For example, known:
{Point pt; Point *p = new Point3D; Foo (&PT, p); Delete p;}
You can see that PT and P must be initialized to some coordinate values before they are the parameters of the Foo () function. A constructor is required, otherwise the user must clearly provide the coordinate value.
In general , class users are not able to test a local variable or a heap variable to see if they are initialized . It's wrong to think of constructor as an extra burden on the program.,
because their work has its necessity. Without them, the use of abstraction would have the wrong inclination..
What happens when you delete p clearly? Do you have to deal with it in whatever program?
do you need to do this before delete :
P->x (0);p->y (0);
No
of course not. There is no reason why it is necessary to clean up the contents of an object before you delete it. No need to return whatever resources.Before the end of PT and P's life, no matter what "class user plane" program operation is absolutely necessary, therefore, it does not necessarily need a destructor.
However, considering the vertex class, it maintains a linked list of adjacent "vertices", and when the life of a vertex ends, moves back and forth on the linked list to complete the delete operation. Assuming this is what the program apes need, that's vertex destructor's work.
When deriving vertex3d from Point3D and vertex, assuming that a explicit vertex3d destructor is not supplied, you still want vertex destructor to be called to end a vertex3d Object. Therefore, the compiler must synthesize a vertex3d destructor, whose only task is to call Vertex destructor. Assuming a vertex3d destructor is provided, the compiler expands it to call vertex destructor. A destructor extended way defined by the program ape resembles constructors extended way, but in order opposite:
1. Assuming that the object has a vptr in it, first reset (reset) related virtual table.
The 2.destructor function itself is now running, meaning that vptr will be reset before the code of the program ape is run.
3. Assuming that class has member class objects and that the latter has destructors, they are called in the reverse order of the declaration order.
4. Assuming that there is no direct (previous layer) Nonvirtual base classes has destructor, they are called in reverse order of their declaration order.
5. Assuming that the virtual base classes has destructor, and that the class currently discussed is the end of the class (most-derived), then they will be called in the reverse order of their original construction order ..
(this order seems to be problematic and should be 2,3,1,4,5.1 of them after 2,3)
Just like constructor,
one of the best strategies for destructor now is to maintain two copies of destructor entities.:
1. A complete object entity, always set the vptr, and call virtual base class destructors.
2. A base class Subobject entity: Unless a virtual function is called in the destructor function, it will never call the virtual base class destructors and set the vptr.
One
the life of object ends when its destructor starts to run,
because each base class destructor is called in turn, the derived class actually becomes a complete object.Like abefore the Pvertex object returns its memory space, it becomes a Vertex3d object, a vertex object, a Point3D object, and finally a point objectWhen calling member functions in destructor, the object's metamorphosis will be due to another set of vptr (in each destructor, before the code provided by the program Ape) affected. The real language of implementing destructor in the program is detailed in the 6th chapter.
C + + object model--deconstruction Semantics (fifth chapter)
