blocks|key|2174752|text|std::string不是Plain+Old+Data(POD)，它的原始大小也不是最重要的东西。例如，如果传入的字符串长度大于SSO的长度并分配到堆上，我希望复制构造函数不会复制SSO存储。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2174753|建议这样做的原因是因为inval是从参数表达式构造的，因此总是根据需要移动或复制-假设您需要参数的所有权，则不会造成性能损失。如果您不这样做，const引用可能仍然是更好的方法。|2174754|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/146452/what-are-pod-types-in-c^0|0|B|D|J|0|0|B|5|1Z|5|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@$9|S|A|T|1|U]]|E|$]]|$1|F|3|G|5|6|7|V|8|@$9|W|A|X|B|C]|$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

<code>std::string</code> is not <a href="https://stackoverflow.com/questions/146452/what-are-pod-types-in-c">Plain Old Data(POD)</a>, and its raw size is not the most relevant thing ever. For example, if you pass in a string which is above the length of SSO and allocated on the heap, I would expect the copy constructor to not copy the SSO storage.

The reason this is recommended is because <code>inval</code> is constructed from the argument expression, and thus is always moved or copied as appropriate- there is no performance loss, assuming that you need ownership of the argument. If you don't, a <code>const</code> reference could still be the better way to go.

blocks|key|1854179|text|除非您确实需要一个副本，否则使用const+&仍然是合理的。例如：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1854180|bool+isprint(std::string+const+&s)+{
++++return+all_of(begin(s),end(s),(bool(*)(char))isprint);
}|code-block|syntax|javascript|1854181|如果您将其更改为按值获取字符串，那么您将最终移动或复制参数，而不需要这样做。复制/移动不仅可能更昂贵，而且还会引入新的潜在故障；复制/移动可能会抛出异常(例如，复制期间的分配可能会失败)，而引用现有值则不会。|1854182|如果您确实需要一个副本，那么通过值传递和返回通常是(总是？)最好的选择。事实上，在C%2B%2B03中我通常不会担心这个问题，除非你发现额外的副本实际上会导致性能问题。在现代编译器上，复制省略似乎相当可靠。我认为人们的怀疑和坚持你必须检查你的编译器对RVO的支持表现在已经过时了。|1854183|1854184|简而言之，C%2B%2B11在这方面并没有真正改变任何东西，除了那些不信任复制省略的人。|1854185|entityMap^0|G|7|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|W|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|X|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|Y|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|10|8|@]|D|@]|E|$]]|$1|R|3|-4|5|6|7|11|8|@]|D|@]|E|$]]]|S|$]]

Unless you actually need a copy it's still reasonable to take <code>const &amp;</code>. For example:

<pre><code>bool isprint(std::string const &amp;s) {
 return all_of(begin(s),end(s),(bool(*)(char))isprint);
}
</code></pre>

If you change this to take the string by value then you'll end up moving or copying the parameter, and there's no need for that. Not only is copy/move likely more expensive, but it also introduces a new potential failure; the copy/move could throw an exception (e.g., allocation during copy could fail) whereas taking a reference to an existing value can't.

If you do need a copy then passing and returning by value is usually (always?) the best option. In fact I generally wouldn't worry about it in C++03 unless you find that extra copies actually causes a performance problem. Copy elision seems pretty reliable on modern compilers. I think people's skepticism and insistence that you have to check your table of compiler support for RVO is mostly obsolete nowadays.

<hr>

In short, C++11 doesn't really change anything in this regard except for people that didn't trust copy elision.

blocks|key|211728|text|这在很大程度上取决于编译器的实现。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|211729|但是，这也取决于您使用的是什么。|211730|让我们考虑下一个函数：|211731|bool+foo1(+const+std::string+v+)
{
++return+v.empty();
}
bool+foo2(+const+std::string+&+v+)
{
++return+v.empty();
}|code-block|syntax|javascript|211732|这些函数在单独的编译单元中实现，以避免内联。然后：|211733|211734|如果您将文字传递给这两个函数，您将不会看到性能上的太大差异。在这两种情况下，都必须为|ordered-list-item|211735|创建string对象。如果传递另一个std::string对象，foo2的性能将优于foo1，因为foo1将执行深度复制。|offset|length|style|CODE|211736|211737|在我的PC上，使用g%2B%2B+4.6.1，我得到了以下结果：|211738|211739|variable+by+reference:+1000000000+iterations+->+time+elapsed:+2.25912秒|unordered-list-item|211740|variable+by+value:+1000000000+iterations+->+time+elapsed:+27.2259秒|211741|literal+by+reference:+100000000+iterations+->+time+elapsed:+9.10319秒|211742|literal+value:+100000000+iterations+->+time+code:+8.62659秒|211743|<>F219|211744|entityMap^0|0|0|0|0|0|0|0|W|4|16|4|1D|4|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1E|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1F|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1G|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|1H|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|1J|8|@]|9|@]|A|$]]|$1|Q|3|R|5|P|7|1K|8|@$S|1L|T|1M|U|V]|$S|1N|T|1O|U|V]|$S|1P|T|1Q|U|V]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1S|8|@]|9|@]|A|$]]|$1|Z|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|10|3|11|5|12|7|1U|8|@]|9|@]|A|$]]|$1|13|3|14|5|12|7|1V|8|@]|9|@]|A|$]]|$1|15|3|16|5|12|7|1W|8|@]|9|@]|A|$]]|$1|17|3|18|5|12|7|1X|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]]|1C|$]]

This highly depends on the compiler's implementation.

However, it also depends on what you use.

Lets consider next functions : 

<pre><code>bool foo1( const std::string v )
{
 return v.empty();
}
bool foo2( const std::string &amp; v )
{
 return v.empty();
}
</code></pre>

These functions are implemented in a separate compilation unit in order to avoid inlining. Then : 
1. If you pass a literal to these two functions, you will not see much difference in performances. In both cases, a string object has to be created 
2. If you pass another std::string object, <code>foo2</code> will outperform <code>foo1</code>, because <code>foo1</code> will do a deep copy.

On my PC, using g++ 4.6.1, I got these results :

<ul>
<li>variable by reference: 1000000000 iterations -> time elapsed: 2.25912 sec</li>
<li>variable by value: 1000000000 iterations -> time elapsed: 27.2259 sec</li>
<li>literal by reference: 100000000 iterations -> time elapsed: 9.10319 sec</li>
<li>literal by value: 100000000 iterations -> time elapsed: 8.62659 sec</li>
</ul>

blocks|key|1854323|text|我已经在这里复制/粘贴了this+question的答案，并更改了名称和拼写以适合此问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1854324|下面是用来测量被询问内容的代码：|1854325|#include+<iostream>

struct+string
{
++++string()+{}
++++string(const+string&)+{std::cout+<<+"string(const+string&)\n";}
++++string&+operator=(const+string&)+{std::cout+<<+"string&+operator=(const+string&)\n";return+*this;}
#if+(__has_feature(cxx_rvalue_references))
++++string(string&&)+{std::cout+<<+"string(string&&)\n";}
++++string&+operator=(string&&)+{std::cout+<<+"string&+operator=(string&&)\n";return+*this;}
#endif

};

#if+PROCESS+==+1

string
do_something(string+inval)
{
++++//+do+stuff
++++return+inval;
}

#elif+PROCESS+==+2

string
do_something(const+string&+inval)
{
++++string+return_val+=+inval;
++++//+do+stuff
++++return+return_val;+
}

