blocks|key|1760724|text|你可以在任何地方使用智能指针！整个类的内存泄漏都会消失。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1760725|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|$]]

User smart pointers everywhere you can! Whole classes of memory leaks just go away.

blocks|key|1760776|text|您将需要查看智能指针，例如boost's+smart+pointers。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1760777|而不是|1760778|int+main()
{+
++++Object*+obj+=+new+Object();
++++//...
++++delete+obj;
}|code-block|syntax|javascript|1760779|一旦引用计数为零，boost::shared_ptr将自动删除：|1760780|int+main()
{
++++boost::shared_ptr<Object>+obj(new+Object());
++++//...
++++//+destructor+destroys+when+reference+count+is+zero
}|1760781|请注意我的上一个注释，“当引用计数为零时，这是最酷的部分。因此，如果你的对象有多个用户，你就不必跟踪该对象是否仍在使用。一旦没有人引用你的共享指针，它就会被销毁。”|1760782|然而，这并不是万能的。虽然你可以访问基指针，但除非你对它所做的事情有信心，否则你不会想把它传递给第三方API。很多时候，在创建作用域完成后，您的“发布”内容会被发送到其他线程，以便完成工作。这在Win32中的PostThreadMessage中很常见：|1760783|void+foo()
{
+++boost::shared_ptr<Object>+obj(new+Object());+

+++//+Simplified+here
+++PostThreadMessage(....,+(LPARAM)ob.get());
+++//+Destructor+destroys!+pointer+sent+to+PostThreadMessage+is+invalid!+Zohnoes!
}|1760784|像往常一样，使用任何工具来使用你的思维上限。|1760785|entityMap|0|LINK|mutability|MUTABLE|url|http://www.boost.org/doc/libs/1_36_0/libs/smart_ptr/shared_ptr.htm^0|D|M|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@$A|15|B|16|1|17]]|C|$]]|$1|D|3|E|5|6|7|18|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|19|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|1A|8|@]|9|@]|C|$]]|$1|M|3|N|5|H|7|1B|8|@]|9|@]|C|$I|J]]|$1|O|3|P|5|6|7|1C|8|@]|9|@]|C|$]]|$1|Q|3|R|5|6|7|1D|8|@]|9|@]|C|$]]|$1|S|3|T|5|H|7|1E|8|@]|9|@]|C|$I|J]]|$1|U|3|V|5|6|7|1F|8|@]|9|@]|C|$]]|$1|W|3|-4|5|6|7|1G|8|@]|9|@]|C|$]]]|X|$Y|$5|Z|10|11|C|$12|13]]]]

You'll want to look at smart pointers, such as <a href="http://www.boost.org/doc/libs/1_36_0/libs/smart_ptr/shared_ptr.htm" rel="noreferrer">boost's smart pointers</a>.

Instead of 

<pre><code>int main()
{ 
 Object* obj = new Object();
 //...
 delete obj;
}
</code></pre>

boost::shared_ptr will automatically delete once the reference count is zero:

<pre><code>int main()
{
 boost::shared_ptr&lt;Object&gt; obj(new Object());
 //...
 // destructor destroys when reference count is zero
}
</code></pre>

Note my last note, "when reference count is zero, which is the coolest part. So If you have multiple users of your object, you won't have to keep track of whether the object is still in use. Once nobody refers to your shared pointer, it gets destroyed.

This is not a panacea, however. Though you can access the base pointer, you wouldn't want to pass it to a 3rd party API unless you were confident with what it was doing. Lots of times, your "posting" stuff to some other thread for work to be done AFTER the creating scope is finished. This is common with PostThreadMessage in Win32:

<pre><code>void foo()
{
 boost::shared_ptr&lt;Object&gt; obj(new Object()); 

 // Simplified here
 PostThreadMessage(...., (LPARAM)ob.get());
 // Destructor destroys! pointer sent to PostThreadMessage is invalid! Zohnoes!
}
</code></pre>

As always, use your thinking cap with any tool...

blocks|key|1760815|text|在您的项目中共享并了解内存所有权规则。使用COM规则可以实现最佳的一致性(in参数归调用者所有，被调用者必须复制；out参数归调用者所有，如果保持引用，则被调用者必须复制；等等)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1760816|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|$]]

Share and know memory ownership rules across your project. Using the COM rules makes for the best consistency ([in] parameters are owned by the caller, callee must copy; [out] params are owned by the caller, callee must make a copy if keeping a reference; etc.)

