[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
32: デフォルトの名無しさん [sage] 2015/11/22(日) 22:36:02.07 ID:iT1tZCI1(1) AAS
またお前か
メンバに持つのが間違い
149(1): デフォルトの名無しさん [sage] 2015/12/03(木) 21:59:47.07 ID:/xqyH1ID(1) AAS
>>147知ってて言ってると思うが、定数を==の左辺にするのは
if (a=1) { ...
と書き間違うのを恐れているらしい
>>139free()から設計し直す、
まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ
>>135スレッド安全に書かない奴が悪いていうかそれは別の話
シングルスレッド状況（またはそれと等価な状況）では>>134の言っていることは全く正しい
283(1): 名無しさん＠そうだ選挙に行こう [] 2015/12/14(月) 17:59:33.07 ID:hn3965Zz(4/4) AAS
>>282282(1): 名無しさん＠そうだ選挙に行こう [sage] 2015/12/14(月) 17:06:58.52 ID:eBJzgHzn(3/4) AAS
Javaのプロジェクトだとほぼ使ってるけどな隠蔽してるだけで
そのせいで共有リソース壊したり、逆に個人情報の領域が共有されたりして、とんでもないインシデントが発生する
そんな奴等にメモリ管理なんて任せられんし、共有リソースも触らせたくないから
更に隠蔽したフレームワークもどきが出来上がる
勝手に使うな。勝手にトリッキーコードにすんな。
素直に、設計書通りに作れ。
勝手なことやって勝手に自爆してるだけじゃねーか。
312: デフォルトの名無しさん [sage] 2015/12/20(日) 14:42:20.07 ID:ofrSOHxv(5/7) AAS
解決策の一つはActive ObjectパターンでリソースCの管理を1スレッドXにやらせて
Cに対する要求を全部Xのキューにシリアル化して入れさせるというのがあるが、それはそれで
リソースCを使う全てのオブジェクトがスレッドXに依存するから、Xの開放コードが面倒なことになりかねない
かつ、シリアル化はマルチコア時代のせっかくの並列実行性能を殺してしまう
GCに合わせて生きることは、神仙にでもならねば到底かなわぬ…
406(2): デフォルトの名無しさん [sage] 2016/03/26(土) 18:52:26.07 ID:QL60ocAy(1/2) AAS
参照カウンタがオーバーフローしたらどうなんの？
415(1): デフォルトの名無しさん [sage] 2016/03/27(日) 00:26:17.07 ID:vj+h39OC(1/10) AAS
>>399399(1): デフォルトの名無しさん [sage] 2016/03/23(水) 21:43:30.89 ID:SoMbpeP6(2/2) AAS
この際、呼び名はどうでも良い
参照カウンタ方式以外のGCでは、どこからも参照されなくなったことが、即座にはわからない
だから、自動で即座に開放関数を呼び出すことが出来ない→RAIIが出来ない
C#で言うところのusingみたいに、プログラマが手動で情報を与えるなら出来る
だが、usingはGCでは無い
からの流れを見ればわかるがそういう話ではない
参照カウンタ方式以外のGCは、オブジェクトがどこからも参照されなくなったことが「即座」にわからない
だからRAIIが出来ない、そういう話
もちろん、参照の値が書き換わるたびに毎回マークスイープを実行すれば
即座にゴミが分かるがのでRAII出来るが、マークスイープは重いので参照が書き換わるたびに毎回実行できない
その意味で、循環参照以外のGCは重いと言っている
参照カウンタ方式は軽いので毎回実行できる
即座にゴミが分かるからRAIIが出来る
参照カウンタ方式で問題になるのは循環参照が起こった場合だが
循環参照が発生する箇所は設計段階で分かるので、実際には大した問題ではない
C++であれば、片方をweak_ptrにすればよいというだけの話
そこさえ気を付ければ、参照カウンタ方式とデストラクタの組み合わせは非常にうまく機能する
IDisposableのようなものも要らない
693: デフォルトの名無しさん [sage] 2017/09/23(土) 13:33:17.07 ID:J7EIO5I9(1/2) AAS
malloc()関数の内部はOSからメモリをまとめて取ってくる処理と、
すでに取ってきたメモリを（free()で空きが生じたとき）やりくりする処理の2本立て
前者の処理（システムコールの呼び出し）は比較的高コストなのでmalloc()の度に呼びはしない
また後者の処理は、連続したアドレス範囲のメモリを確保できている前提で動く
ページングはもっと下のレイヤーで行われるので、
malloc()のコード自体がMMUの有無やOSの違いを関知したりはしない
708(1): デフォルトの名無しさん [] 2020/02/26(水) 10:49:39.07 ID:wiEfavJ1(1) AAS
(destructor)()
dispose()
destroy()
close()
free()
delete
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.044s