🔒 Locked

Returning classes and structs

Started by spiffgq Nov 7, 2002 at 1:28 PM 2 replies 200+ views

Original Post

Nov 7, 2002 at 1:28 PM

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.

Sneftel

Nov 7, 2002 at 1:51 PM

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.

spiffgq

Nov 7, 2002 at 2:43 PM

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?

Sneftel

Nov 7, 2002 at 6:21 PM

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.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.