#if+(__has_feature(cxx_rvalue_references))

string
do_something(string&&+inval)
{
++++//+do+stuff
++++return+std::move(inval);
}

#endif

#endif

string+source()+{return+string();}

int+main()
{
++++std::cout+<<+"do_something+with+lvalue:\n\n";
++++string+x;
++++string+t+=+do_something(x);
#if+(__has_feature(cxx_rvalue_references))
++++std::cout+<<+"\ndo_something+with+xvalue:\n\n";
++++string+u+=+do_something(std::move(x));
#endif
++++std::cout+<<+"\ndo_something+with+prvalue:\n\n";
++++string+v+=+do_something(source());
}|code-block|syntax|javascript|1854326|对我来说，这是输出：|1854327|$+clang%2B%2B+-std=c%2B%2B11+-stdlib=libc%2B%2B+-DPROCESS=1+test.cpp
$+a.out
do_something+with+lvalue:

string(const+string&)
string(string&&)

do_something+with+xvalue:

string(string&&)
string(string&&)

do_something+with+prvalue:

string(string&&)
$+clang%2B%2B+-std=c%2B%2B11+-stdlib=libc%2B%2B+-DPROCESS=2+test.cpp
$+a.out
do_something+with+lvalue:

string(const+string&)

do_something+with+xvalue:

string(string&&)

do_something+with+prvalue:

string(string&&)|1854328|下表总结了我的结果(使用clang+-std=c%2B%2B11)。第一个数字是复制构造的数量，第二个数字是移动构造的数量：|1854329|%2B----%2B--------%2B--------%2B---------%2B
%7C++++%7C+lvalue+%7C+xvalue+%7C+prvalue+%7C
%2B----%2B--------%2B--------%2B---------%2B
%7C+p1+%7C++1/1+++%7C++0/2+++%7C+++0/1+++%7C
%2B----%2B--------%2B--------%2B---------%2B
%7C+p2+%7C++1/0+++%7C++0/1+++%7C+++0/1+++%7C
%2B----%2B--------%2B--------%2B---------%2B|1854330|按值传递解决方案只需要一个重载，但在传递左值和x值时需要额外的移动构造。对于任何给定的情况，这可能是可接受的，也可能是不可接受的。这两种解决方案各有优缺点。|1854331|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/q/9952622/576911^0|C|D|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@$A|13|B|14|1|15]]|C|$]]|$1|D|3|E|5|6|7|16|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|17|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|18|8|@]|9|@]|C|$]]|$1|M|3|N|5|H|7|19|8|@]|9|@]|C|$I|J]]|$1|O|3|P|5|6|7|1A|8|@]|9|@]|C|$]]|$1|Q|3|R|5|H|7|1B|8|@]|9|@]|C|$I|J]]|$1|S|3|T|5|6|7|1C|8|@]|9|@]|C|$]]|$1|U|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]]|V|$W|$5|X|Y|Z|C|$10|11]]]]

I've copy/pasted the answer from <a href="https://stackoverflow.com/q/9952622/576911">this question</a> here, and changed the names and spelling to fit this question.

Here is code to measure what is being asked:

<pre><code>#include &lt;iostream&gt;

struct string
{
 string() {}
 string(const string&amp;) {std::cout &lt;&lt; "string(const string&amp;)\n";}
 string&amp; operator=(const string&amp;) {std::cout &lt;&lt; "string&amp; operator=(const string&amp;)\n";return *this;}
#if (__has_feature(cxx_rvalue_references))
 string(string&amp;&amp;) {std::cout &lt;&lt; "string(string&amp;&amp;)\n";}
 string&amp; operator=(string&amp;&amp;) {std::cout &lt;&lt; "string&amp; operator=(string&amp;&amp;)\n";return *this;}
#endif

};

#if PROCESS == 1

string
do_something(string inval)
{
 // do stuff
 return inval;
}

#elif PROCESS == 2

string
do_something(const string&amp; inval)
{
 string return_val = inval;
 // do stuff
 return return_val; 
}

#if (__has_feature(cxx_rvalue_references))

string
do_something(string&amp;&amp; inval)
{
 // do stuff
 return std::move(inval);
}

#endif

#endif

string source() {return string();}

int main()
{
 std::cout &lt;&lt; "do_something with lvalue:\n\n";
 string x;
 string t = do_something(x);
#if (__has_feature(cxx_rvalue_references))
 std::cout &lt;&lt; "\ndo_something with xvalue:\n\n";
 string u = do_something(std::move(x));
#endif
 std::cout &lt;&lt; "\ndo_something with prvalue:\n\n";
 string v = do_something(source());
}
</code></pre>

For me this outputs:

<pre><code>$ clang++ -std=c++11 -stdlib=libc++ -DPROCESS=1 test.cpp
$ a.out
do_something with lvalue:

string(const string&amp;)
string(string&amp;&amp;)

do_something with xvalue:

string(string&amp;&amp;)
string(string&amp;&amp;)

do_something with prvalue:

string(string&amp;&amp;)
$ clang++ -std=c++11 -stdlib=libc++ -DPROCESS=2 test.cpp
$ a.out
do_something with lvalue:

string(const string&amp;)

do_something with xvalue:

string(string&amp;&amp;)

do_something with prvalue:

string(string&amp;&amp;)
</code></pre>

The table below summarizes my results (using clang -std=c++11). The first number is the number of copy constructions and the second number is the number of move constructions:

<pre><code>+----+--------+--------+---------+
| | lvalue | xvalue | prvalue |
+----+--------+--------+---------+
| p1 | 1/1 | 0/2 | 0/1 |
+----+--------+--------+---------+
| p2 | 1/0 | 0/1 | 0/1 |
+----+--------+--------+---------+
</code></pre>

The pass-by-value solution requires only one overload but costs an extra move construction when passing lvalues and xvalues. This may or may not be acceptable for any given situation. Both solutions have advantages and disadvantages.

blocks|key|1854373|text|赫伯说这些话的原因就是因为有这样的案例。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1854374|假设我有一个调用函数B的函数A，这个函数调用了函数C。A通过B传递一个字符串并进入C。A既不知道也不关心C；A只知道B。也就是说，C是B的一个实现细节。|offset|length|style|CODE|1854375|假设A的定义如下：|1854376|void+A()
{
++B("value");
}|code-block|syntax|javascript|1854377|如果B和C接受const&的字符串，那么它看起来像这样：|1854378|void+B(const+std::string+&str)
{
++C(str);
}

