[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
61: デフォルトの名無しさん [sage] 2015/11/27(金) 22:35:05.80 ID:CyIO1ZuX(1) AAS
Rust使えば解決
96: デフォルトの名無しさん [sage] 2015/11/29(日) 16:17:37.80 ID:AV0cYAnH(1) AAS
>>9292(2): デフォルトの名無しさん [sage] 2015/11/29(日) 15:57:55.75 ID:Co3W2iFa(2/5) AAS
そもそもc++においてメモリリークって対策も発見も
大して難しい部類のバグではないんだよなぁ
GCの優位性をアピールするために過剰に恐怖心を煽ってる気がする
それな
メモリの確保と開放の対応すら管理できない奴は
なんかもう何をどうしたってダメな気がする
初歩の初歩の初歩の話題を何度も何度も何度も繰り返しすぎ
98(1): デフォルトの名無しさん [sage] 2015/11/29(日) 16:24:33.80 ID:sCmmZzWu(2/3) AAS
>>9595(1): デフォルトの名無しさん [sage] 2015/11/29(日) 16:15:05.64 ID:Co3W2iFa(3/5) AAS
>>93
いやいや普通難しいとされるバグってメモリ破壊とか同期周りだから
メモリリークなんてデバッガがチェックして丁寧なダンプ出してくれるし
組み込みとかの貧弱な環境なら専用のメモリ管理を用意して
いくらでも好きなチェックや情報出せるから
なるほど。経験の少なさがすぐ分るな。ログ出したらで数十ギガなんてよくあるよ。
ログから問題点をスクリプトで抽出するにも何時間とかかるとかいろいろ。
マルチスレッド絡んで特定のパターンだけだったりして再現性がなかったりする。
他システムの連携だと手が出せない部分の挙動がおかしい可能性もある。結局、oracleのバグだったとかね。
171: デフォルトの名無しさん [sage] 2015/12/05(土) 14:36:53.80 ID:NRX1k+Is(2/6) AAS
shareed_ptrはC++で比較的効率よくやれることと、GCしたい人が真にやりたいことの妥協の産物であって
どんなシチュでもベストにフィットするような一押しの決定版ってほどでも無い…
参照カウンタの排他が不要で循環参照が無いことも保証できるまで設計が詰められているなら
スレッドごとに、メモリを確保して使って返す処理を直に書くのが一番良い
193: デフォルトの名無しさん [sage] 2015/12/05(土) 19:38:41.80 ID:eGerJrSR(5/5) AAS
>>191throwせずにreturnするパスが有ったらどうするんだよ
そういうのを防ぐためのfinallyやRAIIなのに
まったくちんぷんかんぷん
結局returnする前に手動で忘れないようにthrowすることを強制するんなら
goto文とか開放用ラムダ呼び出すのとかと替わらないだろ
251(1): デフォルトの名無しさん [sage] 2015/12/08(火) 16:37:24.80 ID:zjJIjn6V(2/2) AAS
>>250自分のクラスがファイルなんかのcloseを持つリソースをメンバに持っていたとする
そうすると、それらのメンバのリソースを明示的にcloseできるようにするために
自身もcloseを実装することになるだろう
それで、自身のcloseが呼ばれた時、勝手にメンバのcloseが呼ばれるか？
結局手動でメンバのcloseを呼び出しまわるコードを書かなければならない
C++のデストラクタならメンバのデストラクタが芋づる式に勝手に呼び出されるから
気にしなくて良い
289: デフォルトの名無しさん [sage] 2015/12/14(月) 21:54:10.80 ID:ETDpPCfc(2/2) AAS
動的型言語
↑
これ
コード書いている人間の注意力次第でtypoするだけで
実行するまでわからないバグが入るなら
言語も設計も間違ってるよ
363: デフォルトの名無しさん [sage] 2016/01/27(水) 17:10:09.80 ID:eULyfEEH(1/3) AAS
GCのすべてを否定するつもりはないけど・・・
GCはメモリ管理を自動化する技術だけど、今のコンピュータはメインメモリを何十ギガ積んでたりするのも普通で
メインメモリが足りなくなることはほぼ無くて、しかも仮想メモリもあるから、なおさらメモリは潤沢で・・・
むしろメインメモリ以外のリソースの方が余程貴重で、もし仮にメインメモリが足りなくなるまで
GCを発動しないアホなGCが有ったとしたらメインメモリより先に他のリソースが枯渇する状況
だからメインメモリは無駄遣いしてもよいけど、他のリソースは使い終わったら
こまめに開放しないとダメだから、いつ実行されるか分からないマークスイープ系GCの余計にRAIIな仕組みも必要なわけ
しかしこのRAIIが付け焼刃でなまっちょろい出来だったりする
C#で言えばDisposeが有るけど、C++のデストラクタのように特別扱いされておらず
ただの普通の関数でしかないので、C++のデストラクタみたいに自身のメンバ変数について
自動で芋づる式に呼び出してくれない
だから手動でメンバのDisposeを芋づる式に呼び出すコードを記述しなければならない
いちいち自身のメンバ変数にIDisposableなものが有るか無いか調べるのもひと手間かかるし
もしそうだったら自身もIDisposableにする必要があり、例の一連のイディオムを書かなければならない
当たり前にDisposeの呼び出し忘れが有ってもいけない
まるで、mallocしたらfreeするのと似ている
しかもIDisposableはコンポジションで増殖する
IDisposableなオブジェクトをコンポジションしたら、自身もIDisposableといった具合
C#のようにコンパイラマジックでなんでも実現する言語で
どうしてDisposeをC++のデストラクタみたいに特別扱いしなかったのか謎だ
424(2): デフォルトの名無しさん [sage] 2016/03/27(日) 10:01:03.80 ID:MdJCnp0Y(3/6) AAS
メモリとその他のリソースを混同して考えるからダメ
まずその他のリソースは不可視のコードで解放しちゃダメ
リソースのスコープは明示的でなければならない
これはデストラクタにもGCにも任せられない
逆にメモリは不可視のコードで解放してもよい
まずこの基本原則から話を進めよう
542: デフォルトの名無しさん [sage] 2016/04/24(日) 20:22:44.80 ID:fcfJojCV(1) AAS
誰と戦っているんだろう…
694: デフォルトの名無しさん [sage] 2017/09/23(土) 13:35:30.80 ID:J7EIO5I9(2/2) AAS
例外的な変態実装は知らんが、まあ普通は
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.036s