blocks|key|1760852|text|在适当的情况下，尝试使用智能指针而不是手动管理内存。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1760853|看看Boost+lib、TR1和smart+pointers。|offset|length|1760854|此外，智能指针现在是称为C%2B%2B11的C%2B%2B标准的一部分。|1760855|entityMap|0|LINK|mutability|MUTABLE|url|http://www.boost.org/|1|http://en.wikipedia.org/wiki/Technical_Report_1|2|http://www.boost.org/doc/libs/1_36_0/libs/smart_ptr/smart_ptr.htm|3|http://en.wikipedia.org/wiki/Smart_pointer^0|0|2|9|0|C|3|1|G|E|2|0|C|5|3|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]|$D|10|E|11|1|12]|$D|13|E|14|1|15]]|A|$]]|$1|F|3|G|5|6|7|16|8|@]|9|@$D|17|E|18|1|19]]|A|$]]|$1|H|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]|R|$5|K|L|M|A|$N|S]]|T|$5|K|L|M|A|$N|U]]]]

Instead of managing memory manually, try to use smart pointers where applicable. 
Take a look at the <a href="http://www.boost.org/" rel="noreferrer">Boost lib</a>, <a href="http://en.wikipedia.org/wiki/Technical_Report_1" rel="noreferrer">TR1</a>, and <a href="http://www.boost.org/doc/libs/1_36_0/libs/smart_ptr/smart_ptr.htm" rel="noreferrer">smart pointers</a>. 
Also smart pointers are now a part of C++ standard called <a href="http://en.wikipedia.org/wiki/Smart_pointer" rel="noreferrer">C++11</a>.

blocks|key|1760880|text|阅读有关RAII的内容，确保您理解它。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1760881|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Resource_acquisition_is_initialization^0|4|4|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Read up on <a href="http://en.wikipedia.org/wiki/Resource_acquisition_is_initialization" rel="noreferrer">RAII</a> and make sure you understand it.

blocks|key|1760959|text|如果可以，请使用boost+shared_ptr和标准C%2B%2B+auto_ptr。它们传达了所有权语义。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1760960|当你返回一个auto_ptr时，你是在告诉调用者你给了他们内存的所有权。|1760961|当你返回一个shared_ptr时，你是在告诉调用者你有一个对它的引用，并且他们取得了一部分所有权，但这不仅仅是他们的责任。|1760962|这些语义也适用于参数。如果调用者传递给你一个auto_ptr，他们就是在给你所有权。|1760963|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

If you can, use boost shared_ptr and standard C++ auto_ptr. Those convey ownership semantics.

When you return an auto_ptr, you are telling the caller that you are giving them ownership of the memory.

When you return a shared_ptr, you are telling the caller that you have a reference to it and they take part of the ownership, but it isn't solely their responsibility.

These semantics also apply to parameters. If the caller passes you an auto_ptr, they are giving you ownership.

blocks|key|1761018|text|RAII是一种在C%2B%2B中流行的内存管理技术。基本上，您使用构造函数/析构函数来处理资源分配。当然，由于异常安全的原因，C%2B%2B中还有其他一些令人讨厌的细节，但基本思想非常简单。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1761019|问题通常归结为所有权问题。我强烈推荐阅读Scott+Meyer的Effective+C%2B%2B系列和Andrei+Alexandrescu的现代C%2B%2B设计系列。|1761020|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Resource_acquisition_is_initialization^0|0|4|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

One technique that has become popular with memory management in C++ is <a href="http://en.wikipedia.org/wiki/Resource_acquisition_is_initialization" rel="noreferrer">RAII</a>. Basically you use constructors/destructors to handle resource allocation. Of course there are some other obnoxious details in C++ due to exception safety, but the basic idea is pretty simple.

The issue generally comes down to one of ownership. I highly recommend reading the Effective C++ series by Scott Meyers and Modern C++ Design by Andrei Alexandrescu.

blocks|key|1761063|text|此外，如果有std库类(例如vector)，请不要使用手动分配的内存。如果你违反了这个规则，确保你有一个虚拟的析构函数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1761064|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|$]]

Also, don't use manually allocated memory if there's a std library class (e.g. vector). Make sure if you violate that rule that you have a virtual destructor.

