アカウント名:
パスワード:
しばらく前の IEEE Computer Magazine に載っていた記事の受け売りです.職場に置いてあるので,何号の何ページなのかが確認できませんが.
普通の文脈で言うソフトウェアの品質には,クラッシュせず安定して動作すること,ユーザインタフェースが一貫していること,保守しやすいことなどがあります.これらは,一般的なユーザが使用する際に戸惑わないことや,ユーザの新しい要求に応えるためにソフトウェアを変更しやすいことなどを表わす基準です.
一方,計算結果を人間が読み,何らかの判断を下すためのアプリケーションには,「計算結果が間違っ
>メモリリークのような計算結果に影響しない欠陥 この辺りがすでに間違った認識なんじゃないかな。
メモリリークしている領域に、他からアクセスしていないという確証が得られるまで、メモリリークしないように作るべきだと思います。#メモリを確保したら、次行は解放する処理を書きましょう。#確保した領域への処理はその間に書けば良いのです(プログラムにもよりますが・・・)#並列処理を行う場合は排他処理を適度に入れましょう
たまたまうまく動いているように見えるだけで、実はとんでもない間違いが混入している可能性はできるだけ排除すべきだと思いますが、研究者は計算が間違っていても気にしない人が多いようですね。
開放してればSegmantation Faultかなんかのエラーで一発で検知できるよね。少なくとも誤った結果を正当なものと誤解するリスクは回避できる。
メモリを開放することによるリスクって何でしょ?たまたまうまくいっていた計算がうまくいかなくなること?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
公開したくないなぁ (スコア:1, 参考になる)
議論で公開しろと言われれば、しますけどね…
公開するならもう少し綺麗なコードにしたいし、その時間があるなら別のことをしたいというのが本音。
一応、プログラムが正しい結果を出すことはチェックしている…つもりなんですが…
学生さんに渡したプログラムに、卒論提出直前にとんでもないミスが見つかったことがあります。
Re: (スコア:2, 興味深い)
しばらく前の IEEE Computer Magazine に載っていた記事の受け売りです.職場に置いてあるので,何号の何ページなのかが確認できませんが.
普通の文脈で言うソフトウェアの品質には,クラッシュせず安定して動作すること,ユーザインタフェースが一貫していること,保守しやすいことなどがあります.これらは,一般的なユーザが使用する際に戸惑わないことや,ユーザの新しい要求に応えるためにソフトウェアを変更しやすいことなどを表わす基準です.
一方,計算結果を人間が読み,何らかの判断を下すためのアプリケーションには,「計算結果が間違っ
Re: (スコア:2)
>メモリリークのような計算結果に影響しない欠陥
この辺りがすでに間違った認識なんじゃないかな。
メモリリークしている領域に、他からアクセスしていないという確証が得られるまで、メモリリークしないように作るべきだと思います。
#メモリを確保したら、次行は解放する処理を書きましょう。
#確保した領域への処理はその間に書けば良いのです(プログラムにもよりますが・・・)
#並列処理を行う場合は排他処理を適度に入れましょう
たまたまうまく動いているように見えるだけで、実はとんでもない間違いが混入している可能性はできるだけ排除すべきだと思いますが、研究者は計算が間違っていても気にしない人が多いようですね。
Re:公開したくないなぁ (スコア:0)
「できるだけ排除すべき」なのは,その通りです.問題は「できるだけ」の部分です.
有限の労力で全ての欠陥を取り除くことは出来ません.
ですから,アプリケーションの種類によって,優先して取り除くべき欠陥が異なるのです.
これは,先に例として挙げた判断用のアプリケーションに限った話ではありません.
例えば,銀行の基幹システムと,自動車の制御システムでは,問題となる欠陥が異なります.
銀行の基幹システムではデータを失なったり壊したりしないことが最優先であり,自動車の制御システムでは安全性が最優先されます.
以下は,古から繰り返される「malloc/free 論争」なので,私が書くのは今回で最後にします.
興味があるならウェブページを検索してみてください.
メモリを開放したつもりで開放できていないのと,最初から開放しないと決めるのは,全く別の話です.
使わないと決めた領域に,間違ってアクセスすることはありません.
逆に,もし間違ってアクセスしているとしたらそれ自体が問題であり, free() によって開放していても問題は変わらないか,より深刻になります.
> #メモリを確保したら、次行は解放する処理を書きましょう。
例えばグラフ構造の場合,確保と開放をそのように単純に対応させることは出来ません.
ノードを個別に開放するためには, mark & sweep による GC と同等の処理が必要になります.
Re: (スコア:0)
開放してればSegmantation Faultかなんかのエラーで一発で検知できるよね。
少なくとも誤った結果を正当なものと誤解するリスクは回避できる。
Re: (スコア:0)
「少なくとも誤った結果を正当なものと誤解するリスク」はどうやっても出ますし、それを回避するには結果を慎重にチェックするしかないのです。
メモリを解放すること自体にリスクがある以上、どちらが正しいとは言い切れません。
Re: (スコア:0)
メモリを開放することによるリスクって何でしょ?
たまたまうまくいっていた計算がうまくいかなくなること?
Re: (スコア:0)
# もしそうなら、今すぐ Microsoft か Sun に行って、言い値で雇ってもらってください。