void+C(const+std::string+&str)
{
++//Do+something+with+`str`.+Does+not+store+it.
}|1854379|一切都很好。你只是在传递指针，没有复制，没有移动，每个人都很高兴。C接受const&，因为它不存储字符串。它只是简单地使用它。|1854380|现在，我想做一个简单的更改：C需要将字符串存储在某个地方。|1854381|void+C(const+std::string+&str)
{
++//Do+something+with+`str`.
++m_str+=+str;
}|1854382|你好，复制构造函数和潜在的内存分配(忽略Short+String+Optimization+(SSO))。C%2B%2B11的移动语义应该可以消除不必要的复制构造，对吧？并且A会传递一个临时的；C没有理由必须复制数据。它应该带着给它的东西潜逃。|1854383|除非它不能，因为它需要一个const&。|1854384|如果我将C更改为按值接受其参数，这只会导致B复制到该参数中；我什么也得不到。|1854385|因此，如果我只是在所有函数中按值传递str，依靠std::move处理数据，我们就不会有这个问题。如果有人想要保留它，他们可以。如果他们不这样做，哦，好吧。|1854386|是不是更贵？是的，进入一个值比使用引用的开销更大。它比复制品便宜吗？不适用于带有SSO的小字符串。这样做值得吗？|1854387|这取决于您的用例。你有多讨厌内存分配？|1854388|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/10315041/meaning-of-acronym-sso-in-the-context-of-stdstring^0|0|A|1|E|1|P|1|R|1|U|1|15|1|17|1|1G|1|1I|1|1M|1|1T|1|1V|1|0|0|0|7|6|0|0|X|1|10|6|0|E|1|0|0|2B|1|2L|1|K|V|0|0|D|6|0|4|1|L|1|0|I|3|O|9|0|0|0^^$0|@$1|2|3|4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1J|8|@$D|1K|E|1L|F|G]|$D|1M|E|1N|F|G]|$D|1O|E|1P|F|G]|$D|1Q|E|1R|F|G]|$D|1S|E|1T|F|G]|$D|1U|E|1V|F|G]|$D|1W|E|1X|F|G]|$D|1Y|E|1Z|F|G]|$D|20|E|21|F|G]|$D|22|E|23|F|G]|$D|24|E|25|F|G]|$D|26|E|27|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|28|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|29|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|2A|8|@$D|2B|E|2C|F|G]]|9|@]|A|$]]|$1|Q|3|R|5|L|7|2D|8|@]|9|@]|A|$M|N]]|$1|S|3|T|5|6|7|2E|8|@$D|2F|E|2G|F|G]|$D|2H|E|2I|F|G]]|9|@]|A|$]]|$1|U|3|V|5|6|7|2J|8|@$D|2K|E|2L|F|G]]|9|@]|A|$]]|$1|W|3|X|5|L|7|2M|8|@]|9|@]|A|$M|N]]|$1|Y|3|Z|5|6|7|2N|8|@$D|2O|E|2P|F|G]|$D|2Q|E|2R|F|G]]|9|@$D|2S|E|2T|1|2U]]|A|$]]|$1|10|3|11|5|6|7|2V|8|@$D|2W|E|2X|F|G]]|9|@]|A|$]]|$1|12|3|13|5|6|7|2Y|8|@$D|2Z|E|30|F|G]|$D|31|E|32|F|G]]|9|@]|A|$]]|$1|14|3|15|5|6|7|33|8|@$D|34|E|35|F|G]|$D|36|E|37|F|G]]|9|@]|A|$]]|$1|16|3|17|5|6|7|38|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|39|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|3A|8|@]|9|@]|A|$]]]|1B|$1C|$5|1D|1E|1F|A|$1G|1H]]]]

The reason Herb said what he said is because of cases like this.

Let's say I have function <code>A</code> which calls function <code>B</code>, which calls function <code>C</code>. And <code>A</code> passes a string through <code>B</code> and into <code>C</code>. <code>A</code> does not know or care about <code>C</code>; all <code>A</code> knows about is <code>B</code>. That is, <code>C</code> is an implementation detail of <code>B</code>.

Let's say that A is defined as follows:

<pre><code>void A()
{
 B("value");
}
</code></pre>

If B and C take the string by <code>const&amp;</code>, then it looks something like this:

<pre><code>void B(const std::string &amp;str)
{
 C(str);
}

void C(const std::string &amp;str)
{
 //Do something with `str`. Does not store it.
}
</code></pre>

All well and good. You're just passing pointers around, no copying, no moving, everyone's happy. <code>C</code> takes a <code>const&amp;</code> because it doesn't store the string. It simply uses it.

Now, I want to make one simple change: <code>C</code> needs to store the string somewhere.

<pre><code>void C(const std::string &amp;str)
{
 //Do something with `str`.
 m_str = str;
}
</code></pre>

Hello, copy constructor and potential memory allocation (ignore the <a href="https://stackoverflow.com/questions/10315041/meaning-of-acronym-sso-in-the-context-of-stdstring">Short String Optimization (SSO)</a>). C++11's move semantics are supposed to make it possible to remove needless copy-constructing, right? And <code>A</code> passes a temporary; there's no reason why <code>C</code> should have to copy the data. It should just abscond with what was given to it.

Except it can't. Because it takes a <code>const&amp;</code>.

If I change <code>C</code> to take its parameter by value, that just causes <code>B</code> to do the copy into that parameter; I gain nothing.

So if I had just passed <code>str</code> by value through all of the functions, relying on <code>std::move</code> to shuffle the data around, we wouldn't have this problem. If someone wants to hold on to it, they can. If they don't, oh well.

Is it more expensive? Yes; moving into a value is more expensive than using references. Is it less expensive than the copy? Not for small strings with SSO. Is it worth doing?

It depends on your use case. How much do you hate memory allocations?

blocks|key|211884|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|211885|是将const+std::string+&作为参数传递过去的日子吗？|blockquote|211886|211887|211888|No。许多人(包括Dave+Abrahams)超越了它适用的领域，并将其简化为适用于所有std::string参数--总是按值传递std::string对于任何和所有任意参数和应用程序来说都不是“最佳实践”，因为这些演讲/文章关注的优化只适用于有限的几种情况。|offset|length|style|BOLD|CODE|211889|如果要返回值、修改参数或获取值，则通过值传递可以节省昂贵的复制成本，并提供语法上的便利。|211890|一如既往，当你不需要拷贝时，通过const引用可以节省很多拷贝。|211891|现在来看具体的例子：|211892|然而，|211893|仍然比引用(通常以指针的形式实现)的大小要大得多。这是因为std::string具有各种组件，包括一个指向堆的指针和一个用于短字符串优化的成员char[]。所以在我看来，通过引用传递仍然是一个好主意。有人能解释一下赫伯为什么会这么说吗？|211894|211895|211896|如果堆栈大小是一个问题(假设这不是内联/优化的)，return_val+%2B+inval+>+return_val+--+IOW，则可以通过此处的值传递来减少堆栈使用峰值(注意:ABI的过度简化)。同时，通过常量引用传递可能会禁用优化。这里的主要原因不是为了避免堆栈增长，而是为了确保在适用的情况下可以执行优化。|211897|通过const引用传递的日子并没有结束--规则只是比以前更复杂。如果性能很重要，那么根据在实现中使用的细节来考虑如何传递这些类型将是明智的。|211898|entityMap^0|0|0|0|0|0|2|18|B|1T|B|0|0|0|0|0|0|0|0|P|A|12|5|1A|A|0|0^^$0|@$1|2|3|-4|4|5|6|14|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|15|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|16|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|17|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|18|7|@$H|19|I|1A|J|K]|$H|1B|I|1C|J|L]|$H|1D|I|1E|J|L]]|8|@]|9|$]]|$1|M|3|N|4|5|6|1F|7|@]|8|@]|9|$]]|$1|O|3|P|4|5|6|1G|7|@]|8|@]|9|$]]|$1|Q|3|R|4|5|6|1H|7|@]|8|@]|9|$]]|$1|S|3|T|4|5|6|1I|7|@]|8|@]|9|$]]|$1|U|3|V|4|C|6|1J|7|@]|8|@]|9|$]]|$1|W|3|-4|4|5|6|1K|7|@]|8|@]|9|$]]|$1|X|3|-4|4|5|6|1L|7|@]|8|@]|9|$]]|$1|Y|3|Z|4|5|6|1M|7|@$H|1N|I|1O|J|L]|$H|1P|I|1Q|J|L]|$H|1R|I|1S|J|L]]|8|@]|9|$]]|$1|10|3|11|4|5|6|1T|7|@]|8|@]|9|$]]|$1|12|3|-4|4|5|6|1U|7|@]|8|@]|9|$]]]|13|$]]

