返回 C 引用变量的做法是邪恶的吗？

Question

我认为这有点主观；我不确定意见是否一致（我已经看到很多返回引用的代码片段）。

根据 我刚刚问过的对这个问题的评论，关于初始化引用，返回引用可能是邪恶的，因为[据我了解]它更容易错过删除它，这可能导致内存泄漏。

这让我很担心，因为我已经遵循了一些例子（除非我在想象事情）并且在很多地方都这样做了……我误解了吗？是邪恶的吗？如果是这样，到底有多邪恶？

我觉得由于我的指针和引用混杂在一起，再加上我是 C++ 新手，以及对何时使用什么的完全困惑，我的应用程序一定是内存泄漏地狱……

此外，我了解使用智能/共享指针通常被认为是避免内存泄漏的最佳方法。

原文由 Nick Bolton 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

一般来说，返回一个引用是完全正常的，并且一直在发生。

如果你的意思是：

 int& getInt() {
    int i;
    return i;  // DON'T DO THIS.
}

那是各种邪恶。堆栈分配的 i 会消失，你什么都没有提到。这也是邪恶的：

 int& getInt() {
    int* i = new int;
    return *i;  // DON'T DO THIS.
}

因为现在客户最终不得不做奇怪的事情：

 int& myInt = getInt(); // note the &, we cannot lose this reference!
delete &myInt;         // must delete...totally weird and  evil

int oops = getInt();
delete &oops; // undefined behavior, we're wrongly deleting a copy, not the original

请注意，右值引用仍然只是引用，因此所有邪恶的应用程序都保持不变。

如果要分配超出函数范围的内容，请使用智能指针（或通常是容器）：

 std::unique_ptr<int> getInt() {
    return std::make_unique<int>(0);
}

现在客户端存储了一个智能指针：

 std::unique_ptr<int> x = getInt();

引用也可以访问您知道生命周期在更高级别上保持开放的事物，例如：

 struct immutableint {
    immutableint(int i) : i_(i) {}

    const int& get() const { return i_; }
private:
    int i_;
};

在这里，我们知道返回对 i_ 的引用是可以的，因为无论调用我们什么都管理类实例的生命周期，所以 i_ 将至少存活那么久。

当然，只要：

 int getInt() {
   return 0;
}

如果生命周期应该由调用者决定，而您只是在计算值。

摘要：如果对象的生命周期在调用后不会结束，则可以返回引用。

原文由 GManNickG 发布，翻译遵循 CC BY-SA 3.0 许可协议

Answer 2

除了接受的答案：

>  struct immutableint {
>     immutableint(int i) : i_(i) {}
>
>     const int& get() const { return i_; }
> private:
>     int i_;
> };
>
> ```

我认为这个例子 **不好**，如果可能的话应该避免。为什么？很容易得到一个 **悬空的引用**。

用一个例子来说明这一点：

struct Foo { Foo(int i = 42) : boo(i) {} immutableint boo() { return boo; } private: immutableint boo_; };

进入危险区：

Foo foo; const int& dangling = foo.boo().get(); // dangling reference!

”`

原文由 AMA 发布，翻译遵循 CC BY-SA 3.0 许可协议