blocks|key|3834130|text|这不是邪恶。就像C%2B%2B中的许多东西一样，如果使用得当是很好的，但在使用它时，您应该注意许多陷阱(比如返回对局部变量的引用)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3834131|使用它可以实现一些好的功能(比如mapname+=+"hello+world")|3834132|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It's not evil. Like many things in C++, it's good if used correctly, but there are many pitfalls you should be aware of when using it (like returning a reference to a local variable).

There are good things that can be achieved with it (like map[name] = "hello world")

blocks|key|3834166|text|不是的。不，不，一千次都不是。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3834167|什么是邪恶的是引用了一个动态分配的对象，并丢失了原始指针。当您new一个对象时，您承担了拥有一个有保证的delete的义务。|offset|length|style|CODE|3834168|但是看一下，例如，operator<<：它必须返回一个引用，或者|3834169|cout+<<+"foo"+<<+"bar"+<<+"bletch"+<<+endl+;|code-block|syntax|javascript|3834170|行不通的。|3834171|entityMap^0|0|V|3|1G|6|0|9|A|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@$D|U|E|V|F|G]|$D|W|E|X|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Y|8|@$D|Z|E|10|F|G]]|9|@]|A|$]]|$1|J|3|K|5|L|7|11|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|R|$]]

No. No, no, a thousand times no.

What is evil is making a reference to a dynamically allocated object and losing the original pointer. When you <code>new</code> an object you assume an obligation to have a guaranteed <code>delete</code>.

But have a look at, eg, <code>operator&lt;&lt;</code>: that must return a reference, or 

<pre><code>cout &lt;&lt; "foo" &lt;&lt; "bar" &lt;&lt; "bletch" &lt;&lt; endl ;
</code></pre>

won't work.

blocks|key|612697|text|它不仅不是邪恶的，而且有时是必不可少的。例如，不使用引用返回值就不可能实现std::vector的[]运算符。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|612698|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Not only is it not evil, it is sometimes essential. For example, it would be impossible to implement the [] operator of std::vector without using a reference return value.

blocks|key|1173184|text|一般来说，返回一个引用是非常正常的，并且经常发生。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1173185|如果你的意思是：|1173186|int&+getInt()+{
++++int+i;
++++return+i;++//+DON'T+DO+THIS.
}|code-block|syntax|javascript|1173187|这是各种各样的邪恶。堆栈分配的i将消失，而您指的是什么也没有。这也是邪恶的：|offset|length|style|CODE|1173188|int&+getInt()+{
++++int*+i+=+new+int;
++++return+*i;++//+DON'T+DO+THIS.
}|1173189|因为现在客户端最终不得不做一些奇怪的事情：|1173190|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|1173191|请注意，右值引用仍然只是引用，因此所有恶意应用程序都保持不变。|1173192|如果要分配超出函数作用域的内容，请使用智能指针(通常是容器)：|1173193|std::unique_ptr<int>+getInt()+{
++++return+std::make_unique<int>(0);
}|1173194|现在客户端存储了一个智能指针：|1173195|std::unique_ptr<int>+x+=+getInt();|1173196|引用也可以用于访问你知道生命周期在更高级别上保持开放的事物，例如：|1173197|struct+immutableint+{
++++immutableint(int+i)+:+i_(i)+{}

++++const+int&+get()+const+{+return+i_;+}
private:
++++int+i_;
};|1173198|在这里，我们知道返回对i_的引用是可以的，因为无论调用我们什么，都会管理类实例的生命周期，所以i_至少会存在这么长时间。|1173199|当然，仅仅是这样没有什么错：|1173200|int+getInt()+{
+++return+0;
}|1173201|如果生命周期应该由调用者决定，而您只是在计算该值。|1173202|摘要:如果对象的生命周期不会在调用后结束，则可以返回引用。|1173203|entityMap^0|0|0|0|F|1|0|0|0|0|0|0|0|0|0|0|0|B|2|1B|2|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1M|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|1N|8|@$K|1O|L|1P|M|N]]|9|@]|A|$]]|$1|O|3|P|5|F|7|1Q|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|1R|8|@]|9|@]|A|$]]|$1|S|3|T|5|F|7|1S|8|@]|9|@]|A|$G|H]]|$1|U|3|V|5|6|7|1T|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1U|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|F|7|1V|8|@]|9|@]|A|$G|H]]|$1|10|3|11|5|6|7|1W|8|@]|9|@]|A|$]]|$1|12|3|13|5|F|7|1X|8|@]|9|@]|A|$G|H]]|$1|14|3|15|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|16|3|17|5|F|7|1Z|8|@]|9|@]|A|$G|H]]|$1|18|3|19|5|6|7|20|8|@$K|21|L|22|M|N]|$K|23|L|24|M|N]]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|25|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|F|7|26|8|@]|9|@]|A|$G|H]]|$1|1E|3|1F|5|6|7|27|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|28|8|@]|9|@]|A|$]]|$1|1I|3|-4|5|6|7|29|8|@]|9|@]|A|$]]]|1J|$]]

