How to maintain and return local object reference?

Hi guys,
i'd like to return a locally defined object from a function by referece, but i'm even not sure if this is possible. If it is, please help, otherwise, i'll return it by value, as happened in the example below.
Thanks,
Ben

Code:

---

class the_class{
.
.
.
};

the_function(){
the_class the_object();
.
.
.
return the_object;
}

---

Don't return references to local objects because they go out of scope and are destructed when the function exits.

It may be legal if the object was static.

It's not possible.
Allocate on heap or return by value.
I don't recommend doing static either. That's for special purposes and usually such variables are not meant to be returned.

But what will you have a reference to, when the object has gone out of scope?

Edit:
Wow, people were all over this question like a cheap suit ;)

Ok,
thanks, this is what i thought, also it would be nice if it was possible to maintain the memory for better performance.
Ben

Don't bother. Thanks to NRVO, the compiler does that for you.

It's possible. Allocate memory on heap.

Ok, thanks, i'll do that :)

Why messing with heap allocation? He can just adjust the lifetime of his object as needed:

Code:

---

void the_function(the_class the_object& obj)
{
  obj.manipulate();
}

int main()
{
  the_class the_object obj;
  the_function(obj);
}

---

This is fast (no return by value / no heap allocation) and clear.

Yes, you can. But the only way to return a local object is to allocate it on the heap.
Whether this is feasible or a good idea is an entirely different matter.

Quote:

---

Originally Posted by Elysia

Yes, you can. But the only way to return a local object is to allocate it on the heap.
Whether this is feasible or a good idea is an entirely different matter.

---

Well, that applies if you want to have a reference to something from inside another function. The other possibility is to NOT MAKE IT A REFERENCE - just make a copy as you return the object. That is a perfectly valid solution, as long as the object is copyable (and safe to copy - but if it's not safe to copy, then it should be made uncopyable).

--
Mats

Note what I said earlier. NRVO stands for named return value optimization. It means that in this situation:

Code:

---

someclass foo();

int main()
{
  someclass sc = foo();
}

---

... the compiler is allowed to completely omit the copying. Since the implementation of returning large object always means that the calling function allocates space for the temporary and passes a pointer - in other words, the return value is turned into a hidden reference parameter - NRVO says that the compiler may actually pass a reference to the object the temporary is then assigned to. For this optimization, it is even allowed to assume that the object's copy constructor has no side effects! (Even when it can't see the body.)

So allocating on the heap is a horrible pessimization, and passing an out parameter by reference does exactly the same on the binary level, but with a less convenient interface.

Is this NRVO specified in the standard and/or do the most c++ compilers utilize it?

if yes, one can say: returning by value does never impact performance compared to returning by reference/pointer independent from the size of the returned object?
what would be new to me. and it would explain, why I was never able to see any performance boost while changing fuction signatures from return by value to call by non-const reference.

Thanks

It is explicitly specified in the standard as an option (because it changes observable behaviour when the copy constructor has side effects), but not as a requirement. Also, it can only be applied when the return value is assigned to a newly constructed object. (I think.)

Pretty much every compiler in the latest generation supports NRVO. GCC supports it since 3.2 or something, VC++ for quite some time, as does Intel C++. Some more exotic ones also mostly support it.

Hello Guys.
Sorry for not answering for quite a while, due to some problems related to my internet connection, and great thanks for all answers,
Ben