最近のほぼすべてのオペレーティング システムは、プログラムの終了後に、割り当てられたすべてのメモリ領域を回復します。私が考えることができる唯一の例外は、プログラムの静的ストレージと実行時メモリがほとんど同じものである Palm OS のようなものかもしれません。 (ここでは憶測にすぎません。)
したがって、必要以上のストレージを使用することによる実行時のコストを除けば、一般的には害はありません。確かに、あなたが示した例では、変数がクリアされるまで使用される可能性のある変数のメモリを保持したいと考えています.
ただし、必要がなくなったらすぐにメモリを解放し、プログラムの終了時に残っているものはすべて解放するのが良いスタイルと考えられています。これは、使用しているメモリを把握し、それがまだ必要かどうかを検討するための演習です。追跡しないと、メモリ リークが発生する可能性があります。
一方、終了時にファイルを閉じるという同様の警告には、より具体的な結果があります。そうしないと、書き込んだデータがフラッシュされないか、一時ファイルの場合はフラッシュされない可能性があります。終わったら削除。また、データベース ハンドルはトランザクションをコミットし、処理が終わったら閉じる必要があります。同様に、C++ や Objective C などのオブジェクト指向言語を使用している場合、使い終わったオブジェクトを解放しないと、デストラクタが呼び出されず、クラスが担当するリソースがクリーンアップされない可能性があります。
はい、そうです、あなたの例は害を及ぼすことはありません(少なくとも最新のオペレーティングシステムではそうではありません)。プロセスによって割り当てられたすべてのメモリは、プロセスが終了すると、オペレーティング システムによって回復されます。
出典:割り当てと GC の神話 (PostScript アラート!)
とはいえ、すべてのメモリ リークを回避するように努める必要があります。
2 番目の質問:あなたのデザインは問題ありません。アプリケーションが終了するまで何かを保存する必要がある場合は、動的メモリ割り当てを使用してこれを行うことができます。事前に必要なサイズがわからない場合は、静的に割り当てられたメモリを使用できません。
===将来の保証についてはどうですか とコードの再利用 ? ===
しない場合 オブジェクトを解放するコードを書くと、閉じられるプロセスによってメモリが解放されることに依存できる場合にのみ安全に使用できるようにコードが制限されます...つまり、小さな1回限りの使用プロジェクトまたは「スロー-離れて" [1] プロジェクト)... プロセスがいつ終了するかがわかります。
する場合 動的に割り当てられたすべてのメモリを free() するコードを作成すると、そのコードの将来性が証明され、他の人がより大きなプロジェクトでそれを使用できるようになります。
[1] 「使い捨て」プロジェクトについて。 「使い捨て」プロジェクトで使用されるコードには、捨てられない方法があります。次に気がつくと、10 年が経過し、「使い捨て」コードがまだ使用されています)。
自分のハードウェアの動作を改善するために、楽しみのためにコードを書いた人の話を聞きました。彼は「ただの趣味で、大きくてプロにはならないだろう」と言った.数年後、多くの人が彼の「趣味」コードを使用しています。