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