views:

62

answers:

4

I can write a function this way in objective C. This can be used to churn out many UIButtons.

+(UIButton*)getButton:(CGRect)frame{


UIButton *button=[UIButton buttonWithType:UIButtonTypeRoundedRect];

[button setTitle:@"Some title" forState:UIControlStateNormal];

button.frame=frame;

return button;
}

Can the same be done in C++. I am not asking about creation of UIButton in C++.

But churning out many objects with a help of a function as this:

 CString getCstring(some parameters)
{

    CString string = L"Hi sampe string.";
    return string;

 }

I think that the CString object that is created in this function would be in stack and may lose it value once goes out of this function.

In case of Objective C code, we can retain the autoreleased object to use it. Is there any such mechanism available in C++?

+2  A: 

In C++ you can do

CString* getCString(some parameters)
{

    CString* string = new CString(L"Hi sample string.");
    return string;

 }

and delete (by calling delete on the pointer) the string in the caller after he is done with it if you want to have the string on the heap. However in the first version you posted, I see no problem. It is a stack variable, but of course it is still valid in the caller as it is the return value.

fschmitt
Thanks. What is the difference between the version that I have posted and the once you have posted?
Krishnan
Well, this is a bit hard to explain in 600 characters. Basically variables constructed with new live until explicitly killed by calling delete on it and you don't work with the variables themselves but pointers on it. Have a look here: http://www.learncpp.com/cpp-tutorial/79-the-stack-and-the-heap/
fschmitt
Don't forget, in this version, you'll need to `delete` the instance afterwards. In the OP (which works fine!) you don't, since it's all on the stack.
Chris Burt-Brown
Thanks fschmit and Chris.
Krishnan
+3  A: 

I think that the CString object that is created in this function would be in stack and may lose it value once goes out of this function.

It doesn’t lose its value since it will be copied (although the compiler can elide the copy as an optimization).

So don’t worry – this works just fine in C++.

You can also return a pointer to dynamically allocated memory but this makes usage harder since the client has to free the memory explicitly. In general this is not a good solution – handling raw pointers to dynamic memory is the #1 reason for memory leaks and cleaning such code up is horrible.

A better way is to use smart pointers (e.g. shared_ptr or unique_ptr) that take care of the memory management themselves.

Konrad Rudolph
+1  A: 

Your string variable will eventually go out of scope, but return string; will return only the copy and hence you can use it in C++ as such now...

liaK
A: 

Your Obj-C code works against coding styles and memory management rules. It should look like:

+(UIButton*)buttonWithFrame:(CGRect)aRect {
  UIButton *button=[UIButton buttonWithType:UIButtonTypeRoundedRect];
  [button setTitle:@"Some title" forState:UIControlStateNormal];
  button.frame = aRect;
  return button;
}

Seems like minor changes, but it makes memory managament (object ownership) obvious and names the parameter appropriately.

Eiko
Thanks Eiko for the suggestion.
Krishnan