- 1 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 09:13:40.71 ID:mzO+gdRv]
- GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。
以下GCと記す
プログラマをメモリ管理から開放する！
といいつつ、メモリリーク問題の文献が大量にある。
これすなわち、メモリリーク問題が全然解決していないということ。
さらに、メモリ解放のタイミングの文献まで大量に生み出した。
これすなわち、新たなるメモリ管理に関する問題を生み出したということ。
malloc、freeじゃないが
結局のところ、メモリを管理するという技術は、今しばらくは、身につける・教える・学ぶべきではないだろうか？
使って、そのまま放置しても、基本的にはGCがなんとかしてくれている。
ランジョブからジョブ終了までさほどの時間を要さない。メモリも大して使わないならいいだろう。
しかし、規模が大きくなり常駐ジョブやメモリ大量使用のジョブになってくると、そんなメモリ管理の方法でやっていると、
上記「文献」を生み出されてしまう。
入門時は、メモリに無頓着でもいいだろう。それよりも、目的を達成することが先決だ。
しかし、慣れてきたら、やはりメモリの管理まで余裕を持って自分で行うべきだろう。
- 2 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 09:26:04.88 ID:/AOb9xWD]
- メモリの断片化対策でコンパクションを自力で作ってみたぞ！？
ただ、メモリ取得にあわせてメモリの配置をうごかしてるから、
処理としては重くなってるけど
- 3 名前：デフォルトの名無しさん [2014/10/11(土) 09:28:04.43 ID:mzO+gdRv]
- 激しく自作自演による、同意age!
- 4 名前：デフォルトの名無しさん [2014/10/11(土) 09:31:36.41 ID:FTKCoifo]
- >>1
まぁ君の言う通りだとは思うわ
ただ、時の流れを変えるのはなかなか難しいよ
- 5 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 10:00:31.15 ID:4uYM2ueX]
- 結局GCとかいっても、参照握ってるとそれがリークするから
名前が変わっただけなんだよな
- 6 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 10:02:00.16 ID:7SO6QsHv]
- gcc最高
- 7 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 10:07:53.81 ID:RJKjicrV]
- デストラクタは意図的に呼べるようにしてほしい
- 8 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 10:15:19.31 ID:C84ryw+n]
- >>1
何言ってんだよアホ
Javaがメモリリークするのはずっと前から知られてる事だし、それはプログラマが
「リークするようなプログラム」を書くからだろうが
- 9 名前：デフォルトの名無しさん [2014/10/11(土) 10:34:35.80 ID:mzO+gdRv]
- （T。T)なんだよぉ〜反対しろよぉ〜。盛り上がらないだろぉ〜。
- 10 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 10:53:41.89 ID:5HiTQGOf]
- 結局バカにつける薬はないという事
GCはバカにつける薬を目指したけど中途半端で、
他のリソースの管理を楽にするRAIIとも相性が悪く
余計な手間を増やすだけに
- 11 名前：デフォルトの名無しさん [2014/10/11(土) 11:19:13.65 ID:vaox7Njv]
- これGCもそうだけど、
OOでも同じことが言えるんだよね
結局、分割せずに一つのクラスにグダグダと何でもかんでも機能書き込みまくりやがる
んで再利用もされない
馬鹿にプログラミングさせないのが正しい処方
- 12 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 11:24:21.18 ID:5SSzSkT3]
- 肉体労働系にするための餌だったんでしょ
- 13 名前：デフォルトの名無しさん [2014/10/11(土) 12:12:50.56 ID:cpMaL1hK]
- リークしてる箇所を容易に特定できないのがクソだわ
- 14 名前：デフォルトの名無しさん [2014/10/11(土) 12:40:04.63 ID:gz4lvABW]
- そりゃ技術力の問題だわ
- 15 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 12:56:22.77 ID:8yVA6sZ1]
- バカが勝手に生成する循環参照を検出してやる義理はないってことだな。
- 16 名前：デフォルトの名無しさん [2014/10/11(土) 13:16:23.99 ID:XZu+KoKv]
- GCってなんかメリットもたらしたのだろうか？
- 17 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 14:21:55.07 ID:cDJhBayo]
- >>16
ダングリングポインタによるやっかいなバグが発生しない
- 18 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 16:06:07.68 ID:5SSzSkT3]
- ゴミを一箇所に集めると
早くなる
とか
広大なメモリ空間でゴミ集めしてもね
- 19 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 16:22:03.92 ID:0tst77Z4]
- GC使う言語って何があったっけ？
C++ぐらいでしょ？
- 20 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 17:01:29.09 ID:gz4lvABW]
- C++は使わない
- 21 名前：デフォルトの名無しさん [2014/10/11(土) 17:03:09.93 ID:gz4lvABW]
- メモリリークより循環参照のが怖いな。検出のしようもないし
- 22 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 17:35:30.35 ID:eOQAHjvH]
- 循環参照が問題になるような単純なリファレンスカウント方式って
今じゃほとんど使われていないんじゃないか？
メジャーなところでGC搭載前のObjective-Cくらい？
- 23 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 17:41:38.78 ID:Qk2dzUbv]
- しょっぱいGCといえば D
- 24 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 18:24:06.71 ID:Sxw1t6Y7]
- Objective-CはもうGC使うのやめたんじゃね？
- 25 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 18:31:05.39 ID:0tst77Z4]
- >>21
循環参照自体は怖くないでしょｗ
怖いのはそれを原因にしておきるメモリリーク。
そっちは検出できる。
それに循環参照ごときじゃメモリリークは起きないのが
ほとんどだし。
- 26 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 19:04:06.70 ID:h48KXGlz]
- 昔のIEとか循環参照でよくリークしてたよね
- 27 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 19:14:27.18 ID:P1IOX8Um]
- 自分で管理するとしても、finally句が使える言語なら割と楽そうな気がする
- 28 名前：デフォルトの名無しさん mailto:sage [2014/10/11(土) 19:15:00.75 ID:0tst77Z4]
- あれは循環参照がリークの原因ではないんだがな。
- 29 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 05:43:17.17 ID:Du/HgjiN]
- え、Javaは相変わらず循環参照でメモりリークというかメモリキープしたままになるじゃん。
- 30 名前：デフォルトの名無しさん [2014/10/12(日) 07:08:38.14 ID:jwvcB2bY]
- 激しく同意！（自演）
- 31 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 07:16:45.94 ID:jjrAIsW+]
- 参照カウンタ方式でないガベージコレクタを
採用したのはJavaが最初なんだけどな。
- 32 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 07:24:12.59 ID:Du/HgjiN]
- そもそも参照カウントで自動解放するのをGCと呼ぶのに未だに違和感がある。
そして参照カウンタ方式でも循環参照は解決できないよねえ。
objcは少なくとも今でもそうだな。
swiftでは改善されてるの？
- 33 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 07:25:36.74 ID:yWo9u0cs]
- >>29
リークじゃなくてキープなら循環参照関係なくね？
- 34 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 07:25:38.03 ID:jjrAIsW+]
- > そして参照カウンタ方式でも循環参照は解決できないよねえ。
参照カウンタ ”だから" 循環参照でメモリリークするんだけど？
- 35 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 07:35:30.36 ID:Du/HgjiN]
- >>33
プログラマがもう使ってない認識なのにキープしたままになるのは、広義のメモリリークではありますわね。
>>34
いや、原理的にはもう一層上のとこで各オブジェクトの参照カウンタを監視できれば、一応解決はできる。
Delphiのカスタムメモリマネージャでそういうのやろうとしてたプロジェクトあった記憶があるんだけど、どうなったのかなあれ。
- 36 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 09:45:05.81 ID:6t43fLEu]
- 使ってない認識でいいのですか？
開放忘れですよね
- 37 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 10:01:07.24 ID:Rdz70+uR]
- 使ってなくても参照可能な状態ならnull突っ込んどけよ
- 38 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 10:06:02.46 ID:PS2RkwMW]
- null突っ込むとか考えないといけないならもう気持よく開放させてください
- 39 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 11:06:29.68 ID:jwvcB2bY]
- >>38
NULLになってなければ最後に解放。
NULLなら使ってない。解放済み。とかやってたころと結局変わってないよね。
むしろ、解放のタイミングとか考えなきゃいけない。やること増えたような気がする。
char *data = NULL;
略
data = (char *)malloc(.........)
if(!data)
goto 最後
else
略
略略略複雑な動き略略略略略
最後
if(NULL == data)
free(data);
- 40 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 11:11:22.69 ID:cL8Hj/o5]
- >>31
もっとずっと大昔からあるだろ。
>>32
perlも参照カウントだな。
perlのはGCでobjcのはGCではないと思うけど、
何が違うんだろうな。
- 41 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 11:17:35.70 ID:Du/HgjiN]
- objcはスクリプト言語じゃないから、吐き出されたバイナリ自身にメモリ管理コードが入ってるところじゃないかな。
- 42 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 11:20:10.87 ID:Du/HgjiN]
- 当時GCという言葉は無かったが、オブジェクトパスカルの文字列は唯一自動解放されてたな。
一方Cはnullパディングなメモリを自分で確保して解放して…
- 43 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 11:32:15.06 ID:cL8Hj/o5]
- >>41
なるほど。
あとobjcのは自動だけどあんまり透過的ではないね。
- 44 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 11:42:15.44 ID:yWo9u0cs]
- >>40
参照カウントを明示的にデクリメントするのは普通GCと呼ばれないと思う。
C++のスマートポインタは微妙なとこだが。
個人的には、実際の回収のタイミングをプログラマが制御できるかどうかが
分かれ目かな。
- 45 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 11:45:40.46 ID:cL8Hj/o5]
- >>44
いや、今のobjcはそこは自動。
参照カウントを操作するコードはコンパイラが勝手に入れて、プログラマは触れない。
- 46 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 11:46:08.06 ID:oZdnSd4X]
- GCがあってもメモリリークは起きる ← うんうん
だからGCは失敗 ← は？
- 47 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 12:16:18.39 ID:K67PydJN]
- リソース掴むオブジェクトを扱う場面での
auto_ptr/unique_ptrと同じことをするのに
javaのtry with resourcesや
c#のusing,dのscope
どれも笑えるほど間抜けで間違いやすく
リソース掴むかどうかプログラマが
知っている必要があるとか
色々破綻しすぎ
- 48 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 12:27:00.92 ID:XUhdfZSs]
- >>46
GCの目的を達せられてないなら、そう評価されても仕方ないやろ
- 49 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 12:37:01.74 ID:9H44j9Kw]
- ストップザ・ワールドさえなければGC歓迎なんだけどなー
- 50 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 12:37:50.50 ID:hLdPYKPK]
- >>45
GCじゃなくてARCだろ
- 51 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 13:01:26.29 ID:sv4A2Uaz]
- >>48
> GCの目的を達せられてない
ちゃんと使えてないだけだろ
それを GC のせいにするなよ w
- 52 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 13:25:42.92 ID:aqGemz9O]
- 明示的に消すのはまあ良いとしてnullされたら芋ツルに循環追跡して断
ち切る仕組みはあって良いと思うまあ手抜きしたいだけだが
- 53 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 13:29:57.54 ID:oZdnSd4X]
- GCがあってもメモリリークは起きるが
GCがあれば起きないメモリリークもあるんだから
それを理由にGC抜きでメモリを管理すべきという主張はおかしい
- 54 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 13:47:40.68 ID:PS2RkwMW]
- 重い、開放されるまでメモリ食う、GCがあってもGC無い時と同じくらい気を使わないとリークするっていう
デメリットがキツすぎてメリットはないようなもの
- 55 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 13:52:35.33 ID:9H44j9Kw]
- リークしても自分で管理してれば解消できるんだけど
GCだとどこでリークしてるかわからないからいらない
- 56 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 13:59:06.09 ID:Du/HgjiN]
- んなもん、ヒープダンプすればだいたい予想つくべよ
- 57 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 14:01:17.81 ID:9H44j9Kw]
- まじかよ
すげーな
- 58 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 16:33:59.45 ID:ZNdZQbYT]
- どーもWEBの所為で、というか今までPGに向いていなかった人にも良い仕事が出来るようになったようで
旧タイプというか本来タイプの技術者と壁があるようだな
- 59 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 16:38:08.31 ID:jjrAIsW+]
- 本来タイプの技術者とはOSを一から作るものよ。
他人が作った技術なんて信用してないからな。
全て自分で管理するのが一流の技術者
- 60 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 16:42:45.90 ID:ZNdZQbYT]
- >>59
それが理想だが、仕事だと環境を選べない。石を直接叩いた時は素直でやりやすかったものよ
- 61 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 16:50:59.96 ID:b192FRFU]
- GCの無いHaskellを想像したら鳥肌が立った。
- 62 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 17:10:56.08 ID:uNtO2YXD]
- >>60
> それが理想だが、仕事だと環境を選べない。
じゃあ趣味の話をしてくれよ。
sqrt(a * 2 + b * 3)
を「素直でやりやすい方法」で書いたらどうなるの？
- 63 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 17:14:52.08 ID:WHilwmxs]
- 石を直接叩いた時代は単に要求が
今よりもはるかに小さかっただけだよ。
簡単な事しかしてない。
いや、コード自体は難しいんでしょ？
簡単なことっていうのは、コードの話ではなくて
作る機能のこと。
- 64 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 17:48:09.49 ID:ZNdZQbYT]
- >>63
多用途コンピュータではない物や独自のデバイスを制御する時に石を叩く。見慣れたアプリとは
違った物を作るときに必要になる。
>>62
お前はその程度のコードに設計が必要なのか？
- 65 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 18:04:01.60 ID:WHilwmxs]
- > お前はその程度のコードに設計が必要なのか？
設計？ どこからでてきたの？
いや、石を直接叩いていたら
難しいだろって話。
これが難しく感じるならダイアログボックスを
出すコードでもいいよ。
JavaScriptなら
alert("あほ");
- 66 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 18:15:24.76 ID:aqGemz9O]
- 上の誰かさんが自分で全部書いた物より長い間保守されたライブラリの方が
信頼出来ると思うのは気のせいか
- 67 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 18:21:08.51 ID:6hSJbmJs]
- プログラマの仕事っていうのは、前にやった同じことを
何度もやることではないんだよね。
一回やったことと同じようなことは
二度とやらないぐらいの気持ちでやらないといけない。
同じことを何度も繰り返すのはコンピュータが得意とするところなので
人間がやってる「同じようなこと」はコンピュータにやらせるもの。
メモリ管理なんてのも、人間がやることじゃないんだよ。
何度も同じことをやるなんてサルのオナニーと一緒だよ。
- 68 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 18:24:13.59 ID:ZNdZQbYT]
- >>65
このスレでは実行環境の話をしてるんだ。それを理解して失せろ
>>67
その理屈だと一度使ったライブラリは二度と使うなという事になるな
- 69 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 18:28:09.44 ID:6hSJbmJs]
- >>68
> その理屈だと一度使ったライブラリは二度と使うなという事になるな
意味不明。同じことができるならコードを書くなって話。
同じコードを書かないで出来るなら、ライブラリを使ったコードも書かなくていいよｗ
- 70 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 19:46:54.20 ID:im4AGP4w]
- 「ガーベジ」コレクションって書いてる奴いると叩き殴りたくなる
- 71 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 19:51:27.69 ID:ZNdZQbYT]
- GC派はコンピュータの仕組みを知らないからかな？メモリを確保できなきゃプログラムをロードする事も
リソースを扱う事もファイルの読み書きも出来ない。その用途は毎回違う。
それを同じ処理で出来ると思ってるのが凄い
- 72 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 20:16:48.31 ID:FZ1mZF0A]
- >>71
> GC派はコンピュータの仕組みを知らないからかな？
まるで、何かの仕組みを知った人は、その仕組みを
使わないことを選ぶみたいな言い方じゃないか？
ポンプの仕組みを知った人は、ポンプを使わずに自分で吸い上げるようになるみたいな。
仕組みを知った上で、その仕組が便利だから使うんだよ。
> それを同じ処理で出来ると思ってるのが凄い
今、GCの話だったよね？ メモリ確保する時の話じゃなくて
メモリを解放する時の話。
お前の書くコードは、同じメモリを使ってるのに、
毎回違う方法でメモリを解放してるのか？
ばかじゃね？
- 73 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 20:18:00.19 ID:FZ1mZF0A]
- 用途ごとに違う方法でメモリ解放するって
freeForFile とかfreeForConfigFileとか
そういう関数作ってんの？
- 74 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 20:21:04.63 ID:vwmhZXgg]
- なんでこいつら仲悪いの？
- 75 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 20:23:19.99 ID:cL8Hj/o5]
- >>70
正しくは？
- 76 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 20:23:46.40 ID:FZ1mZF0A]
- >>74
２ちゃんねるはじめてか？
これが普通なんだよ。
- 77 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 21:18:05.03 ID:ZNdZQbYT]
- それもあるが、コンピュータに対する考え方が真逆でありながら同じ仕事をしてるからだろうな
- 78 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 21:27:56.88 ID:jwvcB2bY]
- GC自体、メモリ管理がちゃんとできない人対策だったわけで
そんなやつが、メモリリークが発生して、それを調査できるスキルがあるわけもなし
ちゃんとメモリ管理できてる人からすると、よけい複雑になっただけ
- 79 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 21:34:54.47 ID:uoArxlQJ]
- >GC自体、メモリ管理がちゃんとできない人対策だったわけで
あぁ、この中でfree書き忘れたことがない人だけ
石を投げなさいってやつだな（大爆笑）
- 80 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 21:45:20.46 ID:K67PydJN]
- 今時c++でdeleteを昔の意味で使う人間は
忘れるとかそれ以前の問題で
終わっているような。
- 81 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 21:52:54.07 ID:uoArxlQJ]
- >>80
仕組みを知った人は、面倒でも効率が悪くて
ミスを誘発しそうでも、
自分でやるのが自称プロだそうですよｗｗｗｗ
- 82 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 22:01:17.22 ID:K67PydJN]
- c++でdelete freeでプログラム書けるし
全く同じやり方で、他のリソースの
解放も勝手にやってくれるようになる。
怖いのは循環参照だけ。
この場合GC言語だとメモリのリークは防げても、循環参照しているオブジェクトに
保持されているリソースの解放タイミングは
全く保証されない。
で、それの対策も考えたら結局
c++で弱参照、単なるポインタなど
駆使するのが一番効率的
- 83 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 22:05:26.88 ID:uoArxlQJ]
- この場合GC言語だとメモリのリークは防げても、循環参照しているオブジェクトに
保持されているリソースの解放タイミングは
全く保証されない。
その反対で、GCではない言語だとメモリリークするわ、循環参照しているオブジェクトは
解放できないわで、もっと問題が起きる。
- 84 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 22:08:58.07 ID:jwvcB2bY]
- >>79
だれ？誰と戦ってるの？
- 85 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 22:09:56.49 ID:uoArxlQJ]
- >>84
知らぬが仏だよ（笑）
- 86 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 22:27:26.00 ID:6t43fLEu]
- GCのやり方？が悪いわけではないでしょ
GCでパフォーマンス上がることもあるし
- 87 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 23:01:07.26 ID:yWo9u0cs]
- >>82
GC言語でリソースの解放タイミングが保証されないのは、別に
循環参照に限った話じゃないと思うが。
- 88 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 23:05:39.92 ID:sv4A2Uaz]
- まあ、適材適所なんだけどね
GC は勝手にやらせとくと色々予測できないし、ちゃんと制御しようとすると面倒なことになって本末転倒だったりする
結局スクリプトとか C# で作るツールとかの小規模なプログラムでしか使ってないや
- 89 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 23:19:48.88 ID:K67PydJN]
- >>87
いやまあ言いたいことは同じなんだけど。
ヒープみたいに、lazyに解放すればいい
リソースなんて少数派な位なのに
ヒープだけを特別扱いしてリークしづらく
しているのがGCで、逆に他のリソースの
解放に関しては糞の役にも立たない。
頑張って使いやすくしても
try with resourcesみたいなのが精々
- 90 名前：デフォルトの名無しさん mailto:sage [2014/10/12(日) 23:20:37.56 ID:Du/HgjiN]
- 単純に速度が必要でメモり欲しいループの前でsystem.gc()すりゃいい
- 91 名前：デフォルトの名無しさん mailto:sage [2014/10/13(月) 00:36:28.02 ID:XlHNUUuP]
- >>89
> 頑張って使いやすくしても
> try with resourcesみたいなのが精々
言い方がひねくれてるだけで、
使いやすくなってるんだろ？
100% じゃなくても90%なら0％よりもはるかにいいし。
君、完璧主義かい？ 完璧じゃなければ0の方がいい。
命を完全に守れないなら、安全装置はいらない。
- 92 名前：デフォルトの名無しさん mailto:sage [2014/10/13(月) 01:50:00.34 ID:qVWnI3+v]
- シートベルト装着義務違反 減点１
- 93 名前：デフォルトの名無しさん mailto:sage [2014/10/13(月) 02:14:43.55 ID:Sk2z4NAD]
- そもそも管理の観点が違うものをリソースとかそういう言葉で一括りにしていいもんなのかなぁ
別にGCとRAIIが必ずしも互いに排他的なものでも無いだろうし
- 94 名前：デフォルトの名無しさん mailto:sage [2014/10/13(月) 02:52:33.01 ID:Y+iyP5NT]
- 参照してるから解放されないのであって、使ってない物は
参照しないようにする＝null入れるだけの話だろ。
- 95 名前：デフォルトの名無しさん mailto:sage [2014/10/13(月) 02:57:40.58 ID:2n2KRb08]
- >>93
Unixなんか、リソースは何でもファイルですよ？
これが抽象化というもの。
- 96 名前：デフォルトの名無しさん mailto:sage [2014/10/13(月) 03:02:03.17 ID:jfB1gY05]
- >>94
OS側から勝手に参照し続けるKindleという機種がありましてな…。
|
 |
