[過去ログ] GCは失敗。メモリは自分で管理せよ! その2©2ch.net (720レス)
前次1-
抽出解除 レス栞

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
29: デフォルトの名無しさん [sage] 2015/11/22(日) 16:57:06.63 ID:vggKhYqJ(1/2) AAS
C++でもスマートポインタ使えば勝手に開放されるよ

所謂GC任せだと、いつ開放処理が走るか分らなくなるから
その事に対する新たな対策が必要になるよ
外部リンク[html]:ufcpp.net

手続き型言語は処理の順番が重要なのに
いつ実行されるか分からないってのは中々チャレンジャーだし大掛かりな話だね
94: デフォルトの名無しさん [sage] 2015/11/29(日) 16:05:07.63 ID:QSPcxrGF(1/2) AAS
>>90
90(1): デフォルトの名無しさん [sage] 2015/11/29(日) 14:29:40.51 ID:c+9MHjtm(1) AAS
マークスイープ型のGCが必要かどうかについて、もう少し建設的な会話をしようよ
リソースを自動で開放してくれる機能は、無いよりは有った方が絶対に良い、と言い切ってよいよね
ただ、その方式が話の焦点だと思う

C++のスマポの参照カウンタ方式はデストラクタとの相性が良いし、RAIIもよく機能するし
開放されるタイミングもはっきりしているのて、手続き型言語と相性が良いし、軽い
ただし、循環参照があるとリークする
解決策として、片方をweak_ptrにするという方法が用意されている
weak_ptrは対象オブジェクトが開放されると勝手にヌルポみたいになるのでいろいろと悪用ができる

一方でマークスイープ系のGCは、循環参照があってもリークしない
しかし参照カウンタ方式に比べてマークスイープ系のGCが優れている点は、それだけ
重いし、いつ開放処理が実行されるか分からないので
リソース開放のタイミングを明確に行いたい場合のための別の仕組みが必要になった

どちらを選ぶ?
つ世代別GC

immutableオブジェクトをバンバンnewしまくる関数型プログラミングに慣れてると
やっぱGCないとキツイわ
108
(1): デフォルトの名無しさん [sage] 2015/11/30(月) 09:12:24.63 ID:UQyKbzCH(1/7) AAS
>>107
107(1): デフォルトの名無しさん [sage] 2015/11/30(月) 08:34:00.92 ID:qSWjFIuy(1) AAS
>>100
リーク箇所がわかってればログ出力の必要なくね?
ホントに開発したことあるのかな?
普通C++のプロジェクトは専用のメモリ管理を用意するから
リークしたメモリはそれを確保したクラスとその行数まで特定できるようにしてるよ
アロケーターも分離しとけばアプリケーション終了させなくても
管理オブジェクトを破棄した時点でリークの判定できるし

リーク箇所特定するのに全ログから解析とか複合的なバグでもない限りしない
そんな状況許してる時点で負け
183
(1): デフォルトの名無しさん [sage] 2015/12/05(土) 15:39:23.63 ID:eGerJrSR(4/5) AAS
C++にfinallyが無いのが気に食わない
今はラムダが有るのでマクロでそれっぽいものを自作したが
標準で用意しておいてほしい
C++はリソースを自分で管理する傾向のある言語なのに
finallyが無いのは本来おかしいよな
ラッパー作ってRAIIを徹底しろってことなんだろうけど
すべてのリソースに対してラッパーを用意するのは面倒だよ
fainallyが有ったって邪魔になるわけでもないのに
最終的に使うかどうかは利用者が選べばよいことだし
C++ってそういう言語だろ
206
(1): ◆QZaw55cn4c [sage] 2015/12/06(日) 16:19:39.63 ID:4bjdt2kC(1) AAS
fclose() にも失敗があるじゃないか?
285: 名無しさん@そうだ選挙に行こう [sage] 2015/12/14(月) 18:28:13.63 ID:eBJzgHzn(4/4) AAS
>>283
283(1): 名無しさん@そうだ選挙に行こう [] 2015/12/14(月) 17:59:33.07 ID:hn3965Zz(4/4) AAS
>>282
勝手に使うな。勝手にトリッキーコードにすんな。
素直に、設計書通りに作れ。
勝手なことやって勝手に自爆してるだけじゃねーか。
理解してないのに無理してレスしなくていいから
374: デフォルトの名無しさん [sage] 2016/02/10(水) 11:41:46.63 ID:83b7Yxnh(1) AAS
Java(VM)は(すべてのプラットフォームで)強制的に解放させることもできるようにすべきだったな。
477: デフォルトの名無しさん [sage] 2016/04/18(月) 19:05:27.63 ID:OvHIqTOi(2/3) AAS
mallocの挙動がわかってれば、ある程度は・・・・
683: デフォルトの名無しさん [] 2017/09/17(日) 22:08:00.63 ID:S40DCpdn(17/20) AAS
メモリの増減には現在のサイズで対応し、このサイズが必要以上に大きくなると
使われてるサイズを拡張するようにした。リミットサイズは滅多に使わないけれども、
一応対応させた。
メモリに対する読み書きは専用関数を経由して読み書きするようにしたから、
素人が使っても安全なぐらいのプログラムになってる。
706: デフォルトの名無しさん [] 2020/02/22(土) 01:52:20.63 ID:eI8xgqVo(1) AAS
No GC派なんだけど、WebサーバーをC++とかで実装しても結局力持て余す感はあるよな
それだからかなり性能下げてもいいからちょっとでも早く作れるスクリプト言語採用されるってのもありそう
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.037s