Each item is very classic, all need to think about, I am here to abstract the main points, easy to recall in the future; I'm just making a fuss about the "porter".
Item 18 makes the interface easy to use correctly
1. Function interface, class interface, template interface ... Each interface is the means by which the customer (the caller) interacts with your code.
2. Another way to prevent possible customer (call) errors is to restrict what can be done in a type, and a common way to impose a restriction is to add a const.
3. One way to avoid customizations that are incompatible with built-in types is to provide an interface that behaves consistently. Few other properties make the interface easier to use correctly than "consistent", and few other properties exacerbate the deterioration of the interface than the "inconsistency".
4. shared_ptr makes the interface easy to use correctly, a simple way to eliminate some customer errors. But it's larger than a bare pointer, slower than a bare pointer, and uses auxiliary dynamic memory. In many applications, these additional runtime overhead is not significant, and the reduction in customer errors is visible to everyone. In addition shared_ptr will dynamically allocate memory for bookkeeping and deleter private (deleter-specific) data, when calling its deleter using a virtual function to invoke, in an application that it thinks is multithreaded, when the reference count is changed, Can cause thread synchronization overhead.
Subsections: Calls, interactions, reads, and writes between different function,class,template are interface operations.
Question: If you want to understand shared_ptr in depth, it will take a lot of time to skip over and see later.
Item 19 visual design for type design
1. Like language designers, in the language of the design of the class (type) to devote a lot of effort.
Section: Everything in this section is included in the other sections, and then come back to think about it and no longer copy it.
Item 20 Passes "constant reference" instead of pass value
1. A const reference, no constructors and destructors are called, because no new objects are constructed.
2. Passing parameters by means of reference can also avoid cutting off problems (slicing problem). When a derived class object is passed as a base class object (by way of a value), the copy constructor of the base class is called, and those special attributes that make the object behave like a derived class object are "cut off".
3. If you have an object of built-in type (for example, an int), passing it as a value is often more efficient than quoting. So, for built-in types, there's no reason to choose not to pass a value when you need to make a choice between passing a value and passing a reference to a const. The same advice applies to iterators (iterators) and Function objects (functions objects) in STL because, as a rule, they are designed for pass-through values. The implementation of iterators (iterators) and Function objects (functions objects) is responsible for ensuring that the copies are efficient and unaffected by the cut-off problem.
Question: Why are iterators (iterators) and Function objects (functions objects) in STL efficient when used for value delivery?
Item 21 do not attempt to return a reference when you must return an object.
1. A reference is simply a name, a name for the object that actually exists. Whenever you see a quoted declaration, you should immediately ask yourself what it is, because it must be another name for something.
2. Any function that returns a reference to a local variable is wrong. (a function that returns a pointer to a local variable is also true.) )
2. Returns a reference to the heap memory, the memory allocated through new is initialized by invoking an appropriate constructor, but now you have another question: Who is the right person to delete the object you made with new?
3. Returns a reference to local static, which immediately causes confusion in our thread safety (thread-safety).
Subsection: This section tells a lot of things, actually: never return a pointer or reference to a local stack object, never return a reference to an allocated heap object, never return a pointer or reference to a local static object.
Item 22, declaring a data member as private
1. The use of functions (relative to variables) allows you to control the accessibility of members more precisely.
2. Hiding data members behind functional interfaces (functions) can provide resiliency for various implementations. For example, it can be very simple to communicate with other objects when reading or writing, you can verify the invariant of the class and the pre-or post-conditions of the function, you can perform synchronization tasks in a multithreaded environment, and so on.
3. The point of encapsulation may be more important than it initially appears. If you hide your data members from your customers (that is, encapsulate them), you can ensure that class invariants are always maintained, because only member functions can affect them.
4. Suppose we have a public data member and then we eliminate it. How much code will be destroyed? All of the customer code that uses it is usually incredibly large in number. Thus the public data members are completely unpackaged. Suppose we have a protected data member, and then we eliminate it. How much code will be destroyed now? All of the derived classes that use it, typically the number of code is incredibly large. As a result, protected data members are not encapsulated like public data members, because in both cases, the number of corrupted customer code is incredibly large if the data member changes. From the encapsulation point of view, there is actually only two access levels: private (provided encapsulation) with all exceptions (no encapsulation provided).
Subsection: Private data can be freely changed by itself without affecting the client.
Item 23, replacing member functions with non-member non-friend functions
1. The Polygon object principle states that the data and functions that manipulate them should be bound together and that the recommended member function is a better choice. Unfortunately, this proposal is not correct. It arises from a misunderstanding of what object-oriented is. The object-oriented principle indicates that data should be encapsulated as much as possible. In many ways a non-member method is better than a member function.
2. If something is encapsulated, it is hidden from sight. The more things are encapsulated, the less you can see them. The less you can see it, the greater the elasticity of our change, because our change only directly affects what we see as something that we have changed. The stronger the encapsulation of something, the stronger our ability to change it. This is why the value of encapsulation is evaluated first: it provides us with a flexibility to change things, and only affects limited customers. Consider data in conjunction with an object. The less code can see the data (that is, access it), the stronger the data encapsulation, the greater the freedom to change the nature of the object's data, such as the number of data members, their types, and so on. As much code can see the coarse scale of a piece of data, we can count the number of functions that can access that piece of data: the more functions can access it, the weaker the encapsulation of the data.
Question: If you are purely object-oriented programming (only classes, no non-member functions), do you need this section? I admit that non-member functions have a stronger encapsulation capability. Maybe I haven't understood object-oriented programming yet.
Item 24, declared as a non-member function when the type conversion should be used for all parameters.
1. If you need to use a type conversion on all parameters of a function (including the one pointed to by the this pointer), the function must be a non-member.
2. A non-member function relative to a member function, not a friend function. Too many programmers assume that if a function is related to a class and should not be a member (for example, because all parameters require a type conversion), it should be a friend. This example proves that such reasoning is flawed. Whenever you can avoid a friend function, you avoid it, because, like in real life, friends often have more trouble than their value.
Section:
Use
Const Rational operator* (const rational& LHS, const rational& RHS)
{
Return Rational (Lhs.numerator () * Rhs.numerator (), Lhs.denominator () * Rhs.denominator ());
}
Replace
Class Rational
{
...
Const Rational operator* (const rational& RHS) const{}
...
};
Item 25 consider support for swap without throwing exceptions
Section: Look a bit confused, the title is not throw abnormal swap, but I seldom see how to guarantee not to throw abnormal, perhaps I did not understand, the template is not very familiar, here to make a note.
Reading Note 4: Design and declaration of <<effective c++>>
