Valid C ++ notes: Clause 18-25 (Chapter 4 Design and Statement)

Clause 20: replace pass-by-reference-to-const with pass-by-value.

In general, pass-by-value requires the cost of calling the copy constructor and destructor. The same applies when return values are returned as values.

Passing parameters in the by reference method can also avoid slicing (Object cutting problem ). When a derived class object is passed to a base class parameter of the function type in the by value method, the base class constructor is called, and the derived object is cut into a base object.

Generally, it can be reasonably assumed that the only object that is not expensive is the built-in type and STL iterator and function object. Both are based on pointers. In other cases, replace pass-by-reference-to-const with pass-by-value. The former is usually relatively efficient and can avoid cutting problems.

 

Clause 21: when an object must be returned, do not think about returning its reference

For example, the operator * operator cannot return a reference. It should return an object returned with a value.

Never return pointer or reference pointing to a local stack object (they will point to or reference an object that has been destroyed ), or return reference pointing to a heap-allocated object (this object cannot be deleted ).

 

Clause 22: declare member variables as private

Encapsulation: If you access a member variable through a function, you can change the implementation of this member function in the future, and the class customers do not know that the internal implementation of the class has changed.

Public member variables mean that they are not encapsulated, but they can be said that they cannot be changed without being encapsulated. Some of them are widely used classes. The widely used classes are the most encapsulated because they benefit most from the "change using a better implementation version.

It is surprising that protected member variables are not more encapsulated than public. Encapsulation of member variables and "destroyed when the content of member variables changesCodeThe quantity is inversely proportional. The so-called change may be to remove it from claas. Removing public member variables can corrupt unpredictable customer code. Removing the protected member variable can destroy all the derived class Customer Code that uses it. The number is still unpredictable. Therefore, the protect member variables are as public and lack encapsulation.

Once you declare a member variable as public or protected and the customer starts to use it, it is difficult to change everything involved in which member variable. From the encapsulation perspective, there are actually only two types of access permissions: Private (providing encapsulation) and non-private (not providing encapsulation ).

Note: Remember to declare the member variables as private. This allows customers to access data in a consistent manner, access control can be divided in detail (read-only, write-only, read/write, non-accessible, etc.), and the promised constraints are guaranteed, it also provides class authors with full implementation method flexibility. In addition, protect is not more encapsulated than public.