[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
72: デフォルトの名無しさん [] 2015/11/28(土) 17:52:47.31 ID:CKvy7+My(3/4) AAS
>>68ここでおしまい！って書いてあるだけ。
こんなんで冗長とは評価されない。むしろ読みやすい。と判断した。
73: デフォルトの名無しさん [sage] 2015/11/28(土) 18:23:41.31 ID:ekTV2Qou(1/3) AAS
変数がどこで不要になるか明示しなきゃならんほど長い関数ばっかり書いてるのか
それともローカル変数とか無い言語を想定してるのか
209: デフォルトの名無しさん [sage] 2015/12/06(日) 17:35:51.31 ID:G3VNQyn5(2/3) AAS
c++信者ってアホだなー
みんなこんなんなの？
外部ﾘﾝｸ[html]:cpplover.blogspot.jp
239: デフォルトの名無しさん [sage] 2015/12/07(月) 23:25:36.31 ID:QznWTKRS(2/2) AAS
>>230230(1): デフォルトの名無しさん [] 2015/12/07(月) 17:29:26.60 ID:nEG5/lEo(2/4) AAS
>>229
処理速度やタイミングがシビアな組み込みや科学技術計算系とかならいざしらず、
ソレ以外は、実際の解放のタイミング自体は問題にならんでしょ。(膨大なメモリの使用も別だけど)
問題は、使い終わったよーって明示しないで良い。という運用が結局、悪い結果をもたらしているという点。
メモリの管理をしっかり最後までやるクセのないプログラマは、
平然と参照が途切れている可能性のあるポイントで参照しに行こうとする。
結局は、そいつがバカだからに集約されてしまうんだけど、使い終わりの明示をしない文化がバカを生む土壌となっている
JavaのGCでサーバー応答が止まるなんてザラにある話だよ
それを聞いたことがないなら文系SEと同レベルだね
>>238238(1): デフォルトの名無しさん [sage] 2015/12/07(月) 20:42:25.43 ID:wP/KA6jo(1) AAS
JavaやC#ではリソースをプログラマが管理してはいけない
せっかくメモリ管理を透過的にしたのにリソース管理でコードをより複雑化させては意味がない
真っ当な教育を受けた少数のプログラマがSafeHandleを作成する
末端のプログラマはSafeHandleのファイナライザに全てを任せてメモリと同様にリソースを完全に透過的に扱うべきだ
管理放棄して開くだけ開いて計算資源を食い潰す玄人気取りプログラマ
253(1): デフォルトの名無しさん [sage] 2015/12/08(火) 19:22:21.31 ID:RKxPG6yJ(1/3) AAS
Rustはどう？
明文化されたmoveセマンティクスと、オブジェクトの寿命と参照のチェッカを型システムに組み込んでるおかげで、
リソース管理の実行時コストをゼロにしつつ、メモリリークが発生しないプログラムが書ける。
shared_ptrに相当するRcもあるから、所有者を複数にしたい場合のコストもそれなりに抑えられる。
372: デフォルトの名無しさん [sage] 2016/01/30(土) 01:11:50.31 ID:QZN0GaAw(1) AAS
そら伝えたかったらやりようはいくらでもあるでしょう？C++に限らず
427: デフォルトの名無しさん [sage] 2016/03/27(日) 11:16:32.31 ID:MdJCnp0Y(4/6) AAS
>>426銀の弾丸は無い
あらゆるリソースのあらゆる利用形態に対してデフォルトの動作を定義できるなら話は別だが無理だよね
結局は人が方針を決めて書くしか無い
幸いにしてメインメモリにはRAIIやマークスイープという正解が見つかっているのでそれを使えばいい
だが他のリソースはダメだ
484: デフォルトの名無しさん [sage] 2016/04/18(月) 21:15:59.31 ID:3yZKjOEp(2/3) AAS
まぁテトリスとかならその程度の理解でいいんじゃない？w
511: デフォルトの名無しさん [sage] 2016/04/22(金) 23:54:45.31 ID:imh5rD9T(2/2) AAS
>>510510(1): デフォルトの名無しさん [sage] 2016/04/22(金) 20:32:21.23 ID:1FeuO5Gj(1) AAS
結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない
しかし論理アドレスの方は何にもしてくれないのでフラグメンテーション起こして
連続したアドレスが確保出来なくなると、それで終わり、どうしようもない
32bitプロセスだと4GBしか空間がないから、まれに問題になる
64bitプロセスだと無尽蔵に空間があるから問題になることは現状ありえない
> 結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない
MMUってのはアドレス変換するハードウェア
勝手に物理メモリを仮想メモリにマップしたりはしない
それをやるのはOS
624: デフォルトの名無しさん [sage] 2016/11/19(土) 15:37:17.31 ID:O7mQP4/b(1) AAS
スコープの話してるのに flush とか頭わいてるだろ
676: デフォルトの名無しさん [] 2017/09/17(日) 17:05:23.31 ID:S40DCpdn(12/20) AAS
malloc,newの挙動の説明ってまんまMMUの説明なんだよな
だから複雑なアルゴリズムを使われていると思うのはMMUが複雑な挙動をしているから
でも、そんなに複雑な挙動してるか？？
単に過去のアプリとの互換性の問題で変な事をしているだけだぞ
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.041s