#### Archived

This topic is now archived and is closed to further replies.

# Returning classes and structs

This topic is 5797 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I know this is a newbie-ish question, but I just want to make sure I have this right to avoid any hard-to-track bugs. Lets say one has the following situation:
class MyClass {

public:
int data;
MyClass () : data (5) {}
~MyClass () {}

};

MyClass getClass (){

MyClass temp;
temp.data = 123;
return temp;

}

The focus of this example is the function
getClass()
. Is that ok? It seems to me I heard somewhere that temp''s destructor would be called and the class would go out of scope after the function ends. That is obvious. But the function returns a copy of temp, so the caller would have a viable copy of the class, correct?
// in some function somewhere
MyClass c = getClass ();
// use ''c'' somewhere

The above should be ok. Is this the same with structs as well as classes? I don''t see why there would be much of a difference. I know that returning the entire class is slow because all of it''s members have to be copied over to the returning variable, but if the class is simplistic, it shouldn''t be much of an issue. Also, if the class has any special members (like pointers to other classes) that are deleted during the class'' destructor, that would cause a problem, too, right? Thanks for the clarification.

##### Share on other sites
Yes, temp does get destroyed, and yes, this is okay.

Just before temp gets destroyed, the c= part of the expression is executed. This invokes MyClass'' assignment operator. So while temp is destroyed, c lives on as an identical copy.

Where this becomes important is when resource acquisition/freeing is nontrivial. If you delete dynamically allocated memory in your destructor, the returned class will have a pointer to freed memory, but expect it to be valid. This, obviously, is problematic. The solution is to implement the assignment operator and copy constructor for your class, which allocates new memory on the target... that''s called "deep-copy".

In general, avoid returning a struct/class. It''s inefficient. Return a pointer/reference where it makes sense, or pass in a mutable reference to an object to fill.

Don''t listen to me. I''ve had too much coffee.

##### Share on other sites
quote:
Original post by Sneftel
In general, avoid returning a struct/class. It''s inefficient. Return a pointer/reference where it makes sense, or pass in a mutable reference to an object to fill.

I agree with this, but there are times where returning a struct/class directly can be advantageous (usually only when the class is simplistic). Thanks for the reply.

What do you mean "Return a reference"? Wouldn''t the reference be to the local stack that is destroyed at the end of the function?

##### Share on other sites
Yes, it would. Returning a reference is technically unsafe, but can be made workable if the lifetime of the returned object is well-defined.

For instance, my AnimLoop class has a function GetCurrentFrame() which returns a reference to a Frame. The Frame is owned by the AnimLoop, not by the function that calls GetCurrentFrame, and it would be a logic error for the calling function to retain the reference for a significant period of time. But since the object is not destroyed at the end of GetCurrentFrame(), it works.

Don''t listen to me. I''ve had too much coffee.

1. 1
2. 2
Rutin
20
3. 3
4. 4
frob
15
5. 5

• 10
• 9
• 14
• 9
• 33
• ### Forum Statistics

• Total Topics
632592
• Total Posts
3007295

×