C + + object Model--temporary object (sixth chapter)

6.3 Temporary objects (temporary Objects) assume that there is a function in the form such as the following:

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

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

A + b;

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

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

The compiler produces a transient object, places the result of the a+b, and then uses the copy constructor of T to treat the transient 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 there is no need for a temporary object, and a call to its constructor and destructor .
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 running 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 guarantee? strictly speaking, C + + standard agrees that the compiler has complete freedom to produce temporary objects.
But in fact, almost no matter what the expression hypothesis has this form:

T C = a + B;

and 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 this initialization operation:

T C = a + B;

Always is 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, such a situation is actually very common in sub-expressions. For example, suppose you write this:

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 of converting 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 a complete expression, which results in a temporary object.
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);

One has five sub-expressions, which are inside a "?: Complete expression". No matter what a sub-expression produces, no matter what a temporary object, you should be able to destroy the full expression after the evaluation is complete.
The life rules of temporary objects are somewhat complicated when temporary objects are conditionally produced according to the program's run-time semantics. For example, consider this expression:

if (s + t | | U + v)

The U+V is evaluated only when the S+T is evaluated as false. The temporary object associated with the second sub-equation must be destroyed. However, it is very obvious that it cannot be destroyed unconditionally. That is, it is hoped that only the temporary object will be produced in the case of the destruction of it. (assuming that the first sub-equation is true, no second temporary object is generated and no destruction is required)
The destructor of a temporary object in the evaluation of each sub-formula can be exempted from "trying to track whether a second sub-formula really needs to be evaluated". However, in the temporary object Life rule of C + + standard, This strategy is no longer agreed. Temporary objects must not be destroyed until the full expression has been evaluated completely. In other words, some form of conditional testing now has 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 rules 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;

Among them, Progname and Progversion are string objects. This will give birth to a temporary object that puts the result of the addition operator's operation:

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 a temporary object, it should be in full "?

: expression "End evaluation is destroyed as soon as possible." However, it is assumed that the initialization of prognameversion requires a copy constructor:

Prognameversion.string::string (temp);

So the deconstruction of temporary objects (in "?

: Complete expression "after") of course that's not expected. C + + standard requirements:
. .. Any temporary object that contains the result of the expression operation should be persisted until the initialization of the object is complete.
The second exception to the life rule of a transient object is "when a transient object is bound by a reference" , such as:

Const String &space = "";

Generate this program code:

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

It is very obvious that the reference is not practical if the temporary object is now destroyed. So C + + standard requirements:
Assuming a transient 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 arrives first.

The myth of a temporary object is that because the current C + + compiler produces a temporary object, it makes the program less efficient to run.

C + + object Model--temporary object (sixth chapter)