[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
124(1): デフォルトの名無しさん [sage] 2015/11/30(月) 21:47:43.54 ID:UQyKbzCH(7/7) AAS
>>122馬鹿相手にしても時間の無駄だぞ
こいつ具体的なこと何も言わんし
132: Office & Gamers @ 試験運用中（トリなしｗ [アハ♪” uh huh] 2015/12/01(火) 04:32:07.54 ID:79aHC4wo(1) AAS
口 先 人 間 展 覧 会 。（ｱﾊ
152: デフォルトの名無しさん [] 2015/12/04(金) 04:37:18.54 ID:HtuddwW0(1) AAS
【 オンラインTCGエディター 】 >>11(3): デフォルトの名無しさん 転載ダメ©2ch.net [sageteoff] 2015/11/18(水) 23:24:59.79 ID:BUQ68wTG(1) AAS
GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。
以下GCと記す
プログラマをメモリ管理から開放する！
といいつつ、メモリリーク問題の文献が大量にある。
これすなわち、メモリリーク問題が全然解決していないということ。
さらに、メモリ解放のタイミングの文献まで大量に生み出した。
これすなわち、新たなるメモリ管理に関する問題を生み出したということ。
malloc、freeじゃないが
結局のところ、メモリを管理するという技術は、今しばらくは、身につける・教える・学ぶべきではないだろうか？
使って、そのまま放置しても、基本的にはGCがなんとかしてくれている。
ランジョブからジョブ終了までさほどの時間を要さない。メモリも大して使わないならいいだろう。
しかし、規模が大きくなり常駐ジョブやメモリ大量使用のジョブになってくると、そんなメモリ管理の方法でやっていると、
上記「文献」を生み出されてしまう。
入門時は、メモリに無頓着でもいいだろう。それよりも、目的を達成することが先決だ。
しかし、慣れてきたら、やはりメモリの管理まで余裕を持って自分で行うべきだろう。
前スレ
GCは失敗。メモリは自分で管理せよ！
2chｽﾚ:tech
デュエル・マスターズ的な非電源TCGの 《 オンライン化ツクール系ソフト 》 制作の企画。
例えば、ガチンコ・ジャッジを直ぐにでも導入できる機能を持っておりながら、
当面それを扱わず単純化させておいて、事後的に導入拡張する際に当該システムを
ブロック構造の組み合わせで後付け挿入できるように予めシステム化してあるソフト（エディター）。
既存の非電源TCGを劣らずに再現できるならば大概のニーズに応えられる筈。
バトスピ、ヴァンガ、ウィクロス、ポケカ、デジモン、ゼクス、モンコレ、ガンダム・ウォー、ライブオン、ディメンション・ゼロ、カードヒーロー、シャーマン・キングなど
のシステムを完全再現できるように設計するけど、他に此のTCGの此のシステムは再現希望とか有ったら書いて。
マジック：ザ・ギャザリングの全システムを完全に再現するのは無理だから、此れだけは必用だ！って部分のみリクエストして。
WEB通信での対戦は、個vs個、多数乱戦、チームvsチーム、個vsチームを可能な仕様とする方針。
設計思想は 《 RPGツクール 》 が良いかな？ 他に、優れたエディター有ったら挙げてみて。
個人や企業などのベンダーが提示する開発費（見積もり）で折り合えば、発注する。
↓
エディター群から基本コンセプトを絞り込む（もちろんオリジナルで優れた新ネタが有れば導入する）。
↓
遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。
なるべく前述３つで可能な再現は全て実装させる方向を目指す。 まぁ努力する・・・
バトスピ、ヴァンガ、バディ、デュエマなど発売済みゲームソフトが存在してるケースはベンダーに研究させる。
↓
各社TCGを再現するテストプレイ ⇒ 更に改良や修正。
↓
機能制限した下位版を５万円以上で発売 ＋ デュエリ−グ用に改造した上位版でサーバー稼動＝営業開始。
↑
下位版の改造および商用利用には、別途で当社との契約が必要。
さ〜て、製作ベンダー見つけよっと！ｗｗ（ｸｽ
2chｽﾚ:entrance2
364: デフォルトの名無しさん [sage] 2016/01/27(水) 17:24:38.54 ID:eULyfEEH(2/3) AAS
謎だといったが、理由ははっきりしていて
メンバのDisposableを自動で呼び出す為には
他で使われてないことを保証する必要があって
参照カウンタ方式のようにローコストなものなら簡単に分かるが
これでは循環参照の問題が出る
プログラマが循環参照を気にしなくてもよいことが前提の
マークスイープ系のGCを搭載した言語では設計思想が破たんするので
参照カウンタ方式は採用できないし
マークスイープ系GCでは何処からも参照されていないことがローコストに分からないので
自動でDisposeを呼び出す仕組みを用意できない
どうにもならない
結局C++の方式が一番優れている
循環参照が発生する場合はweak_ptrを使う事だけ注意を払えば
GCにまつわる他の問題が一切発生しない
428(1): デフォルトの名無しさん [sage] 2016/03/27(日) 16:21:42.54 ID:vj+h39OC(6/10) AAS
>>423423(1): デフォルトの名無しさん [sage] 2016/03/27(日) 07:41:27.84 ID:kBj57j3O(2/3) AAS
>>420
>それはGC関係ないRAIIの話だろ
メモリはGCで回収されると書いたが？あと、そもそもRAII自体がGCと直接関係ないとも書いた。
>usingも、ローカル変数も、deleteも、何れもGCじゃない
いずれもメモリ領域はGCで回収される。
>どんな場合でも、GCで有ろうが無かろうが、手動でデストラクタなりファイナライザなり呼び出せば
>RAII出来るに決まっているだろ、それに何の意味が有るんだよ
ローカルスコープに置いたオブジェクトは手動で呼ぶ必要はない。
gcnewで作成したものにはdeleteを使うってのは普通のC++と同じだ。
ローカルスコープの変数を基点に、スコープを抜けたときに連鎖的にデストラクタが呼ばれて
delete等の後始末がされるってのがRAIIだからな。
普通のC++ではそのdeleteのときにoperator deleteでメモリ領域が解放されるが、C++/CLIでは
GCで回収されるというだけ。
「GCで有ろうが無かろうが」「RAII出来るに決まっている」ということを理解したならまぁそれでいい。
できないってのを否定しただけで、別に意味があるかないかを話していたわけじゃないからな。
要は、GCを使う多くの言語でRAIIができないのはデストラクタの仕組みを持っていないからであって、
それがあるC++/CLIならRAIIも可能ということ。逆にGCを使わない言語でも、デストラクタがなければ
RAIIは不可能。
つまり最初の結論、RAIIとGCの有無に直接の関係はない。
そんな基本的なことを言って何がしたいの？
RAIIとGCは密接な関係が有るんだよ
君はローカル変数が好きみたいだから、ローカル変数の事例で説明するとする
(嫌ならC#のusingと読み替えてもらっても構わない)
ローカルに確保したオブジェクトが、メンバ変数に他のオブジェクトを持っていたとする
いわゆるコンポジションの状態、よくある話
C++で言えば、class my_class{ object *obj; }; といった感じのクラスになる、分かるよね？
で、ローカル変数はスコープを抜けたら解放される、usingも似たようなもの、これはRAIIの基本、良いね？
このとき、マークスイープ系GCだと、my_classのobｊに他からの参照が有るかどうか、即座にわからないので
objを開放してよいのか判断が付かない→my_classは破棄されてもobjはGC発動まで保留される→objは残るのでRAIIの意味がない
もしくは、my_classのobjに他からの参照が全く無いことをプログラマが保証して
my_classの開放部にobjをdeleteなりdisposeなりするコードを記入する
しかしこれは、objの所有権がはっきりしていないことには使えない上に、「手動」である
C++の場合はスマポが有るのでまだましだが、C#のDisposeは完全に手動で呼ばなければならない
自身のメンバにIDisposableなメンバいたら、自身もIDisposableにしなければならず、Disposeメソッドを実装して
自身のメンバのDisposeを芋づる式に呼び出すコードを手動で書かなければならない
mallocしたらfreeしましょうと一緒で、C言語レベルの全くの手動になってしまう
参照カウンタ方式のGCではこれらの問題は発生しない
他からの参照が有るか無いかは即座にわかるし、参照カウンタが0になれば、その場で即座に破棄される
自身のメンバに対して、デストラクタは芋づる式に呼び出されるので、C#のDispose実装のような面倒さは無い
>>424424(2): デフォルトの名無しさん [sage] 2016/03/27(日) 10:01:03.80 ID:MdJCnp0Y(3/6) AAS
メモリとその他のリソースを混同して考えるからダメ
まずその他のリソースは不可視のコードで解放しちゃダメ
リソースのスコープは明示的でなければならない
これはデストラクタにもGCにも任せられない
逆にメモリは不可視のコードで解放してもよい
まずこの基本原則から話を進めよう
お前言ってること無茶苦茶すぎるだろ
>リソースのスコープは明示的でなければならない、デストラクタにもGCにも任せられない
GCはともかく、デストラクタでもダメって意味不明すぎるんだが
考えの根本がおかしい
429: デフォルトの名無しさん [sage] 2016/03/27(日) 16:43:31.54 ID:vj+h39OC(7/10) AAS
C++で書けば
struct A{ *obj };
void func()
{
A a;
}
こういったRAIIの場合のobjの開放はどういう扱いにするんだって話
aが完全にobjを所有しているケースなら、Aのデストラクタにdelete obj;とでも書くかscoped_ptrでも使えばよい
しかし、objが彼方此方から参照されている可能性もあるので
そこんとこコンパイラは判断が付かないので、自動化はきない
あくまで、プログラマが保証する形になる
C#のDisposeのような仕組みを言語側で用意したところで、自身のメンバにIDisposableなメンバが有るかどうか
いちいち調べなきゃならなないし、調べ忘れや呼び出し忘れをするという問題が出てくる
しかも、所有権が単一である場合にしか成り立たない
一方でマークスイープ系GCに任せっぱなしにすると、objの開放はGC発動まで遅延してしまうだろう
参照カウンタはこれらの問題をすべて解決する
参照数はどのタイミングでも直ぐに分かるし、0になれば遅延なしで即座に削除される
デストラクタは自身のメンバに対して芋づる式に自動で呼び出されるので
スマポを使っておけば呼び出し忘れるということもないし
Disposeのような冗長なコードを書く必要もない
431: デフォルトの名無しさん [sage] 2016/03/27(日) 17:07:08.54 ID:vj+h39OC(9/10) AAS
結局、C#のDisposeはどこまで行ってもどんなに進化しても手動で書かなければならない
自身のDisposeが呼ばれたからと言って、自身のメンバ変数のDisposeを芋づる式に勝手に呼び出して良いかは
コンパイラにはまったく判断が付かない
他からも参照されていて今まさに使われている可能性がある以上
コンパイラが勝手に自動でDisposeを呼び出すコードを生成することはできない
GCを発動してみるまでは、どこからも参照されなくなったことが保証できない
しかし、GCの発動まで開放が遅延しても良いのであれば、そもそもDisposeは要らないわけで
Disposeの実行はGC発動より先行していなければならず、GCに頼れないということになる
なので、自身のDisposeが呼ばれたときに、自身のメンバのDisposeをしてよいかは
プログラマが考え、手動で呼び出す必要が有る
所有権が単一であれば、手動でメンバのDisposeを呼び出せばよい
手動で記述しなければならないので面倒くさいし、ミスの元ではあるが、一応できる
所有権が複数であれば参照カウンタを使うしか現実的な方法は無いだろう
マークスイープ系GCなのに参照カウンタで独自に管理するのは馬鹿げているがな
参照カウンタ方式＋デストラクタ
であればこれらの問題は一切発生しない
参照カウンタが0になったことは即座にわかるし、デストラクタはメンバ変数に対して芋づる式に呼び出されるので
開放に関しての特別なコードを手動で書く必要は無い
開放処理も一本化される
435: デフォルトの名無しさん [sage] 2016/03/27(日) 17:24:21.54 ID:MdJCnp0Y(6/6) AAS
まずDisposeは生成できる
めんどくさいという奴は知識が無いだけ
リソースを共有する事は少ない
というか設計段階で可能な限り少なくする
そして共有するならするでしっかり管理して自動解放などという手抜きはしない
基本中の基本だ
522: デフォルトの名無しさん [sage] 2016/04/24(日) 10:27:10.54 ID:W23a3TIA(2/2) AAS
物理アドレスはページサイズで切り売りされるので
元から連続しているアドレスは必要ではなく
フラグメンテーションは問題にならない
連続したアドレスが必要になるのは論理アドレスのほうであり
32bitプロセスでは4GBしか空間がないから問題になることがある
64bitプロセスであれば現状問題にならない
535: デフォルトの名無しさん [sage] 2016/04/24(日) 15:05:53.54 ID:TFb7efu7(3/3) AAS
>>530530(1): デフォルトの名無しさん [sage] 2016/04/24(日) 14:52:01.10 ID:fu8W/E1c(1/2) AAS
>>525
Qt 使ってるからと言って QtGui 使ってるとは限らんけどね
>>528
Qt 本体は C++ で書かれてるけ
ど Java, Ruby, Python, Perl, C# 等からも利用できるよ
色々な言語から使えるのか
そういう場合Qtが使うメモリーなんかはどういう扱いなんだろうね
GC適用外な気がするけど知らないからこれでやめとくわ
616: デフォルトの名無しさん [sage] 2016/11/16(水) 23:34:22.54 ID:EhKul/vA(2/2) AAS
>>615ログファイルであれば日付で切り替えとかあるね。
そしたらストリーム開きっぱで日付が切り替わったら、閉じて新しいの開き直すとかあるわ。
いつもlog4とか使って主処理と切り離してたから考慮から抜けてたわ。
俺の意見はdb接続とかで一部にしか当てはまらんので、
「基本的には」とか
「リソースを管理する必要があるもの」とか前提がつくね。すまん。
672: デフォルトの名無しさん [] 2017/09/17(日) 16:17:49.54 ID:S40DCpdn(9/20) AAS
MMUは多少以上の処理をすると簡単にフォールト返すのが困りもの
結局初心者レベルのプログラマしか想定してないんだよな
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.053s