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