blocks|key|3286800|text|我有一个更好的最佳实践:尽可能结束变量的作用域！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3286801|{
++++Foo*+pFoo+=+new+Foo;
++++//+use+pFoo
++++delete+pFoo;
}|code-block|syntax|javascript|3286802|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I've got an even better best practice: Where possible, end the variable's scope!

<pre><code>{
 Foo* pFoo = new Foo;
 // use pFoo
 delete pFoo;
}
</code></pre>

blocks|key|3286820|text|如果delete后面有更多代码，则为Yes。当在构造函数中或在方法或函数的结尾处删除指针时，No.|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3286821|这个寓言的要点是提醒程序员，在运行时，对象已经被删除。|3286822|更好的做法是使用智能指针(共享的或作用域的)，它可以自动删除它们的目标对象。|3286823|entityMap^0|2|6|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|K|$]]

If there is more code after the <code>delete</code>, Yes. When the pointer is deleted in a constructor or at the end of method or function, No. 

The point of this parable is to remind the programmer, during run-time, that the object has already been deleted.

An even better practice is to use Smart Pointers (shared or scoped) which automagically delete their target objects.

blocks|key|325169|text|在删除指针所指向的内容后，将指针设置为NULL当然不会有什么坏处，但在一个更基本的问题上，这通常是一个创可贴:为什么要首先使用指针？我可以看到两个典型的原因：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|325170|325171|你只是想要在堆上分配一些东西。在这种情况下，将其包装在RAII对象中会更安全、更干净。当您不再需要RAII对象时，结束该对象的作用域。这就是std::vector的工作方式，它解决了意外地留下指向释放的内存的指针的问题。没有指针，|unordered-list-item|offset|length|style|CODE|325172|，|325173|，或者你想要一些复杂的共享所有权语义。从new返回的指针可能与调用delete的指针不同。多个对象可能同时使用了该对象。在这种情况下，最好使用共享指针或类似的指针。|325174|325175|我的经验法则是，如果你在用户代码中留下指针，你就做错了。指针不应该一开始就指向垃圾。为什么没有一个对象来负责确保它的有效性？当指向的对象结束时，它的作用域为什么不结束呢？|325176|entityMap^0|0|0|1Y|B|0|0|K|3|X|6|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|U|8|@$F|V|G|W|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|X|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|Y|8|@$F|Z|G|10|H|I]|$F|11|G|12|H|I]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|R|$]]

Setting pointers to NULL after you've deleted what it pointed to certainly can't hurt, but it's often a bit of a band-aid over a more fundamental problem: Why are you using a pointer in the first place? I can see two typical reasons:

<ul>
<li>You simply wanted something allocated on the heap. In which case wrapping it in a RAII object would have been much safer and cleaner. End the RAII object's scope when you no longer need the object. That's how <code>std::vector</code> works, and it solves the problem of accidentally leaving pointers to deallocated memory around. There are no pointers.</li>
<li>Or perhaps you wanted some complex shared ownership semantics. The pointer returned from <code>new</code> might not be the same as the one that <code>delete</code> is called on. Multiple objects may have used the object simultaneously in the meantime. In that case, a shared pointer or something similar would have been preferable.</li>
</ul>

My rule of thumb is that if you leave pointers around in user code, you're Doing It Wrong. The pointer shouldn't be there to point to garbage in the first place. Why isn't there an object taking responsibility for ensuring its validity? Why doesn't its scope end when the pointed-to object does?

blocks|key|3073458|text|首先，关于这个和密切相关的主题有很多现有的问题，例如Why+doesn't+delete+set+the+pointer+to+NULL?。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3073459|在您的代码中，问题是在中发生了什么(使用p)。例如，如果你在某个地方有这样的代码：|3073460|Foo+*+p2+=+p;|code-block|syntax|javascript|3073461|然后，将p设置为NULL效果很小，因为您仍然需要担心指针p2。|3073462|这并不是说将指针设置为NULL总是没有意义的。例如，如果p是指向一个资源的成员变量，该资源的生命周期与包含p的类的生命周期不完全相同，那么将p设置为NULL可能是指示资源存在与否的一种有用的方法。|3073463|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/704466/why-doesnt-delete-set-the-pointer-to-null^0|Q|17|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@$A|X|B|Y|1|Z]]|C|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|11|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|C|$]]|$1|O|3|-4|5|6|7|14|8|@]|9|@]|C|$]]]|P|$Q|$5|R|S|T|C|$U|V]]]]