<blockquote>
 Are the days of passing const std::string &amp; as a parameter over?
</blockquote>

No. Many people take this advice (including Dave Abrahams) beyond the domain it applies to, and simplify it to apply to all <code>std::string</code> parameters -- Always passing <code>std::string</code> by value is not a "best practice" for any and all arbitrary parameters and applications because the optimizations these talks/articles focus on apply only to a restricted set of cases.

If you're returning a value, mutating the parameter, or taking the value, then passing by value could save expensive copying and offer syntactical convenience.

As ever, passing by const reference saves much copying when you don't need a copy.

Now to the specific example:

<blockquote>
 However inval is still quite a lot larger than the size of a reference (which is usually implemented as a pointer). This is because a std::string has various components including a pointer into the heap and a member char[] for short string optimization. So it seems to me that passing by reference is still a good idea. Can anyone explain why Herb might have said this?
</blockquote>

If stack size is a concern (and assuming this is not inlined/optimized), <code>return_val</code> + <code>inval</code> > <code>return_val</code> -- IOW, peak stack usage can be reduced by passing by value here (note: oversimplification of ABIs). Meanwhile, passing by const reference can disable the optimizations. The primary reason here is not to avoid stack growth, but to ensure the optimization can be performed where it is applicable.

The days of passing by const reference aren't over -- the rules just more complicated than they once were. If performance is important, you'll be wise to consider how you pass these types, based on the details you use in your implementations.

blocks|key|1854520|text|国际海事组织使用std::string的C%2B%2B引用是一种快速而短暂的局部优化，而使用按值传递可能是(也可能不是)更好的全局优化。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1854521|所以答案是:这取决于环境：|1854522|1854523|如果你写了从外部到内部函数的所有代码，你知道代码是做什么的，你可以使用参考const+std::string+&。|ordered-list-item|1854524|如果您编写库代码或在传递字符串的地方大量使用库代码，则可以通过信任std::string复制构造函数行为在全局意义上获得更多。|1854525|1854526|entityMap^0|8|B|0|0|0|11|J|0|X|B|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|T|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|U|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|L|3|M|5|K|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|N|3|-4|5|6|7|11|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|12|8|@]|D|@]|E|$]]]|P|$]]

IMO using the C++ reference for <code>std::string</code> is a quick and short local optimization, while using passing by value could be (or not) a better global optimization. 

So the answer is: it depends on circumstances: 

<ol>
<li>If you write all the code from the outside to the inside functions, you know what the code does, you can use the reference <code>const std::string &amp;</code>. </li>
<li>If you write the library code or use heavily library code where strings are passed, you likely gain more in global sense by trusting <code>std::string</code> copy constructor behavior.</li>
</ol>

blocks|key|212058|text|简短答案：NO!+Long答案：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|212059|如果您不修改字符串(将其视为只读)，请将其作为+const+ref&**.**传递|CODE|212060|(当使用它的函数计划修改它，或者您知道它将超出作用域时，(threads)，const+ref&显然需要保持在作用域内。不要在你的function+executes)|212061|If中复制**+body.|unordered-list-item|212062|
+const+ref&|212063|在cpp-next.com上有一个叫做的帖子。TL;DR：|212064|212065|+指南：不要复制你的函数参数。取而代之的是，通过值传递它们，并让编译器进行复制。|blockquote|212066|212067|212068|%5E的翻译|212069|不要复制您的函数参数值-意思是:如果您计划通过将参数值复制到内部变量来修改参数值，则只需使用参数即可。|212070|所以，，不会这么做|212071|std::string+function(const+std::string&+aString){
++++auto+vString(aString);
++++vString.clear();
++++return+vString;
}|code-block|syntax|javascript|212072|执行此操作|212073|std::string+function(std::string+aString){
++++aString.clear();
++++return+aString;
}|212074|当您需要修改函数体中的参数值时。|212075|你只需要知道你打算如何在函数体中使用参数。是否为只读...如果它停留在范围之内。|212076|entityMap^0|5|3|0|O|C|O|A|0|S|1J|12|A|0|0|D|0|2|A|2|A|0|0|T|0|0|1|13|0|0|0|0|1|2|2|0|0|1F|0|0|3|4|5|0|0|0|5|0|0|0|G|0|0|14|0^^$0|@$1|2|3|4|5|6|7|1I|8|@$9|1J|A|1K|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1L|8|@$9|1M|A|1N|B|C]|$9|1O|A|1P|B|H]]|D|@]|E|$]]|$1|I|3|J|5|6|7|1Q|8|@$9|1R|A|1S|B|C]|$9|1T|A|1U|B|H]]|D|@]|E|$]]|$1|K|3|L|5|M|7|1V|8|@$9|1W|A|1X|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|1Y|8|@$9|1Z|A|20|B|C]|$9|21|A|22|B|H]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|23|8|@$9|24|A|25|B|C]]|D|@]|E|$]]|$1|R|3|-4|5|6|7|26|8|@]|D|@]|E|$]]|$1|S|3|T|5|U|7|27|8|@$9|28|A|29|B|C]]|D|@]|E|$]]|$1|V|3|-4|5|6|7|2A|8|@]|D|@]|E|$]]|$1|W|3|-4|5|6|7|2B|8|@]|D|@]|E|$]]|$1|X|3|Y|5|6|7|2C|8|@$9|2D|A|2E|B|C]|$9|2F|A|2G|B|C]]|D|@]|E|$]]|$1|Z|3|10|5|6|7|2H|8|@$9|2I|A|2J|B|C]]|D|@]|E|$]]|$1|11|3|12|5|6|7|2K|8|@$9|2L|A|2M|B|C]|$9|2N|A|2O|B|C]]|D|@]|E|$]]|$1|13|3|14|5|15|7|2P|8|@]|D|@]|E|$16|17]]|$1|18|3|19|5|6|7|2Q|8|@$9|2R|A|2S|B|C]]|D|@]|E|$]]|$1|1A|3|1B|5|15|7|2T|8|@]|D|@]|E|$16|17]]|$1|1C|3|1D|5|6|7|2U|8|@$9|2V|A|2W|B|C]]|D|@]|E|$]]|$1|1E|3|1F|5|6|7|2X|8|@$9|2Y|A|2Z|B|C]]|D|@]|E|$]]|$1|1G|3|-4|5|6|7|30|8|@]|D|@]|E|$]]]|1H|$]]

Short answer: NO! Long answer:

<ul>
<li>If you won't modify the string (treat is as read-only), pass it as <code>const ref&amp;</code>. (the <code>const ref&amp;</code> obviously needs to stay within scope while the function that uses it executes)</li>
<li>If you plan to modify it or you know it will get out of scope (threads), pass it as a <code>value</code>, don't copy the <code>const ref&amp;</code> inside your function body.</li>
</ul>

There was a post on cpp-next.com called <a href="http://web.archive.org/web/20120908071416/http://cpp-next.com/archive/2009/08/want-speed-pass-by-value">"Want speed, pass by value!"</a>. The TL;DR:

<blockquote>
 Guideline: Don’t copy your function arguments. Instead, pass them by value and let the compiler do the copying.
</blockquote>

TRANSLATION of ^

