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