[過去ﾛｸﾞ]
GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
GCは失敗。メモリは自分で管理せよ！ その2©2ch.net http://mevius.5ch.net/test/read.cgi/tech/1447856699/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
20: デフォルトの名無しさん [] 2015/11/22(日) 01:48:28.16 ID:7AflF1fM メモリ管理を楽にするためにあるわけで人間が全部面倒みんのとは違うだろ http://mevius.5ch.net/test/read.cgi/tech/1447856699/20
21: デフォルトの名無しさん [] 2015/11/22(日) 04:41:20.06 ID:WFE6EpHf やっぱりGCのほうがいいかな大規模になってくると Cでリークはしてないけど本来開放すべきタイミングで開放してないでメモリいっぱいになるのは防ぎやすいと思うし http://mevius.5ch.net/test/read.cgi/tech/1447856699/21
22: デフォルトの名無しさん [] 2015/11/22(日) 07:04:28.69 ID:MUaNGGyB >>20 楽になってメモリリークがなくなるならいいけど、メモリリーク発生するわ プログラマがメモリ管理なんてしなくて大丈夫、とメモリの扱いが雑になって意図しないタイミングで解放されたりされなかったり 最初から管理するという方針で教えないから、こんなことになる 管理漏れをGCがうまいことやってくれる。でもGCにやらせるようだと恥。 というくらいで教育すべき http://mevius.5ch.net/test/read.cgi/tech/1447856699/22
23: デフォルトの名無しさん [] 2015/11/22(日) 07:12:51.89 ID:MUaNGGyB メモリ管理すらまともにできないやつが寿命や世代やら管理できるわけがない。 http://mevius.5ch.net/test/read.cgi/tech/1447856699/23
24: デフォルトの名無しさん [sage] 2015/11/22(日) 10:54:50.51 ID:MJCWCZ10 GCそのものではなく新人教育や解説書が最初のスタンス間違えたんだよ。 GC=メモリ管理適当 という認識作ったから、GCに新しい名称つけて 教育や解説書では、メモリーの確保から解放まできちっと説明し直したほうがいい http://mevius.5ch.net/test/read.cgi/tech/1447856699/24
25: デフォルトの名無しさん [sage] 2015/11/22(日) 12:31:51.68 ID:Qlq25ltW GCって完全なものだと思ってたから、C#案件でメモリリークの調査にえらく手間がかかった GCはダメな子って認識は必要だな http://mevius.5ch.net/test/read.cgi/tech/1447856699/25
26: デフォルトの名無しさん [sage] 2015/11/22(日) 12:38:37.22 ID:mfzN9aoV C/C++はライブラリレベルでメモリリリークの検査もテストも書けるけど GC前提言語だとその辺がごっそり抜け落ちて後で問題になる http://mevius.5ch.net/test/read.cgi/tech/1447856699/26
27: デフォルトの名無しさん [sage] 2015/11/22(日) 12:42:49.74 ID:zNwKjU3u メモリ管理できない人がお気楽で作れば、GCあっても・・・・ http://mevius.5ch.net/test/read.cgi/tech/1447856699/27
28: デフォルトの名無しさん [sage] 2015/11/22(日) 13:08:14.89 ID:KDgQ57Ye >>25 結局どんなバグだったんだい？ http://mevius.5ch.net/test/read.cgi/tech/1447856699/28
29: デフォルトの名無しさん [sage] 2015/11/22(日) 16:57:06.63 ID:vggKhYqJ C++でもスマートポインタ使えば勝手に開放されるよ 所謂GC任せだと、いつ開放処理が走るか分らなくなるから その事に対する新たな対策が必要になるよ http://ufcpp.net/study/csharp/rm_disposable.html 手続き型言語は処理の順番が重要なのに いつ実行されるか分からないってのは中々チャレンジャーだし大掛かりな話だね http://mevius.5ch.net/test/read.cgi/tech/1447856699/29
30: デフォルトの名無しさん [sage] 2015/11/22(日) 17:32:48.70 ID:vggKhYqJ 前スレでも書いたけど、C#のDisposeの問題を紹介しよう IDisposableなオブジェクトをコンポジションしてメンバに持つと自身もIDisposableにしなければならない だから自分がコンポジションしているオブジェクトがIDisposableかどうか一々調べなければならないし IDisposableなオブジェクトがメンバにあれば、自身もIDisposableにしなければならない さらに、その作ったクラスをコンポジションして使うクラスもIDisposableにする必要があり・・・ という風にIDisposableはクラスで閉じずコンポジションで伝染する というか、むしろ手動で伝染させなければならないという しかもIDisposableの一連のイディオムはとても長くて煩雑 http://ufcpp.net/study/csharp/rm_disposable.html こういうものを書いて、マネッジドリソースとアンマネッジドリソースで場合わけをしつつ IDisposableなオブジェクトに関しては 手動で自分のメンバのDisposeを漏れなく呼び出すコードを書かなければならない 当たり前だが、どのメンバがIDisposableか完全に把握しておく必要が有る 手動で自分のメンバのDisposeを呼び出す作業は、まるでCのmallocを思い起こさせる 問題点は明確で、DisposeがC++のデストラクタのように芋づる式に勝手に呼ばれない事に有る だから手動で芋づる式に呼び出すコードを書かなくてはならない http://mevius.5ch.net/test/read.cgi/tech/1447856699/30
31: デフォルトの名無しさん [] 2015/11/22(日) 18:20:40.59 ID:WFE6EpHf Formなんかも参照が亡くなったら強制的に殺すべきだったと思うわ ファイナライザーの処理がひどいことになると思うけど http://mevius.5ch.net/test/read.cgi/tech/1447856699/31
32: デフォルトの名無しさん [sage] 2015/11/22(日) 22:36:02.07 ID:iT1tZCI1 またお前か メンバに持つのが間違い http://mevius.5ch.net/test/read.cgi/tech/1447856699/32
33: デフォルトの名無しさん [sage] 2015/11/22(日) 23:18:34.23 ID:7zQV9dKP 無茶いうな http://mevius.5ch.net/test/read.cgi/tech/1447856699/33
34: デフォルトの名無しさん [] 2015/11/23(月) 08:11:32.17 ID:XNOSKZeE 解放処理をしなくてもGCがやってくれる。 でも、ソースに解放処理が書いてあれば、後から見たらあぁここで用済みになったのかとわかる。 可読性は非常に重要よ。 http://mevius.5ch.net/test/read.cgi/tech/1447856699/34
35: デフォルトの名無しさん [sage] 2015/11/23(月) 15:41:37.20 ID:qRZYsqEh 解放処理のタイミングが制御できないと、解放して欲しくないタイミングで解放されて 挙動が変わることがある リアルタイム性が要求されるシステムでこれで困ったことがある（そもそもそんな言語使うなって話だが） http://mevius.5ch.net/test/read.cgi/tech/1447856699/35
36: ◆QZaw55cn4c [sage] 2015/11/23(月) 17:14:59.57 ID:JWzW06M6 >>35 それはあまりない 挙動が変わるというか停止するというのならあるのかもしれないが http://mevius.5ch.net/test/read.cgi/tech/1447856699/36
37: デフォルトの名無しさん [sage] 2015/11/23(月) 17:21:44.69 ID:y4njP/wV うわっ頭のおかしいQだ http://mevius.5ch.net/test/read.cgi/tech/1447856699/37
38: デフォルトの名無しさん [sage] 2015/11/23(月) 17:22:22.95 ID:9XGqpqVu ＞解放して欲しくないタイミングで解放 なんでそんなことになったの？ 参照切ってなきゃGCの対象にならないはず http://mevius.5ch.net/test/read.cgi/tech/1447856699/38
39: デフォルトの名無しさん [sage] 2015/11/23(月) 17:24:18.17 ID:OK+rBFmG 空きメモリによって使用するアルゴリズム変えたりする。 だから実行前にGC手動で走らせて、できるだけ空きメモリ増やしたりとかする。 できるだけ開放したいのに過負荷でまだメモリに余裕あるからGC走らないってのが困る。 http://mevius.5ch.net/test/read.cgi/tech/1447856699/39
40: デフォルトの名無しさん [] 2015/11/23(月) 17:46:43.41 ID:XNOSKZeE メモリの解放漏れってさ、とどのつまり下手だからするんだよね 下手なやつにはプログラムを組ませないってのが鉄則だと思うの http://mevius.5ch.net/test/read.cgi/tech/1447856699/40
41: デフォルトの名無しさん [sage] 2015/11/23(月) 19:25:05.71 ID:6m6E/SfN c++11のshared_ptrの参照カウンタってそもそも要るんだろうか？ 複数のオブジェクトが所有権を持ちあう必要性に迫られる事がないんだけど weak_ptrの対応だけあれば良くない？ http://mevius.5ch.net/test/read.cgi/tech/1447856699/41
42: デフォルトの名無しさん [sage] 2015/11/23(月) 19:56:47.15 ID:+Ddm9172 リソースを共有する場合なんかは使うと楽だよ まーshared_ptrが有れば、いつ実行されるか分からないような、手の込んだGCは要らないよな 巡回参照が有る場合はどちらかをweak_ptrにする、これだけを守ってれば問題は起きない 大体の場合は所有権というか上下関係がはっきりしているからな 巡回参照のある場合も自動で開放したいという、たったこれだけのために いつ実行されるか分からない上に重いマークスイープ式GCを導入するのは 業界全体の早とちりだったようだね http://mevius.5ch.net/test/read.cgi/tech/1447856699/42
43: デフォルトの名無しさん [sage] 2015/11/23(月) 20:06:26.94 ID:+Ddm9172 最近のC++はdeleteを直接書かないだけでなく、最早newも直接書かない方向 std::make_shared<int>() って書くよね 始めからshread_ptrで受け取るから、循環参照だけ気をつければ リークする余地がないよね RAIIも健在で、C#みたいにIDisposableとか要らない デストラクタも芋づる式に呼び出されるから >>30で書いたような問題も起きないよ http://mevius.5ch.net/test/read.cgi/tech/1447856699/43
44: デフォルトの名無しさん [sage] 2015/11/23(月) 20:09:18.99 ID:OK+rBFmG C++は益々混沌としているのか。手に負えん。 http://mevius.5ch.net/test/read.cgi/tech/1447856699/44
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 676 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.014s