「Inside the C++ Object Model」という本のセクション 6.3 で、Temporary Objects (page 230):
実際の結果は、基になる削除演算子がアドレス指定されたメモリを実際に解放する際にどれだけ積極的であるかに基づいて、実装に依存します。一部の実装では、メモリを空きとしてマークしながら、実際には変更しません。メモリが他の何かによって要求されるまで、メモリは削除されていないかのように使用できます。明らかにソフトウェア エンジニアリングの模範的なアプローチではありませんが、メモリが解放された後にメモリにアクセスするという慣用句は珍しくありません。 実際、の多くの実装では、まさにこの動作を保証
malloc()する特別な呼び出しが提供されています。malloc(0);
上記によると、malloc(0)すでに解放されている（ただし、内容は変更されていない）メモリへのアクセスに関連しているようです。
私の質問は、malloc(0)この動作をどのように保証できるでしょうか?
編集：「C ++オブジェクトモデルの内部」が参照であり、質問のタイトルの一部ではないことに気づきませんでした。
ディートマー・クールが言うように、それは恨みのように見えます、そしてあなたはそれがあなたのプラットホームに現れたとしてもそのような拡張に頼るべきではありません。
「ほとんどのプラットフォーム」にはmalloc、プログラマーがすでに渡されたメモリにアクセスするコードを見つけるのに役立つ、ある種のデバッグ機能が含まれていfreeます。これには、メモリ管理の遅延を少なくしたり、特別なバイトパターンで上書きしたりすることが含まれます。そのテキストは、そのようなmalloc(0)機能を無効にする手段として説明しているようです。Mac OS XIのリコールでは、これを制御する環境変数（のようなものMALLOC_DEBUG）があります。ファシリティの機能とその有効化方法は、プラットフォームによって大きく異なります。オーバーライドmalloc(0)は一般的でも、優れたインターフェースでもありません。
編集：1996年のStanleyLippmanによるC++オブジェクトモデルの内部で見つけました。信頼できる情報源ではありません。そのページ全体は、標準と「標準前」のプラットフォーム実装の違いを議論することに専念しているように見えますが、1996年も最初の標準が完成する前でした。それはずっと昔のコンピューター時代であり、特定のアプリを死から蘇らせない限り、そのような情報はまったく無関係であることに注意してください。Lippmanは、マルチスレッドをサポートする更新されたオブジェクトモデルを含むC++11に関する新しい本をリリースしたようです。（彼とその本のどちらが良いかはわかりませんが。）
引用から、未使用としてマークするときに割り当てメモリの内容を変更しない方法で(そしておそらく) メモリを割り当てるための将来の呼び出しを示すために、ある種のスイッチとしてmalloc()使用する実装があるようです。これは、明らかに、依存しないほうがよい標準準拠の拡張機能です。malloc(0)malloc()free()realloc(p, 0)
実用的な観点からは、malloc実際に割り当てられるスペースを与えることさえできません。
がどのように動作するかを確認する最も効果的な方法mallocは、それをカーネルへの要求と考えることです。カーネルは「OK」または「NO」と言うことができますが、カーネルが「OK」と言うと、それが本当に正しいかどうかを単純に確認できません。メモリを割り当てるか、「OK」と言って満足させるだけです。
これはメモリ ページに関する一種のオーバーブッキングです。たとえば、Linux でよくある問題です。通常、Linux カーネルはリクエストに対して非常に寛容ですが、リクエストが肯定的な結果を返したmallocとしても、メモリ不足になることがあります。malloc
「Linux メモリ オーバーコミット」のトピック検索の名前が必要な場合、mallocLinux でどのように機能するかについての一般的なアイデアが得られますが、同様の概念が他のプラットフォームにも適用されますmalloc。基本的にすべてがカーネルに依存します。