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

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

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

几乎。

在c++ 17中，我们有basic_string_view<?>，这基本上把我们带到了std::string的一个狭窄的用例。

move语义的存在消除了std::string const&的一个用例——如果您计划存储参数，按值获取std::string是更优的，因为您可以移出参数。

如果有人用一个原始的C“string”调用你的函数，这意味着只有一个std::string缓冲区被分配，而不是std::string const&case中的两个。

然而，如果你不打算复制，通过std::string const&在c++ 14中仍然是有用的。

使用std::string_view，只要你没有将该字符串传递给一个期望c风格以“\0”结尾的字符缓冲区的API，你就可以更有效地获得类似std::string的功能，而无需承担任何分配风险。一个原始的C字符串甚至可以转换为std::string_view，而不需要任何分配或字符复制。

在这一点上，std::string const&的使用是当您不批量复制数据，并将其传递给一个c风格的API，该API期望一个以null结束的缓冲区，并且您需要std::string提供的高级字符串函数。在实践中，这是一组罕见的需求。

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

假设我有一个函数A，它调用函数B，函数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接受一个参数&，因为它不存储字符串。它只是简单地使用它。

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

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

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

但它不能。因为它需要一个常量。

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

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

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

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

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

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

#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构造。对于任何特定的情况，这可能是可接受的，也可能是不可接受的。这两种解决方案各有优缺点。

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

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

让我们考虑下一个函数:

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

为了避免内联，这些函数在单独的编译单元中实现。然后: 1. 如果将一个字面值传递给这两个函数，将不会看到性能上的太大差异。在这两种情况下，都必须创建一个字符串对象 2. 如果传递另一个std::string对象，foo2将优于foo1，因为foo1将进行深度复制。

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

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

问题是“const”是一个非粒度限定符。“const string ref”通常的意思是“不要修改这个字符串”，而不是“不要修改引用计数”。在c++中，根本没有办法说哪些成员是“const”。它们要么都是，要么都不是。

为了解决这个语言问题，STL可以允许“C()”在你的例子中做一个移动语义复制，并在引用计数(可变)方面尽责地忽略“const”。只要它是指定好的，这就可以了。

因为STL没有，我有一个const_cast <>的字符串版本，去掉引用计数器(没有办法在类层次结构中追溯一些可变的东西)，并且-你瞧-你可以自由地传递cmstring作为const引用，并在深层函数中复制它们，一整天，没有泄漏或问题。

由于c++在这里没有提供“派生类的const粒度”，编写一个好的规范并创建一个新的“const可移动字符串”(cmstring)对象是我见过的最好的解决方案。