我最近听了Herb Sutter的一个演讲,他认为通过const &传递std::vector和std::string的原因已经基本消失了。他建议现在最好编写如下这样的函数:
std::string do_something ( std::string inval )
{
std::string return_val;
// ... do stuff ...
return return_val;
}
我知道return_val在函数返回时将是一个右值,因此可以使用move语义返回,这非常便宜。然而,inval仍然比引用(通常实现为指针)的大小大得多。这是因为std::string有各种组件,包括指向堆的指针和用于短字符串优化的成员char[]。所以在我看来,通过引用传递仍然是一个好主意。
谁能解释一下赫伯为什么会这么说?
除非你真的需要一个副本,否则使用const &仍然是合理的。例如:
bool isprint(std::string const &s) {
return all_of(begin(s),end(s),(bool(*)(char))isprint);
}
如果你改变它,以按值获取字符串,那么你最终会移动或复制参数,这是没有必要的。复制/移动不仅成本更高,而且还会带来新的潜在失败;复制/移动可能会抛出异常(例如,复制期间的分配可能会失败),而引用现有值则不会。
如果你确实需要一个副本,那么通过值传递和返回通常是(总是?)最好的选择。事实上,在c++ 03中我通常不会担心这个问题,除非你发现额外的副本实际上会导致性能问题。复制省略在现代编译器上似乎相当可靠。我认为人们的怀疑和坚持,你必须检查你的编译器支持RVO的表,现在大部分已经过时了。
简而言之,c++ 11在这方面并没有真正改变任何东西,除了那些不相信复制省略的人。
除非你真的需要一个副本,否则使用const &仍然是合理的。例如:
bool isprint(std::string const &s) {
return all_of(begin(s),end(s),(bool(*)(char))isprint);
}
如果你改变它,以按值获取字符串,那么你最终会移动或复制参数,这是没有必要的。复制/移动不仅成本更高,而且还会带来新的潜在失败;复制/移动可能会抛出异常(例如,复制期间的分配可能会失败),而引用现有值则不会。
如果你确实需要一个副本,那么通过值传递和返回通常是(总是?)最好的选择。事实上,在c++ 03中我通常不会担心这个问题,除非你发现额外的副本实际上会导致性能问题。复制省略在现代编译器上似乎相当可靠。我认为人们的怀疑和坚持,你必须检查你的编译器支持RVO的表,现在大部分已经过时了。
简而言之,c++ 11在这方面并没有真正改变任何东西,除了那些不相信复制省略的人。
问题是“const”是一个非粒度限定符。“const string ref”通常的意思是“不要修改这个字符串”,而不是“不要修改引用计数”。在c++中,根本没有办法说哪些成员是“const”。它们要么都是,要么都不是。
为了解决这个语言问题,STL可以允许“C()”在你的例子中做一个移动语义复制,并在引用计数(可变)方面尽责地忽略“const”。只要它是指定好的,这就可以了。
因为STL没有,我有一个const_cast <>的字符串版本,去掉引用计数器(没有办法在类层次结构中追溯一些可变的东西),并且-你瞧-你可以自由地传递cmstring作为const引用,并在深层函数中复制它们,一整天,没有泄漏或问题。
由于c++在这里没有提供“派生类的const粒度”,编写一个好的规范并创建一个新的“const可移动字符串”(cmstring)对象是我见过的最好的解决方案。
几乎。
在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提供的高级字符串函数。在实践中,这是一组罕见的需求。
是传递const std::string &作为参数的日子?
不。许多人采纳了这个建议(包括Dave Abrahams),并将其简化为适用于所有std::string参数——始终按值传递std::string对于任何和所有任意参数和应用程序都不是“最佳实践”,因为这些演讲/文章关注的优化只适用于有限的一组情况。
如果要返回值、改变参数或获取值,那么按值传递可以节省昂贵的复制,并提供语法上的便利。
与以往一样,当您不需要拷贝时,传递const引用可以节省大量复制。
现在来看看具体的例子:
然而,inval仍然比引用(通常实现为指针)的大小大得多。这是因为std::string有各种组件,包括指向堆的指针和用于短字符串优化的成员char[]。所以在我看来,通过引用传递仍然是一个好主意。谁能解释一下赫伯为什么会这么说?
如果考虑到堆栈大小(并且假设这不是内联/优化的),return_val + inval > return_val——IOW,可以通过在这里传递值来降低堆栈使用的峰值(注意:ABIs的过度简化)。同时,通过const引用传递可以禁用优化。这里的主要原因不是为了避免堆栈增长,而是为了确保优化可以在适用的地方执行。
通过const引用传递的日子并没有结束——规则只是比以前更复杂了。如果性能很重要,明智的做法是根据实现中使用的细节考虑如何传递这些类型。