pros and cons of returning const ref to string instead of string by value
in [C++]
|
Prev: Templated return value "is being used without being initialized"
Next: pros and cons of returning const ref to string instead of string by value
From: John H. on 2 Dec 2009 04:58 On Dec 2, 7:06 am, Andrew <marlow.and...(a)googlemail.com> wrote: > When I write a method that returns a string I always return the string > by value. This is as opposed to returning a const reference to the > string held as a private data member in the object. Doing it my way > means that when the object goes out of scope, my string is still > valid. I agree, this is a good thing about pass by value. > Can anyone think of any other reasons to prefer returning a string by > value. I am encountering some opposition to this, mainly in the name > of performance. The performance has not been measured (of course) but > this is often the case with 'performance' arguments. Unfortunately, > "show me the figures" cuts no ice. Yes the performance for pass-by-reference is probably better, but you are also right to question if that is important in this particular application. One advantage that passing it out by reference has is that the caller can assign that value to either a string variable or a reference to a string. The former gives you behavior as if you had returned the variable by value, because the text of the referenced string will be copied into the variable. The latter has the characteristic that if the private member variable changes, the caller's reference will be aware of the change, which may or may not be what your you want. e.g.: #include <string> class String { public: std::string getStrVal() const { return str; } std::string const & getStrRef() const { return str; } void setStr(std::string const & new_str) { str = new_str; } private: std::string str; }; int main() { String * hi = new String; hi->setStr(std::string("hi")); std::string str1 = hi->getStrVal(); std::string str2 = hi->getStrRef(); std::string const & str3 = hi->getStrRef(); hi->setStr(std::string("hello")); // str1 and str2 still say "hi" while str3 will say "hello" delete hi; // str1 and str2 still say "hi" while str3 is invalid return 0; } -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: A. McKenney on 2 Dec 2009 04:59 On Dec 2, 8:06 am, Andrew <marlow.and...(a)googlemail.com> wrote: > When I write a method that returns a string I always return the string > by value. This is as opposed to returning a const reference to the > string held as a private data member in the object. Doing it my way > means that when the object goes out of scope, my string is still > valid. Doing it the other way means you HAVE to keep the object around > for as long as you have a reference to the string. > > Can anyone think of any other reasons to prefer returning a string by > value? Warning: I'm not entirely on your side. The main reason to return a value (as opposed to a reference to a value) is, as you say, to avoid having to worry about whether the value you are referring to will go away or be changed before you are done using it. The main reason to return a reference (n.b.: a pointer is a kind of reference) is efficiency. In my experience (based on profiling), the cost of copying std::string values can be pretty high. However, if you return a reference (e.g., std::string & or const char *), you do have to make sure the underlying object doesn't change. In many cases, it's a no-brainer -- for example, if are just returning a value that's already in a container that is never modified after program start-up. On the other hand, returning by reference might not give you _any_ increase in efficiency. If the value you want to return is the result of some calculation, the cost of managing the storage space inside your object so you can return a reference to it may be higher than the cost of copying the value. Keeping in mind that if the compiler can use RVO, returning by value might not be any more expensive than returning a reference. Another approach if you have reason to worry about the inefficiency of copying std::string is to "roll your own" replacement for std::string that has the features you need and is cheaper to copy; e.g., a struct containing a char array, if that works in your application. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Philip on 2 Dec 2009 04:55 Here is a good article on the subject: http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/ Basically, the argument for passing/returning by value is performance! -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Michael Aaron Safyan on 2 Dec 2009 05:01 Reporting a string by reference may give a slight speedup; however, this would be a terrible practice in a multi-threaded environment, where the underlying string might be modified before the thread that has requested it has had the opportunity to use it. Additionally, the rvalue references in the upcoming C++ standard will reduce the amount of waste/overhead when copying (it will copy only once instead of twice). Given that the trend is towards multithreading and that returning a const reference is a premature optimization and very likely to hamper multithreading, it is better to return a value. On Dec 2, 7:06 am, Andrew <marlow.and...(a)googlemail.com> wrote: > When I write a method that returns a string I always return the string > by value. This is as opposed to returning a const reference to the > string held as a private data member in the object. Doing it my way > means that when the object goes out of scope, my string is still > valid. Doing it the other way means you HAVE to keep the object around > for as long as you have a reference to the string. > > Can anyone think of any other reasons to prefer returning a string by > value. I am encountering some opposition to this, mainly in the name > of performance. The performance has not been measured (of course) but > this is often the case with 'performance' arguments. Unfortunately, > "show me the figures" cuts no ice. > > Regards, > > Andrew Marlow -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Zachary Turner on 2 Dec 2009 05:00
On Dec 2, 7:06 am, Andrew <marlow.and...(a)googlemail.com> wrote: > When I write a method that returns a string I always return the string > by value. This is as opposed to returning a const reference to the > string held as a private data member in the object. Doing it my way > means that when the object goes out of scope, my string is still > valid. Doing it the other way means you HAVE to keep the object around > for as long as you have a reference to the string. > > Can anyone think of any other reasons to prefer returning a string by > value. I am encountering some opposition to this, mainly in the name > of performance. The performance has not been measured (of course) but > this is often the case with 'performance' arguments. Unfortunately, > "show me the figures" cuts no ice. > > Regards, > > Andrew Marlow Just because you're returning by const reference doesn't mean you have to assign it *to* a const reference. You can just as easily write std::string blah = foo.get_string(); even if get_string() returns a const reference, and it will still make a copy. On the other hand, returning by const reference gives you the ability to NOT make a copy if that is what's desired. So it opens up new possibilities, while not sacrificing any functionality. Maybe I'm overlooking something, but I see little reason to return by value. What matters is whether you assign it to a const reference or to a value. Zach -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |