0

このように機能する短命プログラムのクラスがあります。

1. Allocate some resources - memory, open files, etc.
2. Make some computations
3. Free allocated resources
4. Terminate

同じ質問は、タイプの長期プログラムの終了段階にも当てはまります。

1. Do some job
2. If not the end - goto 1
3. Free the resources still allocated
4. Terminate

これで、プログラムの終了後に OS 自体が常にクリーンアップすることがわかりました。割り当てられたメモリをコードでクリーンアップする必要が本当にあるのでしょうか? OS によって解放されて同じ成功を収め、さらに一歩進んでいるとしたら?

上記の例のポイント 3 を安全に省略できますか? 結局のところ、時間とコードです。

明確化 1 : 私は、別のコンテキストで誰かがコードを再利用できるライブラリについて話しているのではありません。上記の構造が十分にきれいな完成したプログラムについて質問しています。

明確化 2 : 「グッド プラクティス」は、「悪影響」を防止することを目的としているため、そのように呼ばれています。しかし、悪い影響が起こりえない場合、これらの慣行は依然として「良い」のでしょうか? それとも単に「伝統」ですか？

4

4 に答える 4

2

これはOSに大きく依存します。最近のほとんどの OS は、プログラムが終了するとすべてのリソースを自動的に解放します。つまり、プログラムを終了する前に何かを解放する必要はありません。

ただし、これは常に当てはまるとは限りません。特に、特定のタイプの組み込み OS では、より単純なアプローチがあります。

もちろん、あなた (またはもっと重要なことに、他の誰か) がコードを取得して、実行時間の短いプロセスから長寿命のプログラムに変更することを決定した場合も、うまく機能しません...

于 2013-10-14T16:47:40.143 に答える
1

これに対して、言語にとらわれない意味のある答えは本当にないと思います。

ガベージ コレクターを使用する言語では、終了前に GC が自動的に実行される可能性は低く、手動で強制的に実行することは一般的に無意味です (たとえ、ガベージ コレクターを使用できる言語/ライブラリを使用していると仮定しても)。それで）。

C++ では、ほとんどの場合、リソースの取得はコンストラクターで行われ、そのリソースの解放は通常、対応するデストラクタで行われます。この場合、適切なデストラクタを使用せずにコードを記述することは、ほぼ間違いなくバグです。単に不完全なクラスを記述し、そのバグが現れないようにする方法でのみ使用されることを望んでいるだけです。

C や、クリーンアップを手動で行わなければならないその他の同様のものでは、最終的なクリーンアップを行うコードを書くことを好みますが、通常はコメントアウトします。これにより、速度とコード サイズの両方が向上するだけでなく、データを解放するためのコードのバグを防ぐことができます (問題を引き起こすためにコンパイルされていないコードではかなり困難です)。

于 2013-10-21T06:27:36.520 に答える
0

あなたはいつも自分の後片付けをするべきです。誰かがいつあなたのコードを盗み、別の状況で使用するかはわかりません。

完全なソリューションをコーディングすることは、すべての状況で正しいことです。

于 2013-10-14T16:47:27.050 に答える
0

私もある時点でその質問を自問したことがあり、少し議論した後、次の結論に達しました。

後で大規模なプロジェクトでそのコードを再利用することにした場合に備えて、リソースを解放することをお勧めします。古いコードをデバッグすることほど悪いことはありません。すぐにそれを行い、優れたプログラミング手法に固執してください。

于 2013-10-14T16:48:12.800 に答える