Function out of scope
-
hrishiS wrote:
the problem I could notice is that, ret is a automatic variable , so it is no longer available once it comes out from the function ToStr().
A copy of the object will be returned, so no there's no problem there.
hrishiS wrote:
Either you can have it as global variable, or make a variable of pointer/reference of String , inside fun and pass it to ToStr
- global variable for that is really ugly (but that's my personal taste) 2) variable of type pointer: not really nice neither because each time you will create the object on the stack and furthermore, you delegate the destruction of the pointer to somewhere else, which potentially introduce memory leaks. 3) return a reference to the object: that's wrong. In this case, the object will be destroyed, no copy will be made and you will return the address of the destroyed object which is wrong. So in conclusion, returning the object as he mentioned is the best option. I could agree with superman in the sense that his proposed solution is more efficient: no temporary object gets created but honestly, it doesn't make a lot of difference (unless your code is in a part of the code which should be highly optimized).
Cédric Moonen Software developer
Charting control [v2.0] OpenGL game tutorial in C++ -
There's no problem with your code. The problem appears when you return something like this:
char* ToStr()
{
return "test";
}In which case you return the address of a temporary variable. If you return an object, the compiler will make a copy of it and assign it to val correctly. EDIT: changed the return type to char* instead of CString.
Cédric Moonen Software developer
Charting control [v2.0] OpenGL game tutorial in C++modified on Tuesday, September 8, 2009 9:54 AM
You sure about that Cedric? I think you'll find that "test" is used to construct a CString object that's returned by copy...that's what happened when I compiled and debugged it, anyway :-)
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Hi, In the below code ret value become invalid as it comes out of the funcation scope. can any suggest better idea to solve this. CString ToStr() { CString ret = "test"; return ret; } void fun() { CString val = ToStr(); // it returns nothing (bad pointer) } I have compiled this code in MS VC++2005 under winxp OS. Thanks, Nandu
If CString is the standard ATL/MFC string class, then there is nothing wrong with the code you've posted -
retwill effectively be copied intovalwhen the return statement is executed. Part of the implied contract of ToStr is that callers will pass the address of a CString object into which the return value can be copied.Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
You sure about that Cedric? I think you'll find that "test" is used to construct a CString object that's returned by copy...that's what happened when I compiled and debugged it, anyway :-)
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Ooops, sorry,I forgot to change the return type to
char*:-O If the return type is CString, then I agree with you, there's no problem neither. Thanks for pointing it out.Cédric Moonen Software developer
Charting control [v2.0] OpenGL game tutorial in C++ -
There's no problem with your code. The problem appears when you return something like this:
char* ToStr()
{
return "test";
}In which case you return the address of a temporary variable. If you return an object, the compiler will make a copy of it and assign it to val correctly. EDIT: changed the return type to char* instead of CString.
Cédric Moonen Software developer
Charting control [v2.0] OpenGL game tutorial in C++modified on Tuesday, September 8, 2009 9:54 AM
I don't find any issues with your code. You are returning by value and not returning any reference to the temporary. So I guess your code is perfectly valid.
Cedric Moonen wrote:
If you return an object, the compiler will make a copy of it and assign it to val correctly.
Even if you return by value, with return value optimization, a copy won't be made. Please correct me if I am wrong here. [edit]Saw your post updated[/edit] :)
Navaneeth How to use google | Ask smart questions
-
If CString is the standard ATL/MFC string class, then there is nothing wrong with the code you've posted -
retwill effectively be copied intovalwhen the return statement is executed. Part of the implied contract of ToStr is that callers will pass the address of a CString object into which the return value can be copied.Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Stuart Dootson wrote:
Part of the implied contract of ToStr is that callers will pass the address of a CString object
Not exactly - the original post shows:
CString ToStr()
{
CString ret = "test";
return ret;
}void fun()
{
CString val = ToStr(); // it returns nothing (bad pointer)
}The contract here is that
ToStr()will return a CString object, which the caller may store or destroy as he/she wishes. The code as written always returns a valid CString object so I don't see how it can fail. However functionfun()does nothing with its CString val so that may be where the original problem occurred. -
There's no problem with your code. The problem appears when you return something like this:
char* ToStr()
{
return "test";
}In which case you return the address of a temporary variable. If you return an object, the compiler will make a copy of it and assign it to val correctly. EDIT: changed the return type to char* instead of CString.
Cédric Moonen Software developer
Charting control [v2.0] OpenGL game tutorial in C++modified on Tuesday, September 8, 2009 9:54 AM
Your example isn't be a problem since "test" is in the data segment and isn't going to change location. I would recommend returning a
const char *, but that code is perfectly fine. What isn't fine is the following:char* ToStr()
{
char buffer[5];
lstrcpy(buffer, "test");
return buffer;
} -
Stuart Dootson wrote:
Part of the implied contract of ToStr is that callers will pass the address of a CString object
Not exactly - the original post shows:
CString ToStr()
{
CString ret = "test";
return ret;
}void fun()
{
CString val = ToStr(); // it returns nothing (bad pointer)
}The contract here is that
ToStr()will return a CString object, which the caller may store or destroy as he/she wishes. The code as written always returns a valid CString object so I don't see how it can fail. However functionfun()does nothing with its CString val so that may be where the original problem occurred.Note the use of the word 'implied' :-) An object (of struct/class type) gets returned from a function in C/C++ by the caller making space for it and the return statement in the function copying the actual value returned (ret in this case) into this space, constructing a temporary, unnamed object. This temporary object is then used in the callers context (in this case, it gets assigned to val). A compiler is permitted to optimise away this temporary object when suitable, by giving the function a reference to the final destination (in this case val) rather than the temporary object.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Note the use of the word 'implied' :-) An object (of struct/class type) gets returned from a function in C/C++ by the caller making space for it and the return statement in the function copying the actual value returned (ret in this case) into this space, constructing a temporary, unnamed object. This temporary object is then used in the callers context (in this case, it gets assigned to val). A compiler is permitted to optimise away this temporary object when suitable, by giving the function a reference to the final destination (in this case val) rather than the temporary object.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Note the use of the word 'implied' :-) An object (of struct/class type) gets returned from a function in C/C++ by the caller making space for it and the return statement in the function copying the actual value returned (ret in this case) into this space, constructing a temporary, unnamed object. This temporary object is then used in the callers context (in this case, it gets assigned to val). A compiler is permitted to optimise away this temporary object when suitable, by giving the function a reference to the final destination (in this case val) rather than the temporary object.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p