Normally I get warnings on problems like that. (MSVC2005)
warning C4172: returning address of local variable or temporary
Are you sure you aren't getting this warning?
Edit: nevermind, depends on how its set up. If your function returns a copy and you are catching it in a reference that doesn't seem to produce this warning. Seems like a no brainer that it should. pos. :)
Code demons again (real this time). Memory molestations.
Author
Quote:Original post by PalidineQuote:Original post by Kest
Is there any way to avoid these types of typos? I could have more right now. Shouldn't the compiler warn about storing a copy of something being returned from a function into a reference variable?
Nope. It's perfectly valid code. If something is already being returned by value (i.e. a copy) then you might want a reference to it if you're just doing local stack work. Otherwise, you'd incur 2 copies when you just need one.
-me
But the copy is being sent into the abyss, right? The function returns a copy, I assign it to the reference variable, then the copy is chucked into the recycler. Isn't that always going to end badly?
Quote:Original post by DrEvil
Normally I get warnings on problems like that. (MSVC2005)
warning C4172: returning address of local variable or temporary
Are you sure you aren't getting this warning?
No, and I'm using warning level 4. Are there any specific reasons it would ignore the warning? I need to purposely test it a few times to see if it always ignores it.
edit after your edit: That sucks.
Quote:Original post by Kest
But the copy is being sent into the abyss, right? The function returns a copy, I assign it to the reference variable, then the copy is chucked into the recycler. Isn't that always going to end badly?
No. when objects go out of scope they get their destructor called. there are plenty of times you let objects die on the stack. For instance:
class Vector{ float x; float y; float z;};that's an object that you often return by value:
Vector toTarget = target.pos - my.pos;//do some stuff with toTarget//exit scopeVector is returned by value (copy) from the operator-
[EDIT: that warning is for returning the address of an internal stack variable:
Vector *getVector(){ Vector theAnswer; return &theAnswer;}that's bad because theAnswer is destructed right after returning it's ponter.]
-me
It's caught properly there. The compiler ought to be smart enough to error/warning on something like this
I can't think of any situation this would be anything other than a bug.
Edit: Palidine, I don't see how you're example is relevant. I think his quote is spot on. Catching something returned by value in a reference is a no win situation. Stoopid compilers ought to be able to catch these sort of things.
const Vector &toTarget = target.pos - my.pos;I can't think of any situation this would be anything other than a bug.
Edit: Palidine, I don't see how you're example is relevant. I think his quote is spot on. Catching something returned by value in a reference is a no win situation. Stoopid compilers ought to be able to catch these sort of things.
Author
Quote:Original post by PalidineQuote:Original post by Kest
But the copy is being sent into the abyss, right? The function returns a copy, I assign it to the reference variable, then the copy is chucked into the recycler. Isn't that always going to end badly?
No. when objects go out of scope they get their destructor called. there are plenty of times you let objects die on the stack. For instance:
....
-me
I don't get it. I know it's perfectly valid to return copies. I'm asking why it's okay to store those copies excusively into a reference variable, straight from the called function. This would be okay:
ref = copy = FunctionReturningCopy();
But this also seems to be okay:
ref = FunctionReturningCopy();
Quote:Original post by Kest
But this also seems to be okay:
ref = FunctionReturningCopy();
Right. I believe that's ok because the copy that's returned is returned to the calling function's scope. So in the compiled code it's not any different from doing ref = copy = function().
Whether you put it explicitly there or not, i'd presume it's all more or less the same in the assembly.
-me
Author
It's a little frightening to have the possibility of a single character typo that can occur in a multitude of code and work correctly 95% of the time regardless of possible impending doom on any one occasion.
I can't even count the number of functions I have that return const references. Or rather, I can't count the number of functions that are supposed to be returning const references.
I guess I'll just have to deal with it and remember to look for it next time. Thanks for all of the help. And sorry to the demons for pointing my finger again.
I can't even count the number of functions I have that return const references. Or rather, I can't count the number of functions that are supposed to be returning const references.
I guess I'll just have to deal with it and remember to look for it next time. Thanks for all of the help. And sorry to the demons for pointing my finger again.
Quote:Original post by Kest
So it sounds like another application can't change memory in the stack that effects my program. My code also uses only one thread to execute. What about other threads that run with my program? Such as the timer, directx, or etc? Is it possible that some part of my code is ripping on them - such as changing the address of one of their pointer variables - causing them to modify it and change something of mine? Or is that also impossible? Is there similar protection between threads that exists between programs?
Thought I'd say that this is way off. No other process will access the one your program lives in. But threads will all run in the same address space, same process, so no, there is no protection against one thread screwing around with data from another one.
Quote:Original post by Kest
It's a little frightening to have the possibility of a single character typo that can occur in a multitude of code and work correctly 95% of the time regardless of possible impending doom on any one occasion.
Well, that's one of the reasons they say it's easy to shoot yourself in the foot with C++ :) You may want to try and get your hands onto something like BoundsChecker, which would've pointed this problem out instantly. BoundsChecker is expensive, but most people can probably get away with some free counterpart.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