In general, returning a reference is perfectly normal and happens all the time.

If you mean:

<pre><code>int&amp; getInt() {
 int i;
 return i; // DON'T DO THIS.
}
</code></pre>

That is all sorts of evil. The stack-allocated <code>i</code> will go away and you are referring to nothing. This is also evil:

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

Because now the client has to eventually do the strange:

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

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

Note that rvalue references are still just references, so all the evil applications remain the same.

If you want to allocate something that lives beyond the scope of the function, use a smart pointer (or in general, a container):

<pre><code>std::unique_ptr&lt;int&gt; getInt() {
 return std::make_unique&lt;int&gt;(0);
}
</code></pre>

And now the client stores a smart pointer:

<pre><code>std::unique_ptr&lt;int&gt; x = getInt();
</code></pre>

References are also okay for accessing things where you know the lifetime is being kept open on a higher-level, e.g.:

<pre><code>struct immutableint {
 immutableint(int i) : i_(i) {}

 const int&amp; get() const { return i_; }
private:
 int i_;
};
</code></pre>

Here we know it's okay to return a reference to <code>i_</code> because whatever is calling us manages the lifetime of the class instance, so <code>i_</code> will live at least that long.

And of course, there's nothing wrong with just:

<pre><code>int getInt() {
 return 0;
}
</code></pre>

If the lifetime should be left up to the caller, and you're just computing the value.

Summary: it's okay to return a reference if the lifetime of the object won't end after the call.

blocks|key|3834341|text|有两种情况：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3834342|3834343|const+reference+--好主意，有时会破坏encapsulations|unordered-list-item|3834344|，特别是对于重对象或代理类、编译器优化|3834345|非常量引用--坏主意|3834346|3834347|两者都有相同的问题--可能指向被破坏的对象...|3834348|我建议在许多需要返回引用/指针的情况下使用智能指针。|3834349|另外，请注意以下几点：|3834350|有一条正式的规则--+C%2B%2B标准(如果你感兴趣的话是13.3.3.1.4节)规定，临时值只能绑定到常量引用--如果你试图使用非常数引用，编译器必须将其标记为错误。|3834351|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|X|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|Y|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

There are two cases:

<ul>
<li>const reference --good idea, sometimes, especially for heavy objects or proxy classes, compiler optimization </li>
<li>non-const reference --bad idea, sometimes, breaks encapsulations</li>
</ul>

Both share same issue -- can potentially point to destroyed object... 

I would recommend using smart pointers for many situations where you require to return a reference/pointer.

Also, note the following:

There is a formal rule - the C++ Standard (section 13.3.3.1.4 if you are interested) states that a temporary can only be bound to a const reference - if you try to use a non-const reference the compiler must flag this as an error.

