ポインターを削除した後でNULLにすることは良い習慣ですか？

まず、スマートポインタを使用することから始めます。これについて心配する必要はありません。

次のコードの問題は何ですか？

Foo * p = new Foo;
// (use p)
delete p;
p = NULL;

これは、別の質問に対する回答とコメントによって刺激されました。Neil Butterworthからの1つのコメントで、いくつかの賛成票が生成されました。

削除後にポインターをNULLに設定することは、C ++では普遍的な推奨事項ではありません。これを行うのが良い場合もあれば、無意味でエラーを隠すことができる場合もあります。

それが役に立たない状況はたくさんあります。しかし、私の経験では、害はありません。誰かが私を啓発します。

ポインターを0に設定すると（標準のC ++では「null」であり、CからのNULL定義は多少異なります）、二重削除によるクラッシュを回避できます。

以下を検討してください。

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

一方：

Foo* foo = new Foo();
delete foo; // Deletes the object
delete foo; // Undefined behavior 

つまり、削除済みポインタを0に設定しないと、二重削除を行うと問題が発生します。削除後にポインターを0に設定することに対する反対の議論は、そうすることで二重削除のバグをマスクし、それらを未処理のままにすることです。

明らかに、二重削除バグがないことが最善ですが、所有権のセマンティクスとオブジェクトのライフサイクルによっては、これを実際に達成するのは難しい場合があります。私はUBよりもマスクされた二重削除バグを好む。

最後に、オブジェクトの割り当ての管理に関する補足事項として、ニーズに応じて、std::unique_ptr厳密なstd::shared_ptr所有権または単一の所有権、共有の所有権、または別のスマートポインタの実装を確認することをお勧めします。

ポインターが指すものを削除した後でポインターをNULLに設定しても、害はありませんが、多くの場合、より根本的な問題に対するバンドエイドのようです。なぜ最初にポインターを使用しているのですか？2つの典型的な理由がわかります。

• 単にヒープに何かを割り当てたかっただけです。その場合、それをRAIIオブジェクトでラップするほうがはるかに安全でクリーンになります。オブジェクトが不要になったら、RAIIオブジェクトのスコープを終了します。そうですstd::vectorであり、割り当てを解除されたメモリへのポインタを誤って残してしまう問題を解決します。ポインタはありません。
• または、複雑な共有所有権のセマンティクスが必要な場合もあります。から返されたポインタは、呼び出されたポインタnewと同じでない場合がありますdelete。その間、複数のオブジェクトが同時にそのオブジェクトを使用した可能性があります。その場合は、共有ポインタまたは同様のものが望ましいでしょう。

私の経験則では、ユーザーコード内にポインターを置いたままにしておくと、間違っていることになります。そもそもポインタがゴミを指すようにしてはいけません。なぜその有効性を保証する責任を負うオブジェクトがないのですか？指摘されたオブジェクトが終了してもスコープが終了しないのはなぜですか？

さらに良いベストプラクティスがあります。可能であれば、変数のスコープを終了します。

{
    Foo* pFoo = new Foo;
    // use pFoo
    delete pFoo;
}

ポインターを指すオブジェクトを削除した後は、常にポインターをNULL（今はnullptr）に設定します。

1. これは、解放されたメモリへの多くの参照をキャッチするのに役立ちます（ヌルポインターの逆参照でプラットフォームに障害があると想定）。

2. たとえば、ポインタのコピーがある場合、解放されたメモリへのすべての参照をキャッチしません。しかし、何よりも優れているものもあります。

3. それは二重削除をマスクしますが、それらはすでに解放されたメモリへのアクセスよりもはるかに一般的ではありません。

4. 多くの場合、コンパイラはそれを最適化します。それで、それが不必要であるという主張は私を説得しません。

5. すでにRAIIを使用している場合deleteは、最初からコードにが多くないため、追加の割り当てによって混乱が生じるという議論は私を説得しません。

6. デバッグ時に、古いポインタではなくnull値を確認すると便利なことがよくあります。

7. それでも問題が解決しない場合は、代わりにスマートポインタまたは参照を使用してください。