Firstly, there are a lot of existing questions on this and closely related topics, for example <a href="https://stackoverflow.com/questions/704466/why-doesnt-delete-set-the-pointer-to-null">Why doesn&#39;t delete set the pointer to NULL?</a>.

In your code, the issue what goes on in (use p). For example, if somewhere you have code like this:

<pre><code>Foo * p2 = p;
</code></pre>

then setting p to NULL accomplishes very little, as you still have the pointer p2 to worry about.

This is not to say that setting a pointer to NULL is always pointless. For example, if p were a member variable pointing to a resource who's lifetime was not exactly the same as the class containing p, then setting p to NULL could be a useful way of indicating the presence or absence of the resource.

blocks|key|323147|text|让我来扩展一下你已经在问题中提出的内容。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|323148|以下是您在问题中以项目符号形式提出的内容：|323149|323150|在C%2B%2B中，在delete之后设置指向NULL的指针并不是一种通用的良好做法。在某些情况下：|323151|323152|在没有意义并且可以隐藏错误的时候执行|unordered-list-item|323153|是一件好事。|323154|323155|323156|然而，这并不是一件坏事！你不会通过显式地清空它来引入更多的bug，你不会泄漏内存，你不会导致未定义的行为发生。|323157|因此，如果有疑问，只需将其设为空。|323158|话虽如此，如果你觉得你必须显式地将某个指针设为空，那么在我看来，这听起来好像你对一个方法的拆分还不够，应该看看称为“提取方法”的重构方法，将该方法拆分成不同的部分。|323159|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|E|3|F|5|6|7|Z|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|J|7|12|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|15|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|16|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|17|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|V|$]]

Let me expand what you've already put into your question.

Here's what you've put into your question, in bullet-point form:

<hr>

Setting pointers to NULL following delete is not universal good practice in C++. There are times when:

<ul>
<li>it is a good thing to do</li>
<li>and times when it is pointless and can hide errors.</li>
</ul>

<hr>

However, there is no times when this is bad! You will not introduce more bugs by explicitly nulling it, you will not leak memory, you will not cause undefined behaviour to happen.

So, if in doubt, just null it.

Having said that, if you feel that you have to explicitly null some pointer, then to me this sounds like you haven't split up a method enough, and should look at the refactoring approach called "Extract method" to split up the method into separate parts.

blocks|key|3287046|text|总是有Dangling+Pointers需要担心。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3287047|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Dangling_pointer^0|3|H|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]]]]

There is always <a href="http://en.wikipedia.org/wiki/Dangling_pointer" rel="nofollow noreferrer">Dangling Pointers</a> to worry about.

