Heavy Load ++ and --, heavy load --

Heavy Load ++ and --, heavy load --

Unlike the common binary operator "+/-", the auto-incrementing and auto-subtraction operator "+ +/--" requires extra attention to distinguish between front-end and back-end. The current processing method is: (as a member function) the front "++" does not accept any parameters, while the rear "++" accepts an int type parameter, although it is useless, it helps the compiler determine the overloaded object.

In addition to distinction, they also have different behaviors. QuoteMore Effective tive C ++In, the frontend ++ isIncrement and fetchWhile the rear ++ isFetch and increment. Therefore, we must meet these requirements when reloading these operators.

Another point is that you need to handle the return value with special care. The front ++ usually returns an object reference, while the back ++ returns a const object.

The reason for the front ++ return reference is very simple. For example, the front ++ has the following behavior:

++ (++)

First, it must be clear that the operator is actually a function call and has a return value. The second ++ operation is performed on the return value of the first ++ operation. If we do not return a reference and return a new temporary object, the second time ++ gets the result of the auto-increment operation on this temporary object, this statement can only perform one auto-increment operation on Object. You can view its disassembly code to verify this. The post ++ returns an object, which is also very simple, because you need to temporarily save the old value in the post ++, the old value must be a temporary variable inside the ++ function body. Returning a pointer or reference to a temporary variable is dangerous and not allowed. As to why const modification is required, it is necessary to ensure that expressions such as a ++ are invalid during compilation rather than unexpected results during runtime. Why can't a ++ appear? First, the built-in data type (such as int) does not allow us to do this. Second, even if the custom class can implement this behavior, it is also not in line with your general consensus idea: we usually think that two ++ together will lead to two consecutive increments of a, and just as the above analysis front ++ used together, the returned object is not a reference, so that the second operation object is a temporary object instead of itself, which is inconsistent with our expectation. To avoid such misunderstanding, you must use the const modifier to explicitly disable the service. The const object returned by the function ensures that it does not function on non-const member functions, while operator ++ does not.

In addition, we recommend that you use ++ (* this) When reload the backend ++, while the frontend ++ uses * this + = 1. Because the objects supporting auto-increment operations must support addition operations, this can significantly improve the simplicity and readability of the Code. The Inline Function Optimization of the compiler does not add much extra overhead on the execution speed (compared to writing the function body directly in ++ ).

In this way, we can get the common and overloaded ++ operator sample code:

 

 1 //prefix ++ : increment and fetch 2 myclass & myclass::operator++() 3 { 4     *this += 1; 5     return *this; 6 } 7 //postfix ++ : fetch and increment 8 const myclass myclass::operator++(int) 9 {10     myclass tmp = *this;11     ++(*this);12     return tmp;13 }

 

In terms of efficiency, there is usually a better "frontend auto-increment", because the pre-operator does not need to generate a temporary object or call the constructor and destructor of the temporary object. If this object is large, the memory replication time is also large. Therefore, if it is not a special need, we should try to use the front ++ class type as much as possible. This is also why it seems that you are using the STL iterator as much as possible to use the front ++ in a loop.

Reference: More Effective C ++, Meyer Scott, Hou Jie translation, Electronic Industry Press