C + + object model--construction, deconstruction, copy Semantics (fifth chapter)

5th Chapter Construction, Deconstruction, copy semantics (semantics of construction, destruction, and copy)Consider the following abstract base class declaration:

Class Abstract_base {public:virtual ~abstract_base () = 0;virtual void Interface () const = 0;virtual const char * mumble () const {return _mumble;} Protected:char *_mumble;};

What's the problem?Although this class is designed as an abstract base class (which has pure virtual function, which makes it impossible for abstract_base to have entities), but it still needs a definite constructor to initialize its data member _mumble. Without this initialization, the local object _mumble of its derived class will not be able to determine the initial valueFor example:

Class Concrete_derived:public Abstract_base {public:concrete_derived ();}; void Foo () {//abstract_base::_mumble not initialized concrete_derived trouble;}

It may be that Abstract_base's designers try to give each derived class the initial value of _mumble. However, if so, the only requirement for derived class is that abstract_base must provide a Protected constructor:

Abstract_base::abstract_base (char *mumble_val = 0): _mumble (mumble_value) {}

Generally speaking the data member of class should be initialized, and the initial value is specified only in constructor or in other member functions of class, and any other operation will break the encapsulation nature, making the class maintenance and modification more difficult.
It is also possible that the designer's mistake is not to provide a explicit constructor, but instead to declare the data member in the abstract base class. This is a rather powerful argument ( Separating interface from implementation), but it's not all right in the world because extracting "shared data" into base class is a legitimate design.

Existence of pure virtual functions (presence of pure Vsan) C + + can define and invoke (Invoke) a pure virtual function; However, it can only be called statically (invoke statically) and cannot be called through a virtual mechanism. For example, you can legally write down this code:

OK: Defines pure virtual function, but can only be statically called (invoked statically) inline void Abstract_base::interface () const {function//... }inline void Concrete_derived::interface () const {//OK: Static call (static invocation) Abstract_base::interface (); function// ...}

To do so, it is up to the Class designer to decide. the only exception is the pure virtual Destructor:class designer must define it .. Why? Because each derived class destructor is expanded by the compiler to invoke its "every virtual base class" and the "previous base class" destructor in a static call. The lack of any definition of a base class desstructors will cause the link to fail.
Shouldn't the call to a pure virtual destructor be suppressed when the compiler expands derived class destructor? Not!class the designer may have really defined a pure virtual destructor (as defined in the previous example, Abstract_base::interface (). This design is based on the premise that the C + + language is a guarantee: every class object in the inheritance system destructor is called. So the compiler is not able to suppress this call operation.
A better alternative is to not declare virtual destructor as pure.

Existence of the virtual specification (presence of a virtual specification)If you decide it would be a bad choice to design abstract_base::mumble () as a virtual function, because its function definition content is not related to the type, so it is rarely rewritten by the successor derived class In addition, because its non-virtual function entity is an inline function, if it is often called, the burden of efficiency is not low.
However, can the compiler not pass the analysis, knowing that the function has only one entity in the class hierarchy? If so, is it not possible to convert the invocation operation into a static call operation (static invocation) to allow the call operation's inline Expansion? What if the class hierarchy is added to the new class and the new entity with this function? Yes, the new class will break the optimization. The function must now be recompiled (or produce a second--that is, polymorphic--entities, The compiler will analyze which entity is to be called through the process. However, functions can exist in binary form with a library.
In general, it is not a good idea to declare all the member functions as virtual function and then eliminate the unnecessary virtual invocation by compiler optimizations.

The existence of a const in a virtual specificationDeciding whether a virtual function requires a const is a trivial matter. But it's not easy to make a decision when it comes to an abstract base class. To do this thing, This means that the subclass entity may be used in an infinite number of times. Not declaring a function as const means that the function can obtain a const reference or const pointer.

Reconsider the Declaration of classAs the previous discussion shows, redefining Abstract_base is a more appropriate hypothesis:

Class Abstract_base {public:virtual ~abstract_base ();//is no longer purevirtual void interface () = 0;const char *mumble () const {R Eturn _mumble; }//is no longer virtualprotected:abstract_base (char *pc = 0);//Add a Constructorchar *_mumble with a unique parameter;};

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

C + + object model--construction, deconstruction, copy Semantics (fifth chapter)