アカウント名:
パスワード:
>メモリリークなんかのバグがあってもアウトプットが正しければ良い正しいのか?
まあ言いたい事は分かる。「個別の値に誤りがあったとしても定性的な傾向さえあっていれば良い」的な意味なんだろうけど。
公開されるつもりで書いたほうが論理的になるし、あとでバグを潰すことは大変な苦労をする。
「品質は作りこむものです」という言葉もあるしな。
>メモリリークなんかのバグがあってもアウトプットが正しければ良い 正しいのか? まあ言いたい事は分かる。 「個別の値に誤りがあったとしても定性的な傾向さえあっていれば良い」 的な意味なんだろうけど。
ぜんぜん分かってないってことが分かる。 メモリリークは、途中経過にしろ最終結果にしろ、数値の誤りを意味するものではない。 上出来なプログラムに比べれば、メモリリークするプログラムは実行中により多くの メモリを要求する筈だが、それを賄い切れる限り、単なるメモリリークだけでは 間違った数値を出力したりはしない。
メモリリークは、途中経過にしろ最終結果にしろ、数値の誤りを意味するものではない。
君こそバグの恐ろしさを判っていない。
メモリリークのあるところ、ポインタ操作の間違いアリ、だ。演算対象や、保存先のアドレスが正しくなければ、数値演算の結果の正しさは保証できん。
メモリリークのあるところ、ポインタ操作の間違いアリ、だ。
それは相関関係であって、因果関係ではない。 メモリリークの修正をうかつに奨励すれば、一定量の 「メモリリークのある、低品質なプログラム」が「メモリリークのない、低品質なプログラム」 に変換される。前者の方が後者よりも検知容易であることとを考えると、寧ろ放置すべきである。
前者の方が後者よりも検知容易であることとを考えると、寧ろ放置すべきである。
それこそナンセンスだ。前者だろうが後者だろうが、数値計算結果に間違いがある危険性が高いことに変わりはなく、なおかつソースが公開されない限り、数値計算結果に影響のあるメモリリークか、影響の無いメモリリークかは評価不能なのだから。
「うちの娘は、メモリリークがあっても大丈夫な娘ですっ」と言いたいなら、ちゃんとソースコードを公開するべきだ。
ついでに言っておくなら。研究用のコードを公開するにあたって、コードのクリーンナップは必要ない。
それも間違い。メモリリークではあるから。それ以外の問題でもあるというだけで。
というよりも。メモリリークというバグが単独で発生し、なおかつそれ以外の問題を引き起こさない、と言うのは奇跡的な状況です。
動的メモリ管理というのはすごく簡単に言うと:
1) メモリを確保する。確保したメモリは先頭アドレス/リファレンスで管理する2) 1 で得たアドレス/リファレンスを基点として、一連の演算を行う3) 1 で得たメモリを解放する
という3段階で成り立っています。また、コーディングもこの順序で行われるのが一般的です。メモリリークが「メモリリークとしてだけ」存在するためには 「純粋に 3 の段階だけで」バグが混入しなくてはいけません。
普通はそのようなことは起こりません。2 のステップの最中に 3 に至るはずのパスを一部記述しそこなう事で発生します。問題は 2 のステップの途中でなぜバグが混入されるか。
大抵の場合、メモリ管理が「主目的ではない」ために(主目的なプログラムって malloc/free 自身程度しか私は知らない)、デザインがプログラマの頭の中にしかない場合に問題が発生します。2の記述中に集中が阻害される事象が発生し、回復した時には頭の中のデザインが微妙に違っている。結果として処理順序が変化しメモリリークが起こる。メモリリークがある、というのはプログラミング中にそういうイベントが起こった事を表します。
メモリリークがあるというのは、「他のバグをも発生させている可能性が高い」事象が結構大切な部分をコーディングしている最中に起こった、と言う事なんです。演算部のコーディングそのもので間違える可能性は低いでしょう。一番大事な部分であり、一番意識を集中させているところですからね。でも「数字をどこから持ってくるか」「数字をどこに書き出すか」周りにはバグが混在する公算は非常に高い。間違った数字を正しく演算したら、間違った結果になるに決まっています。
.
メモリリークが生じていないプログラムを組める人は、プログラムのアウトラインデザインを紙に描いている人です。コーディングを始める前に何をどの順番で処理するのかを全部図にする。で、一塊づつコーディングをしていき、一塊単位で バージョン管理システム(自分用)にチェックインしていく。もし、何らかの理由で塊をコーディングしている最中に邪魔が入ったら、そこのコーディングを開始する前までロールバックして組みなおす。なのでチェックインはものすごく細かい単位で行われる。そのために「自分用」のバージョン管理システムをプロジェクトのそれとは別に持っている。
このような組み方をしている人は、メモリリークもめったに起こしませんし、アドレス異常も起こしません。なので、計算部そのものに問題が無ければ、結果は信頼できるでしょう。
>> メモリリークというバグが単独で発生し、なおかつそれ以外の問題を引き起こさない、と言うのは奇跡的な状況です。
プログラムの一般論としてはその通りだと思います.しかし,それは暗黙のうちに「メモリリークの無いプログラムを書こうとしている」という前提の下で「どこかで謎のメモリリークが発生してる.その計算結果が信頼できるか?」って命題になっているわけです.一方,ここの議論で主張されてるのは「計算結果に影響の無いところで解放されてないメモリがあることはわかった上でプログラムを書いている」って話だから,根本的に違う話をしてるわけです.
「計算結果に影響の無いところで解放されてないメモリがあることはわかった上でプログラムを書いている」って話だから
それはもっと根源的に、かつ当然の事として否定されていると思っていたのだが。
あるプログラムを考えて欲しい。このプログラムには2つのメモリリークバグが入っている。あなたは神様なのでそのことを知っている。
一箇所は意図的なもので、プログラマには悪影響がないことが判っている(本当か、本当にその判断は正しいのか?? と疑うのはとりあえずやめておこう)。
もう一箇所は意図していないもので、他の部分への影響があるかどうかは判らない(そりゃそうだ。プログラマはそもそも存在を知らないんだもの、検討しているわけが無い)。
さ。このプログラム、動かしてみたらメモリリークをしているらしい。第3者はこのプログラムの出力結果を信頼できるか出来ないか?
当然、できない。メモリリークが最初のバグに起因しているのか、二つ目のバグが存在してそいつに起因しているのか、わからないからだ。
意図したバグは、意図しないバグの存在を隠蔽する。故に、意図したバグの含まれているプログラムは信頼できないし、してはならない。プログラムを信頼して欲しければ、バグを 意図的に 埋め込んだり、放置したりしてはならない。
出力結果が信頼できるかはメモリリークとは無関係。
それは#1717270 [srad.jp]の主張に対する答になっていない。
#1717270 [srad.jp] は「計算結果に影響の無いところで解放されてないメモリがあることはわかった上でプログラムを書いている」という主張だ。
私が言っているのは そのような「わかった」は存在しない というものだ。
メモリリークがバグじゃなくて仕様なら良いんじゃないの。計算どおり、アロケーションエラーが発生すれば、信頼性抜群。
参照カウント式のGCのある言語での循環参照とかはどうでしょう?グラフをリンクで表現してるとありがちっぽい気も…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
公開したくないなぁ (スコア:1, 参考になる)
議論で公開しろと言われれば、しますけどね…
公開するならもう少し綺麗なコードにしたいし、その時間があるなら別のことをしたいというのが本音。
一応、プログラムが正しい結果を出すことはチェックしている…つもりなんですが…
学生さんに渡したプログラムに、卒論提出直前にとんでもないミスが見つかったことがあります。
Re: (スコア:0)
>メモリリークなんかのバグがあってもアウトプットが正しければ良い
正しいのか?
まあ言いたい事は分かる。
「個別の値に誤りがあったとしても定性的な傾向さえあっていれば良い」
的な意味なんだろうけど。
公開されるつもりで書いたほうが論理的になるし、あとでバグを潰す
ことは大変な苦労をする。
「品質は作りこむものです」という言葉もあるしな。
Re: (スコア:3, すばらしい洞察)
ぜんぜん分かってないってことが分かる。
メモリリークは、途中経過にしろ最終結果にしろ、数値の誤りを意味するものではない。
上出来なプログラムに比べれば、メモリリークするプログラムは実行中により多くの
メモリを要求する筈だが、それを賄い切れる限り、単なるメモリリークだけでは
間違った数値を出力したりはしない。
Re: (スコア:1)
君こそバグの恐ろしさを判っていない。
メモリリークのあるところ、ポインタ操作の間違いアリ、だ。
演算対象や、保存先のアドレスが正しくなければ、数値演算の結果の正しさは保証できん。
fjの教祖様
Re: (スコア:1)
それは相関関係であって、因果関係ではない。
メモリリークの修正をうかつに奨励すれば、一定量の
「メモリリークのある、低品質なプログラム」が「メモリリークのない、低品質なプログラム」
に変換される。前者の方が後者よりも検知容易であることとを考えると、寧ろ放置すべきである。
Re:公開したくないなぁ (スコア:2, すばらしい洞察)
それこそナンセンスだ。
前者だろうが後者だろうが、数値計算結果に間違いがある危険性が高いことに変わりはなく、なおかつソースが公開されない限り、数値計算結果に影響のあるメモリリークか、影響の無いメモリリークかは評価不能なのだから。
「うちの娘は、メモリリークがあっても大丈夫な娘ですっ」
と言いたいなら、ちゃんとソースコードを公開するべきだ。
ついでに言っておくなら。研究用のコードを公開するにあたって、コードのクリーンナップは必要ない。
fjの教祖様
Re: (スコア:0)
そういうのメモリリークって言わないから
Re:公開したくないなぁ (スコア:2, すばらしい洞察)
それも間違い。
メモリリークではあるから。それ以外の問題でもあるというだけで。
というよりも。メモリリークというバグが単独で発生し、なおかつそれ以外の問題を引き起こさない、と言うのは奇跡的な状況です。
動的メモリ管理というのはすごく簡単に言うと:
1) メモリを確保する。確保したメモリは先頭アドレス/リファレンスで管理する
2) 1 で得たアドレス/リファレンスを基点として、一連の演算を行う
3) 1 で得たメモリを解放する
という3段階で成り立っています。また、コーディングもこの順序で行われるのが一般的です。
メモリリークが「メモリリークとしてだけ」存在するためには 「純粋に 3 の段階だけで」バグが混入しなくてはいけません。
普通はそのようなことは起こりません。2 のステップの最中に 3 に至るはずのパスを一部記述しそこなう事で発生します。問題は 2 のステップの途中でなぜバグが混入されるか。
大抵の場合、メモリ管理が「主目的ではない」ために(主目的なプログラムって malloc/free 自身程度しか私は知らない)、デザインがプログラマの頭の中にしかない場合に問題が発生します。2の記述中に集中が阻害される事象が発生し、回復した時には頭の中のデザインが微妙に違っている。結果として処理順序が変化しメモリリークが起こる。メモリリークがある、というのはプログラミング中にそういうイベントが起こった事を表します。
メモリリークがあるというのは、「他のバグをも発生させている可能性が高い」事象が結構大切な部分をコーディングしている最中に起こった、と言う事なんです。演算部のコーディングそのもので間違える可能性は低いでしょう。一番大事な部分であり、一番意識を集中させているところですからね。でも「数字をどこから持ってくるか」「数字をどこに書き出すか」周りにはバグが混在する公算は非常に高い。間違った数字を正しく演算したら、間違った結果になるに決まっています。
.
メモリリークが生じていないプログラムを組める人は、プログラムのアウトラインデザインを紙に描いている人です。コーディングを始める前に何をどの順番で処理するのかを全部図にする。で、一塊づつコーディングをしていき、一塊単位で バージョン管理システム(自分用)にチェックインしていく。もし、何らかの理由で塊をコーディングしている最中に邪魔が入ったら、そこのコーディングを開始する前までロールバックして組みなおす。なのでチェックインはものすごく細かい単位で行われる。そのために「自分用」のバージョン管理システムをプロジェクトのそれとは別に持っている。
このような組み方をしている人は、メモリリークもめったに起こしませんし、アドレス異常も起こしません。なので、計算部そのものに問題が無ければ、結果は信頼できるでしょう。
fjの教祖様
Re: (スコア:0)
>> メモリリークというバグが単独で発生し、なおかつそれ以外の問題を引き起こさない、と言うのは奇跡的な状況です。
プログラムの一般論としてはその通りだと思います.しかし,それは暗黙のうちに「メモリリークの無いプログラムを書こうとしている」という前提の下で「どこかで謎のメモリリークが発生してる.その計算結果が信頼できるか?」って命題になっているわけです.一方,ここの議論で主張されてるのは「計算結果に影響の無いところで解放されてないメモリがあることはわかった上でプログラムを書いている」って話だから,根本的に違う話をしてるわけです.
Re:公開したくないなぁ (スコア:1)
それはもっと根源的に、かつ当然の事として否定されていると思っていたのだが。
あるプログラムを考えて欲しい。このプログラムには2つのメモリリークバグが入っている。あなたは神様なのでそのことを知っている。
一箇所は意図的なもので、プログラマには悪影響がないことが判っている(本当か、本当にその判断は正しいのか?? と疑うのはとりあえずやめておこう)。
もう一箇所は意図していないもので、他の部分への影響があるかどうかは判らない(そりゃそうだ。プログラマはそもそも存在を知らないんだもの、検討しているわけが無い)。
さ。このプログラム、動かしてみたらメモリリークをしているらしい。第3者はこのプログラムの出力結果を信頼できるか出来ないか?
当然、できない。
メモリリークが最初のバグに起因しているのか、二つ目のバグが存在してそいつに起因しているのか、わからないからだ。
.
意図したバグは、意図しないバグの存在を隠蔽する。
故に、意図したバグの含まれているプログラムは信頼できないし、してはならない。
プログラムを信頼して欲しければ、バグを 意図的に 埋め込んだり、放置したりしてはならない。
fjの教祖様
Re: (スコア:0)
結果はリークとは無関係に、別の方法でチェックされるべき。リークがあろうがなかろうが、間違った結果であればエラーと出るべきだ。
間違いの原因はリークかもしれないし、それ以外かもしれない。リークがないことは、結果の正当性を全く担保しない。
担保するのは出力結果のチェックのみ。
そのチェックが信用できない?それは他のどんなエラーに関しても言えることだ。
自分は神様ではないので、何が正しいのかわからない。わからないので、プログラムの出した結果を何一つとして信用しない。
信頼するのはチェックを受けた結果のみであり、リークの有無はまるで関係ない。
Re:公開したくないなぁ (スコア:1)
それは#1717270 [srad.jp]の主張に対する答になっていない。
#1717270 [srad.jp] は「計算結果に影響の無いところで解放されてないメモリがあることはわかった上でプログラムを書いている」という主張だ。
私が言っているのは そのような「わかった」は存在しない というものだ。
fjの教祖様
Re: (スコア:0)
自分は「メモリリーク」って単語よく知らなくって、なんか分からないけどちょっとしたバグの一種なのかなって思ってたけど、ぐぐったら大したことなくも無いんですね。ひょっとして元ACも同じ勘違いしてるんじゃないかな。
自分はFortran位しかいじらないんだけど、普通にFortran77組んでも「メモリリーク」って起こることあるのかな。多分、学者の「適当に」書くプログラムレベルじゃ、「メモリリーク」すら起こせないと思いますよ。
Re: (スコア:0)
メモリリークがバグじゃなくて仕様なら良いんじゃないの。計算どおり、アロケーションエラーが発生すれば、信頼性抜群。
Re:公開したくないなぁ (スコア:1)
というよりも。メモリリークというバグが単独で発生し、なおかつそれ以外の問題を引き起こさない、と言うのは奇跡的な状況です。
参照カウント式のGCのある言語での循環参照とかはどうでしょう?
グラフをリンクで表現してるとありがちっぽい気も…。