"Effective C + +" Note: III (reproduced)

Transferred from: http://www.cnblogs.com/destino74/p/3960802.html

　　

Terms 5:know What functions C + + silently writes and calls

　　

Understanding what functions C + + silently writes and calls

In C + +, writing an empty class, the compiler automatically declares a copy constructor, a copy assignment operator, and a destructor for it. If no constructors are declared, the compiler automatically declares a default constructor.

As follows:

Class empty{};

This is equivalent to

Class empty{
Public
Empty () {...}
Empty (const empty& RHS) {...}
~empty () {...}
empty& operator= (const empty& RHS) {...}
}

The first two things about constructors and copy constructors are already introduced.

Terms 6:explicitly Disallow the use of compiler-generated functions you does not want

If you do not want to use a function generated automatically by the compiler, you should explicitly deny

In some cases, if you do not want a function within the object to be called, you can declare these functions as private hidden, which is the Java in the implementation of the Factory mode to prohibit the new object of the trick.

In fact, this is not insurance, these functions can still be called in the member function or friend function, of course, you can explicitly prohibit the invocation of these functions.

The solution mentioned in the book is to declare only that it is undefined. This is my usual mistake, declaring that the function does not define the body of the function, and at compile time gives an "unresolved external symbol" error.

With this, we can achieve the purpose of shielding automatically generated functions.

Another way is to implement a class like the Uncopyable interface, declare a function that needs to be hidden as a private function, and then privately inherit the Uncopyable class in the derived class.

Declaring a member function private and not implemented prevents the compilation of automatically supplied functions. Using base classes like Uncopyalbe can also achieve the same purpose.

Terms 7:declare destructors virtual in polymorphic base classes

Declaring a virtual destructor for a polymorphic base class

Why would you declare a virtual destructor (virtual destructor) for a polymorphic base class? The reason is that when a base class pointer to a derived class is destroyed, the destructor of the base class is called, and the destructor of the derived class is not executed, the member variables of the derived class object are likely not destroyed, providing a hotbed for resource leaks and baffling bugs, and correspondingly increasing the time you spend on debugging.

Therefore, in all classes that contain virtual functions (virtual functions), the virtual destructor should be declared, which makes it behave differently in different derived classes so that the resources in the derived class can be disposed of correctly when destroyed.

It is worth mentioning that when a class does not contain virtual functions, this often means that the class is not designed to be inherited, it should not declare a virtual destructor, because this is never declared.

It is mentioned in the book that you should not inherit any class without the virtual destructor (such as all STL containers), in the learning of STL access to data, learned that the practice of inheriting STL will cause all kinds of bad consequences, so when you use the combination instead of inheritance, have not encountered the book mentioned in the And the large number of web-based inheritance of STL problems.

A base class with polymorphic properties should declare a virtual destructor. Any class with the virtual function should have a virtual destructor.

If a class does not want to be inherited as a base class or is not designed to be polymorphic, the virtual destructor should not be declared. (STL container derived classes should not be designed)

"Effective C + +" Note: III (reproduced)