Difference between returning object and returning reference to an object
Hi,
I am a bit confused about the following decleration:
what is the difference between:
TraceInfo Tracer::GetTracingInfo(const Pos& Pos) const
&
const TraceInfo& Tracer::GetTracingInfo(const Pos& Pos)
what does it mean by returning an object and returning a reference to an object. how can i handle this in my code when i call GetTracingInfo?
Thanks
The first example returns a copy of the object, while the second one provides read-only access to the original object, thus avoiding the cost of copying.
which one is the best way? and could you please give me an example of how to use it in the code?
if i do like below:
what is the difference in using like below:
const TraceInfo &trinfo = bobj.GetTracingInfo(pos);
&
TraceInfo trinfo = bobj.GetTracingInfo(pos):
which one is effective?
You can copy the returned reference to an object.
You should return by reference only if the returned object is not local to the function, otherwise is just like passing by reference
You should return by reference only if the returned object is not local to the function, otherwise is just like passing by reference
I don't get the point. will it make any difference if a method is returning an object and i recieve it in a reference?
TraceInfo Tracer::GetTracingInfo(const Pos& Pos) const
{
Tracer tracerobj;
return tracerobj;
}
main()
{
const TraceInfo &trinfo = bobj.GetTracingInfo(pos);
trinfo.xyz();
}
If the method is returning a copy of the object, you cannot receive it into a reference; the compiler should give
you an error about a reference to a temporary. (ie, your code above should not compile).
While what Bazzy said is very true, there are more things to consider. When a method returns a reference to
one of it's internal data members, that method is effectively exposing an implementation detail of the object itself
in the sense that if ever you want to change the type of the data member, you will also have to change the API
to the object -- you'll have to change the return type of the function. If you return just a copy, you could change
the implementation of the method to convert the new type to the old one and return a copy, thus leaving the API
unchanged. You could then write a second accessor method that returns the new type.
you an error about a reference to a temporary. (ie, your code above should not compile).
While what Bazzy said is very true, there are more things to consider. When a method returns a reference to
one of it's internal data members, that method is effectively exposing an implementation detail of the object itself
in the sense that if ever you want to change the type of the data member, you will also have to change the API
to the object -- you'll have to change the return type of the function. If you return just a copy, you could change
the implementation of the method to convert the new type to the old one and return a copy, thus leaving the API
unchanged. You could then write a second accessor method that returns the new type.
with the above syntax my code compiles perfectly as i am just taking the the copy in to a reference.
any ideas on this? I want to know the efficient way of handling it. should i take it into a object or should i take it into a pointer?
So which one to use roughly depends on a trade-off between efficiency (return by const&) and encapsulation (return by value).
If I have a large/complex object, I will prefer returning const& for efficiency purposes. There is, however, a third option in this case: delegation. Instead of returning a const& of that big object, I can write methods like int getTracerAttribute() { return m_tracerInfo.getAttribute(); } and hide the fact that I'm holding on to a Tracer instance called m_tracerInfo. The advantage of delegation is, you get encapsulation of the Tracer object. The disadvantage is, if you need to access a lot of methods in the Tracer object, you get code bloat. As noted, if you want to return by const&, you must ensure that the returned reference will actually point to some valid memory (eg not an automatic variable inside the method).
For small objects like std::string, you may want to return by value. The ugly thing about return by value is, you may have to pay for an extra copy-construction upon return. But there is a trick. Read this:
http://www.informit.com/articles/article.aspx?p=25033&seqNum=3
If you call the constructor at return, many compilers will optimize away that extra copy-construction.
So what is better really depends on the context of what you're trying to accomplish. One of the advantages of (and difficulties of learning) C++ is having the choice to pick the implementation most appropriate for what you are trying to accomplish.
If I have a large/complex object, I will prefer returning const& for efficiency purposes. There is, however, a third option in this case: delegation. Instead of returning a const& of that big object, I can write methods like int getTracerAttribute() { return m_tracerInfo.getAttribute(); } and hide the fact that I'm holding on to a Tracer instance called m_tracerInfo. The advantage of delegation is, you get encapsulation of the Tracer object. The disadvantage is, if you need to access a lot of methods in the Tracer object, you get code bloat. As noted, if you want to return by const&, you must ensure that the returned reference will actually point to some valid memory (eg not an automatic variable inside the method).
For small objects like std::string, you may want to return by value. The ugly thing about return by value is, you may have to pay for an extra copy-construction upon return. But there is a trick. Read this:
http://www.informit.com/articles/article.aspx?p=25033&seqNum=3
If you call the constructor at return, many compilers will optimize away that extra copy-construction.
So what is better really depends on the context of what you're trying to accomplish. One of the advantages of (and difficulties of learning) C++ is having the choice to pick the implementation most appropriate for what you are trying to accomplish.
Topic archived. No new replies allowed.