[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
71: デフォルトの名無しさん [sage] 2015/11/28(土) 15:20:08.61 ID:vL/aYykM(1) AAS
>>68意味はあるじゃん
159(1): デフォルトの名無しさん [] 2015/12/05(土) 08:28:25.61 ID:Pfi54LUx(1/2) AAS
>>158158(3): デフォルトの名無しさん [sage] 2015/12/05(土) 04:01:37.91 ID:2vAbbe+i(1/2) AAS
>>154
入門書に書いてるコードしか見たことないんだね。
スレッドプールみたいなテクニックは高速化のためにみな普通に使うんだよ。
OSやライブラリにもメモリリークなんてよくあることだし、それらのバグも開放忘れて起きてるイージーなバグじゃないよ。
他のバグやトラブルがメモリリークという形で表面化してるにすぎない。
具体的にいつのどのバージョンのライブラリで起きてるの？
使い終わったらメモリを開放しろ。使い終わってないなら開放する必要はない。これとスレッドプールとどこに関連性があるの？
218(1): デフォルトの名無しさん [sage] 2015/12/06(日) 20:58:14.61 ID:wxELMJDc(2/2) AAS
>>217217(2): デフォルトの名無しさん [sage] 2015/12/06(日) 20:22:00.43 ID:RyqEmv/A(2/3) AAS
まあ実際Java屋とかってコンパイラやメモリ意識できない奴多いよね
以前2chで↓みたいなコードが勝手に最適化されると思って
StringBuilder使う奴は馬鹿！とか言い出す奴いて目眩したわ
String s;
for(int i = 0; i < strarray.length; ++i){ s += strarray[i]; }
それはStringの+=の実装次第ではあんまり差が付かないケースなんじゃ…
（左辺と右辺が別の実体である（アドレスが違う）ケースでは多分右辺を左辺の末尾に1回コピーするだけという実装が有り得る
真に糞なのは
StringBuilder sb;
String s = "Hello";
sb.Append("[" + s + "]");
が遅いからStringBuilderは糞、と結論付けるニンゲンであってコードではない、
みたいな？
340: デフォルトの名無しさん [sage] 2015/12/21(月) 06:43:24.61 ID:ejqZ3DMD(12/26) AAS
LG OLED TV - The Ultimate Display
外部ﾘﾝｸ:aurorawave.atspace.tv 画像ﾘﾝｸ
#AuroraWaveTV
353: デフォルトの名無しさん [sage] 2015/12/21(月) 16:33:49.61 ID:ejqZ3DMD(22/26) AAS
外部ﾘﾝｸ[html]:www.dospara.co.jp
画像ﾘﾝｸ
476: デフォルトの名無しさん [sage] 2016/04/18(月) 18:51:08.61 ID:RPQ9NKJO(1/2) AAS
メモリのフラグメンテーションをC/C++でコントロールする方法ってあるの？
mallocの実装頼りじゃなく。
488(1): デフォルトの名無しさん [sage] 2016/04/18(月) 22:12:01.61 ID:3yZKjOEp(3/3) AAS
ゲームプログラムとかならメモリ確保は直接システムコール呼び出して
ページ単位でアロケートするのが定石
必要ならmspaceとかインスタンスベースのヒープを自分で作る
501: デフォルトの名無しさん [sage] 2016/04/21(木) 16:37:13.61 ID:lEi5GQja(2/2) AAS
各ゲーム機の事情は知らないが
PCで有れば、64bitプロセスは、論理アドレスの空間が256TB(48bit)もある
ゲーム機も似たようなものだろう
256TBもの物理メモリを積んだPCやゲーム機は存在していないし
例え論理アドレスが激しくラグメンテーションを起こしても
256TBもの論理アドレス空間を使い切るという事態は考えなくてよい
つまり、64bitプロセスなら、論理アドレスの心配はしなくてよい
一方で、物理アドレスのフラグメンテーションはMMUに任せておけばよい
これはハードウェアで自動で行われるし、とても高速
その余計にソフトウェア的アプローチで頑張ってみたところで
多少物理メモリのフラグメンテーションは改善されるかもしれないが
徒労というかなんというか、労力に見合わないし
しかも遅くなるのでゲームには向いていないし、やらなくてよい
物理アドレスは自分だけが使っているわけではなく、OSを含めたほかのプロセスも使っているので
自分のプロセスが使っている物理メモリだけフラグメンテーションを解消しようと
コンパクションするのも何か完璧感が無いし
自分のプロセス内だけで考えても、外部ライブラリやXBoxならDirectXが使用している物理メモリの
フラグメンテーションは手が出せないので解消しようがない、やはりやるだけ徒労
自分の管理出来る部分だけ物理メモリのコンパクションをかけても
「これで計算上、必ずあと200MBの物理メモリを使用できる筈」とかといった保証はどこにもない
理由は、外部のライブラリ内での物理メモリの使用状況が分からないし、手が出せないから
とにかく徒労であり、MMUに任せておけばよい
698: デフォルトの名無しさん [] 2018/07/05(木) 00:30:07.61 ID:RfoszcD2(1) AAS
IZ6
705: デフォルトの名無しさん [sage] 2020/02/13(木) 15:29:41.61 ID:z5cRWLgY(1) AAS
GCがある言語でも、shallow copy と deep copy のどちらにすべきかの判断が難しくて、結局、間違えてバグの原因になる可能性がかなり残る。
また、C/C++ポインタのミスを危険視する人がいるが、多くの場合はプログラム開発時にテストをすれば間違いが発見できる。
C/C++でのバッファオーバーランを気にする人がいるが、逆にGCがある言語でも、間違って1つ右隣の要素にしてしまったり、処理する個数を1つ間違ったりするミスは有り得て、その場合、厳密な意味でのバッファオーバーランは無くても処理内容自体はバグる。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.043s