C + + object model-Temporary object (sixth chapter)

6.3 Temporary objects (temporary Objects) If there is a function, the form is as follows:

T operator+ (const t &, const T &);

As well as two T objects,a and B, then:

A + b;

may result in a temporary object to place the returned objectWhether it will result in a temporary object, depending on the compiler's aggressiveness (aggressiveness) and the program context when the above operation occurs. For example, this fragment:

T A, B; T C = a + B;

The compiler generates a temporary object, places the result of the a+b, and then uses the copy constructor of T to treat the temporary object as the initial value of C. but A better conversion is to put the value of a+b in C directly in the form of copy construction, so that no temporary objects are needed, and the calls to their constructor and destructor are not required .
In addition, depending on the definition of operator+ (), named return value (NRV) optimization (see section 2.3) may also be implemented. This will result in the expression being evaluated directly in the C object above. avoid executing the destructor of copy constructor and named objects (named Object).
The results of the C objects obtained in three different ways are the same. In the meantime, The difference is the cost of the initialization.Can a compiler give any guarantees? Strictly speaking, C + + standard allows the compiler to have complete freedom of temporary object generation.
In practice, however, almost any expression has this form:

T C = a + B;

and where the addition operator is defined as:

T operator+ (const t &, const T &);

Or

T t::operator+ (const T &);

So implementation does not produce a temporary object at all.
Note, however, that the assignment statement is quite meaningful:

c = a + B;

temporary objects cannot be ignored.
So the initialization operation:

T C = a + B;

Always more efficiently converted by the compiler than the following operations:

c = a + B;

The third form of operation is that the target object is not present:

A + b;    No target

This time It is necessary to produce a temporary object to place the result of the operation. Although it may seem a bit strange, this situation is actually very common in sub-expressions. For example, if you write:

String s ("Hello"), T ("World"), U ("!");

Then whether:

String v;

v = s + t + u;

Or

printf ("%s\n", S + t);

will produce a temporary object associated with S + T.
The last expression brings up a proposition that "The life cycle of a temporary object".
A more preferred way to convert is to implement string destructor after calling printf (). in C + + standard, this is exactly how the expression must be converted. Standards this will:
The destruction of a temporary object should be the last step in the evaluation of the complete expression, which causes the temporary object to be generated.
What is a complete expression? Informally, it's the outermost of the expression being enclosed.. The following expression:

Tertiary full expression with 5 sub-expressions ((Obja > 1024x768) && (OBJB > 1024))? Obja + Objb:foo (Obja, OBJB);

A five-child expression that is inside a "?: Complete expression". Any temporary object produced by any one subexpression should be destroyed only after the complete expression has been evaluated.
When temporary objects are conditionally produced according to the execution period of the program, the life rules of the temporary objects are somewhat complicated. For example, think of an expression like this:

if (s + t | | U + v)

The U+V is evaluated only when the S+T is evaluated as false. Temporary objects related to the second sub-equation must be destroyed. However, it is clear that it cannot be destroyed unconditionally. In other words, it is hoped that the temporary object will be destroyed only if it is generated. (If the first sub-equation is true, no second temporary object is generated and no destruction is required)
Putting the destructor of temporary objects in the evaluation of each calculation can exempt "trying to track whether a second sub-formula really needs to be evaluated". However, in the temporary object Life Rules of C + + standard, Such a strategy is no longer allowed. Temporary objects must not be destroyed until the full expression has been fully evaluated. That is, certain forms of conditional testing now have to be inserted in order to determine whether or not to have a temporary object related to the second formula.
There are two exceptions to the life rule of a temporary object. The first exception occurs when an expression is used to initialize an object. For example:

BOOL verbose; String prognameversion =!verbose? 0:progname + progversion;

Where Progname and Progversion are string objects. This time a temporary object is produced, and the result of the addition operator is placed:

String operator+ (const string &, const string &);

The temporary object must be conditionally deconstructed based on the test results of the verbose. Under the life rule of the temporary object, it should be destroyed as soon as the complete "?: expression" finishes evaluation. However, if prognameversion initialization requires a copy constructor:

Prognameversion.string::string (temp);

Then the deconstruction of the temporary object (after the "?: Complete expression") of course that is not expected. C + + standard requirements:
. .. Any temporary object that contains the result of an expression execution should persist until the initialization of object is complete.
The life rules of a temporary object The second exception is "when a temporary object is bound by a reference"For example:

Const String &space = "";

Generate the code for this program:

C + + pseudo codestring temp;temp. String::string (""); const String &space = temp;

Obviously, if the temporary object is now destroyed, the reference is useless. So C + + standard requirements:
If a temporary object is bound to a reference, the object will remain until the end of the initialized reference's life, or until the end of the temporary object's life category (scope)-depending on which case first arrives.

The myth of a temporary object is that because the current C + + compiler produces temporary objects, the execution of the program is less efficient.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

C + + object model-Temporary object (sixth chapter)