返回对对象的常量引用而不是副本

Question

在重构一些代码时，我遇到了一些返回 std::string 的 getter 方法。 例如这样的事情：

class foo
{
private:
    std::string name_;
public:
    std::string name()
    {
        return name_;
    }
};

当然，吸气剂会更好地返回一个const std::string& ？ 当前方法正在返回一个效率不高的副本。 返回 const 引用会导致任何问题吗？

Answer 1

这可能导致问题的唯一方法是调用者存储引用而不是复制字符串，并在对象销毁后尝试使用它。 像这样：

foo *pFoo = new foo;
const std::string &myName = pFoo->getName();
delete pFoo;
cout << myName;  // error! dangling reference

但是，由于您现有的函数返回一个副本，因此您不会破坏任何现有代码。

编辑：现代 C++（即 C++11 及更高版本）支持返回值优化，因此不再反对按值返回内容。 仍然应该注意按值返回非常大的对象，但在大多数情况下应该没问题。

Answer 2

实际上，另外一个问题特别是与通过引用不返回一个字符串，是这样的事实std::string提供了通过指针访问内部const char*经由c_str（）方法。 这让我在调试过程中头疼了好几个小时。 例如，假设我想从 foo 获取名称，并将其传递给 JNI 以用于构造一个 jstring，以便稍后传递给 Java，并且name()返回的是副本而不是引用。 我可能会这样写：

foo myFoo = getFoo(); // Get the foo from somewhere.
const char* fooCName = foo.name().c_str(); // Woops!  foo.name() creates a temporary that's destructed as soon as this line executes!
jniEnv->NewStringUTF(fooCName);  // No good, fooCName was released when the temporary was deleted.

如果您的调用者打算做这种事情，最好使用某种类型的智能指针或常量引用，或者至少在您的 foo.name() 方法上有一个令人讨厌的警告注释标题。 我提到 JNI 是因为以前的 Java 编码人员可能特别容易受到这种在其他方面看起来无害的方法链的影响。

Answer 3

const 引用返回的一个问题是，如果用户编码如下：

const std::string & str = myObject.getSomeString() ;

使用std::string返回，临时对象将保持活动状态并附加到 str 直到 str 超出范围。

但是const std::string &会发生什么？ 我的猜测是，当它的父对象释放它时，我们会有一个对可能死亡的对象的 const 引用：

MyObject * myObject = new MyObject("My String") ;
const std::string & str = myObject->getSomeString() ;
delete myObject ;
// Use str... which references a destroyed object.

所以我更喜欢 const 引用返回（因为，无论如何，我只是更喜欢发送引用而不是希望编译器优化额外的临时文件），只要遵守以下约定：“如果你想要它超越我的对象的存在，他们在我的对象销毁之前复制它”

Answer 4

std::string 的一些实现使用 copy-on-write 语义共享内存，因此按值返回几乎与按引用返回一样有效，您不必担心生命周期问题（运行时给你）。

如果您担心性能，请对其进行基准测试（<= 强调不够）！！！ 尝试两种方法并测量增益（或缺乏）。 如果一个更好，并且您真的很在意，那就使用它。 如果没有，那么更喜欢按价值来保护它提供的其他人提到的终生问题。

你知道他们对假设的看法...

Answer 5

好的，所以返回副本和返回引用之间的区别是：

• 性能：返回引用可能会更快，也可能不会更快； 这取决于编译器实现如何实现std::string （正如其他人指出的那样）。 但即使您返回引用，函数调用后的赋值通常也涉及副本，如std::string name = obj.name();

• 安全：返回引用可能会也可能不会导致问题（悬空引用）。 如果您的函数的用户不知道他们在做什么，将引用存储为引用并在提供对象超出范围后使用它，那么就会出现问题。

如果你想快速安全地使用boost::shared_ptr 。 您的对象可以在内部将字符串存储为shared_ptr并返回shared_ptr 。 这样，就不会复制对象，并且它始终是安全的（除非您的用户使用get()取出原始指针并在您的对象超出范围后对其进行处理）。

Answer 6

我将其更改为返回 const std::string&。 如果您不更改所有调用代码，调用者可能无论如何都会复制结果，但这不会引入任何问题。

如果您有多个线程调用 name()，则会出现一种潜在问题。 如果您返回一个引用，但随后更改了基础值，则调用者的值将更改。 但是现有的代码无论如何看起来都不是线程安全的。

看看 Dima 对相关的潜在但不太可能的问题的回答。

Answer 7

可以想象，如果调用者真的想要副本，您可以破坏某些内容，因为他们即将更改原件并想要保留它的副本。 然而，它更有可能实际上只是返回一个 const 引用。

最简单的方法是尝试一下，然后测试它是否仍然有效，前提是您有某种可以运行的测试。 如果没有，我会先专注于编写测试，然后再继续重构。

Answer 8

如果您更改为 const 引用，那么该函数的典型用法不会中断，可能性非常大。

如果调用该函数的所有代码都在您的控制之下，只需进行更改并查看编译器是否会报错。

Answer 9

有关系吗？ 一旦您使用现代优化编译器，按值返回的函数将不会涉及副本，除非它们在语义上需要。

请参阅C++ lite FAQ 。

Answer 10

取决于你需要做什么。 也许您希望所有调用者在不更改类的情况下更改返回值。 如果您返回不会飞行的常量引用。

当然，下一个论点是调用者可以制作自己的副本。 但是，如果您知道如何使用该函数并且知道无论如何都会发生这种情况，那么这样做可能会在代码中节省一步。

Answer 11

我通常返回 const& 除非我不能。 QBziZ 举例说明了这种情况。 当然 QBziZ 还声称 std::string 具有写时复制语义，这在今天很少正确，因为 COW 在多线程环境中涉及大量开销。 通过返回 const & 你把责任放在调用者身上，用他们的字符串做正确的事情。 但是，由于您正在处理已经在使用的代码，因此您可能不应该更改它，除非分析表明复制此字符串会导致大量性能问题。 然后，如果您决定更改它，则需要彻底测试以确保没有损坏任何东西。 希望与您合作的其他开发人员不要像 Dima 的回答那样做粗略的事情。

Answer 12

返回对成员的引用公开了类的实现。 这可能会阻止更改类。 如果需要优化，可能对私有或受保护的方法有用。 C++ getter 应该返回什么