temp variable lifetime

Started by
11 comments, last by nullsquared 18 years, 7 months ago
int get(int ii) { int i = ii; return i; } int bar(int *i) { return *i; } int i11 = bar(&get(4)); how long is temp variable lifetime?
Advertisement
Quote:Original post by luasitdown
how long is temp variable lifetime?


Until the end of the statement, unless you've used it to initialize a reference, in which case it lasts as long as the reference itself (IIRC).
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
Quote:Original post by Fruny

Until the end of the statement, unless you've used it to initialize a reference, in which case it lasts as long as the reference itself (IIRC).


The data can outlast a pointer that points to it. Just letting the pointer go out of scope won't be enough, you have to explicitly delete the data it points to, or it'll still exist. This is where a lot of memory leaks come from.

For the original question: When you're not using pointers, the variable will last until the code block that you initialized it in ends. For instance in your function get, i goes out of scope when you hit the }.
Quote:Original post by MaskedProgrammer
The data can outlast a pointer that points to it. Just letting the pointer go out of scope won't be enough, you have to explicitly delete the data it points to, or it'll still exist. This is where a lot of memory leaks come from.


I fail to see how this relates to the subject at hand in any way.

Quote:For the original question: When you're not using pointers, the variable will last until the code block that you initialized it in ends. For instance in your function get, i goes out of scope when you hit the }.


Look, he's returning by value. The lifetime we are concerned with isn't that of the local variable, but that of the return value, which is an unnamed temporary.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
Quote:Original post by Fruny
I fail to see how this relates to the subject at hand in any way.
Just adding to what you said. No need to get defensive about it. It's good information, especially since it looks like he's starting to play with pointers.

Quote:Look, he's returning by value. The lifetime we are concerned with isn't that of the local variable, but that of the return value, which is an unnamed temporary.


It was hard for me to tell which variable he was asking about specifically, so I assumed he was asking about variables in general. Yeah, now that I've realized he's talking about the returned value, you're correct.
Quote:Original post by MaskedProgrammer
Just adding to what you said. No need to get defensive about it. It's good information, especially since it looks like he's starting to play with pointers.


Please accept my apologies.

Quote:It was hard for me to tell which variable he was asking about specifically, so I assumed he was asking about variables in general. Yeah, now that I've realized he's talking about the returned value, you're correct.


Glad we agree.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
To add one more thing in here.


Lets say that you have the following:
int ReturnAnInt(){   int i = 20;   return i;}int result = ReturnAnInt();


After the code has ran the "result" variable will have the value of 20 (passed by value) from the function and the temp variable i that contained a value of 20 inside the function will be automatically deallocated when the funtion returns. HOWEVER, if you do a memory dump at that location where the variable i contained its data will still have the value of 20, BUT it is not guarnenteed to be 20 depending on if that memory address has been changed by another variable.

for instance


// Bad Code even though it runs and looks good to the eye of a novice.char* ReturnChar(){   char str[8] = "Testing";   return str;}


In this case. ReturnChar will return a pointer to where str was located and it can contain the value of Testing\0. Since str was a local variable to the function, it was dealocated and that value is not gaurenteed to be Testing\0 after the function has returned.
Quote:Original post by luasitdown
int get(int ii)
{
int i = ii;
return i;
}

int bar(int *i)
{
return *i;
}


int i11 = bar(&get(4));



how long is temp variable lifetime?


but the code not work now. it give me error C2102

compiler treat the & as other operator?

how to fix it?


int i11 = bar(&(get(4))); not work too.
You can only take the address of an l-value. An l-value is anything you can assign to - that is, anything that can appear on the "left" of the equals (=) sign - hence the name "l"-value. An r-value, on the other hand is anything that can appear on the right-hand-side of an equals sign.

Because you can't assign to the return value of a function, you can't take its address.

I'm not sure what you're actually trying to do though, the example you gave is a bit contrived :) Perhaps some more context could shed some light?
Quote:Original post by Dean Harding
You can only take the address of an l-value. An l-value is anything you can assign to - that is, anything that can appear on the "left" of the equals (=) sign - hence the name "l"-value. An r-value, on the other hand is anything that can appear on the right-hand-side of an equals sign.

Because you can't assign to the return value of a function, you can't take its address.

I'm not sure what you're actually trying to do though, the example you gave is a bit contrived :) Perhaps some more context could shed some light?


O ,I see, but why return value can not be l value?

I know only const return value can not be l value. here is not a const return.

This topic is closed to new replies.

Advertisement