pros and cons of returning const ref to string instead of string by value [C++]

Prev: pros and cons of returning const ref to string instead of string by value
Next: pros and cons of returning const ref to string instead of string by value

From: Martin B. on 2 Dec 2009 04:56

Andrew 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.
>

As for performance: As a recent thread of mine ('inlining of functions
returning an unwindable object') has shown the somewhat popular Visual
Studio compiler will refuse to inline even a simple getter function if
it returns-std::string-by-value. But that's no prove for any performance
concern yet, because if you're doing something with "strings" and
performance is important, chances are that std::string is the wrong
class anyway.

I think the argument that holding a const reference to *any* class
internals is quite a bad idea should really be sufficient, because not
only do you run the risk of UB -- you also have the problem that
although you hold a const-ref the class member may well mutate in the
meantime and I don't trust no code holding a const reference to be
prepared for that const-ref mutating.

Safety first. :-)

br,
Martin

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Stuart Golodetz on 2 Dec 2009 04:58

Andrew 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.

This is slightly misleading IMHO. Consider:

struct X
{
std::string m_s;

const std::string& s() const
{
return m_s;
}
};

.....

X x;
const std::string& r = x.s(); // affected by subsequent x destruction
std::string s = x.s(); // not affected by subsequent x destruction

It's not the return type of the function which affects this per se. I'm
not sure this is a reason to prefer return 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 - if you return by value, you can return a string you constructed on
the fly. This can be an important consideration when you're designing an
interface - other people's subclasses may not want to have to store a
string to return here.

FWIW, I'm not sure the performance either way is going to make a huge
difference with just a string. That being said, I generally do return by
const reference with things like this unless I can see a good reason to
do otherwise. Purely on the basis that I might be able to avoid a copy
here or there - it almost certainly won't affect performance in a
significant way, but aside from the interface issue I mentioned, there
aren't all that many downsides I've encountered. YMMV.

Regards,
Stu

> Regards,
>
> Andrew Marlow

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Francis Glassborow on 2 Dec 2009 04:56

From: Johannes Schaub (litb) on 8 Dec 2009 08:55

Francis Glassborow wrote:

> Andrew 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
>>
>
> ..Certainly where performance is an issue, repeated copying of strings
> can cause a measurable loss in performance. However where the library
> uses the small string optimisation (no use of the heap) the loss is
> pretty small. And where you have an implementation that uses move
> semantics I would certainly default to using return by value and only
> move to return by reference where measurement showed a performance gain
> that was critical to the program (and with move semantics think that
> would be pretty uncommon)
>

That sounds like a bad advice to me. As others pointed out, returning by
reference to const is not bad and does not open any "worm-holes". I would
and i do that by default. And only if it matters, i would return by value
(see the ScopeGuard idiom).

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

|
Pages: 1
Prev: pros and cons of returning const ref to string instead of string by value
Next: pros and cons of returning const ref to string instead of string by value