Terms 19: Understand the source of temporary objects
When the programmer is conversation, they often refer to the variables that only take a short period of time as temporary variables. For example, in the SWAP (Exchange) routine below:
Template
Void Swap (T & Object1, T & Object2)
{
T Temp = Object1;
Object1 = object2;
Object2 = TEMP;
}
Temp is usually called temporary variables. However, in C , Temp is not a temporary variable, which is just a partial object of a function.
The real temporary object in C is invisible, they don't appear in your source code. Create a non-heap object that is not named will generate a temporary object. This unnamed object is usually generated under two conditions: in order to make the function successfully invoke, the implicit type conversion and the function return object. It is important to understand how to establish these temporary objects because constructors and release their overhead have an impact on the performance of the program.
First, consider the establishment of a temporary object to establish a temporary object to make functions. This is generated when the object type transmitted to the function is mismatched with the parameter type. For example, a function is used to calculate the number of times the character appears in a string:
/ / Returns the number of times the CH appears in STR
SIZE_T Countchar (Const String & Str, Char CH);
CHAR BUFFER [MAX_STRING_LEN];
Char C;
// Read into a character and string, use SETW
/ / Avoid cache, when reading a string
CIN >> C >> SETW (MAX_STRING_LEN) >> BUFFER;
COUT << "there" << countchar (buffer, c)
<< "Occurrences of the Character" << c
<< "in" << buffer << endl;
Look at the call of Countchar. The first parameter transmitted is the character array, but the type of the positive binding parameter of the corresponding function is Const string &. This call can only be successfully conducted after the elimination type does not match, your compiler is happy to eliminate it for you, and the method is a temporary object of a string type. This temporary object is initialized by calling the String constructor as a parameter as a parameter. The parameter STR of Countchar is bound to this temporary String object. When CountChar returns, the temporary object is automatically released.
Such type conversion is very convenient (although very dangerous - see clause 5), but from the point of view, the construction and release of the temporary String object is unnecessary overhead. There are usually two ways to eliminate it. One is to redesign your code and do not let this type of conversion. This method is studied and analyzed in terms 5. Another method is to say how to do it by modifying software without need type conversion.
These types of conversions are only transmitted only when the object or the Reference-to-const parameter is passed through the By Value. When passing a very quoted-to-non-const parameter object, it will not happen. Consider this function:
Void Uppercasify (String & Str); // Put all the characters in the STR
/ / Change to uppercase
In the example of the character count, you can successfully pass the char array into countchar, but here you try to use the char array to call the UPEERCASIFY function, you will not succeed: char SubtlebookPlug [] = "Effective C ";
Uppercasify (SUBTLEBOOKPLUG); // Error!
There is no temporary object to make the call to success, why?
Suppose a temporary object is created, the temporary object will be passed to the upeercasify, which will modify this temporary object and change its character to uppercase. However, there is no impact on the true parameters called the SubtlebookPlug function; only the String objects generated from SubtleBookPlug are changed. Undoubtedly this is not what programmers want. The programmer passes the subtlebookPlug parameter to the Uppercasify function, and it is desirable to modify the value of the subtlebookPlug. When a programmer expects to modify a non-conventional object, the implicit type conversion of the REFERENCES-TO-Non-Const is modified to modify the temporary object. This is why the C language is forbidden to generate temporary objects for a very quotable reference. This will not encounter such problems in this very quoted reference parameter.
The second environment for establishing a temporary object is when the function returns an object. For example, Operator must return an object to indicate the sum of the two operands (see Effective C Terms 23). For example, give a type number Number, this type of Operator is claimed:
Const Number Operator (Const Number & LHS,
Const number & rhs;
The return value of this function is temporary because it is not named; it is just the return value of the function. You have to pay for each time the Operator constructs and releases this object. (For why the return value is a detailed explanation of Const, see Effective C Terms 21)
Usually you don't want to pay such overhead. For this function, you can switch to Operator =, and avoid overhead. Terms 22 tells us how this conversion is made. However, for most of the functions of the object, you cannot switch to different functions, so there is no way to avoid constructing and release return values. At least there is no way to avoid it. However, there is another dark zone between concepts and reality, called optimization, sometimes you can write a function of returning an object in some way to allow your compiler to optimize temporary objects. These optimizations, the most common and most effective is the return value optimization, which is the content of the provisions 20.
In summary, temporary objects are overhead, so you should remove them as much as possible, but more importantly, training yourself to find a place where you might build temporary objects. At any time, just see the constant reference parameter, there is a possibility that the temporary object is established to bind the parameters. At any time, just see the function returns an object, there will be a temporary object to be established (released later). Learn to look for these object constructs, you can significantly enhance the ability to see its backup through the compiler surface action.
