[RESOLVED] "returning address of local variable or temporary"

Started by
17 comments, last by SiCrane 18 years, 7 months ago
Quote:Original post by liam666
The reason it gives you this error is because a local variable only exists while the function it is local to exists. When the function ends, it (the variable) is deleted into the great void. By returning a reference to a local variable, the variable the reference is to will no longer exist, and the memory could contain anything.

I hope that makes sense.


Yes, that does make sense. What was confusing me (I am used to VB) is the fact that a char[256] is returned as a reference, rather than just a temporary string type thing. My mind is thinking it would return the value of the char, and then the local variable would be out of scope and deleted, but my new variable (which the function was returned to) would have the value, not the reference, of the one that was returned then deleted therefore not causing any problems. I guess I still have a lot to learn with c++.

Thanks again. I really appreciate all the help.
Advertisement
Quote:Original post by GetWindowRect
Roboga
I know a char* is a type of reference, but I am not using that, I am using char [256] not char*.

Ahh, there's the confusion. char[256] is essentially the same as a char* with a known size. They're distinct types to the compiler, but they're treated basically the same. In particular, returning a char[256] returns a pointer to the first element rather than copying all 256 elements, the behavior one might prefer.

CM
I haven't read that in any of my references yet, so thank you Roboguy and CM for the clarification. This is starting to make more sense.
Please, please just use std::string. It's std for a reason. :)
Zahlman, as I stated a few posts above, I know people are opinionated, but I would LIKE to LEARN how to use them both. I asked a specific question on char's and the best way to fix the issue. Not on why I should or should not use the string class. I have read plenty of posts where people state how "evil" and "bad" using a char is. I understand all the pro's of using strings, and that they are probably a lot more easier. But just skipping char and going onto string is not what I would like to do. However, this issue has been resolved, and I understand what I was doing wrong and how to fix the problem.

Thank you to the people who stayed on subject to help me out.
Quote:Original post by Roboguy
Quote:Original post by GetWindowRect
Roboguy:
I know a char* is a type of reference, but I am not using that, I am using char [256] not char*.


Arrays are pointers.


No. Arrays are NOT pointers.

relient
Hey,

Yeah, as has been said, the object will probably cease to exist when you call another function or declare any more locals in your parent function.

However, a dodge hack can ensure that your code works nicely, but you only get one context of it [so something like strcmp(retFunc(),retFunc()) or storing these will give you no end of headaches]. I'd personally only use this if the alternative is very complicated (ie you need to use some funky arithmetic on arbitrary letters or something), but it'll make your return work, be legal and generally let you get onto the next thing.

Just make it static:
static char Text[256];

then your return won't be deleted, and you'll be able to access it externally.

Of course, to your original question, this is not 'the best way', std::strings probably are, or even returning a char* that you free in the caller once it's been used.

--CJM
Quote:Original post by xllx_relient_xllx
Quote:Original post by Roboguy
Quote:Original post by GetWindowRect
Roboguy:
I know a char* is a type of reference, but I am not using that, I am using char [256] not char*.


Arrays are pointers.


No. Arrays are NOT pointers.

relient


They may allocate the memory differently, but the resulting variable is still a pointer (you can dereference it, preform pointer arithmetic, etc).
Quote:Original post by Roboguy
They may allocate the memory differently, but the resulting variable is still a pointer (you can dereference it, preform pointer arithmetic, etc).


Nope. An array has an implicit decay to a pointer type, but that is an rvalue conversion. For example, try passing a char array to a function that takes a char * &.

This topic is closed to new replies.

Advertisement