[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
22: デフォルトの名無しさん [] 2015/11/22(日) 07:04:28.69 ID:MUaNGGyB(1/2) AAS
>>20楽になってメモリリークがなくなるならいいけど、メモリリーク発生するわ
プログラマがメモリ管理なんてしなくて大丈夫、とメモリの扱いが雑になって意図しないタイミングで解放されたりされなかったり
最初から管理するという方針で教えないから、こんなことになる
管理漏れをGCがうまいことやってくれる。でもGCにやらせるようだと恥。
というくらいで教育すべき
37: デフォルトの名無しさん [sage] 2015/11/23(月) 17:21:44.69 ID:y4njP/wV(1) AAS
うわっ頭のおかしいQだ
139(2): デフォルトの名無しさん [] 2015/12/03(木) 16:32:54.69 ID:JraK7tKY(1/2) AAS
>>134mallocでOSから確保したメモリはfreeで解放されないんだが、
「ここで解放」はどうやって書くんでしょう?
173: デフォルトの名無しさん [sage] 2015/12/05(土) 14:45:23.69 ID:+HxrBEdK(2/5) AAS
>>167167(1): デフォルトの名無しさん [] 2015/12/05(土) 13:49:45.99 ID:Pfi54LUx(2/2) AAS
このスレ論点が一致してないよね。
freeやdeleteを記述すべきという論点で話をしている人
freeやdeleteしたところでメモリが解放されてるわけではないですがという論点の人
freeやdeleteは当然、さらにnull等を記述すべきという論点で話をしている人
GCの実装そのものを論点にしている人
論点がばらっばらだから咬み合わない
null云々は別言語だ馬鹿
199: デフォルトの名無しさん [sage] 2015/12/06(日) 12:05:41.69 ID:kVHO13oj(1) AAS
どうしてもやりたいなら対処法はあるしなぁ。
264(1): デフォルトの名無しさん [] 2015/12/12(土) 11:52:29.69 ID:v/VbuB+R(1) AAS
>>263263(1): デフォルトの名無しさん [] 2015/12/12(土) 10:36:13.53 ID:mXWFWn5f(1) AAS
freeし忘れるとか、そんな超ウルトラ素人ミスを大前提に議論するのは間違いだよなｗ
freeしきれないとかｗｗｗｗ
規模が大きくなれば管理が難しくなるのは普通のことだよ。
ライフサイクルはオブジェクトごとに異なるものだし、
人間に頼らずにGCにメモリ管理を任せるっていうのは良いやり方だよ。
453(1): デフォルトの名無しさん [sage] 2016/04/04(月) 02:47:24.69 ID:+1V6ohqL(1) AAS
GCがあるのになぜJavaはメモリリークしまくるソフトウェアを量産するのか
480(1): デフォルトの名無しさん [sage] 2016/04/18(月) 19:21:39.69 ID:IBBVu28x(2/4) AAS
寿命管理で解決できないとか、フラグメンテーションがどういう現象か分かっているの？
汎用の寿命管理APIみたいなのを使うとか言うのと勘違いでもしている？
506: デフォルトの名無しさん [sage] 2016/04/22(金) 11:30:03.69 ID:+Z1ZyILi(1/2) AAS
わかってなさそうな方がそれっぽいこと・・・・
533: デフォルトの名無しさん [] 2016/04/24(日) 15:05:02.69 ID:ynYywbEh(4/8) AAS
ちなみにQt使ってなかったら一日でサービスを書き上げることは不可能だっただろう。
Qtは、その他のGUIライブラリ同様バグが多いのだが、GUIを抜いてみるとどうだろう、
意外なほどに堅牢なのだ。
何しろもう半年動きっぱなし。
俺はこの経験から一つの予測を立てた。
これからのサービスは、C++で書かれるようになる可能性がある。
何しろ圧倒的に速い。
一つのリクエストに対するレスポンスが速いため、平均負荷率が圧倒的に下がるのだ。
この事実に世の中が気づくにはそう時間がかからないはず。
そしてsystemdがこの動きを促進するはず。
ちなみにWindowsで書いてLinuxで動かしてます。
580(1): デフォルトの名無しさん [sage] 2016/08/24(水) 13:32:09.69 ID:2RMcAgaj(1/3) AAS
本当の意味での軽量プロセスをOSがサポートしてくれたら良いんだけどね
メモリプールみたいなもんなんだけど、OSのリソースも紐づいてて
メモリプール解放時にOSのリソースもちゃんと解放されるようなもの
マルチプロセスは非常に強力で良いんだけど
メモリ空間が別になるから色々面倒だしパフォーマンスも出にくい
世の中には呼び出したらしばらく処理が返ってこない時間のかかる関数があるけど
とうぜんUIが固まったら困るから別スレッドで実行するわけだけど
処理中にユーザーがキャンセルボタンを押したとき
処理を中断する手段が関数側に用意されてなかったりすると、困る
外からスレッドごと殺しても、リソースリークの問題が出る
真っ先に困るのが同期オブジェクト
同期オブジェクトを握った状態で死なれると、それ以降デッドロックを引き起こす
それ以外にも、プログラムの整合性が壊れているかもしれないので、以降正しく動く保証がない
だから別プロセスで実行して、キャンセルされたときはプロセスごと殺すしか方法が無い
しかし別プロセスにするとメモリ空間が繋がってないので面倒
だからその中間がほしい
606(2): デフォルトの名無しさん [sage] 2016/11/15(火) 10:48:15.69 ID:4QSE1fRA(1) AAS
スタック変数の 0 クリアすら嫌がる C/C++ が GC 搭載とか夢見すぎ
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.040s