また、リソースが解放されたときに他のタイプのリソースハンドルをno-resource値に設定します（これは通常、リソースをカプセル化するために作成されたRAIIラッパーのデストラクタでのみです）。

大規模な（900万ステートメント）商用製品（主にC）に取り組みました。ある時点で、メモリが解放されたときにマクロマジックを使用してポインターをnullにしました。これにより、すぐに修正された多くの潜んでいるバグがすぐに明らかになりました。私が覚えている限り、ダブルフリーのバグはありませんでした。

更新：マイクロソフトは、これはセキュリティにとって良い習慣であると信じており、SDLポリシーでの実践を推奨しています。どうやら、MSVC ++ 11は、/ SDLオプションを指定してコンパイルすると、削除されたポインタを（多くの状況で）自動的に踏みつけます。

まず、このトピックや密接に関連するトピックについては、既存の質問がたくさんあります。たとえば、削除を行わないとポインタがNULLに設定されないのはなぜですか。。

あなたのコードでは、何が起こっているのかという問題（pを使用）。たとえば、次のようなコードがあるとします。

Foo * p2 = p;

次に、心配するポインタp2が残っているため、pをNULLに設定してもほとんど効果がありません。

これは、ポインタをNULLに設定しても常に無意味であると言っているのではありません。たとえば、pが、存続期間がpを含むクラスとまったく同じではないリソースを指すメンバー変数である場合、pをNULLに設定することは、リソースの有無を示すのに役立つ方法です。

の後にさらにコードがある場合delete、はい。コンストラクターで、またはメソッドや関数の最後でポインターが削除された場合、No。

このたとえの要点は、実行時に、オブジェクトがすでに削除されていることをプログラマに思い出させることです。

さらに良い方法は、ターゲットオブジェクトを自動的に削除するスマートポインタ（共有またはスコープ）を使用することです。

他の人が言ったように、delete ptr; ptr = 0;悪魔があなたの鼻から飛び出すことはありません。ただし、ptr一種のフラグとしての使用を奨励します。コードは散らかってdelete、ポインタをに設定しますNULL。次のステップはif (arg == NULL) return;、NULLポインターを誤って使用しないようにするために、コードを分散させることです。問題は、チェックがNULLオブジェクトまたはプログラムの状態をチェックする主要な手段になると発生します。

どこかでポインタをフラグとして使用することについてコードのにおいがあると確信していますが、見つかりません。

質問を少し変更します。

初期化されていないポインタを使用しますか？NULLに設定していない、またはNULLが指すメモリを割り当てていないものですか。

ポインターをNULLに設定することをスキップできるシナリオは2つあります。

• ポインタ変数はすぐにスコープ外になります
• ポインタのセマンティクスをオーバーロードし、その値をメモリポインタとしてだけでなく、キーまたは生の値としても使用しています。ただし、このアプローチには他の問題があります。

一方、ポインターをNULLに設定するとエラーが隠される可能性があると主張すると、修正によって別のバグが隠される可能性があるため、バグを修正すべきではないと主張するように聞こえます。ポインターがNULLに設定されていない場合に表示される可能性がある唯一のバグは、ポインターを使用しようとするバグです。しかし、これをNULLに設定すると、解放されたメモリで使用した場合とまったく同じバグが発生しますね。

ポインターを削除した後でNULLに設定するかしないかを強制する他の制約がない場合（そのような制約の1つはNeil Butterworthによって言及されました）、私の個人的な好みはそのままにすることです。

私にとっての質問は、「これは良いアイデアですか？」ではありません。しかし、「これを行うことによって、どのような行動を防止または成功させることができますか？」たとえば、これにより他のコードがポインターが使用できなくなったことを確認できる場合、他のコードが解放された後に解放されたポインターを調べようとするのはなぜですか？通常、これはバグです。

また、必要以上に多くの作業を行い、事後デバッグを妨げます。不要になった後にメモリに触れる回数が少ないほど、何かがクラッシュした理由を簡単に理解できます。多くの場合、メモリは特定のバグが発生したときと同じ状態にあり、そのバグを診断して修正するという事実に依存してきました。

