Effective C + + reading notes (iv) Design and statement __c++

4 design and statement • Software design, the steps and practices of "making the software do what you want it to do," usually begins with a fairly general idea and eventually evolves into full detail to allow the development of special interfaces (interface) that must then be converted to C + + declarations. clause 18: Make the interface easy to use correctly, not easy to be misused Makeinterfaces easy to use correctly and hard to use incorrectly.

• Good interfaces are easy to use correctly and are not easily misused. You should strive to achieve these properties in all of your interfaces.

• The "promote proper use" approach includes consistency of interfaces and compatibility with built-in types of behavior.

• The "block misuse" approach includes creating new types, restricting operations on types, constraining object values, and eliminating customer resource management responsibilities.

Tr1::shared_ptr supports custom-type deletes (custom deleter). This can prevent DLL problems and can be used to automatically unlock mutex (mutexes) clause 19: Design class is like design type Treat classdesign as type.

• Methods for designing efficient type (types) classes (classes):

1. How objects of the new type should be created and destroyed.

• Construct and destructor functions and memory allocation and release

2. What is the difference between the initialization of an object and the assignment of an object.

• The behavior of Constructors and assignment (Assignment) operators

3. The object of the new type is what it means if it is passed by value (passed in values).

The copy function is used to define the passed by value of a type

4. What is the "legal value" of the new type.

< exception handling >

5. Your new type needs to fit in with an inherited graph (inheritance graph).

< Whether virtual functions are required >

6. What kind of conversion is needed for your new type.

Explicit

7. What operators and functions are reasonable for this new type.

8. What standard function should be dismissed.

9. Who should take a member of the new type.

public? Private? Protected? Or friend?

10. What is the "undeclared interface" for the new type (undeclaredinterface)?

11. How generalized your new type is.

class template?

12. Do you really need a new type?

derived class?the design of class is the design of type. Before defining a new type, make sure you have considered all the topics covered by this article. clause 20: Prefer to replace pass-by-value with Pass-by-reference-to-const perfer Passby Reference to const to pass by value. • If you have an object that belongs to a built-in type (such as int), Passby value is often more efficient than the pass by reference. • Try to replace pass by value with pass by reference. The former is usually more efficient and avoids cutting problems (slicing problem). • However, it does not apply to built-in types, as well as STL iterators and function objects. For them, pass by value is often more appropriate.
clause 21: When an object must be returned, do not attempt to return to its reference Don ' t try toreturn A reference when your must return to an object

• When we understand the cost of passing values in clause 20, we always avoid using less values, but be careful when returning objects, because you might: pass some references or pointers to objects that no longer exist. That's not a good thing.

• Whenever you see a reference declaration, you should immediately ask yourself what another name it is.

• There are two ways for a function to create a new object: in stack space and heap space

1. On the stack: The local variable within the function. The local variable has no meaning after the function returns, and if it is "obsessed" with it, it will bring disastrous consequences. So it is not feasible to pass the reference on the stack.

2. Heap: Constructs an object on the heap and returns it. Seemingly feasible, but also buried the risk of resource leakage. Who should implement delete on this object? Do not put this kind of resources management sustenance completely to the user. So it's not feasible to pass the reference on the heap.

3. There may be another idea: "Let the returned reference point to a static object defined within the function." We have misgivings about multithreading security, and when two functions in a thread can handle a single object, it may also result in unpredictable behavior. Therefore, static objects are also not feasible.

4. A function that "must return a new object" is correctly written: let that function return a new object.
Compiler implementations are optimized to improve the efficiency of output codes without altering their observed behavior. So let's just go back to an object. Reference is just a name that represents an existing object. • Never return pointer or referencce point to a local stack object, or return reference to a Heap-allocated object. or return pointer or reference point to a local static object and may require multiple such objects at the same time.
clause 22: Declare a member variable private Declare datamembers Private

• Hide member variables behind function interfaces to provide flexibility for "all possible implementations". For example, this makes it easy for member variables to be read or written to notify other objects, to validate CALSS constraints and function prerequisites and afterwards state, and to perform synchronous control in a multithreaded environment ...
No encapsulation means no change. The encapsulation of a member variable is inversely proportional to the amount of code that is bad when the content of a member variable changes.• Remember to declare a member variable private. This gives the customer access to data consistency, fine-grained access control, guaranteed constraint conditions, and provides class authors with full flexibility. protected is no more encapsulated than public.
clause 23: Prefer to replace the member function with Non-member and Non-friend prefernon-member non friend functions to member functions • Prefer to replace the member function with the Non-member non-friend function. This can increase encapsulation, package elasticity, and skill expansion.
Clause 24: If all parameters require type conversion, please use the Non-member function declarenon-member functions When type conversions should apply to all parameters. • This parameter is a qualified participant in an implicit type conversion only if the parameter is listed in the parameter column the inverse of the member function is the Non-member function, not the friend function. • If you need to type conversions for all parameters of a function (including the metaphorical parameter referred to by the This pointer), then this function must be a non-member.
clause 25: Consider writing a swap function that does not throw an exception Considersupport for a non-throwing swap.

• Function template can not be biased, not language implementation, because the function overload (overload) to implement

• Customers can fully classes the templates within the STD, but no new templates (or or functions or anything else) can be added to the Std. The content of the STD is entirely decided by the C + + Standards Committee, which prohibits us from inflating what has been declared good. Can be placed in other namespaces.

when Std::swap is inefficient for your type, provide a swap member function and make sure that the function does not throw an exception. If you provide a member swap, you should also provide a non-member swap to invoke the former. For class (not templates), also special Std::swap. When you call swap, you should use a using declaration for Std::swap, and then call swap with no namespace qualifier. It is good to make STD templates for user-defined types, but never try to add something new to Std.