いいえ
専門家として、私たちが自分自身に尋ねるべきではない質問は、「これをやっても大丈夫ですか?」ということです。むしろ「良いものはありますか? これを行う理由は?" そして、"そのメモリ リークを突き止めるのが面倒" というのは正当な理由ではありません。
私は物事をシンプルに保つのが好きです。そして、簡単なルールは、プログラムにメモリ リークがあってはならないということです。
それは私の人生もシンプルにします。メモリ リークを検出した場合、それが「許容できる」メモリ リークであるかどうかを判断するために精巧なデシジョン ツリー構造を実行するのではなく、それを排除します。
これは、コンパイラの警告に似ています。この警告は、特定のアプリケーションにとって致命的ですか?そうでないかもしれない。
しかし、最終的にはプロの規律の問題です。コンパイラの警告を許容し、メモリ リークを許容することは悪い習慣であり、最終的には私を苦しめます。
極端に言えば、外科医が手術器具を患者の体内に残すことは許されるでしょうか?
SurgeonOverflow.com に投稿されたこの質問を見た場合、その機器を取り外すコスト/リスクが、そのままにしておくコスト/リスクを超える状況が発生する可能性があります。 「いいえ」以外の回答があった場合、医療専門職に対する私の信頼が著しく損なわれることになります。
–
サードパーティのライブラリが私にこのような状況を強いた場合、問題のライブラリの全体的な品質を真剣に疑うようになります.車を試乗して、カップホルダーの 1 つにワッシャーとナットが緩んでいるのを見つけたようなものです。それ自体は大した問題ではないかもしれませんが、品質へのコミットメントの欠如を表しているので、代替案を検討します。
「使用されている」メモリの量が増え続けない限り、メモリリークとは見なしません。理想的ではありませんが、解放されていないメモリがいくらかあることは、必要なメモリの量が増え続けない限り、大きな問題にはなりません。
まず、定義を正しくしましょう。メモリリーク malloc() のように、メモリが動的に割り当てられる場合です。 、およびメモリへのすべての参照は、対応する解放なしで失われます。簡単な作成方法は次のとおりです:
#define BLK ((size_t)1024)
while(1){
void * vp = malloc(BLK);
}
while(1) ループのたびに、1024 (+オーバーヘッド) バイトが割り当てられ、新しいアドレスが vp に割り当てられることに注意してください。以前に malloc されたブロックへのポインターは残っていません。このプログラムは、ヒープがなくなるまで実行されることが保証されており、malloc されたメモリを回復する方法はありません。メモリがヒープから「漏れ」ており、二度と見られません。
ただし、あなたが説明していることは次のように聞こえます
int main(){
void * vp = malloc(LOTS);
// Go do something useful
return 0;
}
メモリを割り当て、プログラムが終了するまで使用します。これは違う メモリリーク;プログラムが損なわれることはなく、プログラムが終了すると、すべてのメモリが自動的に掃除されます。
通常、メモリ リークは回避する必要があります。まず、上空の高度や燃料が格納庫に戻るように、リークして回復できないメモリは役に立たないためです。第二に、後でメモリ リークを見つけるよりも、最初にメモリ リークを起こさずに正しくコーディングする方がはるかに簡単です。