blocks|key|323166|text|将指针设置为0(在标准C%2B%2B中为"+NULL“，从C定义的NULL略有不同)可避免在双重删除时崩溃。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|323167|请考虑以下几点：|323168|Foo*+foo+=+0;+//+Sets+the+pointer+to+0+(C%2B%2B+NULL)
delete+foo;+//+Won't+do+anything|code-block|syntax|javascript|323169|鉴于：|323170|Foo*+foo+=+new+Foo();
delete+foo;+//+Deletes+the+object
delete+foo;+//+Undefined+behavior+|323171|换句话说，如果你不把删除的指针设置为0，如果你在做双重删除，你就会遇到麻烦。反对在删除后将指针设置为0的论点是，这样做只是掩盖了双重删除错误，而不处理它们。|323172|显然，最好不要有双重删除错误，但根据所有权语义和对象生命周期，这在实践中可能很难实现。比起UB，我更喜欢屏蔽的双重删除错误。|323173|最后，关于管理对象分配的附注，我建议您看一下用于严格/单一所有权的std::unique_ptr，用于共享所有权的std::shared_ptr，或者其他智能指针实现，具体取决于您的需求。|offset|length|style|CODE|323174|entityMap^0|0|0|0|0|0|0|0|X|F|1L|F|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|12|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|15|8|@$S|16|T|17|U|V]|$S|18|T|19|U|V]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|X|$]]

Setting a pointer to 0 (which is "null" in standard C++, the NULL define from C is somewhat different) avoids crashes on double deletes.

Consider the following:

<pre><code>Foo* foo = 0; // Sets the pointer to 0 (C++ NULL)
delete foo; // Won't do anything
</code></pre>

Whereas:

<pre><code>Foo* foo = new Foo();
delete foo; // Deletes the object
delete foo; // Undefined behavior 
</code></pre>

In other words, if you don't set deleted pointers to 0, you will get into trouble if you're doing double deletes. An argument against setting pointers to 0 after delete would be that doing so just masks double delete bugs and leaves them unhandled.

It's best to not have double delete bugs, obviously, but depending on ownership semantics and object lifecycles, this can be hard to achieve in practice. I prefer a masked double delete bug over UB.

Finally, a sidenote regarding managing object allocation, I suggest you take a look at <code>std::unique_ptr</code> for strict/singular ownership, <code>std::shared_ptr</code> for shared ownership, or another smart pointer implementation, depending on your needs.

blocks|key|3073704|text|如果您打算在再次使用指针之前重新分配它(取消引用它，将它传递给函数等)，那么将指针设为NULL只是一个额外的操作。但是，如果您不确定在再次使用它之前是否会重新分配它，那么将它设置为NULL是一个好主意。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3073705|正如许多人所说，只使用智能指针当然要容易得多。|3073706|编辑:正如Thomas+Matthews在this+earlier+answer中所说，如果在析构函数中删除了一个指针，就不需要给它赋空，因为它不会被再次使用，因为这个对象已经被销毁了。|offset|length|3073707|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1931126/is-it-good-practice-to-null-a-pointer-after-deleting-it/1931138#1931138^0|0|0|L|J|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|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

If you're going to reallocate the pointer before using it again (dereferencing it, passing it to a function, etc.), making the pointer NULL is just an extra operation. However, if you aren't sure whether it will be reallocated or not before it is used again, setting it to NULL is a good idea.

As many have said, it is of course much easier to just use smart pointers.

Edit: As Thomas Matthews said in <a href="https://stackoverflow.com/questions/1931126/is-it-good-practice-to-null-a-pointer-after-deleting-it/1931138#1931138">this earlier answer</a>, if a pointer is deleted in a destructor, there isn't any need to assign NULL to it since it won't be used again because the object is being destroyed already.

blocks|key|322625|text|我会稍微改变一下你的问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|322626|322627|你会使用未初始化的指针吗？你知道，一个你没有设置为NULL或分配它所指向的内存的变量？|blockquote|322628|322629|322630|有两种情况可以跳过将指针设置为NULL：|322631|immediately|322632|you重载了指针的语义，并将其值不仅用作内存指针，还用作键或原始值。|unordered-list-item|322633|指针变量超出了作用域。然而，这种方法还存在其他问题。|322634|322635|322636|同时，在我看来，将指针设置为NULL可能会隐藏错误，这听起来就像是认为您不应该修复一个bug，因为修复后可能会隐藏另一个bug。如果指针未设置为NULL，则可能显示的唯一错误是尝试使用该指针的错误。但是将它设置为NULL实际上会导致与使用释放内存时完全相同的bug，不是吗？|322637|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Y|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|11|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|12|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|N|7|14|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|17|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|V|$]]

I'll change your question slightly:

<blockquote>
 Would you use an uninitialized
 pointer? You know, one that you didn't
 set to NULL or allocate the memory it
 points to?
</blockquote>

There are two scenarios where setting the pointer to NULL can be skipped:

<ul>
<li>the pointer variable goes out of scope immediately</li>
<li>you have overloaded the semantic of the pointer and are using its value not only as a memory pointer, but also as a key or raw value. this approach however suffers from other problems.</li>
</ul>

Meanwhile, arguing that setting the pointer to NULL might hide errors to me sounds like arguing that you shouldn't fix a bug because the fix might hide another bug. The only bugs that might show if the pointer is not set to NULL would be the ones that try to use the pointer. But setting it to NULL would actually cause exactly the same bug as would show if you use it with freed memory, wouldn't it?