削除後の明示的なnullは、ポインタが概念的にオプションである何かを表すことを読者に強く示唆しています。それが行われているのを見た場合、ソース内のすべての場所でポインタが使用され、最初にNULLに対してテストする必要があるのではないかと心配し始めます。

それが実際の意味である場合は、boost :: optionalのようなものを使用して、ソースで明示的にすることをお勧めします。

optional<Foo*> p (new Foo);
// (use p.get(), but must test p for truth first!...)
delete p.get();
p = optional<Foo*>();

しかし、ポインタが「悪くなった」ことを人々に本当に知りたいのであれば、私は、最善の方法はそれを範囲外にすることだと言う人々と100％同意するつもりです。次に、コンパイラーを使用して、実行時の不正な逆参照の可能性を防ぎます。

それはすべてのC ++浴槽の中の赤ん坊です。それを捨ててはいけません。:)

適切なエラーチェックを備えた適切に構造化されたプログラムでは、nullを割り当てない理由はありません。0この文脈で広く認識されている無効な値として単独で存在します。ハードに失敗し、すぐに失敗します。

割り当てに対する反対意見の多くは、バグを隠したり、制御フローを複雑にしたりする可能性が0あることを示唆しています。基本的に、それは上流のエラー（あなたのせいではなく（悪い駄洒落ではなく））またはプログラマーのための別のエラーです-おそらくプログラムの流れが複雑になりすぎたという兆候ですらあります。

プログラマーが特殊な値としてnullの可能性があるポインターの使用を導入し、その周りに必要なすべての回避を記述したい場合、それは彼らが故意に導入した複雑さです。隔離が適切であればあるほど、誤用のケースが早く発見され、他のプログラムに拡散することが少なくなります。

これらのケースを回避するために、C ++機能を使用して、適切に構造化されたプログラムを設計できます。参照を使用することも、「nullまたは無効な引数を渡す/使用することはエラーである」と言うこともできます。これは、スマートポインタなどのコンテナにも同様に適用できるアプローチです。一貫性のある正しい動作を増やすと、これらのバグが遠ざかることを禁じます。

そこからは、nullポインターが存在する（または許可される）可能性のあるスコープとコンテキストが非常に限定されます。

同じでないポインタにも適用できconstます。ポインタの値をたどることは、そのスコープが非常に小さく、不適切な使用がチェックされ、明確に定義されているため、簡単です。ツールセットとエンジニアが簡単な読み取りでプログラムを追跡できない場合、または不適切なエラーチェックや一貫性のない/緩やかなプログラムフローがある場合は、他に大きな問題があります。

最後に、コンパイラと環境には、エラー（落書き）を導入したり、解放されたメモリへのアクセスを検出したり、他の関連するUBをキャッチしたりするときに、ガード機能が備わっている可能性があります。多くの場合、既存のプログラムに影響を与えることなく、同様の診断をプログラムに導入することもできます。

質問にすでに入力した内容を拡張してみましょう。

箇条書きの形式で、質問に入力した内容は次のとおりです。

削除後にポインターをNULLに設定することは、C ++では普遍的な推奨事項ではありません。以下の場合があります。

• それは良いことです
• そしてそれが無意味でエラーを隠すことができる時。

しかし、これが悪いことはありません！あなたがなりません明示的にゼロにすることによってより多くのバグを紹介し、あなたはありません漏れるメモリを、あなたはありません未定義の動作が原因発生します。

したがって、疑わしい場合は、無効にします。

そうは言っても、いくつかのポインターを明示的にnullにする必要があると感じた場合は、メソッドを十分に分割していないように思えます。メソッドを分割するための「抽出メソッド」と呼ばれるリファクタリングアプローチを検討する必要があります。別パーツ。

はい。

それができる唯一の「害」は、プログラムに非効率性（不必要なストア操作）を導入することです-しかし、このオーバーヘッドは、ほとんどの場合、メモリブロックの割り当てと解放のコストとの関係では重要ではありません。

