[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
226: デフォルトの名無しさん [] 2015/12/07(月) 08:02:18.14 ID:nEG5/lEo(1/4) AAS
こうやって、比較的プログラミングという行為を好きでいる・好きでやっている・興味を持っているという人ですらまともに言語仕様を理解出来ていない。
malloc、freeで管理、GCで管理だと、機構の複雑さは後者。
結局GCもその機構を正しく理解しないと参照が切れてない、参照が切れていても別のリソースが・・・と。
機構を正しく理解していることが前提なら、機構はシンプルなほうがいい。
その点を誤ったから
>プログラマをメモリ管理から開放する！
>といいつつ、メモリリーク問題の文献が大量にある。
>これすなわち、メモリリーク問題が全然解決していないということ。
>さらに、メモリ解放のタイミングの文献まで大量に生み出した。
>これすなわち、新たなるメモリ管理に関する問題を生み出したということ。
なんてことになったんだろうね
230(1): デフォルトの名無しさん [] 2015/12/07(月) 17:29:26.60 ID:nEG5/lEo(2/4) AAS
>>229
229(1): デフォルトの名無しさん [sage] 2015/12/07(月) 15:38:30.00 ID:6rSJBSiX(1) AAS
結局いつ開放されるか分からないってのが曲者で
使い終わったら確実にリソースを開放してほしいときは
別の仕組みが必要になってしまったってのが問題だろう
その別の仕組も、C++のデストラクタのようにクラスのメンバに関して
芋づる式に呼び出す仕組みがないから
C++のデストラクタがやっていることを手動で再現しなければならない始末

一方でC++のスマポなどの参照カウンタ方式は循環参照だけが問題だが
それ以外の問題が一切発生しない、デメリットは循環参照だけ
しかも循環参照が発生する場合は片方をweak_ptrにすれば良い
ということが分かりきっているし、循環参照が発生する箇所も
設計段階でわかる

循環参照に気を配れる知能が有るのであれば、参照カウンタ方式のほうがスマート
処理速度やタイミングがシビアな組み込みや科学技術計算系とかならいざしらず、
ソレ以外は、実際の解放のタイミング自体は問題にならんでしょ。(膨大なメモリの使用も別だけど)
問題は、使い終わったよーって明示しないで良い。という運用が結局、悪い結果をもたらしているという点。
メモリの管理をしっかり最後までやるクセのないプログラマは、
平然と参照が途切れている可能性のあるポイントで参照しに行こうとする。
結局は、そいつがバカだからに集約されてしまうんだけど、使い終わりの明示をしない文化がバカを生む土壌となっている
235: デフォルトの名無しさん [] 2015/12/07(月) 20:07:43.02 ID:nEG5/lEo(3/4) AAS
>>231
231(1): デフォルトの名無しさん [] 2015/12/07(月) 18:21:02.44 ID:q5G1dKJA(2/2) AAS
そういう事になる原因ってさ、構造がぐちゃぐちゃでオブジェクト間も依存しまくって、
いつ解放していいのかわかんねえーというヘボいプログラミングなんだろうなと思う。
そう。そういう状態にしちゃう原因が、いい加減なメモリの管理で教育された結果にあるのではないか？ということで。
236: デフォルトの名無しさん [] 2015/12/07(月) 20:09:47.14 ID:nEG5/lEo(4/4) AAS
>>234
234(1): デフォルトの名無しさん [] 2015/12/07(月) 20:05:22.53 ID:W4QZalq7(1) AAS
メモリ意識した時点で雑魚プログラマ決定だろ。
JavaScriptもPascalも使えないんじゃ話にならないよ。
おちんぽ見られることを意識しすぎて温泉に入れないようなもの。
癒やしのない人生に刺激なんてない。←これ名言
だれの名言かしらんが、

刺激のない人生に癒やしはない。

ならなんかしっくりくる。まぁ逆とっても同じ意味だからいいんだけど・・・。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.024s