我认为这有点主观;我不确定意见是否一致(我见过许多返回引用的代码片段)。
根据对我刚才问的这个问题的评论，关于初始化引用，返回一个引用可能是邪恶的，因为(据我所知)它更容易错过删除它，这可能导致内存泄漏。
这让我很担心，因为我已经遵循了一些例子(除非是我想象的事情)，并且在相当多的地方这样做了……我误解了吗?它邪恶吗?如果是的话，到底有多邪恶?
我觉得因为我的指针和引用的混合包，加上我是c++的新手，以及完全不知道什么时候用什么，我的应用程序一定是内存泄漏的地狱…
另外，我知道使用智能/共享指针被普遍认为是避免内存泄漏的最佳方法。
当前回答
一般来说，返回引用是非常正常的，并且经常发生。
如果你的意思是:
int& getInt() {
int i;
return i; // DON'T DO THIS.
}
那是各种各样的邪恶。stack-allocated 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;
}
如果生命期应该留给调用者，而你只是在计算值。
总结:如果对象的生命周期不会在调用后结束，则可以返回引用。
其他回答
对已接受答案的补充:
Struct immutableint { Immutableint (int i): i_(i) {} Const int& get() Const{返回i_;｝ 私人: 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!
它不仅不邪恶，而且有时是必不可少的。例如，如果不使用引用返回值，就不可能实现std::vector的[]操作符。
No.
不好的是引用动态分配的对象而丢失了原来的指针。当你新建一个对象时，你承担了保证删除的义务。
但是看一下，例如，操作符<<:必须返回一个引用，或者
cout << "foo" << "bar" << "bletch" << endl ;
不能工作。
我认为使用reference作为函数的返回值比使用pointer作为函数的返回值要直接得多。 其次，使用返回值所指向的静态变量总是安全的。
关于糟糕的代码:
int& getTheValue()
{
return *new int;
}
实际上，内存指针在返回后丢失。但是如果你像这样使用shared_ptr:
int& getTheValue()
{
std::shared_ptr<int> p(new int);
return *p->get();
}
内存在返回后不会丢失，并将在分配后释放。