blocks|key|3073855|text|是。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3073856|它唯一的“危害”就是在你的程序中引入了低效(不必要的存储操作)--但是在大多数情况下，与分配和释放内存块的开销相比，这种开销是微不足道的。|3073857|如果你不这样做，总有一天你会有一些讨厌的指针引用错误。|3073858|我总是使用宏来删除：|3073859|#define+SAFEDELETE(ptr)+{+delete(ptr);+ptr+=+NULL;+}|code-block|syntax|javascript|3073860|(类似于数组，free()，释放句柄)|3073861|您还可以编写"self+delete“方法来引用调用代码的指针，这样它们就会强制调用代码的指针为NULL。例如，要删除多个对象的子树：|3073862|static+void+TreeItem::DeleteSubtree(TreeItem+*&rootObject)
{
++++if+(rootObject+==+NULL)
++++++++return;

++++rootObject->UnlinkFromParent();

++++for+(int+i+=+0;+i+<+numChildren)
+++++++DeleteSubtree(rootObject->child[i]);

++++delete+rootObject;
++++rootObject+=+NULL;
}|3073863|编辑|offset|length|style|BOLD|3073864|是的，这些技术确实违反了一些使用宏的规则(是的，现在你可能可以用模板达到同样的结果)-但通过使用多年的I+never++accessed+memory+-这是你可能面临的最讨厌、最困难和最耗时的调试问题之一。在实践中，多年来，他们已经有效地消除了我引入的每个团队中的whjole类bug。|3073865|也有许多方法可以实现上面的方法-我只是试图说明这样一种想法，即如果人们删除了一个对象，就强制他们将指针设为空，而不是提供一种方法让他们释放不会使调用者的指针为空的内存。|3073866|当然，上面的例子只是迈向自动指针的一步。我没有建议，因为操作员特别询问了不使用自动指针的情况。|3073867|entityMap^0|0|0|0|0|0|0|0|0|0|2|0|1H|6|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|18|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|19|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|1A|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|1B|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1C|8|@]|9|@]|A|$]]|$1|Q|3|R|5|J|7|1D|8|@]|9|@]|A|$K|L]]|$1|S|3|T|5|6|7|1E|8|@$U|1F|V|1G|W|X]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1H|8|@$U|1I|V|1J|W|X]]|9|@]|A|$]]|$1|10|3|11|5|6|7|1K|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1L|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|15|$]]

Yes.

The only "harm" it can do is to introduce inefficiency (an unnecessary store operation) into your program - but this overhead will be insignificant in relation to the cost of allocating and freeing the block of memory in most cases.

If you don't do it, you will have some nasty pointer derefernce bugs one day.

I always use a macro for delete:

<pre><code>#define SAFEDELETE(ptr) { delete(ptr); ptr = NULL; }
</code></pre>

(and similar for an array, free(), releasing handles)

You can also write "self delete" methods that take a reference to the calling code's pointer, so they force the calling code's pointer to NULL. For example, to delete a subtree of many objects:

<pre><code>static void TreeItem::DeleteSubtree(TreeItem *&amp;rootObject)
{
 if (rootObject == NULL)
 return;

 rootObject-&gt;UnlinkFromParent();

 for (int i = 0; i &lt; numChildren)
 DeleteSubtree(rootObject-&gt;child[i]);

 delete rootObject;
 rootObject = NULL;
}
</code></pre>

edit

Yes, these techniques do violate some rules about use of macros (and yes, these days you could probably achieve the same result with templates) - but by using over many years I never ever accessed dead memory - one of the nastiest and most difficult and most time consuming to debug problems you can face. In practice over many years they have effectively eliminated a whjole class of bugs from every team I have introduced them on. 

There are also many ways you could implement the above - I am just trying to illustrate the idea of forcing people to NULL a pointer if they delete an object, rather than providing a means for them to release the memory that does not NULL the caller's pointer.

Of course, the above example is just a step towards an auto-pointer. Which I didn't suggest because the OP was specifically asking about the case of not using an auto pointer.

blocks|key|320950|text|正如其他人所说，delete+ptr;+ptr+=+0;不会让恶魔从你的鼻子里飞出来。但是，它确实鼓励使用ptr作为一种标志。代码中充斥着delete并将指针设置为NULL。下一步是在代码中散布if+(arg+==+NULL)+return;，以防止意外使用NULL指针。一旦针对NULL的检查成为检查对象或程序状态的主要手段，就会出现问题。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|320951|我敢肯定在某个地方有关于使用指针作为标志的代码味道，但我还没有找到。|320952|entityMap^0|8|K|1H|3|1X|6|2A|4|2P|O|3L|4|3W|4|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Y|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|Z|8|@]|D|@]|E|$]]]|I|$]]

As others have said, <code>delete ptr; ptr = 0;</code> is not going to cause demons to fly out of your nose. However, it does encourage the usage of <code>ptr</code> as a flag of sorts. The code becomes littered with <code>delete</code> and setting the pointer to <code>NULL</code>. The next step is to scatter <code>if (arg == NULL) return;</code> through your code to protect against the accidental usage of a <code>NULL</code> pointer. The problem occurs once the checks against <code>NULL</code> become your primary means of checking for the state of an object or program.

I'm sure that there is a code smell about using a pointer as a flag somewhere but I haven't found one.

blocks|key|3073916|text|如果你没有其他的约束来强制你在删除指针后将它设置或不设置为NULL+(Neil+Butterworth提到过这样一个约束)，那么我个人的偏好就是让它保持不变。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3073917|对我来说，问题不是“这是个好主意吗？”但是“通过这样做，我会阻止或允许什么行为取得成功？”例如，如果这允许其他代码看到指针不再可用，那么为什么其他代码在释放指针后还要尝试查看它们呢？通常，这是一个bug。|3073918|它还做了更多的工作，并阻碍了事后调试。在你不需要它之后，你接触的内存越少，就越容易弄清楚为什么会崩溃。很多时候，我依靠内存处于与特定bug发生时相似的状态这一事实来诊断和修复该bug。|3073919|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1931126/is-it-good-practice-to-null-a-pointer-after-deleting-it/1931149#1931149^0|Z|G|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

If you have no other constraint that forces you to either set or not set the pointer to NULL after you delete it (one such constraint was mentioned by <a href="https://stackoverflow.com/questions/1931126/is-it-good-practice-to-null-a-pointer-after-deleting-it/1931149#1931149">Neil Butterworth</a>), then my personal preference is to leave it be.

For me, the question isn't "is this a good idea?" but "what behavior would I prevent or allow to succeed by doing this?" For example, if this allows other code to see that the pointer is no longer available, why is other code even attempting to look at freed pointers after they are freed? Usually, it's a bug.

It also does more work than necessary as well as hindering post-mortem debugging. The less you touch memory after you don't need it, the easier it is to figure out why something crashed. Many times I have relied on the fact that memory is in a similar state to when a particular bug occurred to diagnose and fix said bug.

blocks|key|325504|text|在删除它所指向的对象之后，我总是将指针设置为指向NULL+(现在是nullptr)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|325505|325506|它可以帮助捕获许多对已释放内存的引用(假设您的平台错误发生在一个空指针上)。|ordered-list-item|325507|它不会捕获所有对已释放内存的引用，例如，如果您周围有指针的副本。|325508|它会屏蔽一个双删除，但我发现这比访问已经释放的内存要少得多。|325509|在很多情况下，编译器会把它优化掉。因此，没有必要的论点无法说服我。|325510|如果你已经在使用RAII，那么一开始你的代码中就没有多少delete，所以额外赋值会导致混乱的论点说服不了我。|325511|在调试时，查看空值而不是陈旧的指针通常更方便。|325512|如果这仍然困扰着你，请改用智能指针或引用。|325513|325514|当资源空闲时，我还将其他类型的资源句柄设置为no-resource值(通常只在为封装资源而编写的RAII包装器的析构函数中)。|325515|我参与了一个大型(900万条语句)商业产品的开发(主要是用C语言)。有一次，当内存被释放时，我们使用了宏魔术来清空指针。这立即暴露了许多潜伏的bug，这些bug很快就被修复了。据我所知，我们从来没有出现过一个双重释放的bug。|325516|security：微软认为这是一种良好的安全实践，并在他们的策略中推荐这种做法。显然，如果您使用/SDL选项进行编译，MSVC%2B%2B11将自动执行stomp+the+deleted+pointer+(在许多情况下)。|BOLD|325517|entityMap|0|LINK|mutability|MUTABLE|url|https://www.microsoft.com/security/blog/2012/04/24/guarding-against-re-use-of-stale-object-references/^0|O|4|X|7|0|0|0|0|0|0|S|6|0|0|0|0|0|0|U|25|20|P|0|0^^$0|@$1|2|3|4|5|6|7|1B|8|@$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|1G|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|1H|8|@]|D|@]|E|$]]|$1|J|3|K|5|I|7|1I|8|@]|D|@]|E|$]]|$1|L|3|M|5|I|7|1J|8|@]|D|@]|E|$]]|$1|N|3|O|5|I|7|1K|8|@]|D|@]|E|$]]|$1|P|3|Q|5|I|7|1L|8|@$9|1M|A|1N|B|C]]|D|@]|E|$]]|$1|R|3|S|5|I|7|1O|8|@]|D|@]|E|$]]|$1|T|3|U|5|I|7|1P|8|@]|D|@]|E|$]]|$1|V|3|-4|5|6|7|1Q|8|@]|D|@]|E|$]]|$1|W|3|X|5|6|7|1R|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|1S|8|@]|D|@]|E|$]]|$1|10|3|11|5|6|7|1T|8|@$9|1U|A|1V|B|12]]|D|@$9|1W|A|1X|1|1Y]]|E|$]]|$1|13|3|-4|5|6|7|1Z|8|@]|D|@]|E|$]]]|14|$15|$5|16|17|18|E|$19|1A]]]]

I always set a pointer to <code>NULL</code> (now <code>nullptr</code>) after deleting the object(s) it points to.

<ol>
<li>It can help catch many references to freed memory (assuming your platform faults on a deref of a null pointer).</li>
<li>It won't catch all references to free'd memory if, for example, you have copies of the pointer lying around. But some is better than none.</li>
<li>It will mask a double-delete, but I find those are far less common than accesses to already freed memory.</li>
<li>In many cases the compiler is going to optimize it away. So the argument that it's unnecessary doesn't persuade me.</li>
<li>If you're already using RAII, then there aren't many <code>delete</code>s in your code to begin with, so the argument that the extra assignment causes clutter doesn't persuade me.</li>
<li>It's often convenient, when debugging, to see the null value rather than a stale pointer.</li>
<li>If this still bothers you, use a smart pointer or a reference instead.</li>
</ol>

I also set other types of resource handles to the no-resource value when the resource is free'd (which is typically only in the destructor of an RAII wrapper written to encapsulate the resource).

I worked on a large (9 million statements) commercial product (primarily in C). At one point, we used macro magic to null out the pointer when memory was freed. This immediately exposed lots of lurking bugs that were promptly fixed. As far as I can remember, we never had a double-free bug.

Update: Microsoft believes that it's a good practice for security and recommends the practice in their SDL policies. Apparently MSVC++11 will <a href="https://www.microsoft.com/security/blog/2012/04/24/guarding-against-re-use-of-stale-object-references/" rel="nofollow noreferrer">stomp the deleted pointer</a> automatically (in many circumstances) if you compile with the /SDL option.

blocks|key|325526|text|我可以想象一下，在删除指针后将其设置为NULL在少数情况下是有用的，在这种情况下，在单个函数(或对象)中重用它是合法的。否则它就没有意义了--一个指针需要指向一些有意义的东西，只要它存在--句号。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|325527|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 can imagine setting a pointer to NULL after deleting it being useful in rare cases where there is a legitimate scenario of reusing it in a single function (or object). Otherwise it makes no sense - a pointer needs to point to something meaningful as long as it exists - period.

blocks|key|325557|text|如果代码不属于应用程序中最关键的性能部分，请保持简单，并使用shared_ptr：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|325558|shared_ptr<Foo>+p(new+Foo);
//No+more+need+to+call+delete|code-block|syntax|javascript|325559|它执行引用计数并且是线程安全的。您可以在tr1+(std::tr1名称空间，#include+<+memory+>)中找到它，或者如果您的编译器没有提供它，可以从boost中获取它。|325560|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|$]]

If the code does not belong to the most performance-critical part of your application, keep it simple and use a shared_ptr:

<pre><code>shared_ptr&lt;Foo&gt; p(new Foo);
//No more need to call delete
</code></pre>

It performs reference counting and is thread-safe. You can find it in the tr1 (std::tr1 namespace, #include &lt; memory >) or if your compiler does not provide it, get it from boost.

blocks|key|3287533|text|在具有适当错误检查的结构良好的程序中，没有理由不将其赋值为null。在这种情况下，0是一个普遍认可的无效值。失败得很严重，很快就会失败。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3287534|许多反对分配0的争论表明，它可能会隐藏错误或使控制流复杂化。从根本上说，这要么是上游的错误(不是您的错误(抱歉，我说的是糟糕的双关语))，要么是代表程序员的另一个错误--甚至可能是程序流变得太复杂的迹象。|3287535|如果程序员想要引入一个可能为null的特殊值指针的使用，并编写所有必要的回避方法，这是他们故意引入的复杂问题。隔离越好，您就越早发现误用案例，它们传播到其他程序的可能性就越小。|3287536|可以使用C%2B%2B功能来设计结构良好的程序来避免这些情况。您可以使用引用，也可以简单地说“传递/使用null或无效参数是错误的”--这种方法同样适用于容器，如智能指针。增加一致和正确的行为会阻止这些错误的发展。|3287537|在那里，您只有一个非常有限的作用域和上下文，其中可能存在(或允许)空指针。|3287538|同样的情况也可以应用于非const的指针。跟随指针的值是微不足道的，因为它的作用域很小，并且检查和定义了不正确的用法。如果您的工具集和工程师在快速阅读之后不能遵循程序，或者存在不适当的错误检查或不一致/宽松的程序流，那么您就有了其他更大的问题。|3287539|最后，当您想引入错误(涂鸦)、检测对释放的内存的访问以及捕获其他相关的UB时，您的编译器和环境可能会有一些保护措施。您还可以在程序中引入类似的诊断，通常不会影响现有程序。|3287540|entityMap^0|15|1|0|6|1|0|0|0|0|C|5|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|W|8|@$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|Z|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|10|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|11|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|12|8|@$9|13|A|14|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|15|8|@]|D|@]|E|$]]|$1|R|3|-4|5|6|7|16|8|@]|D|@]|E|$]]]|S|$]]

In a well structured program with appropriate error checking, there is no reason not to assign it null. <code>0</code> stands alone as a universally recognized invalid value in this context. Fail hard and Fail soon.

Many of the arguments against assigning <code>0</code> suggest that it could hide a bug or complicate control flow. Fundamentally, that is either an upstream error (not your fault (sorry for the bad pun)) or another error on the programmer's behalf -- perhaps even an indication that program flow has grown too complex.

If the programmer wants to introduce the use of a pointer which may be null as a special value and write all the necessary dodging around that, that's a complication they have deliberately introduced. The better the quarantine, the sooner you find cases of misuse, and the less they are able to spread into other programs.

Well structured programs may be designed using C++ features to avoid these cases. You can use references, or you can just say "passing/using null or invalid arguments is an error" -- an approach which is equally applicable to containers, such as smart pointers. Increasing consistent and correct behavior forbids these bugs from getting far.

From there, you have only a very limited scope and context where a null pointer may exist (or is permitted).

The same may be applied to pointers which are not <code>const</code>. Following the value of a pointer is trivial because its scope is so small, and improper use is checked and well defined. If your toolset and engineers cannot follow the program following a quick read or there is inappropriate error checking or inconsistent/lenient program flow, you have other, bigger problems.

Finally, your compiler and environment likely has some guards for the times when you would like to introduce errors (scribbling), detect accesses to freed memory, and catch other related UB. You can also introduce similar diagnostics into your programs, often without affecting existing programs.

blocks|key|3074179|text|有时这样做是件好事，有时这样做毫无意义并可以隐藏错误|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3074180|我可以看到两个问题:简单的代码：|3074181|delete+myObj;
myobj+=+0|code-block|syntax|javascript|3074182|成为多线程环境中的for-liner：|3074183|lock(myObjMutex);+
delete+myObj;
myobj+=+0
unlock(myObjMutex);|3074184|Don+Neufeld的“最佳实践”并不总是适用的。例如，在一个汽车项目中，即使在析构函数中，我们也必须将指针设置为0。我可以想象，在安全关键型软件中，这样的规则并不少见。遵循它们比试图说服团队/代码检查器对代码中使用的每个指针进行检查更容易(也更明智)，因为将该指针设为空的行是多余的。|3074185|另一个危险是在异常中依赖这种技术-使用代码：|3074186|try{++
+++delete+myObj;+//exception+in+destructor
+++myObj=0
}
catch
{
+++//myObj=0;+<-+possibly+resource-leak
}

if+(myObj)
++//+use+myObj+<--undefined+behaviour|3074187|在这样的代码中，要么产生资源泄漏并推迟问题，要么进程崩溃。|3074188|因此，这两个问题自然而然地出现在我的脑海中(Herb+Sutter肯定会告诉我更多)，这使得“如何避免使用智能指针，并使用普通指针安全地完成工作”的所有问题都过时了。|3074189|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|12|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|F|7|15|8|@]|9|@]|A|$G|H]]|$1|S|3|T|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|17|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

"There are times when it is a good thing to do, and times when it is pointless and can hide errors"

I can see two problems:
That simple code:

<pre><code>delete myObj;
myobj = 0
</code></pre>

becomes to a for-liner in multithreaded environment:

<pre><code>lock(myObjMutex); 
delete myObj;
myobj = 0
unlock(myObjMutex);
</code></pre>

The "best practice" of Don Neufeld don't apply always. E.g. in one automotive project we had to set pointers to 0 even in destructors. I can imagine in safety-critical software such rules are not uncommon. It is easier (and wise) to follow them than trying to persuade
the team/code-checker for each pointer use in code, that a line nulling this pointer is redundant.

Another danger is relying on this technique in exceptions-using code:

<pre><code>try{ 
 delete myObj; //exception in destructor
 myObj=0
}
catch
{
 //myObj=0; &lt;- possibly resource-leak
}

if (myObj)
 // use myObj &lt;--undefined behaviour
</code></pre>

In such code either you produce resource-leak and postpone the problem or the process crashes.

So, this two problems going spontaneously through my head (Herb Sutter would for sure tell more) make for me all the questions of the kind "How to avoid using smart-pointers and do the job safely with normal pointers" as obsolete.

I'll start out by saying, use smart pointers and you'll never have to worry about this.

What are the problems with the following code?

<pre><code>Foo * p = new Foo;
// (use p)
delete p;
p = NULL;
</code></pre>

This was sparked by <a href="https://stackoverflow.com/questions/1930459/c-delete-it-deletes-my-objects-but-i-can-still-access-the-data/1930520#1930520">an answer and comments</a> to another question. One comment from <a href="https://stackoverflow.com/users/69307/neil-butterworth">Neil Butterworth</a> generated a few upvotes:

<blockquote>
 Setting pointers to NULL following delete is not universal good practice in C++. There are times when it is a good thing to do, and times when it is pointless and can hide errors.
</blockquote>

There are plenty of circumstances where it wouldn't help. But in my experience, it can't hurt. Somebody enlighten me.

Is it good practice to NULL a pointer after deleting it?

编译器

容器

我首先要说的是，使用智能指针，您永远不必担心这一点。下面的代码有什么问题？Foo * p = new Foo;// (use p)delete p;p = NULL;这是由引发的另一个问题。来自的一条评论产生了一些好评：在C++中，在delete之后设置指向NULL的指针并不是通用的良好做法。有时它是一件好事，有时它是...

问删除指针后将其设为空是一种好的做法吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问删除指针后将其设为空是一种好的做法吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问删除指针后将其设为空是一种好的做法吗？
EN