あなたがそれをしない場合は、します一日いくつかの厄介なポインタderefernceのバグを持っています。

削除には常にマクロを使用します。

#define SAFEDELETE(ptr) { delete(ptr); ptr = NULL; }

（配列と同様、free（）、ハンドルの解放）

呼び出しコードのポインタへの参照を取得する「自己削除」メソッドを記述して、呼び出しコードのポインタを強制的にNULLにすることもできます。たとえば、多くのオブジェクトのサブツリーを削除するには：

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;
}

編集する

はい、これらのテクニックはマクロの使用に関するいくつかのルールに違反します（そして、はい、最近ではおそらくテンプレートで同じ結果を得ることができます）-しかし、何年にもわたって私がデッドメモリにアクセスしたことはありません -最も厄介で最も難しいものの1つ直面する可能性のある問題のデバッグに最も時間がかかる。実際、長年にわたって、私が導入したすべてのチームから、whjoleクラスのバグを効果的に排除してきました。

上記を実装する方法はたくさんあります。私は、呼び出し側のポインターをNULLにしないメモリを解放する手段を提供するのではなく、オブジェクトを削除した場合に、ユーザーにポインターをNULLにするように強制するというアイデアを説明しようとしています。 。

もちろん、上記の例は自動ポインタへのステップにすぎません。これは、OPが自動ポインターを使用しない場合について具体的に要求していたため、提案しませんでした。

「それを行うのが良いこともあれば、無意味でエラーを隠すことができる場合もあります。」

私は2つの問題を見ることができます：その単純なコード：

delete myObj;
myobj = 0

マルチスレッド環境でfor-linerになります。

lock(myObjMutex); 
delete myObj;
myobj = 0
unlock(myObjMutex);

ドンノイフェルトの「ベストプラクティス」は常に当てはまるとは限りません。たとえば、ある自動車プロジェクトでは、デストラクタでもポインタを0に設定する必要がありました。安全性が重要なソフトウェアでは、このようなルールは珍しくありません。コードでポインターを使用するたびにteam / code-checkerを説得するよりも（そして賢明に）それらをたどる方が簡単です。このポインターをnullにする行は冗長です。

もう1つの危険は、例外を使用するコードでこの手法に依存することです。

try{  
   delete myObj; //exception in destructor
   myObj=0
}
catch
{
   //myObj=0; <- possibly resource-leak
}

if (myObj)
  // use myObj <--undefined behaviour

このようなコードでは、リソースリークを生成して問題を延期するか、プロセスがクラッシュします。

したがって、この2つの問題が頭の中で自然に発生するため（Herb Sutterがもっと詳しく教えてくれます）、「スマートポインターの使用を避けて、通常のポインターで安全にジョブを実行する方法」という質問はすべて廃止されました。

心配するダングリングポインタは常に存在します。

ポインタを再度使用する前に再割り当てする場合（逆参照、関数への引き渡しなど）、ポインタをNULLにすることは単なる追加の操作です。ただし、再度使用する前に再割り当てされるかどうかわからない場合は、NULLに設定することをお勧めします。

多くの人が言ったように、もちろんスマートポインタを使用する方がはるかに簡単です。

編集：トーマスマシューズがこの以前の回答で述べたように、デストラクタでポインターが削除された場合、オブジェクトが既に破棄されているため、再度使用されることはないため、ポインターをNULLに割り当てる必要はありません。

ポインターを削除した後でNULLに設定すると、単一の関数（またはオブジェクト）でそれを再利用する正当なシナリオがあるまれなケースで役立ちます。それ以外の場合は意味がありません-ポインタは、存在する限り意味のある何かを指す必要があります-期間。

コードがアプリケーションの最もパフォーマンスが重要な部分に属していない場合は、コードをシンプルに保ち、shared_ptrを使用します。

shared_ptr<Foo> p(new Foo);
//No more need to call delete

参照カウントを実行し、スレッドセーフです。これはtr1（std :: tr1名前空間、＃include <memory>）で見つけることができます。コンパイラーが提供していない場合は、boostから取得します。