[過去ﾛｸﾞ]
GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
GCは失敗。メモリは自分で管理せよ！ その2©2ch.net http://mevius.5ch.net/test/read.cgi/tech/1447856699/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
124: デフォルトの名無しさん [sage] 2015/11/30(月) 21:47:43.54 ID:UQyKbzCH >>122 馬鹿相手にしても時間の無駄だぞ こいつ具体的なこと何も言わんし http://mevius.5ch.net/test/read.cgi/tech/1447856699/124
132: Office & Gamers @ 試験運用中（トリなしｗ [アハ♪” uh huh] 2015/12/01(火) 04:32:07.54 ID:79aHC4wo 口 先 人 間 展 覧 会 。（ｱﾊ http://mevius.5ch.net/test/read.cgi/tech/1447856699/132
152: デフォルトの名無しさん [] 2015/12/04(金) 04:37:18.54 ID:HtuddwW0 【 オンラインTCGエディター 】 >>1 デュエル・マスターズ的な非電源TCGの 《 オンライン化ツクール系ソフト 》 制作の企画。 例えば、ガチンコ・ジャッジを直ぐにでも導入できる機能を持っておりながら、 当面それを扱わず単純化させておいて、事後的に導入拡張する際に当該システムを ブロック構造の組み合わせで後付け挿入できるように予めシステム化してあるソフト（エディター）。 既存の非電源TCGを劣らずに再現できるならば大概のニーズに応えられる筈。 バトスピ、ヴァンガ、ウィクロス、ポケカ、デジモン、ゼクス、モンコレ、ガンダム・ウォー、ライブオン、ディメンション・ゼロ、カードヒーロー、シャーマン・キングなど のシステムを完全再現できるように設計するけど、他に此のTCGの此のシステムは再現希望とか有ったら書いて。 マジック：ザ・ギャザリングの全システムを完全に再現するのは無理だから、此れだけは必用だ！って部分のみリクエストして。 WEB通信での対戦は、個vs個、多数乱戦、チームvsチーム、個vsチームを可能な仕様とする方針。 設計思想は 《 RPGツクール 》 が良いかな？ 他に、優れたエディター有ったら挙げてみて。 個人や企業などのベンダーが提示する開発費（見積もり）で折り合えば、発注する。 ↓ エディター群から基本コンセプトを絞り込む（もちろんオリジナルで優れた新ネタが有れば導入する）。 ↓ 遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。 なるべく前述３つで可能な再現は全て実装させる方向を目指す。 まぁ努力する・・・ バトスピ、ヴァンガ、バディ、デュエマなど発売済みゲームソフトが存在してるケースはベンダーに研究させる。 ↓ 各社TCGを再現するテストプレイ ⇒ 更に改良や修正。 ↓ 機能制限した下位版を５万円以上で発売 ＋ デュエリ−グ用に改造した上位版でサーバー稼動＝営業開始。 ↑ 下位版の改造および商用利用には、別途で当社との契約が必要。 さ〜て、製作ベンダー見つけよっと！ｗｗ（ｸｽ http://wc2014.2ch.net/test/read.cgi/entrance2/1449039272/-18 http://mevius.5ch.net/test/read.cgi/tech/1447856699/152
364: デフォルトの名無しさん [sage] 2016/01/27(水) 17:24:38.54 ID:eULyfEEH 謎だといったが、理由ははっきりしていて メンバのDisposableを自動で呼び出す為には 他で使われてないことを保証する必要があって 参照カウンタ方式のようにローコストなものなら簡単に分かるが これでは循環参照の問題が出る プログラマが循環参照を気にしなくてもよいことが前提の マークスイープ系のGCを搭載した言語では設計思想が破たんするので 参照カウンタ方式は採用できないし マークスイープ系GCでは何処からも参照されていないことがローコストに分からないので 自動でDisposeを呼び出す仕組みを用意できない どうにもならない 結局C++の方式が一番優れている 循環参照が発生する場合はweak_ptrを使う事だけ注意を払えば GCにまつわる他の問題が一切発生しない http://mevius.5ch.net/test/read.cgi/tech/1447856699/364
428: デフォルトの名無しさん [sage] 2016/03/27(日) 16:21:42.54 ID:vj+h39OC >>423 そんな基本的なことを言って何がしたいの？ 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実装のような面倒さは無い >>424 お前言ってること無茶苦茶すぎるだろ >リソースのスコープは明示的でなければならない、デストラクタにもGCにも任せられない GCはともかく、デストラクタでもダメって意味不明すぎるんだが 考えの根本がおかしい http://mevius.5ch.net/test/read.cgi/tech/1447856699/428
429: デフォルトの名無しさん [sage] 2016/03/27(日) 16:43:31.54 ID:vj+h39OC 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のような冗長なコードを書く必要もない http://mevius.5ch.net/test/read.cgi/tech/1447856699/429
431: デフォルトの名無しさん [sage] 2016/03/27(日) 17:07:08.54 ID:vj+h39OC 結局、C#のDisposeはどこまで行ってもどんなに進化しても手動で書かなければならない 自身のDisposeが呼ばれたからと言って、自身のメンバ変数のDisposeを芋づる式に勝手に呼び出して良いかは コンパイラにはまったく判断が付かない 他からも参照されていて今まさに使われている可能性がある以上 コンパイラが勝手に自動でDisposeを呼び出すコードを生成することはできない GCを発動してみるまでは、どこからも参照されなくなったことが保証できない しかし、GCの発動まで開放が遅延しても良いのであれば、そもそもDisposeは要らないわけで Disposeの実行はGC発動より先行していなければならず、GCに頼れないということになる なので、自身のDisposeが呼ばれたときに、自身のメンバのDisposeをしてよいかは プログラマが考え、手動で呼び出す必要が有る 所有権が単一であれば、手動でメンバのDisposeを呼び出せばよい 手動で記述しなければならないので面倒くさいし、ミスの元ではあるが、一応できる 所有権が複数であれば参照カウンタを使うしか現実的な方法は無いだろう マークスイープ系GCなのに参照カウンタで独自に管理するのは馬鹿げているがな 参照カウンタ方式＋デストラクタ であればこれらの問題は一切発生しない 参照カウンタが0になったことは即座にわかるし、デストラクタはメンバ変数に対して芋づる式に呼び出されるので 開放に関しての特別なコードを手動で書く必要は無い 開放処理も一本化される http://mevius.5ch.net/test/read.cgi/tech/1447856699/431
435: デフォルトの名無しさん [sage] 2016/03/27(日) 17:24:21.54 ID:MdJCnp0Y まずDisposeは生成できる めんどくさいという奴は知識が無いだけ リソースを共有する事は少ない というか設計段階で可能な限り少なくする そして共有するならするでしっかり管理して自動解放などという手抜きはしない 基本中の基本だ http://mevius.5ch.net/test/read.cgi/tech/1447856699/435
522: デフォルトの名無しさん [sage] 2016/04/24(日) 10:27:10.54 ID:W23a3TIA 物理アドレスはページサイズで切り売りされるので 元から連続しているアドレスは必要ではなく フラグメンテーションは問題にならない 連続したアドレスが必要になるのは論理アドレスのほうであり 32bitプロセスでは4GBしか空間がないから問題になることがある 64bitプロセスであれば現状問題にならない http://mevius.5ch.net/test/read.cgi/tech/1447856699/522
535: デフォルトの名無しさん [sage] 2016/04/24(日) 15:05:53.54 ID:TFb7efu7 >>530 色々な言語から使えるのか そういう場合Qtが使うメモリーなんかはどういう扱いなんだろうね GC適用外な気がするけど知らないからこれでやめとくわ http://mevius.5ch.net/test/read.cgi/tech/1447856699/535
616: デフォルトの名無しさん [sage] 2016/11/16(水) 23:34:22.54 ID:EhKul/vA >>615 ログファイルであれば日付で切り替えとかあるね。 そしたらストリーム開きっぱで日付が切り替わったら、閉じて新しいの開き直すとかあるわ。 いつもlog4とか使って主処理と切り離してたから考慮から抜けてたわ。 俺の意見はdb接続とかで一部にしか当てはまらんので、 「基本的には」とか 「リソースを管理する必要があるもの」とか前提がつくね。すまん。 http://mevius.5ch.net/test/read.cgi/tech/1447856699/616
672: デフォルトの名無しさん [] 2017/09/17(日) 16:17:49.54 ID:S40DCpdn MMUは多少以上の処理をすると簡単にフォールト返すのが困りもの 結局初心者レベルのプログラマしか想定してないんだよな http://mevius.5ch.net/test/read.cgi/tech/1447856699/672
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.026s