All this looks very wonderful, but if it is the following example, what happens?
Myclass & mc = foo ();
Now not copy the temporary object to the new object, I just assign it to a reference, (please note that this is a little difference in the example of the first example, in the first example, I will put a local variable The reference is made as a function returned value, and in this example, I assign a reference to a variable that returned by a function to a variable). So what will happen now? When will the temporary object are destroyed? If it is destroyed at the end of the execution of the expression, just like the above example, this code will completely end up because of an application pointing to the object that does not exist. However, please note that the C standard agrees to make an unusual solution to this situation: if a temporary object is assigned to a reference, this temporary object will not be destroyed in this referenced lifecycle. In other words, it is completely legally legally equipped with a reference to returning a local variable to a temporary object, and this object should be valid.
The bug
I guess I can only say that only the compiler has implemented C standards, this reference can be valid. Eugene Gershnik sent me the code listed in Listing 2, which has a function called Foo, returned a std :: Vector
"The instruction at" 0x004121B5 "Reference Memory AT" 0x00000000 ".the memory could not be" read "."
Listing 2
Assigning a Reference to a Temporary Object
// problem with reference bound to temporary
// the function foo returns a Temporary Object
// of type std :: Vector
// TO a Reference of Type const st :: vector
//En the expression "int M [80] = {0};" IS
// executed,
// The reference bar no longer seems to be valid,
// and the program will crash in the call to
//printf.
// Removing the line "int m [80] = {0};" Eliminates
// the problem.
//
// compile with vc7, with the "Program Database
// for edit and continue "debug option.
#include
#include
Std :: Vector
{
Std :: Vector
Return Ret;
}
int main ()
{
Const std :: vector
INT M [80] = {0};
Std :: Printf ("% d / n", bar [0]);
Return 0;
}
I guess this results because of the optimization of "INT M [80] = {0};" this line of code did not do, I think this optimization is eliminated in Release. The lower error. But when I sent the code to Microsoft and solicited their opinions, Jeff Peil gave me a letter and pointed out the real reasons:
This problem is due to editing - continuing debugging support (Edit-Continue Debugging Support)
The function is caused. This error will be repaired in the next version of Visual C that is about to be released.
Positive, you can avoid this error by removing editing - continuing debugging support from the compilation option
The occurrence of debugging occurs when compiling, and you need to do it just to replace / zi options.
/ Zi option). Of course, another solution is not to bind the reference to the temporary object.
This way you can continue to use editing - continue to debug support, just like the code below:
int main ()
{
Std :: vector
Std :: swap (bar, foo ());
INT M [80] = {0};
Std :: Printf ("% d / n", bar [0]);
Return 0;
}
-Jeff peil
Although there is a little loss in performance, Jeff's code works very well. Exchange these two vectors content is a cost of expensive operations, but in fact all exchange work is to exchange few internal variables in two arrays, which do not involve copies of the buffer, so exchange will Completed within a constant time.
Of course, if you want to simply solve this problem, you can move the expression "int M [80] = {0};" before the declaration variable bar. Because there is no dependency between them, there is no relationship between any one.
(Finish)