blocks|key|4676764|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4676765|“返回引用是邪恶的，因为根据我的理解，它更容易错过删除它。”|blockquote|4676766|4676767|4676768|不是这样的。返回引用并不意味着所有权语义。也就是说，仅仅因为你这样做：|4676769|Value&+v+=+thing->getTheValue();|code-block|syntax|javascript|4676770|...does并不意味着你现在拥有v所指的内存；|4676771|然而，这是一个可怕的代码：|4676772|int&+getTheValue()
{
+++return+*new+int;
}|4676773|如果你这样做是因为delete+:+1)如果你需要引用就取消引用指针，2)你最终会需要指针，因为你必须将"you+don't+require+a+pointer+on+that+instance"与delete匹配，并且你需要一个指针来调用delete。|offset|length|4676774|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/752479/am-i-initializing-my-c-reference-variables-correctly^0|0|0|0|0|0|0|0|0|0|1G|1A|0|0^^$0|@$1|2|3|-4|4|5|6|14|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|15|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|16|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|17|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|18|7|@]|8|@]|9|$]]|$1|H|3|I|4|J|6|19|7|@]|8|@]|9|$K|L]]|$1|M|3|N|4|5|6|1A|7|@]|8|@]|9|$]]|$1|O|3|P|4|5|6|1B|7|@]|8|@]|9|$]]|$1|Q|3|R|4|J|6|1C|7|@]|8|@]|9|$K|L]]|$1|S|3|T|4|5|6|1D|7|@]|8|@$U|1E|V|1F|1|1G]]|9|$]]|$1|W|3|-4|4|5|6|1H|7|@]|8|@]|9|$]]]|X|$Y|$4|Z|10|11|9|$12|13]]]]

<blockquote>
 "returning a reference is evil because,
 simply [as I understand] it makes it
 easier to miss deleting it"
</blockquote>

Not true. Returning a reference does not imply ownership semantics. That is, just because you do this:

<pre><code>Value&amp; v = thing-&gt;getTheValue();
</code></pre>

...does not mean you now own the memory referred to by v;

However, this is horrible code:

<pre><code>int&amp; getTheValue()
{
 return *new int;
}
</code></pre>

If you are doing something like this because <a href="https://stackoverflow.com/questions/752479/am-i-initializing-my-c-reference-variables-correctly">"you don't require a pointer on that instance"</a> then: 1) just dereference the pointer if you need a reference, and 2) you will eventually need the pointer, because you have to match a new with a delete, and you need a pointer to call delete.

blocks|key|3834449|text|您应该返回一个对现有对象的引用，该对象不会立即消失，并且您不打算进行任何所有权转移。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3834450|永远不要返回对局部变量或类似变量的引用，因为它不会被引用。|3834451|你可以返回一个独立于函数的引用，你不希望调用的函数承担删除的责任。典型的operator[]函数就是这种情况。|offset|length|style|CODE|3834452|如果你正在创建一些东西，你应该返回值或指针(常规的或智能的)。您可以自由地返回值，因为它将进入调用函数中的变量或表达式。永远不要返回指向局部变量的指针，因为它会消失。|3834453|entityMap^0|0|0|10|A|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@$F|Q|G|R|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

You should return a reference to an existing object that isn't going away immediately, and where you don't intend any transfer of ownership.

Never return a reference to a local variable or some such, because it won't be there to be referenced.

You can return a reference to something independent of the function, which you don't expect the calling function to take the responsibility for deleting. This is the case for the typical <code>operator[]</code> function.

If you are creating something, you should return either a value or a pointer (regular or smart). You can return a value freely, since it's going into a variable or expression in the calling function. Never return a pointer to a local variable, since it will go away.

blocks|key|4676867|text|函数作为左值(也就是非常数引用的返回)应该从C%2B%2B中删除。这是非常不直观的。Scott+Meyer想要一个min()来处理这种行为。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4676868|min(a,b)+=+0;++//+What???|code-block|syntax|javascript|4676869|这并不是真正的改进|4676870|setmin+(a,+b,+0);|4676871|后者甚至更有意义。|4676872|我意识到作为左值函数对于C%2B%2B样式流很重要，但值得指出的是，C%2B%2B样式流非常糟糕。我不是唯一这么想的人。我记得Alexandrescu有一篇关于如何做得更好的大文章，我相信boost也试图创建一个更好的类型安全的I/O方法。|4676873|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

Function as lvalue (aka, returning of non-const references) should be removed from C++. It's terribly unintuitive. Scott Meyers wanted a min() with this behavior.

<pre><code>min(a,b) = 0; // What???
</code></pre>

which isn't really an improvement on

<pre><code>setmin (a, b, 0);
</code></pre>

The latter even makes more sense.

I realize that function as lvalue is important for C++ style streams, but it's worth pointing out that C++ style streams are terrible. I'm not the only one that thinks this... as I recall Alexandrescu had a large article on how to do better, and I believe boost has also tried to create a better type safe I/O method.

blocks|key|1166397|text|我遇到了一个真正的问题，它确实是邪恶的。本质上，开发人员返回了对向量中的对象的引用。太糟糕了！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1166398|我在一月份写过的完整细节：http://developer-resource.blogspot.com/2009/01/pros-and-cons-of-returing-references.html|offset|length|1166399|entityMap|0|LINK|mutability|MUTABLE|url|http://developer-resource.blogspot.com/2009/01/pros-and-cons-of-returing-references.html^0|0|D|2G|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

I ran into a real problem where it was indeed evil. Essentially a developer returned a reference to an object in a vector. That was Bad!!!

The full details I wrote about in Janurary: <a href="http://developer-resource.blogspot.com/2009/01/pros-and-cons-of-returing-references.html" rel="nofollow noreferrer">http://developer-resource.blogspot.com/2009/01/pros-and-cons-of-returing-references.html</a>

blocks|key|3834606|text|关于可怕的代码：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3834607|int&+getTheValue()
{
+++return+*new+int;
}|code-block|syntax|javascript|3834608|所以，实际上，返回后内存指针丢失了。但是如果你像这样使用shared_ptr：|3834609|int&+getTheValue()
{
+++std::shared_ptr<int>+p(new+int);
+++return+*p->get();
}|3834610|返回后内存不会丢失，分配后将被释放。|3834611|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

About horrible code:

<pre><code>int&amp; getTheValue()
{
 return *new int;
}
</code></pre>

So, indeed, memory pointer lost after return. But if you use shared_ptr like that:

<pre><code>int&amp; getTheValue()
{
 std::shared_ptr&lt;int&gt; p(new int);
 return *p-&gt;get();
}
</code></pre>

Memory not lost after return and will be freed after assignment.

blocks|key|4676990|text|返回引用通常用于大型对象的C%2B%2B中的操作符重载，因为返回值需要复制操作。(在运算符重载中，我们通常不使用指针作为返回值)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4676991|但是返回引用可能会导致内存分配问题。由于对结果的引用将作为对返回值的引用传递到函数外部，因此返回值不能是自动变量。|4676992|如果你想使用返回引用，你可以使用一个静态对象缓冲区。例如|4676993|const+max_tmp=5;+
Obj&+get_tmp()
{
+static+int+buf=0;
+static+Obj+Buf[max_tmp];
++if(buf==max_tmp)+buf=0;
++return+Buf[buf%2B%2B];
}
Obj&+operator%2B(const+Obj&+o1,+const+Obj&+o1)
{
+Obj&+res=get_tmp();
+//+%2Boperation
++return+res;
+}|code-block|syntax|javascript|4676994|通过这种方式，您可以安全地使用返回引用。|4676995|但是你可以在函数中使用指针而不是引用来返回值。|4676996|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|T|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

return reference is usually used in operator overloading in C++ for large Object, because returning a value need copy operation.(in perator overloading, we usually don't use pointer as return value)

But return reference may cause memory allocation problem. Because a reference to the result will be passed out of the function as a reference to the return value, the return value cannot be an automatic variable.

if you want use returning refernce, you may use a buffer of static object.
for example

<pre><code>const max_tmp=5; 
Obj&amp; get_tmp()
{
 static int buf=0;
 static Obj Buf[max_tmp];
 if(buf==max_tmp) buf=0;
 return Buf[buf++];
}
Obj&amp; operator+(const Obj&amp; o1, const Obj&amp; o1)
{
 Obj&amp; res=get_tmp();
 // +operation
 return res;
 }
</code></pre>

in this way, you could use returning reference safely.

But you could always use pointer instead of reference for returning value in functiong.

blocks|key|3834689|text|我认为使用引用作为函数的返回值要比使用指针作为函数的返回值简单得多。其次，使用返回值引用的静态变量总是安全的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3834690|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

i think using reference as the return value of the function is much more straight forward than using pointer as the return value of the function. 
Secondly It would be always safe to use static variable to which the return value refer to.

blocks|key|613170|text|最好的方法是创建对象，并将其作为引用/指针参数传递给分配此变量的函数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|613171|在函数中分配对象并将其作为引用或指针返回(指针更安全)不是一个好主意，因为在函数块的末尾会释放内存。|613172|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Best thing is to create object and pass it as reference/pointer parameter to a function which allocates this variable. 

Allocating object in function and returning it as a reference or pointer (pointer is safer however) is bad idea because of freeing memory at the end of function block.

blocks|key|4677090|text|我发现答案不令人满意，所以我将补充我的两点意见。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4677091|我们来分析一下以下几个案例：|4677092|错误用法|4677093|int&+getInt()
{
++++int+x+=+4;
++++return+x;
}|code-block|syntax|javascript|4677094|这显然是错误的|4677095|int&+x+=+getInt();+//+will+refer+to+garbage|4677096|与静态变量一起使用|4677097|int&+getInt()
{
+++static+int+x+=+4;
+++return+x;
}|4677098|这是正确的，因为静态变量在程序的整个生命周期中都存在。|4677099|int&+x+=+getInt();+//+valid+reference,+x+=+4|4677100|这在实现Singleton模式时也很常见|4677101|Class+Singleton
{
++++public:
++++++++static+Singleton&+instance()
++++++++{
++++++++++++static+Singleton+instance;
++++++++++++return+instance;
++++++++};

++++++++void+printHello()
++++++++{
+++++++++++++printf("Hello");
++++++++};

}|4677102|用法：|4677103|+Singleton&+my_sing+=+Singleton::instance();+//+Valid+Singleton+instance
+my_sing.printHello();++//+"Hello"|4677104|运算符|4677105|标准库容器很大程度上依赖于返回引用的运算符的使用，例如|4677106|T+&+operator*();|4677107|可以在以下情况下使用|4677108|std::vector<int>+x+=+{1,+2,+3};+//+create+vector+with+3+elements
std::vector<int>::iterator+iter+=+x.begin();+//+iterator+points+to+first+element+(1)
*iter+=+2;+//+modify+first+element,+x+=+{2,+2,+3}+now|4677109|快速访问内部数据|4677110|有时，&可用于快速访问内部数据|4677111|Class+Container
{
++++private:
++++++++std::vector<int>+m_data;

++++public:
++++++++std::vector<int>&+data()
++++++++{
+++++++++++++return+m_data;
++++++++}
}|4677112|使用用法：|4677113|Container+cont;
cont.data().push_back(1);+//+appends+element+to+std::vector<int>
cont.data()[0]+//+1|4677114|然而，这可能会导致这样的陷阱：|4677115|Container*+cont+=+new+Container;
std::vector<int>&+cont_data+=+cont->data();
cont_data.push_back(1);
delete+cont;+//+This+is+bad,+because+we+still+have+a+dangling+reference+to+its+internal+data!
cont_data[0];+//+dangling+reference!|4677116|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1W|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1X|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|1Z|8|@]|9|@]|A|$I|J]]|$1|O|3|P|5|6|7|20|8|@]|9|@]|A|$]]|$1|Q|3|R|5|H|7|21|8|@]|9|@]|A|$I|J]]|$1|S|3|T|5|6|7|22|8|@]|9|@]|A|$]]|$1|U|3|V|5|H|7|23|8|@]|9|@]|A|$I|J]]|$1|W|3|X|5|6|7|24|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|H|7|25|8|@]|9|@]|A|$I|J]]|$1|10|3|11|5|6|7|26|8|@]|9|@]|A|$]]|$1|12|3|13|5|H|7|27|8|@]|9|@]|A|$I|J]]|$1|14|3|15|5|6|7|28|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|29|8|@]|9|@]|A|$]]|$1|18|3|19|5|H|7|2A|8|@]|9|@]|A|$I|J]]|$1|1A|3|1B|5|6|7|2B|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|H|7|2C|8|@]|9|@]|A|$I|J]]|$1|1E|3|1F|5|6|7|2D|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|2E|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|H|7|2F|8|@]|9|@]|A|$I|J]]|$1|1K|3|1L|5|6|7|2G|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|H|7|2H|8|@]|9|@]|A|$I|J]]|$1|1O|3|1P|5|6|7|2I|8|@]|9|@]|A|$]]|$1|1Q|3|1R|5|H|7|2J|8|@]|9|@]|A|$I|J]]|$1|1S|3|-4|5|6|7|2K|8|@]|9|@]|A|$]]]|1T|$]]

I find the answers not satisfactory so I'll add my two cents.

Let's analyze the following cases:

<h1>Erroneous usage</h1>

<pre><code>int&amp; getInt()
{
 int x = 4;
 return x;
}
</code></pre>

This is obviously error

<pre><code>int&amp; x = getInt(); // will refer to garbage
</code></pre>

<h1>Usage with static variables</h1>

<pre><code>int&amp; getInt()
{
 static int x = 4;
 return x;
}
</code></pre>

This is right, because static variables are existant throughout lifetime of a program.

<pre><code>int&amp; x = getInt(); // valid reference, x = 4
</code></pre>

This is also quite common when implementing Singleton pattern

<pre><code>Class Singleton
{
 public:
 static Singleton&amp; instance()
 {
 static Singleton instance;
 return instance;
 };

 void printHello()
 {
 printf("Hello");
 };

}
</code></pre>

Usage:

<pre><code> Singleton&amp; my_sing = Singleton::instance(); // Valid Singleton instance
 my_sing.printHello(); // "Hello"
</code></pre>

<h1>Operators</h1>

Standard library containers depend heavily upon usage of operators which return reference, for example

<pre><code>T &amp; operator*();
</code></pre>

may be used in the following

<pre><code>std::vector&lt;int&gt; x = {1, 2, 3}; // create vector with 3 elements
std::vector&lt;int&gt;::iterator iter = x.begin(); // iterator points to first element (1)
*iter = 2; // modify first element, x = {2, 2, 3} now
</code></pre>

<h1>Quick access to internal data</h1>

There are times when &amp; may be used for quick access to internal data

<pre><code>Class Container
{
 private:
 std::vector&lt;int&gt; m_data;

 public:
 std::vector&lt;int&gt;&amp; data()
 {
 return m_data;
 }
}
</code></pre>

with usage:

<pre><code>Container cont;
cont.data().push_back(1); // appends element to std::vector&lt;int&gt;
cont.data()[0] // 1
</code></pre>

HOWEVER, this may lead to pitfall such as this:

<pre><code>Container* cont = new Container;
std::vector&lt;int&gt;&amp; cont_data = cont-&gt;data();
cont_data.push_back(1);
delete cont; // This is bad, because we still have a dangling reference to its internal data!
cont_data[0]; // dangling reference!
</code></pre>

blocks|key|613235|text|++++Class+Set+{
++++int+*ptr;
++++int+size;

++++public:+
++++Set(){
+++++size+=0;
+++++++++}

+++++Set(int+size)+{
++++++this->size+=+size;
++++++ptr+=+new+int+[size];
+++++}

++++int&+getPtr(int+i)+{
+++++return+ptr[i];++//+bad+practice+
+++++}
++};|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|613236|getPtr函数可以在删除后访问动态内存，甚至可以访问空对象。这可能会导致糟糕的访问异常。相反，应该实现getter和setter，并在返回之前验证大小。|unstyled|613237|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$B|C]]|$1|D|3|E|5|F|7|J|8|@]|9|@]|A|$]]|$1|G|3|-4|5|F|7|K|8|@]|9|@]|A|$]]]|H|$]]

<pre><code> Class Set {
 int *ptr;
 int size;

 public: 
 Set(){
 size =0;
 }

 Set(int size) {
 this-&gt;size = size;
 ptr = new int [size];
 }

 int&amp; getPtr(int i) {
 return ptr[i]; // bad practice 
 }
 };
</code></pre>

getPtr function can access dynamic memory after deletion or even a null object. Which can cause Bad Access Exceptions. Instead getter and setter should be implemented and size verified before returning.

blocks|key|4677182|text|对可接受答案的添加：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|4677183|返回结构|4677184|+{+immutableint(int+i)：i_(i)+{}+const+int&+get()+const+{+return+i_；}+private:+int+i_；}；|blockquote|4677185|4677186|4677187|我认为这个例子是不好的，如果可能的话，应该避免使用。为什么？很容易得到一个悬空的引用。|4677188|用一个例子来说明这一点：|4677189|struct+Foo
{
++++Foo(int+i+=+42)+:+boo_(i)+{}
++++immutableint+boo()
++++{
++++++++return+boo_;
++++}++
private:
++++immutableint+boo_;
};|code-block|syntax|javascript|4677190|进入危险区域：|4677191|Foo+foo;
const+int&+dangling+=+foo.boo().get();+//+dangling+reference!|4677192|entityMap^0|7|3|0|0|0|0|0|11|5|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@$9|12|A|13|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|14|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|15|8|@]|D|@]|E|$]]|$1|K|3|-4|5|6|7|16|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|17|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|18|8|@$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|O|3|P|5|6|7|1B|8|@]|D|@]|E|$]]|$1|Q|3|R|5|S|7|1C|8|@]|D|@]|E|$T|U]]|$1|V|3|W|5|6|7|1D|8|@]|D|@]|E|$]]|$1|X|3|Y|5|S|7|1E|8|@]|D|@]|E|$T|U]]|$1|Z|3|-4|5|6|7|1F|8|@]|D|@]|E|$]]]|10|$]]

Addition to the accepted answer:

<blockquote>
<pre><code>struct immutableint {
 immutableint(int i) : i_(i) {}

 const int&amp; get() const { return i_; }
private:
 int i_;
};
</code></pre>
</blockquote>

I'd argue that this example is not okay and should be avoided if possible. Why? It is very easy to end-up with a dangling reference. 

To illustrate the point with an example:

<pre><code>struct Foo
{
 Foo(int i = 42) : boo_(i) {}
 immutableint boo()
 {
 return boo_;
 } 
private:
 immutableint boo_;
};
</code></pre>

entering the danger-zone:

<pre><code>Foo foo;
const int&amp; dangling = foo.boo().get(); // dangling reference!
</code></pre>

This is a little subjective I think; I'm not sure if the opinion will be unanimous (I've seen a lot of code snippets where references are returned).

According to a comment toward <a href="https://stackoverflow.com/questions/752479/am-i-initializing-my-c-reference-variables-correctly">this question I just asked, regarding initializing references</a>, returning a reference can be evil because, [as I understand] it makes it easier to miss deleting it, which can lead to memory leaks.

This worries me, as I have followed examples (unless I'm imagining things) and done this in a fair few places... Have I misunderstood? Is it evil? If so, just how evil?

I feel that because of my mixed bag of pointers and references, combined with the fact that I'm new to C++, and total confusion over what to use when, my applications must be memory leak hell...

Also, I understand that using smart/shared pointers is generally accepted as the best way to avoid memory leaks.

Is the practice of returning a C++ reference variable evil?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我认为这有点主观；我不确定是否会有一致的意见(我已经看到了很多返回引用的代码片段)。根据对的评论，返回引用可能是邪恶的，因为据我所知，它更容易错过删除它，这可能会导致内存泄漏。这让我很担心，因为我遵循了示例(除非我是在想象)，并在相当多的地方做到了这一点……我是不是误解了？它是邪恶的吗？如果是这样的话，到底有多邪恶？我...

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

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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