blocks|key|1761102|text|任何函数只返回一次。这样你就可以在那里进行释放，而不会错过它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1761103|否则很容易犯错误：|1761104|new+a()
if+(Bad())+{delete+a;+return;}
new+b()
if+(Bad())+{delete+a;+delete+b;+return;}
...+//+etc.|code-block|syntax|javascript|1761105|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Exactly one return from any function. That way you can do deallocation there and never miss it.

It's too easy to make a mistake otherwise:

<pre><code>new a()
if (Bad()) {delete a; return;}
new b()
if (Bad()) {delete a; delete b; return;}
... // etc.
</code></pre>

blocks|key|1761176|text|我们用一个层包装了所有的分配函数，该层在前面附加了一个简短的字符串，在末尾附加了一个标记。举个例子，你可以调用"myalloc(+pszSomeString，iSize，iAlignment+)；或者new(+"description"，iSize+)+MyObject()；它在内部分配指定的大小，并为你的头和前哨分配足够的空间。当然，对于非调试构建，不要忘记注释掉它！这样做需要更多的内存，但好处远远大于成本。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1761177|这有三个好处--首先，它允许你通过快速搜索分配在某些“区域”中的代码，轻松快速地跟踪哪些代码正在泄漏，而不是在这些区域本应释放的时候进行清理。通过检查以确保所有前哨都完好无损来检测边界何时被覆盖，这也是有用的。当我们试图找到那些隐藏得很好的崩溃或数组错误时，这为我们节省了无数次。第三个好处是跟踪内存的使用情况，看看谁是最大的玩家--例如，当“声音”占用的空间比你预期的要多时，MemDump中某些描述的整理就会告诉你。|1761178|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|$]]

We wrap all our allocation functions with a layer that appends a brief string at the front and a sentinel flag at the end. So for example you'd have a call to "myalloc( pszSomeString, iSize, iAlignment ); or new( "description", iSize ) MyObject(); which internally allocates the specified size plus enough space for your header and sentinel. Of course, don't forget to comment this out for non-debug builds! It takes a little more memory to do this but the benefits far outweigh the costs. 

This has three benefits - first it allows you to easily and quickly track what code is leaking, by doing quick searches for code allocated in certain 'zones' but not cleaned up when those zones should have freed. It can also be useful to detect when a boundary has been overwritten by checking to ensure all sentinels are intact. This has saved us numerous times when trying to find those well-hidden crashes or array missteps. The third benefit is in tracking the use of memory to see who the big players are - a collation of certain descriptions in a MemDump tells you when 'sound' is taking up way more space than you anticipated, for example.

blocks|key|1761212|text|C%2B%2B是按照RAII的设计思想设计的。我认为在C%2B%2B中真的没有更好的方法来管理内存。但要小心，不要在本地作用域上分配非常大的块(如buffer对象)。它可能导致堆栈溢出，如果在使用该块时边界检查存在缺陷，您可能会覆盖其他变量或返回地址，这会导致各种安全漏洞。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1761213|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|$]]

C++ is designed RAII in mind. There is really no better way to manage memory in C++ I think.
But be careful not to allocate very big chunks (like buffer objects) on local scope. It can cause stack overflows and, if there is a flaw in bounds checking while using that chunk, you can overwrite other variables or return addresses, which leads to all kinds security holes.

blocks|key|1546418|text|其他人提到了避免内存泄漏的方法(比如智能指针)。但是，一旦出现内存问题，分析和内存分析工具通常是跟踪这些问题的唯一方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1546419|Valgrind+memcheck是一个优秀的免费软件。|offset|length|1546420|entityMap|0|LINK|mutability|MUTABLE|url|http://valgrind.org/info/tools.html#memcheck^0|0|0|H|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]]]]

Others have mentioned ways of avoiding memory leaks in the first place (like smart pointers). But a profiling and memory-analysis tool is often the only way to track down memory problems once you have them.

<a href="http://valgrind.org/info/tools.html#memcheck" rel="nofollow noreferrer">Valgrind memcheck</a> is an excellent free one.

blocks|key|1546485|text|我完全赞同所有关于RAII和智能指针的建议，但我还想添加一个更高级别的提示:最容易管理的内存是您从未分配过的内存。与C#和Java这样的语言不同，在C%2B%2B中，只要有可能，就应该将对象放在堆栈上。正如我看到的一些人(包括Dr.Stroustrup)指出的那样，垃圾收集在C%2B%2B中从未流行的主要原因是，编写良好的C%2B%2B从一开始就不会产生太多垃圾。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1546486|不要写|1546487|Object*+x+=+new+Object;|code-block|syntax|javascript|1546488|甚至是|1546489|shared_ptr<Object>+x(new+Object);|1546490|当你可以只写|1546491|Object+x;|1546492|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I thoroughly endorse all the advice about RAII and smart pointers, but I'd also like to add a slightly higher-level tip: the easiest memory to manage is the memory you never allocated. Unlike languages like C# and Java, where pretty much everything is a reference, in C++ you should put objects on the stack whenever you can. As I've see several people (including Dr Stroustrup) point out, the main reason why garbage collection has never been popular in C++ is that well-written C++ doesn't produce much garbage in the first place.

Don't write

<pre><code>Object* x = new Object;
</code></pre>

or even

<pre><code>shared_ptr&lt;Object&gt; x(new Object);
</code></pre>

when you can just write

<pre><code>Object x;
</code></pre>

blocks|key|1546570|text|有关在不同位置分配和销毁的唯一示例之一是线程创建(传递的参数)。但即使在这种情况下也很容易。下面是创建线程的函数/方法：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1546571|struct+myparams+{
int+x;
std::vector<double>+z;
}

std::auto_ptr<myparams>+param(new+myparams(x,+...));
//+Release+the+ownership+in+case+thread+creation+is+successfull
if+(0+==+pthread_create(&th,+NULL,+th_func,+param.get())+param.release();
...|code-block|syntax|javascript|1546572|这里使用的是线程函数|1546573|extern+"C"+void*+th_func(void*+p)+{
+++try+{
+++++++std::auto_ptr<myparams>+param((myparams*)p);
+++++++...
+++}+catch(...)+{
+++}
+++return+0;
}|1546574|很轻松，不是吗？如果线程创建失败，资源将由auto_ptr释放(删除)，否则所有权将传递给线程。如果线程太快，以至于在创建后，它会在|1546575|param.release();|1546576|在主函数/方法中被调用？没什么!因为我们将“告诉”auto_ptr忽略释放。C%2B%2B内存管理是不是很简单？干杯,|1546577|Ema！|1546578|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

One of the only examples about allocating and destroying in different places is thread creation (the parameter you pass).
But even in this case is easy.
Here is the function/method creating a thread:

<pre><code>struct myparams {
int x;
std::vector&lt;double&gt; z;
}

std::auto_ptr&lt;myparams&gt; param(new myparams(x, ...));
// Release the ownership in case thread creation is successfull
if (0 == pthread_create(&amp;th, NULL, th_func, param.get()) param.release();
...
</code></pre>

Here instead the thread function

<pre><code>extern "C" void* th_func(void* p) {
 try {
 std::auto_ptr&lt;myparams&gt; param((myparams*)p);
 ...
 } catch(...) {
 }
 return 0;
}
</code></pre>

Pretty easyn isn't it? In case the thread creation fails the resource will be free'd (deleted) by the auto_ptr, otherwise the ownership will be passed to the thread.
What if the thread is so fast that after creation it releases the resource before the

<pre><code>param.release();
</code></pre>

gets called in the main function/method? Nothing! Because we will 'tell' the auto_ptr to ignore the deallocation.
Is C++ memory management easy isn't it?
Cheers,

Ema!

blocks|key|1546646|text|仅限MSVC，将以下内容添加到每个.cpp文件的顶部：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1546647|#ifdef+_DEBUG
#define+new+DEBUG_NEW
#endif|code-block|syntax|javascript|1546648|然后，当使用VS2003或更高版本进行调试时，当您的程序退出时，您将被告知任何泄漏(它跟踪新的/删除的)。这是基本的，但它在过去对我很有帮助。|1546649|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

For MSVC only, add the following to the top of each .cpp file:

<pre><code>#ifdef _DEBUG
#define new DEBUG_NEW
#endif
</code></pre>

Then, when debugging with VS2003 or greater, you will be told of any leaks when your program exits (it tracks new/delete). It's basic, but it has helped me in the past.

blocks|key|1546756|text|这些错误的一个常见来源是，当你有一个方法，它接受一个对象的引用或指针，但所有权不明确。样式和注释约定会使这种情况变得不太可能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1546757|假设函数取得对象所有权的情况是特例。在所有发生这种情况的情况下，一定要在头文件中的函数旁边写一条注释来指明这一点。您应该努力确保在大多数情况下，分配对象的模块或类也负责释放该对象。|1546758|在某些情况下，使用const会很有帮助。如果函数不会修改对象，并且不存储在返回后持续存在的对该对象的引用，则接受const引用。从调用者的代码中可以明显看出，您的函数没有接受对象的所有权。你可以让同样的函数接受一个非常量指针，调用者可能会也可能不会假设被调用者接受了所有权，但是使用常量引用就没有问题了。|1546759|不要在参数列表中使用非常数引用。在读取调用者代码时，被调用者可能保留了对参数的引用，这一点非常不清楚。|1546760|我不同意推荐引用计数指针的评论。这通常可以很好地工作，但是当你有一个bug而它不能工作时，特别是当你的析构函数做了一些非常重要的事情时，比如在多线程程序中。如果不是太难的话，一定要试着调整你的设计，使其不需要引用计数。|1546761|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

A frequent source of these bugs is when you have a method that accepts a reference or pointer to an object but leaves ownership unclear. Style and commenting conventions can make this less likely.

Let the case where the function takes ownership of the object be the special case. In all situations where this happens, be sure to write a comment next to the function in the header file indicating this. You should strive to make sure that in most cases the module or class which allocates an object is also responsible for deallocating it.

Using const can help a lot in some cases. If a function will not modify an object, and does not store a reference to it that persists after it returns, accept a const reference. From reading the caller's code it will be obvious that your function has not accepted ownership of the object. You could have had the same function accept a non-const pointer, and the caller may or may not have assumed that the callee accepted ownership, but with a const reference there's no question.

Do not use non-const references in argument lists. It is very unclear when reading the caller code that the callee may have kept a reference to the parameter.

I disagree with the comments recommending reference counted pointers. This usually works fine, but when you have a bug and it doesn't work, especially if your destructor does something non-trivial, such as in a multithreaded program. Definitely try to adjust your design to not need reference counting if it's not too hard.

blocks|key|1761686|text|按重要性顺序排列的提示：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1761687|-Tip#1总是记得把你的析构函数声明为“虚拟的”。|1761688|-Tip#2使用率|1761689|-Tip#3使用boost的智能指针|1761690|-Tip#4不要写你自己的but智能指针，使用boost+(在我现在正在做的一个项目中，我不能使用boost，而且我不得不调试我自己的智能指针，我肯定不会再采用同样的方法，但是现在我不能向我们的依赖项添加boost+)|1761691|-Tip#5如果这是一些随意的/非性能关键的工作(就像在有数千个对象的游戏中)，那么可以看看Thorsten+Ottosen的boost指针容器|1761692|-Tip#6查找适合您选择的平台的泄漏检测标头，如视觉泄漏检测的"vld“标头|1761693|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

Tips in order of Importance:

-Tip#1 Always remember to declare your destructors "virtual".

-Tip#2 Use RAII

-Tip#3 Use boost's smartpointers

-Tip#4 Don't write your own buggy Smartpointers, use boost (on a project I'm on right now I can't use boost, and I've suffered having to debug my own smart pointers, I would definately not take the same route again, but then again right now I can't add boost to our dependencies)

-Tip#5 If its some casual/non-performance critical (as in games with thousands of objects) work look at Thorsten Ottosen's boost pointer container

-Tip#6 Find a leak detection header for your platform of choice such as Visual Leak Detection's "vld" header

blocks|key|1546927|text|管理内存的方式与管理其他资源(句柄、文件、数据库连接、套接字等)的方式相同。GC也不会帮你解决这些问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1546928|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|$]]

Manage memory the same way you manage other resources (handles, files, db connections, sockets...). GC would not help you with them either.

blocks|key|1761862|text|valgrind+(仅适用于*nix平台)是一个非常好的内存检查器|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1761863|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|$]]

valgrind (only avail for *nix platforms) is a very nice memory checker

What are some general tips to make sure I don't leak memory in C++ programs? How do I figure out who should free memory that has been dynamically allocated?

General guidelines to avoid memory leaks in C++

内存管理

数据库

容器

Java

有什么一般的技巧可以确保我不会在C++程序中泄漏内存？如何确定谁应该释放已动态分配的内存？

问避免C++中内存泄漏的一般指导原则
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问避免C++中内存泄漏的一般指导原则EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问避免C++中内存泄漏的一般指导原则
EN