問題タブ [delete-operator]

を使用して配列を割り当てる場合new []、ポインタからその配列のサイズがわからないのはなぜですか? 実行時に知る必要があります。そうdelete []しないと、解放するメモリの量がわかりません。

私が何かを見逃していない限り？

C ++のdeleteと演算子の違いは何ですか？delete[]

オブジェクトがどのように渡されるか（参照または値）およびオブジェクトが配列にどのように格納されるかについての情報が見つからないため、C++でオブジェクトの配列を処理することについて少し混乱しています。

オブジェクトの配列はそのオブジェクトタイプへのポインタの配列であると思いますが、これがどこにも書かれているのは見つかりませんでした。それらはポインタでしょうか、それともオブジェクト自体がメモリ内の配列に配置されているのでしょうか。

以下の例では、カスタムクラスmyClassが文字列を保持します（これにより可変サイズになりますか、または文字列オブジェクトが文字列へのポインタを保持するため、一定量のスペースを占有します。 myContainer内のmyClassオブジェクト。myContainer.addObject（）メソッドで、より大きな配列を作成し、すべてのオブジェクトを新しいオブジェクトと一緒にその配列にコピーしてから、古いオブジェクトを削除しようとしています。 mデストラクタを使用してメモリを適切にクリーンアップします-この領域でどのような改善を行うことができますか？

オブジェクトの配列を割り当てました

このアレイを削除するにはどうすればよいですか？ただ

または、配列の要素を反復処理しますか？

ありがとう

アップデート：

ループ本体を次のように変更しました

コードを強制的にコンパイルします。

以下が未定義の動作をもたらすというのは本当ですか:

最初にキャストsomethingする必要がありchar *ますか?

前方宣言で何をしてはいけないかを説明するために使用されるこの古典的な例を考えてみましょう:

Bodyのデストラクタは自明ではないため、このケースはUBに向かっていることを標準から理解しています。私が理解しようとしているのは、これの根本的な原因です。

つまり、ハンドルの dtor がインラインであるという事実によって問題が「トリガー」されているように見えるため、コンパイラは次の「インライン展開」のようなことを行います (ここではほぼ疑似コード)。

Handle インスタンスが破棄されるすべての翻訳単位 (Handle_user.cppこの場合のみ) で、そうですか? 私はこれを理解できません:わかりました、上記のインライン展開を生成するとき、コンパイラーは Body クラスの完全な定義を持っていませんが、なぜ単純にリンカにimpl_->~Body()物事を解決させて、Body のデストラクタを呼び出させることができないのでしょうか?実装ファイルで実際に定義されている関数?

言い換えれば、Handle 破壊の時点で、コンパイラは Body に対して (自明ではない) デストラクタが存在するかどうかさえわからないことを理解していますが、なぜいつものようにできないのでしょうか。リンカーが埋めるための「プレースホルダー」であり、その機能が実際に利用できない場合、最終的にリンカーは「未解決の外部」になりますか?

ここで何か大きなものを見逃していますか (その場合、愚かな質問で申し訳ありません)。そうでない場合は、この背後にある理論的根拠を理解したいと思っています。

私はいくつかの構造体を持っています：

私はこれが理想からは程遠い、そして完成からは程遠いことを知っています。しかし、私は自分の記憶を適切な方法で削除しているかどうかを知りたいです（適切な方法を教えてはいけません。私はそれを自分で理解しようとしています）。

^{これは私にとって本当に重要な別の質問へのリンクです。}

学部のカリキュラムの多くでJavaに夢中になっていたので、C ++に関しては、私は比較的初心者です（残念です）。メモリ管理は面倒ですが、私はansiCとC++に関する本をたくさん購入しました。関連する質問を調べましたが、この特定の基準に一致する質問が見つかりませんでした。多分それは誰もそれについて言及していないのは明らかですか？

この質問は私を悩ませてきましたが、私が利用していない概念的なポイントがあるように感じます。

仮定する：

どこ、

その点で重要なのは、「original」を文字で埋めるバッファにし、そのコピーを定期的に削って他の場所で使用することです。

明確にするために、オリジナルは、、、、または任意のインプレース充填入力リーダーを介して充填されますstd::gets(char* buff)。文字列を「削る」ために、基本的に切り捨てられ、未使用の配列スペースが削除されます。std::getline(char* buff, buff_sz)std::read(char* buff, buff_sz)

このエラーはヒープ割り当てエラーであり、に発生しますdelete[]。

リークを防ぐために、「shaved」によって保持されているメモリを解放して、いくつかの引数を通過した後に再び使用できるようにします。これが制限されているのにはおそらく正当な理由がありますが、この構成ではデータの元の所有者（ポインタ）にアクセスする方法がないため、メモリを解放する方法があるはずです。

このページには、

1つの理由は、deleteのオペランドが左辺値である必要がないことです。検討：

ここで、deleteの実装には、ゼロを割り当てることができるポインターがありません。

ポインタに数値を追加すると、それらの数のsizeof(*p)単位だけメモリ内で前方にシフトします。

delete pでは、との違いは何ですか。delete p+1また、ポインタを作成する0だけで問題が発生するのはなぜdelete p+1ですか。

削除とデストラクタに問題があります（ここで愚かな間違いを犯していると確信していますが、現時点ではそれを理解できていません）。

デストラクタにステップスルーし、ポインタでdeleteを呼び出そうとすると、「アドレスのあるアドレスのメモリにアクセスできません」というメッセージが表示されます。

関連するコードは次のとおりです。

と