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