Don’t copy your function arguments --- means: if you plan to modify the argument value by copying it to an internal variable, just use a value argument instead.

So, don't do this:

<pre><code>std::string function(const std::string&amp; aString){
 auto vString(aString);
 vString.clear();
 return vString;
}
</code></pre>

do this:

<pre><code>std::string function(std::string aString){
 aString.clear();
 return aString;
}
</code></pre>

When you need to modify the argument value in your function body.

You just need to be aware how you plan to use the argument in the function body. Read-only or NOT... and if it sticks within scope.

blocks|key|1159259|text|差不多了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1159260|在C%2B%2B17中，我们有basic_string_view<?>，这使得我们基本上只有一个std::string+const&参数的狭义用例。|offset|length|style|CODE|1159261|move语义的存在消除了std::string+const&的一个用例--如果您计划存储参数，则按值获取std::string更好，因为您可以从参数中取出move。|1159262|如果有人用一个原始的C+"string"调用你的函数，这意味着只分配了一个std::string缓冲区，而在std::string+const&的情况下是两个。|1159263|但是，如果您不打算复制，那么在C%2B%2B14中使用std::string+const&仍然很有用。|1159264|有了std::string_view，只要你不把这个字符串传递给一个需要C风格的'\0'-terminated字符缓冲区的应用程序接口，你就可以更有效地获得类似std::string的功能，而不会有任何分配的风险。原始C字符串甚至可以在不进行任何分配或字符复制的情况下转换为std::string_view。|1159265|在这一点上，std::string+const&的用法是当您不是要批量复制数据，而是要将其传递给一个C风格的应用程序接口，该接口需要一个以null结尾的缓冲区，并且您需要std::string提供的更高级别的字符串函数。在实践中，这是一组罕见的需求。|1159266|entityMap^0|0|B|K|18|I|0|C|I|1G|B|25|4|0|C|8|11|B|1I|I|0|N|I|0|2|G|14|4|28|B|3T|G|0|6|I|2D|B|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@$D|V|E|W|F|G]|$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@$D|10|E|11|F|G]|$D|12|E|13|F|G]|$D|14|E|15|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|16|8|@$D|17|E|18|F|G]|$D|19|E|1A|F|G]|$D|1B|E|1C|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1D|8|@$D|1E|E|1F|F|G]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1G|8|@$D|1H|E|1I|F|G]|$D|1J|E|1K|F|G]|$D|1L|E|1M|F|G]|$D|1N|E|1O|F|G]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1P|8|@$D|1Q|E|1R|F|G]|$D|1S|E|1T|F|G]]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]]|S|$]]

Almost.

In C++17, we have <code>basic_string_view&lt;?&gt;</code>, which brings us down to basically one narrow use case for <code>std::string const&amp;</code> parameters.

The existence of move semantics has eliminated one use case for <code>std::string const&amp;</code> -- if you are planning on storing the parameter, taking a <code>std::string</code> by value is more optimal, as you can <code>move</code> out of the parameter.

If someone called your function with a raw C <code>"string"</code> this means only one <code>std::string</code> buffer is ever allocated, as opposed to two in the <code>std::string const&amp;</code> case.

However, if you don't intend to make a copy, taking by <code>std::string const&amp;</code> is still useful in C++14.

With <code>std::string_view</code>, so long as you aren't passing said string to an API that expects C-style <code>'\0'</code>-terminated character buffers, you can more efficiently get <code>std::string</code> like functionality without risking any allocation. A raw C string can even be turned into a <code>std::string_view</code> without any allocation or character copying.

At that point, the use for <code>std::string const&amp;</code> is when you aren't copying the data wholesale, and are going to pass it on to a C-style API that expects a null terminated buffer, and you need the higher level string functions that <code>std::string</code> provides. In practice, this is a rare set of requirements.

blocks|key|2180177|text|问题是"const“是一个非粒度的限定符。"const+string+ref“通常的意思是”不要修改这个字符串“，而不是”不要修改引用计数“。在C%2B%2B中，根本没有办法说出哪些成员是"const“。它们要么都是，要么都不是。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2180178|为了解决这个语言问题，STL可以允许示例中的"C()“进行移动语义复制，并尽职尽责地忽略关于引用计数(可变)的"const”。只要它被很好地指定，这就可以了。|2180179|因为STL没有，所以我有一个字符串的版本，它const_casts<>了引用计数器(没有办法在类层次结构中回溯使某些东西可变)，并且-瞧-你可以自由地将cmstring作为const引用传递，并在深层函数中复制它们，一整天都没有泄漏或问题。|2180180|由于C%2B%2B在这里没有提供“派生类常量粒度”，所以写一个好的规范并创建一个闪亮的新“常量可移动字符串”(cmstring)对象是我见过的最好的解决方案。|2180181|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

The problem is that "const" is a non-granular qualifier. What is usually meant by "const string ref" is "don't modify this string", not "don't modify the reference count". There is simply no way, in C++, to say which members are "const". They either all are, or none of them are. 

In order to hack around this language issue, STL could allow "C()" in your example to make a move-semantic copy anyway, and dutifully ignore the "const" with regard to the reference count (mutable). As long as it was well-specified, this would be fine. 

Since STL doesn't, I have a version of a string that const_casts&lt;> away the reference counter (no way to retroactively make something mutable in a class hierarchy), and - lo and behold - you can freely pass cmstring's as const references, and make copies of them in deep functions, all day long, with no leaks or issues.

Since C++ offers no "derived class const granularity" here, writing up a good specification and making a shiny new "const movable string" (cmstring) object is the best solution I've seen.

blocks|key|2175018|text|Herb+Sutter和Bjarne+Stroustroup仍在推荐const+std::string&作为参数类型；请参阅https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-in。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2175019|这里有一个在其他答案中没有提到的陷阱:如果您将字符串文字传递给const+std::string&参数，它将传递对临时字符串的引用，该临时字符串是动态创建的，用于保存文字的字符。如果您随后保存了该引用，则一旦释放临时字符串，该引用将无效。为了安全起见，您必须保存一个副本，而不是引用。这个问题源于字符串类型是const+char[N]类型，需要提升到std::string。|2175020|下面的代码说明了陷阱和解决方法，以及一个次要的效率选项--使用Is+there+a+way+to+pass+a+string+literal+as+reference+in+C%2B%2B描述的const+char*方法重载。|2175021|(注意:+Sutter+&+Stroustroup建议，如果您保留字符串的副本，还要提供一个带有&&参数和std::move()的重载函数。)|2175022|#include+<string>
#include+<iostream>
class+WidgetBadRef+{
public:
++++WidgetBadRef(const+std::string&+s)+:+myStrRef(s)++//+copy+the+reference...
++++{}

++++const+std::string&+myStrRef;++++//+might+be+a+reference+to+a+temporary+(oops!)
};

class+WidgetSafeCopy+{
public:
++++WidgetSafeCopy(const+std::string&+s)+:+myStrCopy(s)
++++++++++++//+constructor+for+string+references;+copy+the+string
++++{std::cout+<<+"const+std::string&+constructor\n";}

++++WidgetSafeCopy(const+char*+cs)+:+myStrCopy(cs)
++++++++++++//+constructor+for+string+literals+(and+char+arrays);
++++++++++++//+for+minor+efficiency+only;
++++++++++++//+create+the+std::string+directly+from+the+chars
++++{std::cout+<<+"const+char+*+constructor\n";}

++++const+std::string+myStrCopy;++++//+save+a+copy,+not+a+reference!
};

int+main()+{
++++WidgetBadRef+w1("First+string");
++++WidgetSafeCopy+w2("Second+string");+//+uses+the+const+char*+constructor,+no+temp+string
++++WidgetSafeCopy+w3(w2.myStrCopy);++++//+uses+the+String+reference+constructor
++++std::cout+<<+w1.myStrRef+<<+"\n";+++//+garbage+out
++++std::cout+<<+w2.myStrCopy+<<+"\n";++//+OK
++++std::cout+<<+w3.myStrCopy+<<+"\n";++//+OK
}|code-block|syntax|javascript|2175023|输出：|2175024|2175025|常量char+*构造函数const+std::+string+&构造函数第二个字符串第二个字符串|blockquote|2175026|2175027|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-in|1|https://stackoverflow.com/questions/27365824/is-there-a-way-to-pass-a-string-literal-as-reference-in-c/27365886#27365886^0|Y|I|1Q|2A|0|0|V|I|4A|D|4V|B|0|2L|B|V|1N|1|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|17|8|@$9|18|A|19|B|C]]|D|@$9|1A|A|1B|1|1C]]|E|$]]|$1|F|3|G|5|6|7|1D|8|@$9|1E|A|1F|B|C]|$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1K|8|@$9|1L|A|1M|B|C]]|D|@$9|1N|A|1O|1|1P]]|E|$]]|$1|J|3|K|5|6|7|1Q|8|@]|D|@]|E|$]]|$1|L|3|M|5|N|7|1R|8|@]|D|@]|E|$O|P]]|$1|Q|3|R|5|6|7|1S|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1T|8|@]|D|@]|E|$]]|$1|T|3|U|5|V|7|1U|8|@]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1V|8|@]|D|@]|E|$]]|$1|X|3|-4|5|6|7|1W|8|@]|D|@]|E|$]]]|Y|$Z|$5|10|11|12|E|$13|14]]|15|$5|10|11|12|E|$13|16]]]]

Herb Sutter is still on record, along with Bjarne Stroustroup, in recommending <code>const std::string&amp;</code> as a parameter type; see <a href="https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-in" rel="nofollow noreferrer">https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-in</a> . 

There is a pitfall not mentioned in any of the other answers here: if you pass a string literal to a <code>const std::string&amp;</code> parameter, it will pass a reference to a temporary string, created on-the-fly to hold the characters of the literal. If you then save that reference, it will be invalid once the temporary string is deallocated. To be safe, you must save a copy, not the reference. The problem stems from the fact that string literals are <code>const char[N]</code> types, requiring promotion to <code>std::string</code>. 

The code below illustrates the pitfall and the workaround, along with a minor efficiency option -- overloading with a <code>const char*</code> method, as described at <a href="https://stackoverflow.com/questions/27365824/is-there-a-way-to-pass-a-string-literal-as-reference-in-c/27365886#27365886">Is there a way to pass a string literal as reference in C++</a>.

(Note: Sutter &amp; Stroustroup advise that if you keep a copy of the string, also provide an overloaded function with a &amp;&amp; parameter and std::move() it.)

<pre><code>#include &lt;string&gt;
#include &lt;iostream&gt;
class WidgetBadRef {
public:
 WidgetBadRef(const std::string&amp; s) : myStrRef(s) // copy the reference...
 {}

 const std::string&amp; myStrRef; // might be a reference to a temporary (oops!)
};

class WidgetSafeCopy {
public:
 WidgetSafeCopy(const std::string&amp; s) : myStrCopy(s)
 // constructor for string references; copy the string
 {std::cout &lt;&lt; "const std::string&amp; constructor\n";}

 WidgetSafeCopy(const char* cs) : myStrCopy(cs)
 // constructor for string literals (and char arrays);
 // for minor efficiency only;
 // create the std::string directly from the chars
 {std::cout &lt;&lt; "const char * constructor\n";}

 const std::string myStrCopy; // save a copy, not a reference!
};

int main() {
 WidgetBadRef w1("First string");
 WidgetSafeCopy w2("Second string"); // uses the const char* constructor, no temp string
 WidgetSafeCopy w3(w2.myStrCopy); // uses the String reference constructor
 std::cout &lt;&lt; w1.myStrRef &lt;&lt; "\n"; // garbage out
 std::cout &lt;&lt; w2.myStrCopy &lt;&lt; "\n"; // OK
 std::cout &lt;&lt; w3.myStrCopy &lt;&lt; "\n"; // OK
}
</code></pre>

OUTPUT:

<blockquote>
<pre><code>const char * constructor
const std::string&amp; constructor

Second string
Second string
</code></pre>
</blockquote>

blocks|key|212275|text|正如@JD+Herb在评论中指出的那样，ł在另一个评论中给出了其他建议(稍后？)从这里粗略地看一下：https://youtu.be/xnqTKD8uD64?t=54m50s。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|212276|他的建议归结为只使用函数f的值参数，该函数接受所谓的接收器参数，假设您将从这些接收器参数移动构造。|style|CODE|212277|与分别针对左值和右值参数定制的f的优化实现相比，这种通用方法只增加了左值和右值参数的移动构造函数的开销。要了解为什么会出现这种情况，假设f接受一个值参数，其中T是某种可复制和移动的构造类型：|212278|void+f(T+x)+{
++T+y{std::move(x)};
}|code-block|syntax|javascript|212279|使用左值参数调用f将导致调用复制构造函数来构造x，并调用移动构造函数来构造y。另一方面，使用右值参数调用f将导致调用一个move构造函数来构造x，并调用另一个move构造函数来构造y。|212280|通常，左值参数的f的最佳实现如下：|212281|void+f(const+T&+x)+{
++T+y{x};
}|212282|在这种情况下，只调用一个复制构造函数来构造y。rvalue参数的f的最佳实现通常如下所示：|212283|void+f(T&&+x)+{
++T+y{std::move(x)};
}|212284|在这种情况下，只调用一个移动构造函数来构造y。|212285|因此，一个合理的折衷方案是接受一个value参数，并让一个额外的移动构造函数调用关于最佳实现的lvalue或rvalue参数，这也是Herb的演讲中给出的建议。|212286|正如@JDługosz在注释中指出的那样，通过值传递只对将从接收器参数构造一些对象的函数有意义。当您有一个复制其参数的函数f时，按值传递方法将比一般的按常量引用传递方法具有更多的开销。保留其参数副本的函数f的按值传递方法将采用以下形式：|212287|void+f(T+x)+{
++T+y{...};
++...
++y+=+std::move(x);
}|212288|在这种情况下，左值参数有一个复制构造和移动赋值，右值参数有一个移动构造和移动赋值。左值参数的最佳情况是：|212289|void+f(const+T&+x)+{
++T+y{...};
++...
++y+=+x;
}|212290|归根结底，这只是一个赋值，这可能比按值传递方法所需的复制构造函数加上移动赋值要便宜得多。这样做的原因是，分配可能会重用y中现有的已分配内存，从而阻止(取消)分配，而复制构造函数通常会分配内存。|212291|对于右值参数，保留副本的最优f实现具有以下形式：|212292|void+f(T&&+x)+{
++T+y{...};
++...
++y+=+std::move(x);
}|212293|所以，在这种情况下，只有移动赋值。将右值传递给接受常量引用的f版本只需执行赋值操作，而不是移动赋值操作。因此，相对而言，在这种情况下采用常量引用作为一般实现的f版本更可取。|212294|因此，一般而言，为了实现最优的实现，您需要重载或执行某种完美的转发，如谈话中所示。缺点是所需重载数量的组合爆炸式增长，这取决于f的参数数量，以防您选择重载参数的值类别。完美转发的缺点是，f变成了一个模板函数，这阻止了它的虚拟化，如果你想让它100%25正确，它会导致更复杂的代码(参见谈话中的血淋淋的细节)。|212295|entityMap|0|LINK|mutability|MUTABLE|url|https://youtu.be/xnqTKD8uD64?t=54m50s^0|1E|11|0|0|C|1|0|F|1|1W|1|27|1|0|0|8|1|N|1|11|1|1G|1|1Z|1|2I|1|0|8|1|0|0|L|1|W|1|0|0|L|1|0|0|1P|1|2U|1|0|0|0|0|1N|1|0|E|1|0|0|U|1|27|1|0|1R|1|2L|1|0^^$0|@$1|2|3|4|5|6|7|1S|8|@]|9|@$A|1T|B|1U|1|1V]]|C|$]]|$1|D|3|E|5|6|7|1W|8|@$A|1X|B|1Y|F|G]]|9|@]|C|$]]|$1|H|3|I|5|6|7|1Z|8|@$A|20|B|21|F|G]|$A|22|B|23|F|G]|$A|24|B|25|F|G]]|9|@]|C|$]]|$1|J|3|K|5|L|7|26|8|@]|9|@]|C|$M|N]]|$1|O|3|P|5|6|7|27|8|@$A|28|B|29|F|G]|$A|2A|B|2B|F|G]|$A|2C|B|2D|F|G]|$A|2E|B|2F|F|G]|$A|2G|B|2H|F|G]|$A|2I|B|2J|F|G]]|9|@]|C|$]]|$1|Q|3|R|5|6|7|2K|8|@$A|2L|B|2M|F|G]]|9|@]|C|$]]|$1|S|3|T|5|L|7|2N|8|@]|9|@]|C|$M|N]]|$1|U|3|V|5|6|7|2O|8|@$A|2P|B|2Q|F|G]|$A|2R|B|2S|F|G]]|9|@]|C|$]]|$1|W|3|X|5|L|7|2T|8|@]|9|@]|C|$M|N]]|$1|Y|3|Z|5|6|7|2U|8|@$A|2V|B|2W|F|G]]|9|@]|C|$]]|$1|10|3|11|5|6|7|2X|8|@]|9|@]|C|$]]|$1|12|3|13|5|6|7|2Y|8|@$A|2Z|B|30|F|G]|$A|31|B|32|F|G]]|9|@]|C|$]]|$1|14|3|15|5|L|7|33|8|@]|9|@]|C|$M|N]]|$1|16|3|17|5|6|7|34|8|@]|9|@]|C|$]]|$1|18|3|19|5|L|7|35|8|@]|9|@]|C|$M|N]]|$1|1A|3|1B|5|6|7|36|8|@$A|37|B|38|F|G]]|9|@]|C|$]]|$1|1C|3|1D|5|6|7|39|8|@$A|3A|B|3B|F|G]]|9|@]|C|$]]|$1|1E|3|1F|5|L|7|3C|8|@]|9|@]|C|$M|N]]|$1|1G|3|1H|5|6|7|3D|8|@$A|3E|B|3F|F|G]|$A|3G|B|3H|F|G]]|9|@]|C|$]]|$1|1I|3|1J|5|6|7|3I|8|@$A|3J|B|3K|F|G]|$A|3L|B|3M|F|G]]|9|@]|C|$]]|$1|1K|3|-4|5|6|7|3N|8|@]|9|@]|C|$]]]|1L|$1M|$5|1N|1O|1P|C|$1Q|1R]]]]

As @JDługosz points out in the comments, Herb gives other advice in another (later?) talk, see roughly from here: <a href="https://youtu.be/xnqTKD8uD64?t=54m50s" rel="nofollow noreferrer">https://youtu.be/xnqTKD8uD64?t=54m50s</a>.

His advice boils down to only using value parameters for a function <code>f</code> that takes so-called sink arguments, assuming you will move construct from these sink arguments.

This general approach only adds the overhead of a move constructor for both lvalue and rvalue arguments compared to an optimal implementation of <code>f</code> tailored to lvalue and rvalue arguments respectively. To see why this is the case, suppose <code>f</code> takes a value parameter, where <code>T</code> is some copy and move constructible type:

<pre><code>void f(T x) {
 T y{std::move(x)};
}
</code></pre>

Calling <code>f</code> with an lvalue argument will result in a copy constructor being called to construct <code>x</code>, and a move constructor being called to construct <code>y</code>. On the other hand, calling <code>f</code> with an rvalue argument will cause a move constructor to be called to construct <code>x</code>, and another move constructor to be called to construct <code>y</code>.

In general, the optimal implementation of <code>f</code> for lvalue arguments is as follows:

<pre><code>void f(const T&amp; x) {
 T y{x};
}
</code></pre>

In this case, only one copy constructor is called to construct <code>y</code>. The optimal implementation of <code>f</code> for rvalue arguments is, again in general, as follows:

<pre><code>void f(T&amp;&amp; x) {
 T y{std::move(x)};
}
</code></pre>

In this case, only one move constructor is called to construct <code>y</code>.

So a sensible compromise is to take a value parameter and have one extra move constructor call for either lvalue or rvalue arguments with respect to the optimal implementation, which is also the advice given in Herb's talk.

As @JDługosz pointed out in the comments, passing by value only makes sense for functions that will construct some object from the sink argument. When you have a function <code>f</code> that copies its argument, the pass-by-value approach will have more overhead than a general pass-by-const-reference approach. The pass-by-value approach for a function <code>f</code> that retains a copy of its parameter will have the form:

<pre><code>void f(T x) {
 T y{...};
 ...
 y = std::move(x);
}
</code></pre>

In this case, there is a copy construction and a move assignment for an lvalue argument, and a move construction and move assignment for an rvalue argument. The most optimal case for an lvalue argument is:

<pre><code>void f(const T&amp; x) {
 T y{...};
 ...
 y = x;
}
</code></pre>

This boils down to an assignment only, which is potentially much cheaper than the copy constructor plus move assignment required for the pass-by-value approach. The reason for this is that the assignment might reuse existing allocated memory in <code>y</code>, and therefore prevent (de)allocations, whereas the copy constructor will usually allocate memory.

For an rvalue argument the most optimal implementation for <code>f</code> that retains a copy has the form:

<pre><code>void f(T&amp;&amp; x) {
 T y{...};
 ...
 y = std::move(x);
}
</code></pre>

So, only a move assignment in this case. Passing an rvalue to the version of <code>f</code> that takes a const reference only costs an assignment instead of a move assignment. So relatively speaking, the version of <code>f</code> taking a const reference in this case as the general implementation is preferable.

So in general, for the most optimal implementation, you will need to overload or do some kind of perfect forwarding as shown in the talk. The drawback is a combinatorial explosion in the number of overloads required, depending on the number of parameters for <code>f</code> in case you opt to overload on the value category of the argument. Perfect forwarding has the drawback that <code>f</code> becomes a template function, which prevents making it virtual, and results in significantly more complex code if you want to get it 100% right (see the talk for the gory details).

