問題タブ [delete-operator]

これによりメモリエラーが発生するのはなぜですか?

itoaを削除しaVarますか? C++関数がポインタを削除するかどうかを知る方法はありますか?それについての規則はありますか?

これを行うと、エラーは発生しません。

私は C++ で、int の配列の末尾からゼロを削除するメソッドを書いている学生です。配列は構造体にあり、構造体には配列の長さを追跡する int もあります。

このメソッドは、最初のゼロ以外の要素に遭遇するまで、最後の要素から始めて各要素を調べ、長さの値を変更することによってその要素を「最後の要素」としてマークします。次に、メソッドは元の「最後の要素」に戻り、範囲外ではない要素 (ゼロ) を削除します。

i配列の更新された長さよりも大きい場合に配列内の th 要素を削除する部分はi、次のようになります。

しかし、その行は間違っています。Delete はポインターを受け取ります。iしたがって、削除したい整数のメモリ位置を取得するには、配列へのポインターを回復してから追加する必要があると感じています。

私の直感は間違っていますか？エラーは微妙ですか？それとも、私は完全に間違った考えを持っていますか? 私は疑問に思い始めました: 本当にこれらのプリミティブを解放する必要があるのでしょうか? それらがプリミティブでない場合、私はそうする必要があります。

私は現在、状態が変化した場合にクラスがオブザーバーを呼び出すことができるアプリケーションをリファクタリングしています。これは、オブザーバーが次の場合に呼び出されることを意味します。

• クラスが変更されたインスタンスのデータ
• クラスの新しいインスタンスが作成されます
• クラスのインスタンスが削除されます

私が心配するのはこの最後のケースです。

私のクラスが本だとします。オブザーバーはBookManagerと呼ばれるクラスに格納されます（BookManagerはすべてのブックのリストも保持します）。これは、これがあることを意味します。

本が削除された場合（リストから削除され、メモリから削除された場合）、オブザーバーは次のように呼び出されます。

問題は、オブザーバーのロジックを制御できないことです。オブザーバーは、プラグイン、顧客の開発者によって作成されたコードによって配信できます。

したがって、このようなコードを書くことはできますが（インスタンスが削除された場合に備えて、リストの次のコードを確実に取得します）：

オブザーバーがリストから他の本も削除する可能性は常にあります。

この場合、リストにTolkienの本が含まれ、その後にCarl Saganの本が続く場合、次のイテレータ（itNext）が無効になるため、Tolkienのすべての本を削除するループがクラッシュする可能性があります。

示されている問題は他の状況でも発生する可能性がありますが、アプリケーションが簡単にクラッシュする可能性があるため、削除の問題が最も深刻です。

アプリケーションで、削除するすべてのインスタンスを最初に取得し、それらを2番目のコンテナーに入れてから、2番目のコンテナーをループしてインスタンスを削除することで問題を解決できますが、常にリスクがあるため、オブザーバーは、削除予定リストに既に含まれている他のインスタンスを明示的に削除します。この2番目のコピーも最新の状態に保つために、明示的なオブザーバーを配置する必要があります。

また、オブザーバーの呼び出し中に（直接または間接的に）コンテナーを反復処理する場合は常に、すべてのアプリケーションコードにリストのコピーを作成するように要求すると、アプリケーションコードの記述がはるかに困難になります。

このような問題を解決するために使用できる[デザイン]パターンはありますか？アプリケーション全体が共有ポインターを使用してインスタンスにアクセスすることを保証できないため、共有ポインターアプローチを使用しないことをお勧めします。

NULLポインタを削除しても安全ですか？

そして、それは良いコーディングスタイルですか？

プロジェクトの場合、ビットセットクラスを実装する必要があります。これまでの私のコードは次のとおりです。

ヘッダーファイル

ソースファイル

私の問題は、deconstructorとassignメソッドのコアダンプの両方でのdeleteステートメントです。このメモリの割り当てを解除する必要はありませんか？これまで読んだことから、newを呼び出すときは常にdeleteコマンドを使用する必要があります。

編集：修正の1つを反映するために、上記のコードを変更しました。コンストラクターにビットセット=NULLを追加しました。これにより、assignメソッドのコアダンプが修正されましたが、デコンストラクターでエラーが発生します。

私は私のコードにこれを持っています：

これを削除するにはどうすればよいdescですか？

私がすべきこと：

また

また

？

私はこのようなことをすると言う

ループで使用した後、ポインター オブジェクトを削除する必要がありますか? 私はそれを削除しなければ、新しいオブジェクトを10回作成し続け、その後オブジェクトはそこにぶら下がってリソースを消費するだろうと考えていました。

重複の可能性:
(POD)メモリの解放: delete[] は delete と同じですか?

私が C++ を教えられたとき、これはずっと前のことでした。絶対に使用しないように言われましたdeleteが、単一のオブジェクトでdelete[]実行すると. 先生を信用しすぎてはいけないと思うのですが、これは本当ですか？delete[]delete

deleteの代わりに電話する理由はありdelete[]ますか?

SOで関連する可能性のある質問をスキャンしましたが、明確な答えが見つかりませんでした。

これは、最も基本的な用途を除いて C++ で使用newしたことがないため、単なる好奇心のためです。delete

私はそれdeleteがメモリを解放することを知っています。私が疑問に思っているのは、より複雑なケースをどのように処理するのですか?

たとえば、次のようなユーザー定義クラスがあるとします。

クラスが何らかの方法でメモリを割り当てintArray、デストラクタで解放すると仮定すると、次のようにクラスを使用した場合MyClass* myClass = new MyClass();:delete myclass;

deleteすべてのメモリの解放をどのように処理しますか? クラス デストラクタは、最初に呼び出されて、クラスによって割り当てられたすべてのメモリを解放し (つまりint* intArray)、クラスを保持するために割り当てられたメモリを解放しますか?

次のようなクラスがあるとしたらどうでしょうか。

がコンストラクターで割り当てられていないと仮定するとanotherMyClass、メモリをすぐに使い果たしてしまいます。連結リストのように互いに関連付けられた MyClasses のチェーンがあった場合はどうなるでしょうか? この場合、デストラクタの削除ステートメントは機能しますか? デストラクタが呼び出されると、それぞれanotherMyClassが再帰的に解放されますか?

あなたが知っているnewandステートメントに関する特定の奇妙なトリックや警告はありますか?delete

重複の可能性:
「delete this」を使用して現在のオブジェクトを削除してもよろしいですか?

クラス関数で実行されたコードを見たところです。delete this;これは良い設計ではないことはわかっていますが、何が起こるかを定義しています。クラスは常にどこかからのポインターであるとしましょう。常に正しい方法で削除されますか?