Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Assuming that the code in your function is of the form:</p> <pre><code>std::string data = ...; //do some processing. return data; </code></pre> <p>Then this is required to call <code>std::string</code>'s move constructor if elision is not available. So worst-case, you get to move from your internal string.</p> <p>If you can't afford the cost of a move operation, then you'll have to pass it as a reference.</p> <p>That being said... do you worry about compilers not being able to inline short functions? Are you concerned about whether or not small wrappers won't be properly optimized away? Does the possibility of the compiler not optimizing <code>for</code> loops and the like bother you? Do you think about whether <code>if(x &lt; y)</code> is faster than <code>if(x - y &lt; 0)</code>?</p> <p>If not... then why do you care about copy/move elision (the technical term for "return value optimization", as it's used in more places than that)? If you are using a compiler that can't support copy elision, then you're using a horrible compiler that probably can't support a ton of other optimizations. For performance sake, you'd be better off spending your time upgrading your compiler than turning return values into references.</p> <blockquote> <p>preventing the improbable case of a copy actually happening is not worth the ... hassle? less readable code? what exactly? what is the extra thing that weights on the side of simple return?</p> </blockquote> <p>The "extra thing" is that this:</p> <pre><code>std::string aString = to_string(a); </code></pre> <p>Is more readable than this:</p> <pre><code>std::string aString; to_string(a, aString); </code></pre> <p>In the first case, it is <em>immediately</em> apparent that <code>to_string</code> is initializing a string. In the second, it isn't; you have to look up <code>to_string</code>'s signature to see that it's taking a <em>non-<code>const</code></em> reference.</p> <p>The first case is not even "idiomatic"; that's how everyone would normally write it. You would never see a <code>to_int(a, someInt)</code> call for integers; that's ridiculous. Why should integer creation and object creation be so different? You shouldn't <em>have to care</em> as a programmer whether too many copies are happening for a return value or something. You just do things the simple, obvious, and well-understood way.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload