std::string不是原始数据(POD)，它的原始大小也不是最相关的东西。例如，如果传入的字符串超过SSO的长度，并且分配在堆上，我希望复制构造函数不复制SSO存储。

推荐这样做的原因是，inval是从参数表达式构造的，因此总是会根据需要移动或复制——假设您需要参数的所有权，这样做不会造成性能损失。如果您不这样做，const引用可能仍然是更好的方法。

除非你真的需要一份副本，否则带上const &仍然是合理的。例如:

bool isprint(std::string const &s) {
return all_of(begin(s),end(s),(bool(*)(char))isprint);
}

如果你改变它，以按值获取字符串，那么你最终会移动或复制参数，这是没有必要的。复制/移动不仅成本更高，而且还会带来新的潜在失败;复制/移动可能会抛出异常(例如，复制期间的分配可能会失败)，而引用现有值则不会。

如果你做需要一个副本，那么通过值传递和返回通常是(总是?)最好的选择。事实上，在c++ 03中我通常不会担心这个问题，除非你发现额外的副本实际上会导致性能问题。复制省略在现代编译器上似乎相当可靠。我认为人们的怀疑和坚持，你必须检查你的编译器支持RVO的表，现在大部分已经过时了。

简而言之，c++ 11在这方面并没有真正改变任何东西，除了那些不相信复制省略的人。

这在很大程度上取决于编译器的实现。

然而，这也取决于你使用什么。

让我们考虑下一个函数:

bool foo1( const std::string v )
{
return v.empty();
}
bool foo2( const std::string & v )
{
return v.empty();
}

在我的PC上，使用g++ 4.6.1，我得到了这些结果:

• 参考变量:1000000000次迭代——>时间流逝:2.25912秒
• 变量值:1000000000次迭代—>时间流逝:27.2259秒
• 参考文字:100000000次迭代——>时间流逝:9.10319秒
• 字面值:100000000次迭代——>时间流逝:8.62659秒

我复制/粘贴了这个问题的答案在这里，并改变了名称和拼写，以适应这个问题。

下面是用来衡量问题的代码:

#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());
}

对我来说，这输出:

$ clang++ -std=c++11 -stdlib=libc++ -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++ -std=c++11 -stdlib=libc++ -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&&)

下表总结了我的结果(使用clang -std=c++11)。第一个数字是复制结构的数量，第二个数字是移动结构的数量:

+----+--------+--------+---------+
|    | lvalue | xvalue | prvalue |
+----+--------+--------+---------+
| p1 |  1/1   |  0/2   |   0/1   |
+----+--------+--------+---------+
| p2 |  1/0   |  0/1   |   0/1   |
+----+--------+--------+---------+

值传递解决方案只需要一次重载，但在传递左值和x值时需要额外的move构造。对于任何特定的情况，这可能是可接受的，也可能是不可接受的。这两种解决方案各有优缺点。

赫伯说那些话的原因就是因为这样的案子。

假设函数A调用函数B，函数C。A将一个字符串从B传递到C。A不知道也不关心C;A只知道B。也就是说，C是B的实现细节。

假设A的定义如下:

void A()
{
B("value");
}

如果B和C通过const&获取字符串，那么它看起来像这样:

void B(const std::string &str)
{
C(str);
}


void C(const std::string &str)
{
//Do something with `str`. Does not store it.
}

一切都很好。你只是传递指针，没有复制，没有移动，每个人都很开心。C接受const&，因为它不存储字符串。它只是简单地使用它。

现在，我想做一个简单的更改:C需要将字符串存储在某个地方。

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

你好，复制构造函数和潜在的内存分配(忽略短串优化(SSO))。c++ 11的move语义应该可以消除不必要的复制构造，对吧?A传递一个临时;没有理由C必须要复制数据。它应该带着给它的东西潜逃。

但它不能。因为它需要const&。

如果我改变C的参数值，这只会导致B复制到该参数;我什么也得不到。

因此，如果我只是在所有函数中按值传递str，依靠std::move来打乱数据，我们就不会有这个问题。如果有人想留住它，他们可以做到。如果没有，那好吧。

会更贵吗?是的,移动到值中比使用引用代价更大。它比复制品便宜吗?不适合使用SSO的小字符串。值得做吗?

这取决于您的用例。你有多讨厌内存分配?

const std::string &作为参数结束?

# EYZ2。许多人采纳了这个建议(包括Dave Abrahams)，超越了它所适用的领域，并将其简化为适用于所有 std::string参数——总是按值传递std::string对于任何和所有任意参数和应用程序都不是“最佳实践”，因为这些演讲/文章的优化重点是应用只适用于特定的情况。

如果要返回值、改变参数或获取值，那么按值传递可以节省昂贵的复制，并提供语法上的便利。

与以往一样，通过const引用传递可以节省大量复制当你不需要拷贝的时候。

现在来看看具体的例子:

然而，inval仍然比引用(通常实现为指针)的大小大得多。这是因为std::string有各种组件，包括指向堆的指针和用于短字符串优化的成员char[]。所以在我看来，通过引用传递仍然是一个好主意。谁能解释一下赫伯为什么会这么说?

如果需要考虑堆栈大小(并且假设这不是内联/优化的)，return_val + inval > return_val—IOW，通过这里传递的值，堆栈使用峰值可以是减少(注意:ABIs的过度简化)。同时，通过const引用传递可以禁用优化。这里的主要原因不是为了避免堆栈增长，而是为了确保可以执行优化适用的地方。

通过const引用传递的日子并没有结束——规则只是比以前更复杂了。如果性能很重要，明智的做法是根据实现中使用的细节考虑如何传递这些类型。

在我看来，使用c++引用std::string是一个快速而简短的局部优化，而使用值传递可能是(或不是)一个更好的全局优化。

所以答案是:这取决于环境:

1. 如果您编写了所有从外部到内部函数的代码，您知道代码的功能，您可以使用const std::string &引用。
2. 如果您编写库代码或在传递字符串的地方使用大量库代码，那么通过信任std::string复制构造函数行为，您可能会在全局意义上获得更多好处。

简短回答:不!

• # EYZ2 < br > # EYZ3
• 如果你打算修改它或者你知道它会超出(threads)的范围，将它作为value传递，不要在函数体中复制const ref&。

在cpp-next.com上有一个帖子叫“要速度，要价值!”< / >强。TL;博士:

std::string function(const std::string& aString){
auto vString(aString);
vString.clear();
return vString;
}

std::string function(std::string aString){
aString.clear();
return aString;
}