[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
262: デフォルトの名無しさん [sage] 2015/12/09(水) 01:50:08.36 ID:x/ryIvcR(1) AAS
>>259259(1): デフォルトの名無しさん [sage] 2015/12/08(火) 23:55:28.64 ID:NMHe7TFl(4/4) AAS
>>258
ああ、Arcってのが別にいるのね。納得
個人的にもう一点気になる所があるから聞いてしまう
BoxやDropを使ってるとコピー禁止になるらしいけど
これ面倒な場合ない？
最初はコピー可能な型としてガンガンコピーしてたけど
途中から終了処理を書きたくなったらコピーしてる箇所
全部直すって事？
ちなみにググってたらRWArcっての見つけたんだけど
これ読み書き可能なArcなんじゃね
コピーしまくっているような変数の型をTからBox<T>に変えた場合、確かに面倒なことになる。
けど、基本的に単純な代入(let x = y)はコピーじゃなくてmoveになるし、
Box<T>の値をコピーしてBox<T>の値を生成するっていうのは、同じヒープ領域を指すポインタを作るんじゃなく、
新しいヒープ領域を確保して中身をコピーし、そのポインタを返すという意味なんで、
変数の型を後でTをBox<T>に変える、という場面はあまり無い(少なくとも自分は学んでいる最中にそういうことをしたくなったことがない)
値をコピーする場面では、元の変数の型がBox<T>であってもTであっても、参照型&Tを受け取ってTを生成、ということをするのが定石。
&Tはほぼ無制限に安全に作ることができるし、安全じゃない可能性があったらコンパイルが通らない。
で、コピーした型Tの値は呼び出し元がBoxに包んでヒープ領域に置いたりするのが定石
Dropも別にコピーを禁止することは無いよ。後からつけたらエラーまみれ、ということにはならない。
あと、自作じゃない型に自作じゃないトレイト(インターフェイスみたいなもの)をつけることができないので、
例えば標準ライブラリのFileやTcpStreamはCopyできるようには決してできない。メモリ以外の資源管理も安全だよ。
294: デフォルトの名無しさん [] 2015/12/17(木) 17:18:40.36 ID:Szn4FINI(1) AAS
COMのVariantとかJSとかリークしまくりだし
304(2): デフォルトの名無しさん [sage] 2015/12/20(日) 12:13:23.36 ID:ofrSOHxv(1/7) AAS
>>303303(2): デフォルトの名無しさん [sage] 2015/12/20(日) 11:55:11.08 ID:HXRBhwTH(1/3) AAS
C#ではSafeHandleだけ作って後は放置
usingも使わないってのがトレンドだけどね
自分で解放とかバカバカしい
面倒はランタイムに見させて開発者はドメイン設計に集中するって目的を見失うな
オブジェクトの開放を他と独立にやれるケースばかりならそう言えるかもしれんが
オブジェクトAとBがリソースCに依存しているケースでA、Bの開放の少なくとも片方をGCに任せる場合、
リソースCの参照カウンタなりをつかった防護策をプログラマーが書かねばならない
しかしそんな嫌ったらしい雑用を増やすぐらいなら
Cオープン
A生成
B生成
A, B使用
B開放
A開放
Cクローズ
でええやん？
さらにダンプファイルとかからの障害解析において、オブジェクトが生きているべきなのか死んでいるべきなのか決まっていないとか、
アドレスがはっきりしないとか言う状況は地獄
315(1): デフォルトの名無しさん [sage] 2015/12/20(日) 14:48:11.36 ID:ofrSOHxv(6/7) AAS
>>314>その例じゃ308の状況にならないよ
なんで？ビデオメモリに2スレッドから同時に書いて無事に済むと思ってるの…；
359: デフォルトの名無しさん [] 2016/01/10(日) 12:47:28.36 ID:LOFSek54(2/3) AAS
Vivaldiの起動が遅いのは
タブのサムネイルに関係しているかもしれない
Blinkは負荷分散のため？かHDDアクセスも遅いらしい
ローカルストレージ関係がとても遅いからだ
タブサムネイルを
ローカルストレージで保存するのは止めたほうがいい
タブサムネイルは直接アクセスする事
fopen();ランダム書込:fclose();ランダム読込:fopen();
読取だけならオーバーヘッドを避けるためfopen();しない
命題・・・Vivaldiは遅い起動を早期解消せよ！
ランダム書込用HDDスペースを作る 個数*固定サイズ
１トランザクション 個数1024個、固定サイズ256kバイト
そしたら、ランダム読み書きでfopen()すればいい
オーバーヘッドを避けるためfopen();は終了のときだけ
オーバーヘッド無いだけで1000倍ほど速くなるケースも
オーバーヘッドはドコにあるのか？
それはWindowsOSのフォルダ構造検索にある
フォルダ構造検索回数を省けば速くなるのだ
466: デフォルトの名無しさん [sage] 2016/04/17(日) 19:50:47.36 ID:1R/4ebGS(1) AAS
>メモリ管理系のバグが顕在化しにくいだけ
結局これだよね
本当に丸投げできるなら乗っかるのもいいと思う
性能問題はハードの進化で一部の用途を除けば問題無くなると思うし
でも現実は中途半端だから意識して書いたほうがマシだと
575: デフォルトの名無しさん [sage] 2016/08/22(月) 19:24:37.36 ID:csr3LedD(1) AAS
？
今の議論はプログラマーが何も考えないアホでもGC(言語)使ってれば問題無いのか
そうでなければ結局なんらかの管理が必要でちゃんとする事しないとリークするから本質的には管理から開放されないよねって話だと思うが
583: デフォルトの名無しさん [sage] 2016/08/24(水) 20:02:24.36 ID:971rg3P3(1) AAS
いつ無くなってしまうかわからんようなメモリのアクセスが簡単になってもほとんど使いみちないだろ。
安全性重視なら別プロセスにして、必要なデータだけ共有メモリで受け渡してのが妥当なところだろう。
620(1): デフォルトの名無しさん [sage] 2016/11/19(土) 10:16:22.36 ID:HaGDkE41(1/2) AAS
>>618アプリケーションエラーとか異常終了した時にバッファされてる内容が書かれないことがあるから
異常終了した時はまさにそのエラーになる直前のログが欲しいのに〜
ってなる w
ただログってそういうログばかりじゃないし Apache のアクセスログみたいにいちいち閉じてたら全然間に合わないって現実を知らない >>617617(1): デフォルトの名無しさん [sage] 2016/11/19(土) 06:41:14.49 ID:4ie0coBz(1) AAS
ログファイルはログが確実に記録されるのが使命であって性能は二の次なのだよ
よって開きっぱなしは論外
性能で問題が出るなら吐く量を調節すればいいだろう
はもう少し経験積むまで黙ってた方がいいと思う
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.036s