blocks|key|1854945|text|参见“Herb+Sutter+"Back+to+the+Basics!+Essentials+of+Modern+C%2B%2B+Style”。在其他主题中，他回顾了过去给出的参数传递建议，以及C%2B%2B11带来的新想法，并专门研究了按值传递字符串的想法。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1854946|​|1854947|📷|atomic|1854948|1854949|基准测试表明，通过值传递std::string，在函数无论如何都会复制它的情况下，可能会慢得多！|style|CODE|1854950|这是因为您强制它总是进行完整复制(然后移动到适当的位置)，而const&版本将更新旧的字符串，这可能会重用已经分配的缓冲区。|1854951|请看他的幻灯片27:对于“set”函数，选项1和以前一样。选项2为右值引用添加了一个重载，但如果有多个参数，则会产生组合爆炸。|1854952|只有对于必须创建字符串(不更改其现有值)的“接收器”参数，按值传递技巧才是有效的。即构造函数，其中的参数直接初始化匹配类型的成员。|BOLD|1854953|如果你想知道你对此的担忧程度有多深，请观看Nicolai+Josuttis’s演示文稿并祝你好运(“完美完成！”在发现前一个版本的故障后n次。去过那里吗？)|1854954|1854955|这在标准指南中也被总结为⧺F.15。|1854956|1854957|更新|1854958|通常，您希望将"string“参数声明为std::string_view+(通过value)。这使您可以像使用const+std::string&一样高效地传递现有的std::string对象，还可以传递词法字符串文字(如"hello!")而无需复制它，传递string_view类型的对象也是必需的，因为它们也在生态系统中。|1854959|例外情况是，函数需要一个实际的std::string实例，以便传递给另一个声明为使用const+std::string&的函数。|1854960|entityMap|0|LINK|mutability|MUTABLE|url|https://www.youtube.com/watch?v=xnqTKD8uD64|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/fc4deda0273be4a033e1305576ca7a08.png|imageAlt|2|https://www.youtube.com/watch?v=PNRju6_yn3o|3|https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#f15-prefer-simple-and-conventional-ways-of-passing-information^0|2|1T|0|0|0|0|1|1|0|0|C|B|0|U|6|0|0|16|4|0|L|I|2|0|0|C|5|3|0|0|0|K|G|1J|I|2B|B|33|8|3L|B|14|5|0|F|B|16|I|0^^$0|@$1|2|3|4|5|6|7|1O|8|@]|9|@$A|1P|B|1Q|1|1R]]|C|$]]|$1|D|3|E|5|6|7|1S|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|1T|8|@]|9|@$A|1U|B|1V|1|1W]]|C|$]]|$1|I|3|E|5|6|7|1X|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1Y|8|@$A|1Z|B|20|L|M]]|9|@]|C|$]]|$1|N|3|O|5|6|7|21|8|@$A|22|B|23|L|M]]|9|@]|C|$]]|$1|P|3|Q|5|6|7|24|8|@]|9|@]|C|$]]|$1|R|3|S|5|6|7|25|8|@$A|26|B|27|L|T]]|9|@]|C|$]]|$1|U|3|V|5|6|7|28|8|@]|9|@$A|29|B|2A|1|2B]]|C|$]]|$1|W|3|-4|5|6|7|2C|8|@]|9|@]|C|$]]|$1|X|3|Y|5|6|7|2D|8|@]|9|@$A|2E|B|2F|1|2G]]|C|$]]|$1|Z|3|-4|5|6|7|2H|8|@]|9|@]|C|$]]|$1|10|3|11|5|6|7|2I|8|@]|9|@]|C|$]]|$1|12|3|13|5|6|7|2J|8|@$A|2K|B|2L|L|M]|$A|2M|B|2N|L|M]|$A|2O|B|2P|L|M]|$A|2Q|B|2R|L|M]|$A|2S|B|2T|L|M]|$A|2U|B|2V|L|T]]|9|@]|C|$]]|$1|14|3|15|5|6|7|2W|8|@$A|2X|B|2Y|L|M]|$A|2Z|B|30|L|M]]|9|@]|C|$]]|$1|16|3|-4|5|6|7|31|8|@]|9|@]|C|$]]]|17|$18|$5|19|1A|1B|C|$1C|1D]]|1E|$5|1F|1A|1G|C|$1H|1I|1J|-4]]|1K|$5|19|1A|1B|C|$1C|1L]]|1M|$5|19|1A|1B|C|$1C|1N]]]]

See <a href="https://www.youtube.com/watch?v=xnqTKD8uD64" rel="nofollow noreferrer">“Herb Sutter &quot;Back to the Basics! Essentials of Modern C++ Style”</a>. Among other topics, he reviews the parameter passing advice that’s been given in the past, and new ideas that come in with C++11 and specifically looks at the idea of passing strings by value.
<img src="https://i.stack.imgur.com/Tw6BV.png" alt="slide 24" />
The benchmarks show that passing <code>std::string</code>s by value, in cases where the function will copy it in anyway, can be significantly slower!
This is because you are forcing it to always make a full copy (and then move into place), while the <code>const&amp;</code> version will update the old string which may reuse the already-allocated buffer.
See his slide 27: For “set” functions, option 1 is the same as it always was. Option 2 adds an overload for rvalue reference, but this gives a combinatorial explosion if there are multiple parameters.
It is only for “sink” parameters where a string must be created (not have its existing value changed) that the pass-by-value trick is valid. That is, constructors in which the parameter directly initializes the member of the matching type.
If you want to see how deep you can go in worrying about this, watch <a href="https://www.youtube.com/watch?v=PNRju6_yn3o" rel="nofollow noreferrer">Nicolai Josuttis’s</a> presentation and good luck with that (“Perfect — Done!” n times after finding fault with the previous version. Ever been there?)
<hr />
This is also summarized as <a href="https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#f15-prefer-simple-and-conventional-ways-of-passing-information" rel="nofollow noreferrer">⧺F.15</a> in the Standard Guidelines.
<hr />
<h1>update</h1>
Generally, you want to declare &quot;string&quot; parameters as <code>std::string_view</code> (by value). This allows you to pass an existing <code>std::string</code> object as efficiently as with <code>const std::string&amp;</code>, and also pass a lexical string literal (like <code>&quot;hello!&quot;</code>) without copying it, and pass objects of type <code>string_view</code> which is necessary now that those are in the ecosystem too.
The exception is when the function needs an actual <code>std::string</code> instance, in order to pass to another function that's declared to take <code>const std::string&amp;</code>.

I heard a recent talk by Herb Sutter who suggested that the reasons to pass <code>std::vector</code> and <code>std::string</code> by <code>const &amp;</code> are largely gone. He suggested that writing a function such as the following is now preferable:

<pre><code>std::string do_something ( std::string inval )
{
 std::string return_val;
 // ... do stuff ...
 return return_val;
}
</code></pre>

I understand that the <code>return_val</code> will be an rvalue at the point the function returns and can therefore be returned using move semantics, which are very cheap. However, <code>inval</code> is still much larger than the size of a reference (which is usually implemented as a pointer). This is because a <code>std::string</code> has various components including a pointer into the heap and a member <code>char[]</code> for short string optimization. So it seems to me that passing by reference is still a good idea.

Can anyone explain why Herb might have said this?

Are the days of passing const std::string & as a parameter over?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我听过Herb Sutter最近的一次演讲，他建议用const &取代std::vector和std::string的理由已经基本消失了。他建议现在更可取的做法是编写如下函数：std::string do_something ( std::string inval ){   std::string return_val...

问将const std::string &作为参数传递的日子已经过去了吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问将const std::string &作为参数传递的日子已经过去了吗？EN