Gotw # 22 Object Lifetimes - Part I
Author: Herb Sutter
Translation: k] [N g of @ rkTM
[Declaration]: This article takes the Guru of The Week column on www.gotw.ca website, and its copyright belongs to the original person. Translator Kingofark translated this article without the consent of the original person. This translation is only for self-study and reference, please read this article, do not reprint, spread this translation; people download this translation content, please delete its backup immediately after reading. Translator Kingofark is not responsible for people who violate the above two principles. This declaration.
Revision 1.0
GURU Of The Week Terms 22: Survival of Objects (Part 1)
Difficulty: 5/10
("Survival, or destroyed ... [Tetasub: This is the name of Shakespeare" Hamlet "]" When an object is actually existing? This problem is used to examine when a target can be safe.)
[Problem]
[problem]
Review the following block. # 2 The code is safe and / or legal? Please explain your answer.
Void f () {
T t (1);
T & RT = T;
// # 1: Do something with T or RT
t. ~ t ();
NEW (& T) T (2);
// # 2: Do something with T or RT
} // t is destroyed again
[answer]
Yes, the code at # 2 is safe and legal (if only this part of the code is considered), but:
a) function as a whole, it is unsafe, and
b) This is a bad habit.
[Why # 2 is safe (if this part of this code is considered)? ]
The C standard draft is clearly stipulated, allowing this code to appear. In-Place Destruction and Reconstruction (in-place destruction and reconstruction) does not make RT. (Of course, you can't use T or RT between t. ~ T () between Placement New, because there is no object in that period. We also assume that T :: Operator & () is not overloaded, ie Other things other than the "Address of the Object".)
We say "If only this part of the code is considered," # 2 is safe ", because F () is as a whole, it may not be an exception-safe:
[Why is the function unsafe? ]
If the T (2) is invoked, T 's constructor has an abnormality, then f () is not unusual. Considering the cause: If T (2) throws an exception, then there will be no new objects in the memory area where 'T' is located, and at the end of the function at :: ~ t () is still normalized ( Because T is an automatic variable [Automatic variable]), and "T is destroyed again" as described in the comment in the code. That is to say, 't' will be constructed once, but it is destroyed twice (呜 呜). This will result in easily produce non-foreseeable side effects, such as Core Dumps.
[Why is this bad habit? ]
If an abnormal security is ignored, the code can work properly under such settings, because programmers know the specific type of objects that are constructed and destroyed. That is to say, the object is a T and is destroyed and re-constructed as a T. In the actual code, this technology (even if it is really coding) is hardly used, and this is also very bad habit; reason is: If it appears in the member function, then it will be full (sometimes difficult Touching) danger:
Void T :: f (int i) {
THIS-> ~ T ();
NEW (THIS) T (I);
}
Is this technology safe now? Basically, it is not safe. Consider the following code:
Class u: / *...*/ public t {/ * ... * /};
Void f () {
/ * Aaa * / t (1);
/ * Bbb * / & rt = T;
// # 1: Do something with T or RT
T.f (2);
// # 2: Do something with T or RT
} // t is destroyed again
If "/ * aaa * /" is "T", then the code at # 2 is still feasible, even if "/ * bbb * /" is not "T" ("/ * bbb * /" may be the base class of T).
If "/ * aaa * /" is "u" (translation: rather than "t"), then no matter what "/ * bbb * /" is, there is no suspense. Probably what you can expect is a timely Core Dump because the call will be used to cut (SLICES ". "Cut" herein refers to: T.f () replaces the original object with another different type of object - this is said that the function is used instead of U. Even if you intend to write unmiglable code, you can't know "When the memory area where the original U is located is wrapped in the data of the T object, it is still available as a U.?" Although there is still the case, but please don't go to the point ... this is not a good practice.
This GOTW contains some basic, information on the security issues and cutting problems of in-place destruction and reconstruction. This is the next time "GOTW Terms 23: Object Survival (Part 2)"
(Finish)
