GCは失敗。メモリは自分で管理せよ！ その2
以下GCと記す
プログラマをメモリ管理から開放する！
といいつつ、メモリリーク問題の文献が大量にある。
これすなわち、メモリリーク問題が全然解決していないということ。
さらに、メモリ解放のタイミングの文献まで大量に生み出した。
これすなわち、新たなるメモリ管理に関する問題を生み出したということ。
malloc、freeじゃないが
結局のところ、メモリを管理するという技術は、今しばらくは、身につける・教える・学ぶべきではないだろうか？
使って、そのまま放置しても、基本的にはGCがなんとかしてくれている。
ランジョブからジョブ終了までさほどの時間を要さない。メモリも大して使わないならいいだろう。
しかし、規模が大きくなり常駐ジョブやメモリ大量使用のジョブになってくると、そんなメモリ管理の方法でやっていると、
上記「文献」を生み出されてしまう。
入門時は、メモリに無頓着でもいいだろう。それよりも、目的を達成することが先決だ。
しかし、慣れてきたら、やはりメモリの管理まで余裕を持って自分で行うべきだろう。
前スレ
GCは失敗。メモリは自分で管理せよ！
http://peace.2ch.sc/test/read.cgi/tech/1412986420/
以上
そういう問題もコピーGCなら一気に解消できるしGCの方が耐久力があるよね
それGCのない言語の問題じゃなくてC/C++の問題だろ
コンパクションとGCはあくまで別だし
現代の歴史家は2人が失読症ではないかと疑っている。
https://twitter.com/okdshin/status/666903312151613440
他のアプリを使用しながらSleipnirを使う
メモリー不足でのメッセージは良心的
https://i.gyazo.com/57e93e426e7a2b5fe7ba4dcf19a432c8.png
問題点として、場合によってはメモリー不足で
メッセージされずに展開されなくなる
Sleipnirが不安定で信頼感を得られない要因
520 ：名無し~3.EXE：2015/11/19(木) 21:51:47.06 ID:CEKgHuEl
6で書き込み欄が展開されなくなった・・・再起動してカキコした
521 ：名無し~3.EXE：2015/11/19(木) 21:52:39.96 ID:CEKgHuEl
◆重要◆Sleipnirが不安定で信頼感を得られない要因
展開されない時
リロードで展開される場合もあるが
リロードで展開ない場合もある
規模がでかくなればなるほどリスクが大きくなる
確保量の大きい画像なんかを扱っているとどうしても手動で解放したいタイミングもあるし
それが理想的だけど、C#ってそんなことできたっけ？
出来るよ。
ポインタも使える
もしかしてアンマネージなメモリを確保してデータ領域に使う話？
無理に横文字使わなくていいですよｗｗｗ
結局、手動でデストラクタを呼ばなきゃならない。GCの利便性がほとんどなし。
涙ふけよｗｗｗｗ
自動ならメモリリーク等々発生するわけがないのに発生している
この原因はプログラマなんだけど、結局メモリ管理から解放されてないなら最初から管理する方針でいいじゃん
Cでリークはしてないけど本来開放すべきタイミングで開放してないでメモリいっぱいになるのは防ぎやすいと思うし
楽になってメモリリークがなくなるならいいけど、メモリリーク発生するわ
プログラマがメモリ管理なんてしなくて大丈夫、とメモリの扱いが雑になって意図しないタイミングで解放されたりされなかったり
最初から管理するという方針で教えないから、こんなことになる
管理漏れをGCがうまいことやってくれる。でもGCにやらせるようだと恥。
というくらいで教育すべき
GC=メモリ管理適当
という認識作ったから、GCに新しい名称つけて
教育や解説書では、メモリーの確保から解放まできちっと説明し直したほうがいい
GCはダメな子って認識は必要だな
GC前提言語だとその辺がごっそり抜け落ちて後で問題になる
結局どんなバグだったんだい？
所謂GC任せだと、いつ開放処理が走るか分らなくなるから
その事に対する新たな対策が必要になるよ
http://ufcpp.net/study/csharp/rm_disposable.html
手続き型言語は処理の順番が重要なのに
いつ実行されるか分からないってのは中々チャレンジャーだし大掛かりな話だね
IDisposableなオブジェクトをコンポジションしてメンバに持つと自身もIDisposableにしなければならない
だから自分がコンポジションしているオブジェクトがIDisposableかどうか一々調べなければならないし
IDisposableなオブジェクトがメンバにあれば、自身もIDisposableにしなければならない
さらに、その作ったクラスをコンポジションして使うクラスもIDisposableにする必要があり・・・
という風にIDisposableはクラスで閉じずコンポジションで伝染する
というか、むしろ手動で伝染させなければならないという
しかもIDisposableの一連のイディオムはとても長くて煩雑
http://ufcpp.net/study/csharp/rm_disposable.html
こういうものを書いて、マネッジドリソースとアンマネッジドリソースで場合わけをしつつ
IDisposableなオブジェクトに関しては
手動で自分のメンバのDisposeを漏れなく呼び出すコードを書かなければならない
当たり前だが、どのメンバがIDisposableか完全に把握しておく必要が有る
手動で自分のメンバのDisposeを呼び出す作業は、まるでCのmallocを思い起こさせる
問題点は明確で、DisposeがC++のデストラクタのように芋づる式に勝手に呼ばれない事に有る
だから手動で芋づる式に呼び出すコードを書かなくてはならない
ファイナライザーの処理がひどいことになると思うけど
メンバに持つのが間違い
でも、ソースに解放処理が書いてあれば、後から見たらあぁここで用済みになったのかとわかる。
可読性は非常に重要よ。
挙動が変わることがある
リアルタイム性が要求されるシステムでこれで困ったことがある（そもそもそんな言語使うなって話だが）
それはあまりない
挙動が変わるというか停止するというのならあるのかもしれないが
なんでそんなことになったの？
参照切ってなきゃGCの対象にならないはず
だから実行前にGC手動で走らせて、できるだけ空きメモリ増やしたりとかする。
できるだけ開放したいのに過負荷でまだメモリに余裕あるからGC走らないってのが困る。
下手なやつにはプログラムを組ませないってのが鉄則だと思うの
複数のオブジェクトが所有権を持ちあう必要性に迫られる事がないんだけど
weak_ptrの対応だけあれば良くない？
まーshared_ptrが有れば、いつ実行されるか分からないような、手の込んだGCは要らないよな
巡回参照が有る場合はどちらかをweak_ptrにする、これだけを守ってれば問題は起きない
大体の場合は所有権というか上下関係がはっきりしているからな
巡回参照のある場合も自動で開放したいという、たったこれだけのために
いつ実行されるか分からない上に重いマークスイープ式GCを導入するのは
業界全体の早とちりだったようだね
std::make_shared<int>() って書くよね
始めからshread_ptrで受け取るから、循環参照だけ気をつければ
リークする余地がないよね
RAIIも健在で、C#みたいにIDisposableとか要らない
デストラクタも芋づる式に呼び出されるから
>>30で書いたような問題も起きないよ
糞便利な参照カウンタを使わないなんてＣ＋＋使う意味なし
それはManagerやHolder的なものを書かなくて良いってことを言ってるの？
それって大体一時しのぎで大抵後々リソース管理以外にもそういった管理クラスが必要になるケースがほとんどじゃない？
>>45
ねーよ
例えば2chのある板を管理するプログラムを書くとして
BoardクラスとThreadクラスを想像してみてくれ
BoardはThreadオブジェクトを管理するが、Threadは
産まれたり死んだりと揮発的で寿命が定まらないと。
で各Threadは何らかの共有リソースを持つと。
例えば一度読み込んだ画像を各スレッドで共有したいとかが
考えられるけど、画像オブジェクトをshared_ptrで共有するのは
適切ではない
なぜならある瞬間に産まれたThread群がひとつの画像を共有する
からといってshared_ptrで持たせたとしても、後の更新時に
更にその画像を共有したいThreadが現れたときに、画像が
すでにあることを何らかの形で知れないといけないから。
結局Boardなんかが画像オブジェクトのコンテナを持つ必要が
あってそのコンテナへの追加と削除のために別の共有の
仕組みが必要になるんだよ。例えばThreadがBoardに画像を
リクエストして参照カウンタを持ったアクセサを返すようなもの
だから所有権はBoardひとりが持てばよくてshared_ptrを
使う必要がなくなるという理屈
こういったケースを踏まえてもshared_ptr使うケースって
ほとんどなくね
マルチスレッドプログラム書いてみろよ
shared_ptrがないと泣くぞ
いやいくらでも書いてるけど基本一緒
というか上の例もそのままマルチスレッドに適用できる話でしょ
例えばproducer consumerならproducerが所有権を持つし
thread per messageなら共有データはホストが持って固有データは
個別スレッドで持つだけ
むしろマルチスレッドの場合、所有者をより厳格に決めとかないと
泣く事になるぞ
unique_ptrを使うと勝手に所有権が移動してしまうし
生のポインタを使うんならわかるけど
上下関係さえしっかりしていれば良い
>>50の人はどう考えてるのか
今のC++からshared_ptrをそのまま無くせって言ってるんじゃないぞ
shared_ptrのコピーを禁止にしてweak_ptrの対応だけあれば良くないかって事
そもそも何でそんなこと言うかっていうと、
GCない言語→循環参照ガー。みたいによく言われるけど使わないで
済むなら静的解析で循環参照の起こり得るケースをエラーにしてしまう
って解決方法もあるかなと思っただけ
あとshared_ptrとweak_ptrはアトミック操作とメモリバリアを必要としうるから
それに頼った設計は疑問を感じる
設計するとした場合の話ね
C++だとほぼ不可能だろうから
ヘジはなにやってんだか。
中小企業を奴隷にさせる事を第一に考えたツールしかリリースしてないよ
失敗ではなく全部わざと。
Formはnull入れてあげないといけないんだっけ？
なんか、場合場合によってnull入れてあげないといけなかったり入れなくてもよかったり。
ならnull入れるで統一でいいじゃんと思った
A = new A()
Loop Begin
処理
A = null
A = new A()
Loop End
とか、nullをセットをGCって見張ってるの？又はGCに伝えているとかあるの？
newが動いた時点で中の人がメモリが足りない！って騒いで初めてGCさんお願いします！GC「やれやれ・・・
っていう仕組みなんで
>>62の例のnullの代入は無駄
代入演算子の順序の関係でnewの後に代入が起こるから
Aを事前にnullすることでGCさんが回収できるオブジェクトが1個増える
つまり、使い終わったら、スグにnullっておいたほうがいいってことか。
・・・とも言い切れないな。
でも、ここで使い終わったってわかるから、書いたほうがいいか。
よし。決めた。全部書こう。
コードが冗長になって保守性が落ちる。
メモリ食いのオブジェクトなど、クリティカルな部分でのみ使うべき
スマートポインタ使えば済む話だしなぁ
weak_ptrもあるし
意味はあるじゃん
ここでおしまい！って書いてあるだけ。
こんなんで冗長とは評価されない。むしろ読みやすい。と判断した。
それともローカル変数とか無い言語を想定してるのか
どうせ最適化で削除される
で伝わらない人にはどんなコメント書いても伝わらないと思うんだ。
いくら大きくても大概スコープだけで
どうにでもなる。
javascriptみたいなのはlambdaでスコープ切ればいい。
同じ結論ですわ。
null代入ってやっぱり特殊だから、コメントよりはるかに目が行く。
ここで使い終わったYO!！（逆に言えば、ここまでは意識してね。使ってるから。）ってわかってもらえれば良い。
長い関数中にそれ出てきたら変数を使い回す前に初期化したいのかな？とかも考えるな
短い関数なら変数を使い終わったとか重要な情報じゃないから無駄な行入れて可読性下げてるだけ
そうじゃないとしたら、なんでもかんでもnull代入が必要なんてのは幻想だよ。
コンストラクタで例外投げたとき
そこまでに初期化したメンバ変数のデストラクタを呼ぶため
みたいなのは聞いたことあるけどそれくらいのもん？
別にコンストラクタじゃなくて関数内で確保した場合でも、
例外じゃなくreturnで戻った時も勝手に解放してくれたほうが
有り難いし、そもそも解放処理って忘れやすいものだろ
傘を置き忘れたり洗濯物を洗濯機に入れっぱなしにしたことの
ないものだけスマートポインタに石を投げなさい
どうしても明示したければスコープで区切った方がまし
それでもインデントが深くなるのであれだけど
勝手にnull代入すると表現するから気持ち悪く感じるだけで、コンパイラが各変数についてもうアクセスされる可能性の無い基本ブロックに到達したら、その変数をGCのマークの起点として使用しないようにフラグを管理すると言えば当たり前の話じゃね。
フラグの持ち方として変数にnullを代入しているだけで。
> そもそも解放処理って忘れやすいものだろ
それを忘れるなどとんでもない
確保＆開放なんてプログラミングの花じゃん
キモじゃん
そこを工夫するのが楽しいんじゃん
設計も楽しいし
チマチマテストすんのも楽しい
温泉行って湯につかり忘れる心配はない
まあ勉強目的でやるならいいんじゃね
俺は元々ゲームプログラマだったからもう嫌になるほどやったし
メモリ周り工夫するなら言語設計からしたいわ
リソースを自動で開放してくれる機能は、無いよりは有った方が絶対に良い、と言い切ってよいよね
ただ、その方式が話の焦点だと思う
C++のスマポの参照カウンタ方式はデストラクタとの相性が良いし、RAIIもよく機能するし
開放されるタイミングもはっきりしているのて、手続き型言語と相性が良いし、軽い
ただし、循環参照があるとリークする
解決策として、片方をweak_ptrにするという方法が用意されている
weak_ptrは対象オブジェクトが開放されると勝手にヌルポみたいになるのでいろいろと悪用ができる
一方でマークスイープ系のGCは、循環参照があってもリークしない
しかし参照カウンタ方式に比べてマークスイープ系のGCが優れている点は、それだけ
重いし、いつ開放処理が実行されるか分からないので
リソース開放のタイミングを明確に行いたい場合のための別の仕組みが必要になった
どちらを選ぶ？
http://peace.2ch.sc/test/read.cgi/tech/1447856699/l50
大して難しい部類のバグではないんだよなぁ
GCの優位性をアピールするために過剰に恐怖心を煽ってる気がする
その程度の案件しか受けてないからだろう。
つ世代別GC
immutableオブジェクトをバンバンnewしまくる関数型プログラミングに慣れてると
やっぱGCないとキツイわ
いやいや普通難しいとされるバグってメモリ破壊とか同期周りだから
メモリリークなんてデバッガがチェックして丁寧なダンプ出してくれるし
組み込みとかの貧弱な環境なら専用のメモリ管理を用意して
いくらでも好きなチェックや情報出せるから
それな
メモリの確保と開放の対応すら管理できない奴は
なんかもう何をどうしたってダメな気がする
初歩の初歩の初歩の話題を何度も何度も何度も繰り返しすぎ
ゴミクズ。
メモリの解放が必要ならそれは必要な機能の実装ってことになる。
それを忘れるってことはプログラムを組んでいて必要な機能の実装を忘れるってことだ。
必要な機能の実装を忘れるということは、例えば通販サイトのシステム開発請け負っておきながら、決済システムを実装し忘れるのと同等。
ありえない。
プログラム云々以前に頭の問題だろう。
必要な機能の実装を忘れる可能性におびえる池沼プログラマ。
最近流行りのADHD？なんじゃねえの。
なるほど。経験の少なさがすぐ分るな。ログ出したらで数十ギガなんてよくあるよ。
ログから問題点をスクリプトで抽出するにも何時間とかかるとかいろいろ。
マルチスレッド絡んで特定のパターンだけだったりして再現性がなかったりする。
他システムの連携だと手が出せない部分の挙動がおかしい可能性もある。結局、oracleのバグだったとかね。
決済システムとメモリ解放は違うよ。
通販サイトのシステムをC言語で実装してみればわかるかと。
はあ？なんでリーク箇所ダンプするだけの話でログ全部吐き出すことになってんの
普通確保する際にヘッダにそのブロックの確保場所埋め込んでるし
アロケータで生存期間のスコープを切り分けといてすぐ分かるようにするけど？
お前の関わったプロジェクトが糞なだけじゃね？
100〜のスレッドの続きを読む
