GCは失敗。メモリは自分で管理せよ！ その2

1 名前：デフォルトの名無しさん mailto:sageteoff [2015/11/18(水) 23:24:59.79 ID:BUQ68wTG.net] GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。 以下GCと記す プログラマをメモリ管理から開放する！ といいつつ、メモリリーク問題の文献が大量にある。 これすなわち、メモリリーク問題が全然解決していないということ。 さらに、メモリ解放のタイミングの文献まで大量に生み出した。 これすなわち、新たなるメモリ管理に関する問題を生み出したということ。 malloc、freeじゃないが 結局のところ、メモリを管理するという技術は、今しばらくは、身につける・教える・学ぶべきではないだろうか？ 使って、そのまま放置しても、基本的にはGCがなんとかしてくれている。 ランジョブからジョブ終了までさほどの時間を要さない。メモリも大して使わないならいいだろう。 しかし、規模が大きくなり常駐ジョブやメモリ大量使用のジョブになってくると、そんなメモリ管理の方法でやっていると、 上記「文献」を生み出されてしまう。 入門時は、メモリに無頓着でもいいだろう。それよりも、目的を達成することが先決だ。 しかし、慣れてきたら、やはりメモリの管理まで余裕を持って自分で行うべきだろう。 前スレ GCは失敗。メモリは自分で管理せよ！ peace.2ch.net/test/read.cgi/tech/1412986420/ 87 名前：デフォルトの名無しさん mailto:sage [2015/11/28(土) 23:46:43.25 ID:pohBt4lh.net] >>82 勝手にnull代入すると表現するから気持ち悪く感じるだけで、コンパイラが各変数についてもうアクセスされる可能性の無い基本ブロックに到達したら、その変数をGCのマークの起点として使用しないようにフラグを管理すると言えば当たり前の話じゃね。 フラグの持ち方として変数にnullを代入しているだけで。 88 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 00:14:42.24 ID:qbMwzV1h.net] >>84 > そもそも解放処理って忘れやすいものだろ それを忘れるなどとんでもない 確保＆開放なんてプログラミングの花じゃん キモじゃん そこを工夫するのが楽しいんじゃん 設計も楽しいし チマチマテストすんのも楽しい 温泉行って湯につかり忘れる心配はない 89 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 00:30:29.12 ID:Co3W2iFa.net] >>87 まあ勉強目的でやるならいいんじゃね 俺は元々ゲームプログラマだったからもう嫌になるほどやったし メモリ周り工夫するなら言語設計からしたいわ 90 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 13:48:13.85 ID:U49gaUJj.net] 信じて送り出した >>87 がわがままな顧客を✕✕して三面記事に載るなんて… 91 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 14:29:40.51 ID:c+9MHjtm.net] マークスイープ型のGCが必要かどうかについて、もう少し建設的な会話をしようよ リソースを自動で開放してくれる機能は、無いよりは有った方が絶対に良い、と言い切ってよいよね ただ、その方式が話の焦点だと思う C++のスマポの参照カウンタ方式はデストラクタとの相性が良いし、RAIIもよく機能するし 開放されるタイミングもはっきりしているのて、手続き型言語と相性が良いし、軽い ただし、循環参照があるとリークする 解決策として、片方をweak_ptrにするという方法が用意されている weak_ptrは対象オブジェクトが開放されると勝手にヌルポみたいになるのでいろいろと悪用ができる 一方でマークスイープ系のGCは、循環参照があってもリークしない しかし参照カウンタ方式に比べてマークスイープ系のGCが優れている点は、それだけ 重いし、いつ開放処理が実行されるか分からないので リソース開放のタイミングを明確に行いたい場合のための別の仕組みが必要になった どちらを選ぶ？ 92 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 14:58:17.95 ID:7vkfzAlt.net] GCの意見・・・OSではページファイル関連？ peace.2ch.net/test/read.cgi/tech/1447856699/l50 93 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 15:57:55.75 ID:Co3W2iFa.net] そもそもc++においてメモリリークって対策も発見も 大して難しい部類のバグではないんだよなぁ GCの優位性をアピールするために過剰に恐怖心を煽ってる気がする 94 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:00:08.95 ID:sCmmZzWu.net] >>92 その程度の案件しか受けてないからだろう。 95 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:05:07.63 ID:QSPcxrGF.net] >>90 つ世代別GC immutableオブジェクトをバンバンnewしまくる関数型プログラミングに慣れてると やっぱGCないとキツイわ 96 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:15:05.64 ID:Co3W2iFa.net] >>93 いやいや普通難しいとされるバグってメモリ破壊とか同期周りだから メモリリークなんてデバッガがチェックして丁寧なダンプ出してくれるし 組み込みとかの貧弱な環境なら専用のメモリ管理を用意して いくらでも好きなチェックや情報出せるから 97 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:17:37.80 ID:AV0cYAnH.net] >>92 それな メモリの確保と開放の対応すら管理できない奴は なんかもう何をどうしたってダメな気がする 初歩の初歩の初歩の話題を何度も何度も何度も繰り返しすぎ 98 名前：デフォルトの名無しさん [2015/11/29(日) 16:20:05.34 ID:3h4H/kBH.net] 忘れるとか忘れないとか池沼レベルの話じゃん。 ゴミクズ。 メモリの解放が必要ならそれは必要な機能の実装ってことになる。 それを忘れるってことはプログラムを組んでいて必要な機能の実装を忘れるってことだ。 必要な機能の実装を忘れるということは、例えば通販サイトのシステム開発請け負っておきながら、決済システムを実装し忘れるのと同等。 ありえない。 プログラム云々以前に頭の問題だろう。 必要な機能の実装を忘れる可能性におびえる池沼プログラマ。 最近流行りのADHD？なんじゃねえの。 99 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:24:33.80 ID:sCmmZzWu.net] >>95 なるほど。経験の少なさがすぐ分るな。ログ出したらで数十ギガなんてよくあるよ。 ログから問題点をスクリプトで抽出するにも何時間とかかるとかいろいろ。 マルチスレッド絡んで特定のパターンだけだったりして再現性がなかったりする。 他システムの連携だと手が出せない部分の挙動がおかしい可能性もある。結局、oracleのバグだったとかね。 100 名前：デフォルトの名無しさん [2015/11/29(日) 16:25:01.11 ID:1uX74bCE.net] >>97 決済システムとメモリ解放は違うよ。 通販サイトのシステムをC言語で実装してみればわかるかと。 101 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:36:20.27 ID:Co3W2iFa.net] >>98 はあ？なんでリーク箇所ダンプするだけの話でログ全部吐き出すことになってんの 普通確保する際にヘッダにそのブロックの確保場所埋め込んでるし アロケータで生存期間のスコープを切り分けといてすぐ分かるようにするけど？ お前の関わったプロジェクトが糞なだけじゃね？ 102 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:42:54.34 ID:snjMtaUP.net] そもそも今時c++でgcならなんとかなる類いのメモリリーク起こすなんて、プログラマが屑なだけ。 リソースリークやその他の問題も確実に起こすこと請け合い。 GC言語でそのレベルのプログラマを使うような案件はGCによるメモリオーバーヘッドが気にならず、リソースリークも問題にならないような非常に緩い案件でしかない。 103 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:46:22.91 ID:sCmmZzWu.net] >>100 はぁ。話にならんな。扱ってる規模が違いすぎる。 104 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:52:06.50 ID:Co3W2iFa.net] >>102 おいおい反論できずに捨て台詞かよ 上でも書いたがコンシューマで開発してたから 100人*数年の規模でやってたんだけど もしかしてC++みたいな危険な言語使ってて 今の今まで解析ツールなり自前のメモリ管理なり知らなかったの？ 105 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 19:41:19.37 ID:GW0SCIDI.net] お前ら派遣だろw 全体規模とお前らが任されてる範囲を都合よく混ぜるな。 106 名前：デフォルトの名無しさん [2015/11/29(日) 22:07:37.11 ID:3h4H/kBH.net] ほーら、自分の知能が一般人より低いと認めたくないがゆえにレッテル貼りが始まった。 普通の人が当たり前にできることができないってかわいそうだな。 もしADHD？だったら治療法あるらしいから病院行ってみたら？ ここでレッテル貼りやってるよりよっぽど解決する可能性が高いぞ。 107 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 22:12:02.58 ID:QSPcxrGF.net] レッテル貼りは2chの華 108 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 08:34:00.92 ID:qSWjFIuy.net] >>100 リーク箇所がわかってればログ出力の必要なくね？ ホントに開発したことあるのかな？ 109 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 09:12:24.63 ID:UQyKbzCH.net] >>107 普通C++のプロジェクトは専用のメモリ管理を用意するから リークしたメモリはそれを確保したクラスとその行数まで特定できるようにしてるよ アロケーターも分離しとけばアプリケーション終了させなくても 管理オブジェクトを破棄した時点でリークの判定できるし リーク箇所特定するのに全ログから解析とか複合的なバグでもない限りしない そんな状況許してる時点で負け 110 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 12:11:48.62 ID:fg7tHWVi.net] 100人で数年のシステムなら 10人で一年でやるべきだな。 人を無駄に増やせば、意思疎通や連携に無駄に労力を割く。 開放云々より仕様レベルで齟齬が出やすくなるわ。 111 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 15:00:18.02 ID:Ee9Jt/HC.net] >>108 リークしたクラスが分ればリーク原因が分るとかお花畑杉w 112 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 19:23:16.25 ID:UQyKbzCH.net] >>110 誰もリークしたクラスの事なんて言ってないんだが…理解できてる？(笑) 解らないなら解るだけの情報埋めたら？ 113 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 19:24:12.90 ID:Ee9Jt/HC.net] おいおいw 114 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 19:31:17.77 ID:UQyKbzCH.net] >>112 そもそもGCがあろうとコンテナに突っ込んで消し忘れれば オブジェクト破棄するまでメモリ圧迫し続けるって理解できてる？ リーク単体ならC++はそれと同等のレベルまで分かりやすく出来るんだよ C++が困難なのはそういった管理情報も簡単に破壊出来てしまう点 リーク単体なら怖くはない 115 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 19:47:37.41 ID:UQyKbzCH.net] なんかだんだん笑えて来たんだけど、ろくに理由も言わずに 「わかんないんですけど！？わかる奴はお花畑(怒)！！」って なかなか面白い奴だな 116 名前：デフォルトの名無しさん [2015/11/30(月) 19:50:22.70 ID:isQX20zS.net] メモリの解放すら管理できない奴が、複雑な仕様を管理できるとは到底思えない・・・。 メモリの解放なんてなんの苦にもならんが・・・。 117 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 20:14:21.83 ID:Ee9Jt/HC.net] やれやれw MSやLinuxやFreeBSDまでメモリリークやらかす理由が分らないのか。 118 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 20:30:16.55 ID:UQyKbzCH.net] >>116 また反論できずに逃走かよw そもそも欧米は原因分かっててもバグ無視する連中だろうがw ライセンスで守られてりゃ平気で放置するぞ 119 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 20:33:04.33 ID:V9s4KAVu.net] 人生の管理ができない奴が、メモリを管理できるとは到底思えない 120 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 20:49:26.08 ID:UQyKbzCH.net] そもそもLinuxカーネルもFreeBSDカーネルもC言語だろ 馬鹿丸出しだなw 121 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 21:16:22.39 ID:zT+q2mn+.net] >>115 それな プログラミングにおいてメモリ周囲はまだ初歩だよな そしてマルチスレッドはそれよりは大変だがこれも慣れると 結局大事なところをガッチリ排他処理するだけのことだしな プログラミングって最後はインタフェース設計だけだから 使いやすくてコンパクトなインタフェースを求めていくだけ これがプログラミング道の後半の道のり 122 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 21:18:50.76 ID:Ee9Jt/HC.net] >>120 で例外系の実装がないから破綻するんだよ。実務経験ないとすぐ短絡的になるのが分る。 123 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 21:25:49.32 ID:zT+q2mn+.net] 意味が不明すぐるｗ 124 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 21:28:33.92 ID:Ee9Jt/HC.net] うむ。まだおまえには早いかもしれない。 125 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 21:47:43.54 ID:UQyKbzCH.net] >>122 馬鹿相手にしても時間の無駄だぞ こいつ具体的なこと何も言わんし 126 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 22:07:34.86 ID:zT+q2mn+.net] >>124 そやね 一連のレスの意図すらよーわからんわ 127 名前：デフォルトの名無しさん mailto:sage [2015/12/01(火) 00:23:09.00 ID:s1rcgCDh.net] Guilty Crown? たしかに失敗作だったなあ… 128 名前：デフォルトの名無しさん mailto:sage [2015/12/01(火) 01:24:29.91 ID:mVPa8mQr.net] GCが云々というより抽象的なプログラミングしたい時は基本的なメモリ管理を言語に任せたいという欲求 129 名前：デフォルトの名無しさん mailto:sage [2015/12/01(火) 01:27:09.96 ID:mVPa8mQr.net] >>113 c++素人なんだけどリーク単体はともかくそれにメモリ破壊が合わさると頭がおかしくなって死ぬ みたいな感じ？ 130 名前：デフォルトの名無しさん mailto:sage [2015/12/01(火) 01:30:32.01 ID:s1rcgCDh.net] GCは関数型プログラミングでのみ正当化される 命令型プログラミングでは全く正当化されない 命令型プログラミング（＝チューリングマシンに基づく計算モデル）は読み書きの「順序」こそがネ申なので 命令コードの「順序」を横断して存続するブツは善と悪の最終戦争で滅ぼされるであろう つまり確保し、使ったら後開放する、これを明示的に書き下す姿勢こそが正しい 131 名前：デフォルトの名無しさん mailto:sage [2015/12/01(火) 01:31:50.27 ID:s1rcgCDh.net] >GCは関数型プログラミングでのみ正当化される ちな、これは処理系の裏方としての存在が許される、の意味 132 名前：デフォルトの名無しさん mailto:sage [2015/12/01(火) 01:36:31.76 ID:mVPa8mQr.net] 関数型プログラミング好きだけど 代数型データ型と型クラスでモナドとかアプリカティブとかtraverse、free monadとかやってる時に メモリ管理だの言われたら余裕で死ねるな 本物のhaskellプログラマはhaskellで低レイヤを書くらしいけど 133 名前：運用中（トリなしｗ mailto:アハ♪” uh huh [2015/12/01(火) 04:32:07.54 ID:79aHC4wo.net] 口 先 人 間 展 覧 会 。（ｱﾊ 134 名前：デフォルトの名無しさん mailto:sage [2015/12/01(火) 12:55:11.72 ID:S8usJREu.net] >>128 > メモリ破壊が合わさると これが合わさるとなんでもありありなので何が起きても不思議はない なので、ダングリングポインタの管理と配列のレンジチェックはちゃんとやるべし 135 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 12:20:09.85 ID:AuS7g0FI.net] ここでメモリ確保 ここでメモリ解放 たったこれだけが書けない管理できないとかw 136 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 12:23:19.04 ID:n26CULk9.net] 知らないでやるって幸せなことなんですね 137 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 13:19:32.39 ID:N5r0JkUz.net] >>134 下には下がいるんだよ 138 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 13:29:54.15 ID:JbiOZ/E3.net] メモリリークは開放忘れでなると思ってる低レベルがいるのか。 139 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 14:07:05.91 ID:n26CULk9.net] 低レベルなことを舐めるなよ 140 名前：デフォルトの名無しさん [2015/12/03(木) 16:32:54.69 ID:JraK7tKY.net] >>134 mallocでOSから確保したメモリはfreeで解放されないんだが、 「ここで解放」はどうやって書くんでしょう? 141 名前：デフォルトの名無しさん [2015/12/03(木) 19:43:25.89 ID:R/g8PPkY.net] >>137や>>139みたいのが知識や技術に溺れて本質を見失い、 人と会話ができなくなった人の見本なんだろうか 142 名前：デフォルトの名無しさん [2015/12/03(木) 19:47:17.15 ID:JraK7tKY.net] >>140 今まで正しいと信じきってた鰯の頭が迷信だと指摘され発狂中 143 名前：デフォルトの名無しさん [2015/12/03(木) 19:53:39.75 ID:R/g8PPkY.net] >>141おｗ　おまえ会社で孤立してるだろ派遣ｗ 144 名前：デフォルトの名無しさん [2015/12/03(木) 20:32:35.32 ID:R04IP6VM.net] 確保したやつが解放するんだぞ。大丈夫か？ 145 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 20:33:46.24 ID:cWTIfUD3.net] 想像を絶するアホは居るもんだよ if (cond) exp; の場合も中カッコを必ず付ける流派ってのがあって 理由を聞くと if (cond) {exp1; exp2;}とするはずが if (cond) exp1; exp2;としてしまうのを防ぐための常に中カッコらしい 中カッコを書き忘れるくらいの意識レベルで書かれたコードって 他のとこももう全部ダメだろそれは 146 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 20:52:03.75 ID:s/TINiTx.net] >>144 お前がアホなｗｗｗ 147 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 21:25:03.70 ID:n26CULk9.net] カッコ先につけといたほうが　後々、都合がいいことも 148 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 21:30:08.65 ID:WeEbsZB7.net] アホな書き方といえば 　if ( 1 == a ) { って比較元と先を逆にしてる奴 149 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 21:41:57.39 ID:4rUKwdGH.net] 別におかしくない 基準値が先にあって、それと比べてaがどうなのか、と考えるか aが先にあって、基準値と比べてどうなのか、と考えるかの違いでしか無いから どっちでも良い 150 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 21:59:47.07 ID:/xqyH1ID.net] >>147 知ってて言ってると思うが、定数を==の左辺にするのは if (a=1) { ... と書き間違うのを恐れているらしい >>139 free()から設計し直す、 まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ >>135 スレッド安全に書かない奴が悪いていうかそれは別の話 シングルスレッド状況（またはそれと等価な状況）では>>134の言っていることは全く正しい 151 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 22:27:47.14 ID:zepIVOGi.net] ここ数日一気にレベルが下がったなw ＧＣの話しろよw 152 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 22:46:13.76 ID:srgQPG9D.net] つーか前スレと同じこと書いてる人多数 頼むから前スレ読んできて 153 名前：デフォルトの名無しさん [2015/12/04(金) 04:37:18.54 ID:HtuddwW0.net] 【　オンラインTCGエディター　】　>>1 デュエル・マスターズ的な非電源TCGの　《　オンライン化ツクール系ソフト　》　制作の企画。 例えば、ガチンコ・ジャッジを直ぐにでも導入できる機能を持っておりながら、 当面それを扱わず単純化させておいて、事後的に導入拡張する際に当該システムを ブロック構造の組み合わせで後付け挿入できるように予めシステム化してあるソフト（エディター）。 既存の非電源TCGを劣らずに再現できるならば大概のニーズに応えられる筈。 バトスピ、ヴァンガ、ウィクロス、ポケカ、デジモン、ゼクス、モンコレ、ガンダム・ウォー、ライブオン、ディメンション・ゼロ、カードヒーロー、シャーマン・キングなど のシステムを完全再現できるように設計するけど、他に此のTCGの此のシステムは再現希望とか有ったら書いて。 マジック：ザ・ギャザリングの全システムを完全に再現するのは無理だから、此れだけは必用だ！って部分のみリクエストして。 WEB通信での対戦は、個vs個、多数乱戦、チームvsチーム、個vsチームを可能な仕様とする方針。 設計思想は　《　RPGツクール　》　が良いかな？　　他に、優れたエディター有ったら挙げてみて。 個人や企業などのベンダーが提示する開発費（見積もり）で折り合えば、発注する。 ↓ エディター群から基本コンセプトを絞り込む（もちろんオリジナルで優れた新ネタが有れば導入する）。 ↓ 遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。 なるべく前述３つで可能な再現は全て実装させる方向を目指す。　まぁ努力する・・・ バトスピ、ヴァンガ、バディ、デュエマなど発売済みゲームソフトが存在してるケースはベンダーに研究させる。 ↓ 各社TCGを再現するテストプレイ　⇒　更に改良や修正。 ↓ 機能制限した下位版を５万円以上で発売　＋　デュエリ−グ用に改造した上位版でサーバー稼動＝営業開始。 ↑ 下位版の改造および商用利用には、別途で当社との契約が必要。 さ〜て、製作ベンダー見つけよっと！ｗｗ（ｸｽ wc2014.2ch.net/test/read.cgi/entrance2/1449039272/-18 154 名前：デフォルトの名無しさん mailto:sage [2015/12/04(金) 12:21:13.29 ID:GzeAUkqU.net] >>149 >free()から設計し直す、 >まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ じゃ>>134は設計し直してから言うんだな。坊や。 って、事でオッケーね。 155 名前：デフォルトの名無しさん [2015/12/04(金) 20:05:33.81 ID:SAJ9n/s7.net] >>137これって何が言いたいの？OSやライブラリ自体にミスがあるって言いたいの？ wikiより >メモリリーク (Memory leak) とは、プログラミングにおけるバグの一種。 >プログラムが確保したメモリの一部、または全部を解放するのを忘れ、確保したままになってしまうことを言う。 >プログラマによる単純なミスやプログラムの論理的欠陥によって発生することが多い。 >>137みたいなこと言う奴って、電磁波からデータが盗まれる！対応しないと！とか言い出すタイプ？ 156 名前：デフォルトの名無しさん mailto:sage [2015/12/04(金) 21:16:45.71 ID:7W1HEY29.net] >> 157 名前：151 そもそも１５年ぐらい前から延々繰り返されてるんだが… [] [ここ壊れてます] 158 名前：デフォルトの名無しさん mailto:sage [2015/12/04(金) 23:45:19.53 ID:j6MEWqDN.net] >>154 開放コードを忘れずに書いたのに開放されないという怪奇現象がマルチスレッド状況ではしばしばあるんじゃー！ マルチコア時代になってこれはますます危険になった 見ただけで正しさがわかる系のスレッド安全策はクロックサイクルを糞のごとく消費するし… こういうのは専門家が徹底的にデバッグしたGCで面倒を見て欲しいと思う反面、 やっぱプロセス全体のごみ処理を選任モジュールにやらせるのはクロックサイクルをドブに捨てるがごとき センス無い設計なｷﾓｽ、、 159 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 00:08:28.41 ID:+HxrBEdK.net] それ単にメモリバリアの問題じゃ… 160 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 04:01:37.91 ID:2vAbbe+i.net] >>154 入門書に書いてるコードしか見たことないんだね。 スレッドプールみたいなテクニックは高速化のためにみな普通に使うんだよ。 OSやライブラリにもメモリリークなんてよくあることだし、それらのバグも開放忘れて起きてるイージーなバグじゃないよ。 他のバグやトラブルがメモリリークという形で表面化してるにすぎない。 161 名前：デフォルトの名無しさん [2015/12/05(土) 08:28:25.61 ID:Pfi54LUx.net] >>158 具体的にいつのどのバージョンのライブラリで起きてるの？ 使い終わったらメモリを開放しろ。使い終わってないなら開放する必要はない。これとスレッドプールとどこに関連性があるの？ 162 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 09:45:44.55 ID:P9ivIQ+p.net] >>159詰めても無意味。 こういう連中は、まず自分の考えややり方が絶対正しく絶対に曲げない。曲げないために無理やり理由を当てはめようとしている。 で、さもそれを自分はやってるように言っているが、実際は単に本に載ってることを言ってるだけ。 実装もできない。面前で詰めてやれば発狂して勝敗がハッキリつくけどネット上では無理だね。 163 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 09:48:00.71 ID:BOwcKS4A.net] メモリの話とスレッドの話を混ぜ込んでしまうタイプは 問題の切り分けがそもそも出来ないタイプ だからメモリリーク（）に悩まされる スレッド間の協調と、メモリのケアは直交する別の話題 164 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 10:18:00.14 ID:NRX1k+Is.net] >>158 ちょっ漏れが作ったわけでも漏れの使い方に問題があるわけでもない階層で起きるメモリリークの責任を漏れに負わされても困る… それに他人が作ったモジュール内でのメモリリークも結局は開放が書かれていなかったか、書かれていても正しくなかったからリークしているはず… >>161 全面同意だが同意したからと言ってメモリリークがゼロになるかっていうと以下略 単純にクリティカルセクションとかキューによるシリアライズ（Active Objectパターン）で排他して マルチコアを活かさずパフォーマンスをドブに捨てて良ければ平和なんだが… 165 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 12:34:30.29 ID:eGerJrSR.net] だからメモリを自動開放してほしいときはスマートポインタを使えばよいだろ 循環参照が無い限りshared_ptrで問題ないだろ 循環参照がある場合はどちらかをweak_ptrにすれば済む話だろ 現実にshared_ptrの様な物が存在して無いなら、そういう議論も意味があるが 実際にはshared_ptrは現実に有るのだから、自動管理したい場合は使えばよいだけの話でしかない 166 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 12:38:09.16 ID:eGerJrSR.net] むしろ議論すべきはshared_ptrのような参照カウンタ方式のスマポと 言語ビルドインのマークスイープ系のGCとで どちらが良いか、だろう 参照カウンタ方式は循環参照で問題を起こすし マークスイープ系のGCはいつ実行されるか分からない 167 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 13:11:12.91 ID:eGerJrSR.net] つまり、完璧なGCは無いということだ 完璧なGCが無い以上、使う側が状況に合わせて選べた方が良いわけだが そうなるとC++/CLIのような変体言語しかないのが残念だ 168 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 13:42:35.29 ID:FurPG6R/.net] 普通に言語を選べば良いだけの話では 169 名前：デフォルトの名無しさん [2015/12/05(土) 13:49:45.99 ID:Pfi54LUx.net] このスレ論点が一致してないよね。 　freeやdeleteを記述すべきという論点で話をしている人 　freeやdeleteしたところでメモリが解放されてるわけではないですがという論点の人 　freeやdeleteは当然、さらにnull等を記述すべきという論点で話をしている人 　GCの実装そのものを論点にしている人 論点がばらっばらだから咬み合わない 170 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 13:58:32.14 ID:wharPYQR.net] >>158 > OSやライブラリにもメモリリークなんてよくあることだし よくあると言うなら１０個ぐらいすぐにあげられるよな もちろん最新版でリークする奴ね 171 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:16:25.84 ID:2vAbbe+i.net] MSのサイトにfix分と調査中のものが全部公開されてる。他のOSもlog、mlみれば腐るほど出てくる。 10個上げろとか、ほんと幼稚園児かよ、おまえらは。頭悪すぎw 172 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:33:31.47 ID:9PUwCRa0.net] C++でRAIIを徹底しておくのが一番いいよ 解放タイミングのコントロールが必要になったら後からでも柔軟に対応できるし GCは解放に係る少し変わった条件が発生した時に滅茶汚いことをしなきゃならなくなる 173 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:36:53.80 ID:NRX1k+Is.net] shareed_ptrはC++で比較的効率よくやれることと、GCしたい人が真にやりたいことの妥協の産物であって どんなシチュでもベストにフィットするような一押しの決定版ってほどでも無い… 参照カウンタの排他が不要で循環参照が無いことも保証できるまで設計が詰められているなら スレッドごとに、メモリを確保して使って返す処理を直に書くのが一番良い 174 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:43:55.34 ID:9PUwCRa0.net] 確保／解放を直に書くのはスピード的には一番速いだろうけど解放漏れバグの温床過ぎてネ 特に例外が絡むとやってられない状況になる 175 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:45:23.69 ID:+HxrBEdK.net] >>167 null云々は別言語だ馬鹿 176 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:47:17.08 ID:wharPYQR.net] >>169 > もちろん最新版でリークする奴ね 早くあげてよね w 177 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:52:20.59 ID:NRX1k+Is.net] >>172 >特に例外が絡むとやってられない状況になる そこだけはstd::unique_ptr<T>の一押し これで例外状況でのRAIIが完成するので真にGCが要らんところまで逝く ていうか大概のアプリなら、例外を生じたらFatal errorなことをユーザーに知らせて終了、でいいんじゃ… 178 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:59:01.89 ID:9PUwCRa0.net] >>175 いやーリソース獲得した状態でファイルI/Oとかネットワークとかが絡む場合は終了じゃすまん場合が多いでしょ 179 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:06:58.28 ID:MOG2PmhH.net] 昔C言語で数珠繋ぎの独自スコープとしてblock_enter/block_leaveというのを作って { block_handle h = block_enter(b) object = block_create_object(h) block_leave(h) } 180 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:10:52.59 ID:MOG2PmhH.net] 書き損じた 昔C言語で数珠繋ぎの独自スコープとしてblock_enter/block_leaveというのを作って func(b){ block_handle h = block_enter(b) object = block_create_object(h) block_leave(b, h) } というので例外にも対応したリソースマネージャ作った block_leave(b, h)せずにスコープ抜けても上位のblock_leaveで開放が保証されたり block_leave(b, 0)で全開放とかそんなの 181 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:15:45.24 ID:MOG2PmhH.net] デメリットはblock_create〜で作成するものは全部ヒープに確保されること 結局C言語でここまで必要な案件てのが回ってこなくてあんま使ってないけどリーク予防法の参考程度に 182 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:24:40.86 ID:4CEShJeO.net] 例外にも対応って？ 183 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:29:31.41 ID:K ] [ここ壊れてます] 184 名前：dBqlpoa.net mailto: C#でアンマネージドなメモリを扱えるのはわかった 確保したメモリ領域にオブジェクトを配置する事は出来ない？ C++で言うところの配置newを再現したいんだ メモリの確保解放はプログラマが特別に管理してその間は普通のオブジェクトと同じように透過的に扱いたい [] [ここ壊れてます] 185 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:30:53.84 ID:MOG2PmhH.net] >>180 例外つってるのは具体的にはSEHの話 どっかで止めた時点のblock_leave(b, h)でそれまでの開放が保証されるってこと 186 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:39:23.63 ID:eGerJrSR.net] C++にfinallyが無いのが気に食わない 今はラムダが有るのでマクロでそれっぽいものを自作したが 標準で用意しておいてほしい C++はリソースを自分で管理する傾向のある言語なのに finallyが無いのは本来おかしいよな ラッパー作ってRAIIを徹底しろってことなんだろうけど すべてのリソースに対してラッパーを用意するのは面倒だよ fainallyが有ったって邪魔になるわけでもないのに 最終的に使うかどうかは利用者が選べばよいことだし C++ってそういう言語だろ 187 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:50:01.56 ID:9PUwCRa0.net] >>183 C++にはテンプレートがあるからリソースの型をテンプレート引数とするラッパーを作るのは そんなに面倒なことじゃないと思う あとC++でRAIIを徹底してればfainallyの必要性を感じたことはない fainallyを書かなければいけない時点で危なっかしいコードだと思う 188 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 16:34:34.82 ID:+HxrBEdK.net] むしろfinallyってデストラクタがない言語だから 必要なものなんじゃ… どうしても必要ならデストラクタで任意のラムダ呼ぶ ユーティリティクラス作れば同じこと出来るし 189 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 16:50:13.74 ID:+HxrBEdK.net] 98以前でもローカルクラス定義できるんだからすこし冗長なだけで同じだし 190 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 16:59:06.52 ID:NRX1k+Is.net] 例外発生はバグ、というプログラミングしかしたことないからよくは知らんが、 try { 　try { 　　/*...*/ 　} catch (std::badalloc()) { 　　/*...*/ } catch (UserException e) { 　　/*...*/ } } catch (...) { // fainally節の代わり 　/*...*/ } じゃあいかんの？実行時コストは知らん 191 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 17:00:08.66 ID:NRX1k+Is.net] ｽﾏﾝ 誤： } catch (std::badalloc()) { 正： } catch (std::badalloc e) { 192 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 17:32:52.06 ID:+HxrBEdK.net] 違う。そんぐらいググれ 193 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 17:37:26.87 ID:KdBqlpoa.net] デストラクタの問題点は不可視なところだな usingやfinallyは目に見えるから安心する 194 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 18:00:14.20 ID:NRX1k+Is.net] >>189 内側のtry〜catchから再throwするのを忘れたorz 内側のtry〜catchから再throwして外側ので再捕捉したらいいんじゃ… 195 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 18:22:16.37 ID:0v99S3Ys.net] 例外をロジックとして使うなってばっちゃんが言ってた 196 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 19:38:41.80 ID:eGerJrSR.net] >>191 throwせずにreturnするパスが有ったらどうするんだよ そういうのを防ぐためのfinallyやRAIIなのに まったくちんぷんかんぷん 結局returnする前に手動で忘れないようにthrowすることを強制するんなら goto文とか開放用ラムダ呼び出すのとかと替わらないだろ 197 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 20:44:27.97 ID:ZNw2R9x1.net] だから忘れる忘れないレベルをぶち込んでくるのは止めようやｗ これをぶち込むから全ての議論が池沼レベルになってる 198 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 06:02:02.37 ID:JYyEEHci.net] 異常系で例外返す仕様のライブラリが失敗。 199 名前：デフォルトの名無しさん [2015/12/06(日) 08:06:42.75 ID:XhferEg+.net] >>194 GCなんて池沼のために生まれたようなものだし・・・ NULLったりfreeったりすることすらまともに把握、指示しきれない 200 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 11:36:02.06 ID:G3VNQyn5.net] c++のデストラクタって後処理に失敗しても 例外投げられないからウンコ 結果的にエラーを握り潰すゴミコードを量産する原因になってる 201 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 11:40:47.08 ID:zGnP2wpv.net] そのクラスが管理してる範囲で後処理の失敗って何が起こるの？ 202 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 12:05:41.69 ID:kVHO13oj.net] どうしてもやりたいなら対処法はあるしなぁ。 203 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 12:23:19.67 ID:MkaxAbH2.net] 現実的な確率で発生して無視出来ないリスクが有る解放処理はデストラクタでやるべきじゃない そういうリソースに対してデストラクタがやる事はプログラマに対しいて未解放のリソースを通知する事だけでよい 204 名前：デフォルトの名無しさん [2015/12/06(日) 12:30:12.96 ID:XhferEg+.net] 具体的に何があるん？？？ クラス内で使っているリソースで解放に失敗（失敗し続ける）するって。 205 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 13:14:17.95 ID:lk97yytv.net] どっか他のオブジェクトと共有してるものを解放しようとして失敗するとか？ それはそもそもの設計に問題ありすぎだが。。 206 名前：デフォルトの名無しさん [2015/12/06(日) 15:01:28.77 ID:XhferEg+.net] >>202 だよね。 否定しようとして無理やり現象を創りだそうとしているとしか・・・。 でもその無理やりつくった現象は、そもそも論理設計のミスが大前提だったりする。 論理設計のミスまで言われたらなんにも組めないわ。 207 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 15:42:32.97 ID:wxELMJDc.net] >>200 デストラクタの中で起きた例外については try { } catch (...) { }で囲った上で、リカバリ処理（何とかしてリソース解法漏れをなくす）を行えばいいじゃない？ もし例外発生後に行うべき適切なリカバリ処理が書けない（存在しない）んだとすると、 もはやデストラクタ内に限った話ではなくなって、例外を発生させた時点で設計か実装にバグが居たとしか… 208 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 16:03:58.23 ID:5cQQ9Lrm.net] バグ（リソースへのポインタやハンドルを壊しちゃったとか）以外で リソース解放に失敗するケースなんて１つも思いつかない 209 名前： ◆QZaw55cn4c mailto:sage [2015/12/06(日) 16:19:39.63 ID:4bjdt2kC.net] fclose() にも失敗があるじゃないか？ 210 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 16:54:30.29 ID:djRjUyAt.net] fflush() しとけばＯＫ 211 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 16:59:21.77 ID:5cQQ9Lrm.net] >>206 fcloseの失敗はハンドルが正しい限りflush時のI/Oエラーの通知であって、その場合でもリソースは解放されるよ 212 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 17:35:51.31 ID:G3VNQyn5.net] c++信者ってアホだなー みんなこんなんなの？ cpplover.blogspot.jp/2011/01/fclose.html?m=1 213 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 17:44:16.50 ID:G3VNQyn5.net] fcloseに失敗してファイルに正常に書き込みされなくてもシカトしてるんだよね？ それともerrnoとかチェックしちゃってるの？ 214 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 19:05:12.47 ID:RyqEmv/A.net] まあC++の例外を援護するつもりはないがそういう場合は 普通にフラッシュしろよ そもそもC++が二重例外時にstd::terminate呼ぶのはGCのあるなしに 関係ないからスレ違いだお前ら。よそでやれ 215 名前：デフォルトの名無しさん [2015/12/06(日) 19:24:21.60 ID:XJADMoL5.net] GCというよりライブラリとの関係だな .net framework libraryのいくつかのクラスは中で自分自身をロックするから プログラマ側で参照が切れてもGCされない 216 名前：デフォルトの名無しさん [2015/12/06(日) 19:25:02.74 ID:XJADMoL5.net] 今日一日なんでFormがGCされないのか調べてて大変な思いしたわ 217 名前：デフォルトの名無しさん [2015/12/06(日) 19:31:56.53 ID:bkfT5adp.net] >>213 よくそこまで調べたな。( ・∀・)つ旦　お茶ﾄﾞｿﾞｰ 218 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 19:37:02.30 ID:Gxx7TgqC.net] いまだにプログラマはアセンブリ言語を使えるべきだ派？ 219 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 19:40:49.58 ID:JYyEEHci.net] アセンブラ知ってると知らないとじゃスキルレベル全然違うからな。話にならないぐらいのレベル差 220 名前：。 [] [ここ壊れてます] 221 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 20:22:00.43 ID:RyqEmv/A.net] まあ実際Java屋とかってコンパイラやメモリ意識できない奴多いよね 以前2chで↓みたいなコードが勝手に最適化されると思って StringBuilder使う奴は馬鹿！とか言い出す奴いて目眩したわ String s; for(int i = 0; i < strarray.length; ++i){ s += strarray[i]; } 222 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 20:58:14.61 ID:wxELMJDc.net] >>217 それはStringの+=の実装次第ではあんまり差が付かないケースなんじゃ… （左辺と右辺が別の実体である（アドレスが違う）ケースでは多分右辺を左辺の末尾に1回コピーするだけという実装が有り得る 真に糞なのは StringBuilder sb; String s = "Hello"; sb.Append("[" + s + "]"); が遅いからStringBuilderは糞、と結論付けるニンゲンであってコードではない、 みたいな？ 223 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 21:26:17.35 ID:IAFYzi6n.net] >>217みたいにループ中で一個づつくっつける場合は別にして s = a + b + c + d; // このように、高々数個をくっつけてる場合は Javaだと無駄にStringBufferが作られてダメと言うのが定説だったが C#の場合は内部的にString#Concatに置き換えられて それによって StringBuilder b = 略 s = a.Append(b)中略.Append(d).ToString() するより早い、という話題があってそれと勘違いしたのかもね 224 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 21:28:20.04 ID:IAFYzi6n.net] いちおう訂正しとこｗ StringBuilder sb = 略 s = sb.Append(a)中略.Append(d).ToString() 225 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 21:50:20.98 ID:MkaxAbH2.net] そもそもその最適化は仕様なのか 226 名前：デフォルトの名無しさん mailto:sage [2015/12/06(日) 22:27:08.91 ID:RyqEmv/A.net] >>218 ？？、これJavaだぞ。演算子オーバーロードなんて出来ないから >>219 違う違う。+の連結がStringじゃなくてStringBufferに 最適化されるらしいって話だけで、StringBulderって 必要ないでしょ？レガプロ？(笑)、って認識レベル しかもそいつ一人ならまだしもスレに同じレベルの 認識の奴結構多かったよ。レベルの低さ舐めたらあかんで 227 名前：デフォルトの名無しさん [2015/12/07(月) 01:50:02.58 ID:3Z+aJEnB.net] >>222 実装云々でなんで演算子オーバーロードがでてくるんだ？ 228 名前：デフォルトの名無しさん mailto:sage [2015/12/07(月) 05:22:13.32 ID:QznWTKRS.net] 逆だろ？ C#との勘違いでないなら、その最適化されるJVM実装とやらを示さないと 229 名前：デフォルトの名無しさん mailto:sage [2015/12/07(月) 07:11:57.22 ID:X5Y+ON7N.net] >>219 全く逆の認識してないか？ classファイル解析したら分かるけど、ループ中の+=の方が問題で毎回newされるから遅い s = a + b + c + d の方は一つしかStringBuilderのインスタンスは作られない 230 名前：デフォルトの名無しさん [2015/12/07(月) 08:02:18.14 ID:nEG5/lEo.net] こうやって、比較的プログラミングという行為を好きでいる・好きでやっている・興味を持っているという人ですらまともに言語仕様を理解出来ていない。 malloc、freeで管理、GCで管理だと、機構の複雑さは後者。 結局GCもその機構を正しく理解しないと参照が切れてない、参照が切れていても別のリソースが・・・と。 機構を正しく理解していることが前提なら、機構はシンプルなほうがいい。 その点を誤ったから >プログラマをメモリ管理から開放する！ >といいつつ、メモリリーク問題の文献が大量にある。 >これすなわち、メモリリーク問題が全然解決していないということ。 >さらに、メモリ解放のタイミングの文献まで大量に生み出した。 >これすなわち、新たなるメモリ管理に関する問題を生み出したということ。 なんてことになったんだろうね 231 名前：デフォルトの名無しさん mailto:sage [2015/12/07(月) 08:12:44.70 ID:EA ] [ここ壊れてます] 232 名前：/TwAsy.net mailto: そもそもプログラマの大半にマネージリソース、アンマネージリソースとはなに？ って質問してまともに回答できる割合がどんなもんになるのか 始めたら終わらせる これワンセットね にしたほうがミスはなくなるかと ファイル開いたら閉じる メモリ確保したら解放する 通信接続したら切断する [] [ここ壊れてます] 233 名前：デフォルトの名無しさん [2015/12/07(月) 09:22:45.43 ID:q5G1dKJA.net] やっぱりARC最強だな 234 名前：デフォルトの名無しさん mailto:sage [2015/12/07(月) 15:38:30.00 ID:6rSJBSiX.net] 結局いつ開放されるか分からないってのが曲者で 使い終わったら確実にリソースを開放してほしいときは 別の仕組みが必要になってしまったってのが問題だろう その別の仕組も、C++のデストラクタのようにクラスのメンバに関して 芋づる式に呼び出す仕組みがないから C++のデストラクタがやっていることを手動で再現しなければならない始末 一方でC++のスマポなどの参照カウンタ方式は循環参照だけが問題だが それ以外の問題が一切発生しない、デメリットは循環参照だけ しかも循環参照が発生する場合は片方をweak_ptrにすれば良い ということが分かりきっているし、循環参照が発生する箇所も 設計段階でわかる 循環参照に気を配れる知能が有るのであれば、参照カウンタ方式のほうがスマート 235 名前：デフォルトの名無しさん [2015/12/07(月) 17:29:26.60 ID:nEG5/lEo.net] >>229 処理速度やタイミングがシビアな組み込みや科学技術計算系とかならいざしらず、 ソレ以外は、実際の解放のタイミング自体は問題にならんでしょ。(膨大なメモリの使用も別だけど) 問題は、使い終わったよーって明示しないで良い。という運用が結局、悪い結果をもたらしているという点。 メモリの管理をしっかり最後までやるクセのないプログラマは、 平然と参照が途切れている可能性のあるポイントで参照しに行こうとする。 結局は、そいつがバカだからに集約されてしまうんだけど、使い終わりの明示をしない文化がバカを生む土壌となっている 236 名前：デフォルトの名無しさん [2015/12/07(月) 18:21:02.44 ID:q5G1dKJA.net] そういう事になる原因ってさ、構造がぐちゃぐちゃでオブジェクト間も依存しまくって、 いつ解放していいのかわかんねえーというヘボいプログラミングなんだろうなと思う。 237 名前：デフォルトの名無しさん mailto:sage [2015/12/07(月) 18:23:12.12 ID:tBfENkIS.net] と馬鹿なSEやPGはそう思うだろうなとも思う。 238 名前：デフォルトの名無しさん mailto:sage [2015/12/07(月) 19:54:31.23 ID:GogXEvJk.net] ある意味メモリなんて一番扱いやすいリソースだからな。 メモリの管理すら適当なプログラマが、他のリソースを適切に扱える訳がないのに、GC前提の言語ではそちらのケアが言語側でやりづらくなってしまっている。 239 名前：デフォルトの名無しさん [2015/12/07(月) 20:05:22.53 ID:W4QZalq7.net] メモリ意識した時点で雑魚プログラマ決定だろ。 JavaScriptもPascalも使えないんじゃ話にならないよ。 おちんぽ見られることを意識しすぎて温泉に入れないようなもの。 癒やしのない人生に刺激なんてない。←これ名言 240 名前：デフォルトの名無しさん [2015/12/07(月) 20:07:43.02 ID:nEG5/lEo.net] >>231 そう。そういう状態にしちゃう原因が、いい加減なメモリの管理で教育された結果にあるのではないか？ということで。 241 名前：デフォルトの名無しさん [2015/12/07(月) 20:09:47.14 ID:nEG5/lEo.net] >>234 だれの名言かしらんが、 刺激のない人生に癒やしはない。 ならなんかしっくりくる。まぁ逆とっても同じ意味だからいいんだけど・・・。 242 名前：デフォルトの名無しさん mailto:sage [2015/12/07(月) 20:16:31.05 ID:ZNsl6+sP.net] メモリ意識しないプログラマとかカスだろ。 243 名前：デフォルトの名無しさん mailto:sage [2015/12/07(月) 20:42:25.43 ID:wP/KA6jo.net] JavaやC#ではリソースをプログラマが管理してはいけない せっかくメモリ管理を透過的にしたのにリソース管理でコードをより複雑化させては意味がない 真っ当な教育を受けた少数のプログラマがSafeHandleを作成する 末端のプログラマはSafeHandleのファイナライザに全てを任せてメモリと同様にリソースを完全に透過的に扱うべきだ 244 名前：デフォルトの名無しさん mailto:sage [2015/12/07(月) 23:25:36.31 ID:QznWTKRS.net] >>230 JavaのGCでサーバー応答が止まるなんてザラにある話だよ それを聞いたことがないなら文系SEと同レベルだね >>238 管理放棄して開くだけ開いて計算資源を食い潰す玄人気取りプログラマ 245 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 00:48:22.00 ID:pyjW8EMu.net] full GCが頻繁に生じちゃうのは明らかに設計ミスやな immutableな短命objectを使いまくるのだ。。 つかimmutableなオブジェクト使いまくるとGCないときつくね？ 246 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 02:05:45.39 ID:H3TgUaFB.net] RAIIで事足りる immutableかどうかとＧＣは無関係 247 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 02:21:53.95 ID:RVFMry3L.net] むしろ短命なオブジェクトなんてスタックで十分だし 管理するならshared_ptrのが優れてる 248 名前：デフォルトの名無しさん [2015/12/08(火) 03:41:28.67 ID:pU1qoPPC.net] ライブラリ、アプリ、ユーザの三者で考えないと 一部リソースはユーザがを閉じることができる。 そのときアプリの参照を消す仕組みがどのライブラリにもない 249 名前：デフォルトの名無しさん [2015/12/08(火) 08:07:46.77 ID:rWJ9nJMw.net] >>243 よくわからんが、それは階層的におかしいのでは？ ユーザーがアプリを通さずにリソースを閉じる事ができるって事？ 250 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 12:16:07.11 ID:VV6tYNBF.net] Manager.Execute((res) => ...); これが終着点 短命なリソースは全てこの形式で事足りし長命なリソースはファイナライザにでも任せればよい ユーザーが管理しちゃ絶対にダメ 251 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 15:11:36.25 ID:DYNM3xm/.net] このスレでGCいらんて言ってる人たちは環境に恵まれてるんだなぁって思う 252 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 15:20:06.88 ID:Bkt0caBE.net] GC タモリが昔宣伝してやつ？ 253 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 15:28:54.90 ID:NMHe7TFl.net] むしろGCなんて環境良くないと使えないだろ 254 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 16:16:30.38 ID:zjJIjn6V.net] 参照がなくなったタイミングで必ず開放してくれて かつ 循環参照でも問題ない パーフェクトなGCが有れば最高なわけだが 実際にはそんなGCは無い となれば、通常であれば言語側は性質の異なる複数のGCを用意しておいて 使う側はシチュエーションに合わせて選べるようにしておくのが自然な発想 しかしそういう言語は殆ど無い、これが問題 といってもマークスイープ系GCが前提のC#やJavaのような言語に RAIIの発想を持ち込もうとしても C++のデストラクタのように自身のメンバのデストラクタを自動で芋づる式に呼び出す仕組みが 元々無いので、手動で芋づる式に解放関数を呼び出すコードを書かなければならなく うまく行っていない 255 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 16:25:08.60 ID:RVFMry3L.net] >>246 JavaでPhantomReferenceも使ったこと無い人って恵まれてるんだなあって思う >>249 無いのでってもろにAutoCloseableとかあるやん 256 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 16:37:24.80 ID:zjJIjn6V.net] >>250 自分のクラスがファイルなんかのcloseを持つリソースをメンバに持っていたとする そうすると、それらのメンバのリソースを明示的にcloseできるようにするために 自身もcloseを実装することになるだろう それで、自身のcloseが呼ばれた時、勝手にメンバのcloseが呼ばれるか？ 結局手動でメンバのcloseを呼び出しまわるコードを書かなければならない C++のデストラクタならメンバのデストラクタが芋づる式に勝手に呼び出されるから 気にしなくて良い 257 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 17:08:50.17 ID:NMHe7TFl.net] 強参照、ソフト参照、弱参照、ファントム参照 この字面だけで糞言語って察せられるから凄い 258 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 19:22:21.31 ID:RKxPG6yJ.net] Rustはどう？ 明文化されたmoveセマンティクスと、オブジェクトの寿命と参照のチェッカを型システムに組み込んでるおかげで、 リソース管理の実行時コストをゼロにしつつ、メモリリークが発生しないプログラムが書ける。 shared_ptrに相当するRcもあるから、所有者を複数にしたい場合のコストもそれなりに抑えられる。 259 名前：デフォルトの名無しさん [2015/12/08(火) 19:35:14.32 ID:Hrv9Cion.net] >>253 すげえ難しいらしいじゃん 260 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 19:52:40.51 ID:NMHe7TFl.net] rustの清貧さは好みだけどまだ触った事ないな 同期処理を省略するためかshared_ptr相当がタスク間跨げないらしいけど そこら辺の使い勝手ってどうなんだろう 261 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 21:00:06.21 ID:RKxPG6yJ.net] >>254 難しいのは難しいが、低レベルの世界に相応な難易度であって、理不尽さはあまり無いと思う。 自分が遭遇した理不尽というか不便は、トレイト(型クラスみたいなの)を戻り値にした、ジェネリックな関数の型注釈の煩雑さで、 そのworkaroundが、その関数の返り値専用の型を定義する、ってのがカルチャーショックだった。 https://doc.rust-lang.org/std/iter/trait.Iterator.html ↑はIteratorトレイト(Listインターフェイスみたいなもの)のドキュメントだけど、mapとかfoldとかよくある高階関数の戻り値が、それ専用の型(MapとかFold)になってる。 だから、よくある関数型言語のイメージで、何か高階関数を利用したアダプタ関数を試しに定義してみよう！ってやると、 型注釈のエラー、ライフタイムのエラー等が一辺に出てきてわけが分からなくなる。 その関数の戻り値専用の型、なんて贅沢に見えるけど、返り値のサイズを見る限り、余計なデータで膨れているわけでもなかった。 Cでstruct wrap_int { int c; };とやったときにsizeof(wrap_int)がsizeof(int)と等しいけど、それと同じことをやっていた。 型情報なんてコンパイル時に全部消えちゃうから、実行コストも無いんじゃないかと今では思う。 メモリ/リソースの所有権を意識してコードを書くこと、が身について面白いよ。 ヒープを贅沢に使ってコピーしまくりなコードを書くと汚いし遅いしなんで、ちょっとダイエットする気分も出てくる。 262 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 22:39:35.60 ID:RVFMry3L.net] >>251 C++もヒープ相手は自分で呼ぶので、実装は必要だよ Javaでもメンバの特定メソッド呼び出しはやろうと思えばできる 現実に横断的な呼び出しをやる場合はある 結局要求される物と実装の問題 263 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 22:59:22.32 ID:RKxPG6yJ.net] >>255 shared_ptrと恒等なものは無いけど、ポインタ的に使える型がBox, Rc, Cell(あるいはRefCell)とあって、 Boxはヒープ領域であること、Rcは複数の所有者がいる(つまり所有者全員が死ぬまでは生きている)こと、Cellは複数の書き込みが作れること、 とか機能とコストが別れているから、これらを組み合わせて使う。 で、Thread Safetyを実現させる機構は上記には無いので、Atomicityを導入させるRcの類似形であるArcと、 書き込みもしたいならMutexっていう型も合わせて使う。 すると、例えば整数のベクトルをスレッド間で共有したい、とかになるとArc<Mutex<Vec<i32>>>という目が滑るような型表記をすることになる。 あんま詳しくないので、ケース毎にもっと簡単なやり方があるとは思うんだけどね。 264 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 23:55:28.64 ID:NMHe7TFl.net] >>258 ああ、Arcってのが別にいるのね。納得 個人的にもう一点気になる所があるから聞いてしまう BoxやDropを使ってるとコピー禁止になるらしいけど これ面倒な場合ない？ 最初はコピー可能な型としてガンガンコピーしてたけど 途中から終了処理を書きたくなったらコピーしてる箇所 全部直すって事？ ちなみにググってたらRWArcっての見つけたんだけど これ読み書き可能なArcなんじゃね 265 名前：デフォルトの名無しさん mailto:sage [2015/12/09(水) 00:46:02.26 ID:WVnNYSfg.net] >>249 javaは世代別管理でGCの種類は色々選べるはずでは 266 名前：デフォルトの名無しさん [2015/12/09(水) 01:14:15.85 ID:wAGGTtTq.net] >>260 起動時に切り替えられるだけであって オブジェクトごとには切り替えられないのでは 267 名前：デフォルトの名無しさん mailto:sage [2015/12/09(水) 01:50:08.36 ID:x/ryIvcR.net] >>259 コピーしまくっているような変数の型をTからBox<T>に変えた場合、確かに面倒なことになる。 けど、基本的に単純な代入(let x = y)はコピーじゃなくてmoveになるし、 Box<T>の値をコピーしてBox<T>の値を生成するっていうのは、同じヒープ領域を指すポインタを作るんじゃなく、 新しいヒープ領域を確保して中身をコピーし、そのポインタを返すという意味なんで、 変数の型を後でTをBox<T>に変える、という場面はあまり無い(少なくとも自分は学んでいる最中にそういうことをしたくなったことがない) 値をコピーする場面では、元の変数の型がBox<T>であってもTであっても、参照型&Tを受け取ってTを生成、ということをするのが定石。 &Tはほぼ無制限に安全に作ることができるし、安全じゃない可能性があったらコンパイルが通らない。 で、コピーした型Tの値は呼び出し元がBoxに包んでヒープ領域に置いたりするのが定石 Dropも別にコピーを禁止することは無いよ。後からつけたらエラーまみれ、ということにはならない。 あと、自作じゃない型に自作じゃないトレイト(インターフェイスみたいなもの)をつけることができないので、 例えば標準ライブラリのFileやTcpStreamはCopyできるようには決してできない。メモリ以外の資源管理も安全だよ。 268 名前：デフォルトの名無しさん [2015/12/12(土) 10:36:13.53 ID:mXWFWn5f.net] freeし忘れるとか、そんな超ウルトラ素人ミスを大前提に議論するのは間違いだよなｗ freeしきれないとかｗｗｗｗ 269 名前：デフォルトの名無しさん [2015/12/12(土) 11:52:29.69 ID:v/VbuB+R.net] >>263 規模が大きくなれば管理が難しくなるのは普通のことだよ。 ライフサイクルはオブジェクトごとに異なるものだし、 人間に頼らずにGCにメモリ管理を任せるっていうのは良いやり方だよ。 270 名前：デフォルトの名無しさん mailto:sage [2015/12/12(土) 12:05:07.06 ID:yfUf7LLZ.net] shared_ptrって参照カウント式のGCじゃないの？ 271 名前：デフォルトの名無しさん mailto:sage [2015/12/12(土) 12:44:09.71 ID:7G0ybzbE.net] 循環を綺麗に扱えるなら参照カウントの方が良いと思うけど VB6は循環参照の扱いどうやってるんだろう 272 名前：デフォルトの名無しさん mailto:sage [2015/12/12(土) 14:25:51.97 ID:npRd3MLZ.net] >>265 RAIIじゃろ 273 名前：デフォルトの名無しさん mailto:sage [2015/12/12(土) 15:20:38.55 ID:tVgJgcBS.net] >>265 GCの一種だけど、文脈的にはプログラマが 管理が非局所的で明確な型宣言もなしに使えるのをGCと言ってるわけで 議論で揚げ足にしかならない野暮な突っ込みはやめようぜ 274 名前：名無しさん＠そうだ選挙に行こう [2015/12/14(月) 08:16:09.53 ID:hn3965Zz.net] >>264 いや、下手って一言で片付けられるよ。 よっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっぽど、出ない限り 275 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 08:38:44.84 ID:sXTPVO5Q.net] 片付ける奴が馬鹿なのだ。素人ほど簡単だと言いたがり、上級者ほど簡単ではないとはっきり言うものだ。 どの分野でもな。 276 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 09:09:02.89 ID:lNUL9lX8.net] freeとか言ってる奴はC++使えよ。いつまでＣ使ってんだ。 277 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 09:20:53.11 ID:MauTQhQ/.net] >>270 東大生が人に教えるとき、何がわからないのかわからないというのがわからない。 上級者になればなるほど自分がやってることなんて簡単に見えてくる 278 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 09:35:23.70 ID:sXTPVO5Q.net] >>272 何が分らないか分らない、つまり東大生も生徒がどういう思考をしてるか分析できず分らないと言ってるのだ。 低学歴ほど、分らないのはおまえが馬鹿だからと簡単に片付けるものだ。 279 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 09:37:05.77 ID:eBJzgHzn.net] それ中級者 あと、東大生は教えるの上手いのもいるから想像で話すな馬鹿 280 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 09:41:37.74 ID:sXTPVO5Q.net] このようにおまえのようなコンテキストすらまともに読めないPGは五万といる。 スレッドがデッドロックしてメモリを開放できないなんてよくあることだ。 281 名前：名無しさん＠そうだ選挙に行こう [2015/12/14(月) 10:59:16.82 ID:hn3965Zz.net] >>275 。。。。。完全な設計ミスじゃん 282 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 11:15:19.23 ID:eBJzgHzn.net] >>275 俺は272に向けてたんだが そりゃコンテキスト読めてないように見えるよなw 283 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 11:40:27.14 ID:ETDpPCfc.net] スレッドがデッドロックしたらメモリリークどころじゃないじゃないかwww 284 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 14:48:51.74 ID:MOnxQz3f.net] スレッドがデッドロックしちゃってメモリ解放できない（泣） っていうPGが五万といるのかよｗ 285 名前：名無しさん＠そうだ選挙に行こう [2015/12/14(月) 15:51:19.55 ID:hn3965Zz.net] まぁfreeやdeleteやnullやらすらできないPGに、「僕はそんなこと管理しきれる脳みそ持ってない！」って言われたらソレは真実なんだろうけど・・・。 そんな脳みそPGに「もっと複雑な業務使用」を理解できるとは思えないんだ。 そんなPGにプログラミングの場を与えるのが間違い。 286 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 15:58:21.86 ID:2JSVZtRY.net] そもそも実務でスレッド使うＰＧなんてゴマンもいない 287 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 17:06:58.52 ID:eBJzgHzn.net] Javaのプロジェクトだとほぼ使ってるけどな隠蔽してるだけで そのせいで共有リソース壊したり、逆に個人情報の領域が共有されたりして、とんでもないインシデントが発生する そんな奴等にメモリ管理なんて任せられんし、共有リソースも触らせたくないから 更に隠蔽したフレームワークもどきが出来上がる 288 名前：名無しさん＠そうだ選挙に行こう [2015/12/14(月) 17:59:33.07 ID:hn3965Zz.net] >>282 勝手に使うな。勝手にトリッキーコードにすんな。 素直に、設計書通りに作れ。 勝手なことやって勝手に自爆してるだけじゃねーか。 289 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 18:15:27.90 ID:Z4FycFda.net] javaってc++のconst参照に対応するものが無いのに、素人みたいなプログラマを大量にかき集めているのが怖すぎる。 290 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 18:28:13.63 ID:eBJzgHzn.net] >>283 理解してないのに無理してレスしなくていいから 291 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 18:42:08.38 ID:CJqGCki1.net] C#はマルチスレッド使いまくりだけど事故の話はあまり聞かないな マイクロソフトが優秀なのか低品質プログラマがいないのか 292 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 19:01:59.11 ID:2+GDL4RD.net] JAVA自体がDQN 293 名前：uy ◆Qawu9.2l1E [2015/12/14(月) 20:57:26.55 ID:J5PYIleC.net] Freeし忘れ ↑これ。 ソースコード書いてる人間の注意力次第でバグが入るなら 言語も設計も間違ってるよ 294 名前：デフォルトの名無しさん mailto:sage [2015/12/14(月) 21:54:10.80 ID:ETDpPCfc.net] 動的型言語 ↑ これ コード書いている人間の注意力次第でtypoするだけで 実行するまでわからないバグが入るなら 言語も設計も間違ってるよ 295 名前：デフォルトの名無しさん mailto:sage [2015/12/14(月) 22:23:00.81 ID:lNUL9lX8.net] C#でcatchやfinally書くの嫌すぎる C++に戻りたい 296 名前：デフォルトの名無しさん mailto:sage [2015/12/14(月) 22:43:08.79 ID:bhzmg0NL.net] >>290 おかえり 297 名前：デフォルトの名無しさん mailto:sage [2015/12/15(火) 06:39:51.52 ID:gQhFMQgY.net] (ヽ´ω`)眠い 298 名前：デフォルトの名無しさん mailto:sage [2015/12/16(水) 08:46:15.45 ID:fgV80IeN.net] >>290 C++/CLR「こっちこいよ」 299 名前：デフォルトの名無しさん [2015/12/17(木) 17:18:40.36 ID:Szn4FINI.net] COMのVariantとかJSとかリークしまくりだし 300 名前：デフォルトの名無しさん mailto:sage [2015/12/17(木) 23:16:36.40 ID:kltDf5Nv.net] そういやVBScriptって参照カウンタ以外のGC積んでんのあれ 必要には見えないんだけど 301 名前：デフォルトの名無しさん [2015/12/18(金) 23:17:49.50 ID:b1Otx84Y.net] プログラマはMacを使ってるってマジ？ hayabusa3.2ch.net/test/read.cgi/news/1450395043/ 302 名前：デフォルトの名無しさん mailto:sage [2015/12/19(土) 07:07:37.11 ID:qL4RiVer.net] マカーってどんだけアホなの？ 303 名前：デフォルトの名無しさん [2015/12/19(土) 12:49:09.79 ID:EW8XrhCB.net] 解放処理 すら、まともにお前ら管理できねーのかよ・・・・・・・・・・・・・・・・。そらオレが完璧な仕様書渡してもバグってるわけだ 304 名前：デフォルトの名無しさん mailto:sage [2015/12/19(土) 13:38:07.82 ID:i3zp3GbO.net] 開放処理を手動でやれって書いてある仕様書かw 御免こうむるwwwww 305 名前：デフォルトの名無しさん [2015/12/19(土) 14:42:49.35 ID:iG82T79N.net] ガベコレのあるPyObjectをラップするクラスをガベコレのあるDで書いたら wxPythonで書いたクラスをDから使ったとき意味不明なタイミングで落ちるようになった 二重に管理するとだめなんかな 306 名前：デフォルトの名無しさん [2015/12/19(土) 15:57:38.71 ID:qL4RiVer.net] >>298 ﾌﾟﾌﾟﾌﾟ　馬鹿だこいつw 307 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 08:46:23.14 ID:gr0U1KS4.net] ガベージコレクションはたしかに便利だ だからといって「本来はてめぇのケツはてめぇで拭け＝自分で解放すること」を忘れてはならない そんだけ 308 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 11:55:11.08 ID:HXRBhwTH.net] C#ではSafeHandleだけ作って後は放置 usingも使わないってのがトレンドだけどね 自分で解放とかバカバカしい 面倒はランタイムに見させて開発者はドメイン設計に集中するって目的を見失うな 309 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 12:13:23.36 ID:ofrSOHxv.net] >>303 オブジェクトの開放を他と独立にやれるケースばかりならそう言えるかもしれんが オブジェクトAとBがリソースCに依存しているケースでA、Bの開放の少なくとも片方をGCに任せる場合、 リソースCの参照カウンタなりをつかった防護策をプログラマーが書かねばならない しかしそんな嫌ったらしい雑用を増やすぐらいなら 　Cオープン 　A生成 　B生成 　A, B使用 　B開放 　A開放 　Cクローズ でええやん？ さらにダンプファイルとかからの障害解析において、オブジェクトが生きているべきなのか死んでいるべきなのか決まっていないとか、 アドレスがはっきりしないとか言う状況は地獄 310 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 12:21:54.48 ID:ofrSOHxv.net] つかこの世はうつろうもののであって、物理的ハードウェアでプログラムを実行する限り、 計算モデルは明らかに状態遷移ベース（チューリングマシン）の方に分がある GCとかチューリングマシンで無理矢理関数型プログラミングを行うためのつなぎの技術、 いわば邪道 どんだけ蛇が出てくるか、GCの方がかえってわからん 311 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 13:48:14.94 ID:HXRBhwTH.net] >>304 設計が悪い 使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない 知らなきゃ困るような設計にしたのが間違いだね 312 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 13:52:55.68 ID:8RLYRFXT.net] メモリ空間は無限であるべき 使い終わったメモリの断片化なにそれ？ 仮想メモリを管理するのはCPUの責任だろ 313 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:03:49.29 ID:ofrSOHxv.net] >>306 >>304の例で、さらにCを上書き更新したいオブジェクトDがいたらどうすんの？ GCがA、B両方開放してくれるまでDは期限不定で待たされるけどそれが>>306的に良い設計なの？ つまり、ハードウェアリソースの有限性を考慮する限り >使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない が常に成立はしないという話 314 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:28:20.48 ID:i39XsMQ2.net] >>308 そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？ 意見を否定するためだけの極端な反例(この場合は例にすらなっていないが)を引き合いに出すのは不毛だよ 315 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:35:53.96 ID:xl2QwS3M.net] >>303 いい加減だなぁw 316 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:36:58.02 ID:ofrSOHxv.net] >>309 >そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？ 極論なもんｶﾖ； 例：　表示デバイスの数＞表示したいスレッドの数 というのはざらにある で、>>308のオブジェクトDのケースはどう解決すんのさ… GCが「いつ開放してくれるかわからない」ブツである以上解消しない問題だとおもうんだけど （A、BにCのための明示的closeメソッドを付けるぐらいならGCに頼らずに順序管理するわ； 317 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:42:20.07 ID:ofrSOHxv.net] 解決策の一つはActive ObjectパターンでリソースCの管理を1スレッドXにやらせて Cに対する要求を全部Xのキューにシリアル化して入れさせるというのがあるが、それはそれで リソースCを使う全てのオブジェクトがスレッドXに依存するから、Xの開放コードが面倒なことになりかねない かつ、シリアル化はマルチコア時代のせっかくの並列実行性能を殺してしまう GCに合わせて生きることは、神仙にでもならねば到底かなわぬ… 318 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:44:35.05 ID:ZDEpjFBd.net] つくづく、ARC最強だな。 319 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:46:27.58 ID:i39XsMQ2.net] >>311 その例じゃ308の状況にならないよ どんなコード書いてんだよw 320 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:48:11.36 ID:ofrSOHxv.net] >>314 >その例じゃ308の状況にならないよ なんで？ビデオメモリに2スレッドから同時に書いて無事に済むと思ってるの…； 321 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:51:52.93 ID:i39XsMQ2.net] だから同時に書く設計が悪いんだって 気合入れて設計を見直してみろ そんな必要はないってわかるから 322 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:55:30.48 ID:ofrSOHxv.net] ていうか>>316の言っていることはますます矛盾で、 >同時に書く設計が悪い >そんな必要はないってわかる というのは明白に「書き込みの順序を設計できる」ということを言っていて、 それはその通り（チューリングマシンの計算モデルに合致する）ので別段漏れの立場と対立するものではなく、 かつ気合を入れて設計すれば順序で全て解決する（GCは不要である）という言明でもある 323 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 15:17:45.93 ID:14eB8c4R.net] >>315 もはやGCがどう関係するのかわからない 324 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 15:20:28.11 ID:i39XsMQ2.net] >>318 彼は敵対意見に反論する材料が欲しいというだけで変な例をでっち上げて出してしまったんだ 本人も今頃困ってるんじゃないかな 325 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 17:05:42.48 ID:6vo8OCaj.net] >>319 >>308を変な例変な例というばかりでGCを用いた正しい解決方法が一向に示されない件について： 繰り返しになるが、>>308のオブジェクトDのケースはどう解決すんのさ… たとえ変でも反例は反例だし >>308のリソースCがファイルなのだとしたら、病的な反例というほど例外的想定でもない 読み書き順序の設計の必要性（破壊的代入前提のプログラミング）を口にしつつ >使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない （>306） と言い切ることはできないとかそういう話 で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306) >>318 ウィンドウシステムでの描画は一般に裏VRAMに描いてハードウェアでBitBlt転送するが 裏VRAMに書く際のデバイスコンテキストが複数使えるが数に限りがある場合… とか細かい話をしても通じないようならリソースCをファイルと考えてくんな 326 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 17:12:24.84 ID:6vo8OCaj.net] ﾌﾟﾁ訂正 誤: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306) 正: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>308) 327 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 17:19:25.13 ID:HXRBhwTH.net] 読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る 書き込みたいから読み込み終わるの待ってますってリソースの無駄だろ 328 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 17:21:31.86 ID:ZDEpjFBd.net] なんか参照カウントの話とマルチスレッドの話がごっちゃになってね？ 329 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 17:33:49.10 ID:6vo8OCaj.net] >>322 >読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る 破壊的代入の世界ではそいつは常に可能とは限らない >308の例で、リソースCがファイルXなのだとしたら、オブジェクトDが上書きすべきもあくまでファイルXでないといけない。 つまりリソース分離の余地など無い （正確には、無理矢理ファイルA、BはファイルX、DはファイルYに分ける設計もありえるが、XとYに対する変更をいつどのように統合するかという超難題が生じる この手の混乱は、A、BがアクセスするリソースCの開放タイミングの決定をGCに任せてサボったがために生じるのである 330 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 18:10:09.92 ID:ZDEpjFBd.net] おいおい、バージョン管理のマージの話にまで拡張したら収集つかなくなるぞw 331 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 19:32:49.85 ID:i39XsMQ2.net] >>324 ファイルの分割は必ずしも必要ではないし更新モデルから読み取りモデルへの同期も必要ないよ 332 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 19:44:06.53 ID:9YX+2XWA.net] >>323 (Rust信者で)すまんな。 ttp://smallcultfollowing.com/babysteps/blog/2015/12/18/rayon-data-parallelism-in-rust/#data-race-freedom マルチスレッドで起きるデータ競合といった問題も、シングルスレッドで起きうるdangling pointerなどの問題も、 どっちも所有権を持つオブジェクトが無闇にいたり、変な参照関係があるから起きるんじゃないか？って言う人がおる。 根っこが同じ、あるいは近しい問題なんで、横滑りに見えても堪忍な。 333 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 19:49:46.85 ID:kaqci566.net] メモリ管理もできないんだから データの依存関係とか関係ねえ〜〜〜〜〜〜〜〜〜〜〜〜 でおわりでは 334 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 05:26:25.94 ID:ejqZ3DMD.net] GoogleChrome動作中のタスクマネージャーのイメージ名にsvchost.exeが見当たらない GoogleChromeでは、svchost.exeを使用せずに、chrome.exe自身で制御しているらしい Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36 Width/1360px/1920px 335 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 05:32:28.99 ID:ejqZ3DMD.net] その理由・・・GCは失敗。メモリは自分で管理せよ！ peace.2ch.net/test/read.cgi/tech/1447856699/l50 336 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 05:35:31.18 ID:ejqZ3DMD.net] メインメモリに対するGC・・・MGC HDDならストレージGC・・・SGC 337 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 05:38:11.78 ID:ejqZ3DMD.net] GoogleChromeかsvchost.exeを使わなくなった理由・・・ページメモリGC制御が遅過ぎでお粗末だからか？ 338 名前：デフォルトの名無しさん mailto:sage [2 ] [ここ壊れてます] 339 名前：015/12/21(月) 05:42:27.02 ID:ejqZ3DMD.net mailto: GoogleChrome動作中のタスクマネージャーのイメージ名にsvchost.exeが見当たらない GoogleChromeでは、svchost.exeを使用せずに、chrome.exe自身で制御しているらしい Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36 Width/1360px/1920px [] [ここ壊れてます] 340 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 05:45:15.43 ID:ejqZ3DMD.net] 「Svchost Process Analyzer」 svchost.exeのプロセスの中身が何かを調べて表示するフリーソフト gigazine.net/news/20131114-svchost-process-analyzer/ 341 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 05:51:39.30 ID:ejqZ3DMD.net] そろそろsvchost.exeを使うソフトは使用禁止なのかも？ 342 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 06:11:17.64 ID:ejqZ3DMD.net] svchost.exeを使わないことでGoogleChromeは確実に応答性能が速くなって� 343 名前：｢る ・・・動画マルチ再生でクラッシュしたFirefoxは見習うべき [] [ここ壊れてます] 344 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 06:17:26.48 ID:ejqZ3DMD.net] 残念だがスリープだ！ 　 pds.exblog.jp/pds/1/201104/11/06/e0026606_2391337.jpg i.imgur.com/qrjJDgC.jpg 345 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 06:40:32.08 ID:ejqZ3DMD.net] Wave aurorawave.atspace.tv/?sop:v/jfgn-S6JzfM!RDtSvhh7Sq1OU i1.ytimg.com/vi/jfgn-S6JzfM/mqdefault.jpg #AuroraWaveTV 346 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 06:42:41.39 ID:ejqZ3DMD.net] LG OLED TV : You Dream We Display aurorawave.atspace.tv/?sop:v/VenG8TF90yA!RDVenG8TF90yA i1.ytimg.com/vi/VenG8TF90yA/mqdefault.jpg #AuroraWaveTV 347 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 06:43:24.61 ID:ejqZ3DMD.net] LG OLED TV - The Ultimate Display aurorawave.atspace.tv/?sop:v/JubFjalfNIY!RDJubFjalfNIY i1.ytimg.com/vi/JubFjalfNIY/mqdefault.jpg #AuroraWaveTV 348 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 07:08:24.86 ID:ejqZ3DMD.net] LG 4K OLED: Paris and Chicago aurorawave.atspace.tv/?sop:v/Hi_WWhih4n4!RDHi_WWhih4n4 i1.ytimg.com/vi/Hi_WWhih4n4/mqdefault.jpg #AuroraWaveTV 349 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 09:26:05.64 ID:ejqZ3DMD.net] 国別ISO登録件数　⇒　技術マフィア　⇒　技術流出状況　　　 www.jicqa.co.jp/09info/07newsletter/2012/no168_news1201.html www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1741.JPG www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1818.JPG www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1742-a.JPG www.google.co.jp/search?q=ISO%E6%9C%AC%E9%83%A8&num=100&ie=utf-8 pds.exblog.jp/pds/1/200909/06/87/a0137487_22475768.jpg 350 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 09:41:02.29 ID:ejqZ3DMD.net] 中国、ダークマターの検出に挑む探査衛星「悟空」を打ち上げ news.mynavi.jp/news/2015/12/17/495/ n.mynv.jp/news/2015/12/17/495/images/001l.jpg n.mynv.jp/news/2015/12/17/495/images/002l.jpg n.mynv.jp/news/2015/12/17/495/images/003l.jpg 351 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 09:44:40.17 ID:ejqZ3DMD.net] 京がお仕置き候補に??? gigazine.net/news/20130618-fastest-supercomputers/ ◆1位：Tianhe-2(天河二号)、中国人民解放軍国防科学技術大学 i.gzn.jp/img/2013/06/18/fastest-supercomputers/01_m.jpg IntelのIvy Bridge(12コア・2.2GHz)とXeon Phi(57コア・1.1GHz)を採用し、 コア数は312万、計算速度は33.9ペタフロップス、消費電力は17.8MW ◆2位：Titan、アメリカのオークリッジ国立研究所 i.gzn.jp/img/2013/06/18/fastest-supercomputers/02_titan2_m.jpg AMD Opteron 6274(16コア・2.2GHz)とNvidia Kepler(14コア・0.732GHz)を採用し、 コア数は56万640、計算速度は17.6ペタフロップス、消費電力は8.3MW ◆3位：Sequoia、アメリカのローレンス・リバモア国立研究所 i.gzn.jp/img/2013/06/18/fastest-supercomputers/03_8716842181_3f50ae207a_o_m.jpg IBM BlueGene/Qを採用し、中のプロセッサーはPower BQC(16コア・1.60GHz)、 コア数は157万2864、計算速度は17.2ペタフロップス、消費電力は7.9MW ◆4位：スーパーコンピュータ京、独立行政法人理化学研究所 計算科学研究機構(AICS) i.gzn.jp/img/2013/06/18/fastest-supercomputers/04_01_m.jpg 富士通 SPARC64 VIIIfx(8コア・2.0GHz)を採用し、コア数は70万5204、 計算速度は10.5ペタフロップス、消費電力は12.7MW ◆5位：Mira、アメリカのアルゴンヌ国立研究所のエネルギー部門 i.gzn.jp/img/2013/06/18/fastest-supercomputers/05_30292D004-72dpi_m.jpg BM BlueGene/Qを採用し、中のプロセッサーはPower BQC(16コア・1.60GHz)、 コア数は78万6432、計算速度は8.6ペタフロップス、消費電力は3.95MW 352 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 09:50:17.19 ID:ejqZ3DMD.net] 気づかないかISOは中国のためにある www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1742-a.JPG 353 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 10:45:57.17 ID:1HvlxK+M.net] >>344 蓮舫さんに次の選挙は次点で良いですよねって言ってきて 354 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 11:12:03.51 ID:1HvlxK+M.net] >>336 ほんそれ 355 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 12:31:40.33 ID:ejqZ3DMD.net] https://ja.wikipedia.org/wiki/%E8%93%AE%E8%88%AB 356 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 12:34:04.50 ID:ejqZ3DMD.net] https://www.google.co.jp/search?q=%E3%81%BB%E3%82%93%E3%81%9D%E3%82%8C 357 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 12:36:38.19 ID:x6st9rMu.net] ただしChromeはプロセスが一杯できるから タスクマネージャ覗いた時に気持ち悪い 358 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 16:06:45.56 ID:ejqZ3DMD.net] 64の時代だから、そろそろCore64ぐらいでイイのでは？ blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/3568.Windows_2D00_7_2D00_CPU_2D00_Usage_2D00_History_5F00_3E37E697.png download.intel.com/newsroom/kits/xeon/phi/gallery/images/XeonPhiDie_02.jpg 359 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 16:21:26.45 ID:ejqZ3DMD.net] ラーメン www.chikuwachan.com/ramen/ www.chikuwachan.com/ramen/image/ramen/1430/10_417_512.jpg 360 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 16:33:49.61 ID:ejqZ3DMD.net] www.dospara.co.jp/ad/stick_mv.html www.dospara.co.jp/ad/img/stick_mv/title_main.gif 361 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 16:35:11.77 ID:ejqZ3DMD.net] diginnos stickpc_02 www.youtube.com/watch?v=OPt0OGNQhnU&list=RDOPt0OGNQhnU 362 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 18:37:51.00 ID:ejqZ3DMD.net] Holiday Glam aurorawave.atspace.tv/?sop:v/tEdxHgCoXss!RDtEdxHgCoXss i1.ytimg.com/vi/tEdxHgCoXss/mqdefault.jpg #AuroraWaveTV 363 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 18:38:29.84 ID:ejqZ3DMD.net] Midnight Luster aurorawave.atspace.tv/?sop:v/DBTd9qv_sJI!RDDBTd9qv_sJI i1.ytimg.com/vi/DBTd9qv_sJI/mqdefault.jpg #AuroraWaveTV 364 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 18:43:07.58 ID:ejqZ3DMD.net] Chromeの調子が良い件について・・・TCL 4K Demo: Ultra-Running Beauty aurorawave.atspace.tv/?sop:v/Gg54Miwa8K4!RDHi_WWhih4n4 i1.ytimg.com/vi/Gg54Miwa8K4/mqdefault.jpg #AuroraWaveTV 365 名前：デフォルトの名無しさん [2016/01/10(日) 12:45:59.41 ID:LOFSek54.net] 723 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:24:00.06 ID:rlcuxF0A0 Vivaldiの起動が遅いのは タブのサムネイルに関係しているかもしれない Blinkは負荷分散のため？かHDDアクセスも遅いらしい ローカルストレージ関係がとても遅いからだ 724 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:31:29.50 ID:rlcuxF0A0 タブサムネイルを ローカルストレージで保存するのは止めたほうがいい タブサムネイルは直接アクセスする事 fopen();ランダム書込:fclose();ランダム読込:fopen(); 読取だけならオーバーヘッドを避けるためfopen();しない 725 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:33:41.35 ID:rlcuxF0A0 命題・・・Vivaldiは遅い起動を早期解消せよ！ 726 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:37:50.17 ID:rlcuxF0A0 ランダム書込用HDDスペースを作る　個数*固定サイズ　 １トランザクション　個数1024個、固定サイズ256kバイト　 727 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:40:34.65 ID:rlcuxF0A0 そしたら、ランダム読み書きでfopen()すればいい オーバーヘッドを避けるためfopen();は終了のときだけ オーバーヘッド無いだけで1000倍ほど速くなるケースも 728 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:44:26.42 ID:rlcuxF0A0 オーバーヘッドはドコにあるのか？ それはWindowsOSのフォルダ構造検索にある フォルダ構造検索回数を省けば速くなるのだ 366 名前：デフォルトの名無しさん [2016/01/10(日) 12:47:28.36 ID:LOFSek54.net] Vivaldiの起動が遅いのは タブのサムネイルに関係しているかもしれない Blinkは負荷分散のため？かHDDアクセスも遅いらしい ローカルストレージ関係がとても遅いからだ タブサムネイルを ローカルストレージで保存するのは止めたほうがいい タブサムネイルは直接アクセスする事 fopen();ランダム書込:fclose();ランダム読込:fopen(); 読取だけならオーバーヘッドを避けるためfopen();しない 命題・・・Vivaldiは遅い起動を早期解消せよ！ ランダム書込用HDDスペースを作る　個数*固定サイズ　 １トランザクション　個数1024個、固定サイズ256kバイト　 そしたら、ランダム読み書きでfopen()すればいい オーバーヘッドを避けるためfopen();は終了のときだけ オーバーヘッド無いだけで1000倍ほど速くなるケースも オーバーヘッドはドコにあるのか？ それはWindowsOSのフォルダ構造検索にある フォルダ構造検索回数を省けば速くなるのだ 367 名前：デフォルトの名無しさん [2016/01/10(日) 12:52:32.51 ID:LOFSek54.net] fopen();のときフォルダ構造検索するようだ 368 名前：デフォルトの名無しさん [2016/01/26(火) 06:48:44.23 ID:v48l+1vS.net] やっとこの気色の悪い仕組みにトドメが刺されたか javaとかGCが基本だけどflash();とかできるの？ 369 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 07:35:03.77 ID:RBo8KHcc.net] ゴミ言語は所詮ゴミ 370 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 17:10:09.80 ID:eULyfEEH.net] GCのすべてを否定するつもりはないけど・・・ GCはメモリ管理を自動化する技術だけど、今のコンピュータはメインメモリを何十ギガ積んでたりするのも普通で メインメモリが足りなくなることはほぼ無くて、しかも仮想メモリもあるから、なおさらメモリは潤沢で・・・ むしろメインメモリ以外のリソースの方が余程貴重で、もし仮にメインメモリが足りなくなるまで GCを発動しないアホなGCが有ったとしたらメインメモリより先に他のリソースが枯渇する状況 だからメインメモリは無駄遣いしてもよいけど、他のリソースは使い終わったら こまめに開放しないとダメだから、いつ実行されるか分からないマークスイープ系GCの余計にRAIIな仕組みも必要なわけ しかしこのRAIIが付け焼刃でなまっちょろい出来だったりする C#で言えばDisposeが有るけど、C++のデストラクタのように特別扱いされておらず ただの普通の関数でしかないので、C++のデストラクタみたいに自身のメンバ変数について 自動で芋づる式に呼び出してくれない だから手動でメンバのDisposeを芋づる式に呼び出すコードを記述しなければならない いちいち自身のメンバ変数にIDisposableなものが有るか無いか調べるのもひと手間かかるし もしそうだったら自身もIDisposableにする必要があり、例の一連のイディオムを書かなければならない 当たり前にDisposeの呼び出し忘れが有ってもいけない まるで、mallocしたらfreeするのと似ている しかもIDisposableはコンポジションで増殖する IDisposableなオブジェクトをコンポジションしたら、自身もIDisposableといった具合 C#のようにコンパイラマジックでなんでも実現する言語で どうしてDisposeをC++のデストラクタみたいに特別扱いしなかったのか謎だ 371 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 17:24:38.54 ID:eULyfEEH.net] 謎だといったが、理由ははっきりしていて メンバのDisposableを自動で呼び出す為には 他で使われてないことを保証する必要があって 参照カウンタ方式のようにローコストなものなら簡単に分かるが これでは循環参照の問題が出る プログラマが循環参照を気にしなくてもよいことが前提の マークスイープ系のGCを搭載した言語では設計思想が破たんするので 参照カウンタ方式は採用できないし マークスイープ系GCでは何処からも参照されていないことがローコストに分からないので 自動でDisposeを呼び出す仕組みを用意できない どうにもならない 結局C++の方式が一番優れている 循環参照が発生する場合はweak_ptrを使う事だけ注意を払えば GCにまつわる他の問題が一切発生しない 372 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 17:46:52.79 ID:eULyfEEH.net] もっと言えばC#でDisposeを実装する場合でも↑は問題になる 自身のメンバのDisposeを呼んでよいのかどうなのか 完全に自分しか使ってないことが分かっているのであればDisposeを呼び出して問題ないが あちこちから参照されている可能性があるメンバなら勝手にDisposeを呼び出してはいけない GC任せにするか、自分で参照カウンタを実装するか どちらにせよ、RAIIと相性が悪い 373 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 17:58:09.12 ID:aloDWtjb.net] 前から何度も言ってるがDisposeの実装はしていいが呼び出しは禁止 これがC#では基本だからね リソースの使用効率が悪いとか軟弱な反論をするバカがたまにいるが 実行効率気にするならそもそも別の言語使えって話になるからな C++CLIを使えってこった 本質を見誤るなよ 374 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 18:38:52.76 ID:XmqLFQFE.net] c#の欠点はデストラクタが呼び出されるタイミングが分からないこと。 不便で仕方ないや。 375 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 18:56:08.53 ID:VDkVQpP+.net] 最近VB.NETを使い始めたんだけど new したオブジェクトが不要� 376 名前：ﾉなった時にDispose()よんだり参照にNothing代入する必要ってない（やってもいいが無意味・無駄）なのかな？ [] [ここ壊れてます] 377 名前：デフォルトの名無しさん mailto:sage [2016/01/28(木) 08:05:17.75 ID:oip5UtLa.net] c++のデストラクタは例外投げられないウンコ仕様 だから皆デストラクタ内で発生したエラーは握り潰してる 他の言語はあんなバカなの真似する必要ない 378 名前：デフォルトの名無しさん mailto:sage [2016/01/28(木) 17:53:06.50 ID:M0BYpVOa.net] デストラクタで投げるなよ。迷惑な奴だな。 379 名前：デフォルトの名無しさん mailto:sage [2016/01/28(木) 18:02:00.92 ID:xwQj4KRs.net] javaはファイナライザで発生した例外は握りつぶすことが仕様で決まっているな。 c++の場合は、デストラクタでどうしても例外を外に伝えたかったらやりようはある。 380 名前：デフォルトの名無しさん mailto:sage [2016/01/30(土) 01:11:50.31 ID:QZN0GaAw.net] そら伝えたかったらやりようはいくらでもあるでしょう？C++に限らず 381 名前：デフォルトの名無しさん [2016/02/10(水) 11:29:59.19 ID:lL2Wg2mH.net] Javaは強制的に解放させることもできるようにすべきだったな。 382 名前：デフォルトの名無しさん mailto:sage [2016/02/10(水) 11:41:46.63 ID:83b7Yxnh.net] Java(VM)は(すべてのプラットフォームで)強制的に解放させることもできるようにすべきだったな。 383 名前：デフォルトの名無しさん mailto:sage [2016/02/10(水) 12:19:44.29 ID:k9iR7lzz.net] 都度メモリ管理するよか、GCに任せた方がスループット的に有利な場合も多いでしょ。 384 名前：デフォルトの名無しさん mailto:sage [2016/02/10(水) 14:29:59.29 ID:CcpqYYAq.net] GCはメモリ管理に関しては成功してる、 でも、メモリブロックをオブジェクトに昇格させたにも関わらず、相変わらず「メモリ管理」だから失敗。 385 名前：デフォルトの名無しさん mailto:sage [2016/02/10(水) 17:29:46.71 ID:+sMp0qjD.net] そうそう、メインメモリの管理に関しては100%成功している しかし、今やメインメモリはそれほど貴重なものではないわけだがな コンシューマでも数十GB積んでたりは珍しくない メインメモリがなくなるより他のリソースが枯渇する方が現実的 だからメインメモリ以外のリソースに関しては使い終わったら即座に開放してほしいから GCとは別にRAIIを行う仕組みを導入するわけだが 真剣に考えていくと、RAIIはGCと相性が悪い そもそも使い終わったら自動で即座に開放(RAII)できるなら全てのGCはそう実装すべきで それが出来ないからわざわざコストのかかるマークスイープを遅延して実行しているわけだからな C++みたいにGCを参照カウンタ方式にして、プログラマが人力で循環参照が無いことを保証する以外に あちこちから参照されるオブジェクトのRAIIを自動化する方法は無い 386 名前：デフォルトの名無しさん mailto:sage [2016/02/10(水) 20:59:51.38 ID:rEABlirv.net] JAVAはクソ 387 名前：デフォルトの名無しさん mailto:sage [2016/02/10(水) 21:00:45.91 ID:ZQ/yQmxu.net] 簡単だよ スレッド立ててGCをフルサイクル実行し続けるだけ 388 名前：デフォルトの名無しさん mailto:sage [2016/02/11(木) 16:22:39.56 ID:vxbPXQEr.net] javaもsandy-bridge以降でSSDとかならそれほど重いってわけじゃないけど 相変わらずatomでeMMCだったりする環境も並行して存在してて そこで動かすと改めて糞だと思うわけよ GCが悪いんじゃなくてjavaランタイムが悪いんだろうけどね 389 名前：デフォルトの名無しさん mailto:sage [2016/02/11(木) 19:04:56.18 ID:EuRhj+pR.net] フラッシュとJAVAは、システムに見つかり次第、速攻アンインストールしている 390 名前：デフォルトの名無しさん mailto:sage [2016/02/12(金) 08:32:20.35 ID:Uwfak+5B.net] >>377 Pythonみたいに参照カウント+GC（循環参照を解放するため）が最強ってこと？ 391 名前：デフォルトの名無しさん mailto:sage [2016/02/13(土) 15:34:22.04 ID:OKKAbu21.net] 最近のPC環境でも贅沢が過ぎるプログラムは動かん。 最近の奴だと、Node.jsのパッケージマネージャnpmが`npm search`と初回に打つとパッケージ検索用のインデックスを作ろうとするんだけど、 1つのjsonオブジェクトにまとめようとするからかOOMエラーを吐いて失敗するっていう不具合。 npmに登録されてるパッケージ数が膨大になったせいもあるが、設計を間違えると遅いどころか動かなくなる。 392 名前：デフォルトの名無しさん mailto:sage [2016/02/13(土) 22:32:48.48 ID:6Xm9VASh.net] GCがある言語でRAIIみたいな事したいのなら loan patten使えばいいだけでは 393 名前：デフォルトの名無しさん mailto:sage [2016/02/13(土) 23:42:47.95 ID:VLo29AwR.net] リソースを共有した上で最後の参照が切れた時点で回収してほしい しかし誰が共有するかもその寿命も実行時までわからない そういう前時代的なダサい設計をした時の話しなんだろ Loan Patternはこの状況では役に立たない 394 名前：デフォルトの名無しさん mailto:sage [2016/02/14(日) 00:56:38.97 ID:mwiD0ozs.net] しかし、言語側は、そういうダサい設計も許さないといけないので マークスイープ系GC搭載で、循環参照が有っても良いことが前提になっている言語で 「使い終わったら自動で即座に開放」を実現するのは困難 そんなことが可能なら、マークスイープは要らないからな 395 名前：デフォルトの名無しさん mailto:sage [2016/02/14(日) 19:42:04.72 ID:I7Qc+kxz.net] 循環参照なんて放置すればいいの どうせプロセスが終了すればOSが開放してくれるの 396 名前：デフォルトの名無しさん [2016/02/14(日) 20:10:25.23 ID:EqhxGdNa.net] >>387 Windowsのように定期的に再起動しなければいけないソフトウェアができあがっちゃいそう 397 名前：デフォルトの名無しさん mailto:sage [2016/02/15(月) 18:16:17.47 ID:TvNTryet.net] ErlangでOS作るか 398 名前：デフォルトの名無しさん [2016/02/15(月) 19:50:44.55 ID:L+A+Kd2h.net] そこはRustで 399 名前：デフォルトの名無しさん mailto:sage [2016/03/01(火) 15:00:17.89 ID:QERDe7Jh.net] 5分でわかるガベージコレクションの仕組み https://geechs-magazine.com/tag/tech/20160229 400 名前：デフォルトの名無しさん [2016/03/23(水) 02:31:06.32 ID:MFzvJNSi.net] 常識的に考えてカーネルの実装にはGCなんて使えないし 業務アプリケーションではパフォーマンスより開発速度がはるかに重要になる 結局適材適所だ GCを強制されるのは苦痛だが使えないのも苦痛だ 好きな時に使える言語がいいよね！ 401 名前：デフォルトの名無しさん mailto:sage [2016/03/23(水) 03:41:39.64 ID:SoMbpeP6.net] パフォーマンスが問題にならないGCが一つだけあって、それが参照カウンタ方式のGC パフォーマンスが問題にならない→即座に逐一削除できる→RAIIが出来る 非常に強力だがプログラマが循環参照が無いことを保証しなければならない しかし、循環参照が発生する場合は設計段階で分かるのでそれほど深刻では無いのだ！ 402 名前：デフォルトの名無しさん mailto:sage [2016/03/23(水) 03:47:03.14 ID:VzK80P8k.net] androidでもう何も判らん状態でプログラミングして それなりに動くのができたからおれは許したよ でもサービスまで勝手に回収されちゃうとは思わなかったわ アホだろグーグル 403 名前：デフォルトの名無しさん mailto:sage [2016/03/23(水) 07:53:14.58 ID:JT2FURwc.net] RAIIに必要なのはデストラクタが呼ばれることであって実際にメモリが解放されることじゃないから GC言語でもRAIIができないわけじゃない。 404 名前：デフォルトの名無しさん mailto:sage [2016/03/23(水) 10:07:19.06 ID:SB04Y3rp.net] RAIIに必要なのは適切なタイミングで確実に解放処理が呼ばれることであって いつ呼ばれるかわからないデストラクタではだめ 405 名前：デフォルトの名無しさん mailto:sage [2016/03/23(水) 18:24:05.29 ID:jWiL+V+6.net] かつてStandard MLの実装で、GCじゃないメモリ管理方法をやってみたのがあったな。 コンパイラが全部自動でやるからコードの見た目はSMLなんだけど、いざ動かすとGCより遅かった。 ある程度プログラマがリソース管理のためのヒントを与えないと、GCを捨てられない。 406 名前：デフォルトの名無しさん mailto:sage [2016/03/23(水) 20:05:29.02 ID:JT2FURwc.net] >>396 おまえが言っているのはファイナライザ。 それと、デストラクタはメモリの解放なんかしないよ。デストラクトするだけ。 407 名前：デフォルトの名無しさん mailto:sage [2016/03/23(水) 21:43:30.89 ID:SoMbpeP6.net] この際、呼び名はどうでも良い 参照カウンタ方式以外のGCでは、どこからも参照されなくなったことが、即座にはわからない だから、自動で即座に開放関数を呼び出すことが出来ない→RAIIが出来ない C#で言うところのusingみたいに、プログラマが手動で情報を与えるなら出来る だが、usingはGCでは無い 408 名前：デフォルトの名無しさん mailto:sage [2016/03/24(木) 00:53:54.57 ID:smGLwjga.net] いまさら、ゲームキューブ叩いてどうするんだ？ 409 名前：デフォルトの名無しさん [2016/03/26(土) 05:40:22.28 ID:vD3g1idC.net] >>393 間違い マークスイープのように負荷が集中しないだけでありパフォーマンスへの影響はある 特にツリー状のデータついてルートが削除された時子要素もデクリメントする必要があるため負荷が大きい カウンタはオブジェクト毎に持つためコピーオンライトとの相性が悪い また言語の機能として実装されなければ明示的に行う必要がある（例えばCとか） そのためgcない言語ではマークスイープと比べ非常に面倒なことになる 410 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 10:35:48.15 ID:GKwGPSgf.net] androidで原因不明のフリーズが発生、プロジェクトはデスマーチに突入した これだからGCは 411 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 11:39:27.66 ID:drxQ1xsy.net] これだからGCに頼りきった未熟者は 412 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 11:39:40.83 ID:MgEq8J/o.net] >>401 そりゃどんなものだって多少の負荷は有るよ しかし参照カウンタの上げ下げの負荷なんか マークスイープに比べれば無いも同然 413 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 18:02:09.56 ID:2IjmMYr5.net] マルチスレッド環境だと参照カウンタとかいうクソアルゴリズムは使い物にならない 414 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 18:52:26.07 ID:QL60ocAy.net] 参照カウンタがオーバーフローしたらどうなんの？ 415 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 19:10:36.57 ID:nXtJgRqN.net] >>405 SSOのが遅いだろ >>406 size_t にしとけばオーバーフローしない 416 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 19:44:45.11 ID:R9brpoqy.net] >>406 殿堂入りさせて、回収しない 417 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 20:22:44.37 ID:QL60ocAy.net] >>407 確かに現実的にオーバーフローしないと言えると思うけど STLとかもそういう実装になってる？ 418 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 20:52:01.21 ID:rTAUpSul.net] 使う側は少なくとも１つのポインタを持たなくちゃいけないんだからオーバーフローし得ないだろ 419 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 22:10:23.58 ID:6zuFQelp.net] マルチスレッドでGCスレッド立ち上げて、再配置起こる可能性のある普通のGCだと、オブジェクト毎にLock,Unlockできる何らかの機構が必要だし、参照カウンタ増減するより高頻度でその機構使うよね。 420 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 22:34:25.82 ID:2IjmMYr5.net] そうでもない 421 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 23:56:59.65 ID:MgEq8J/o.net] 例えばWindowsだとInterlocked系のAPIを使えば マルチスレッドでも安全に参照カウンタを増減できるから パフォーマンスは何の問題もない 422 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 00:13:33.76 ID:MdJCnp0Y.net] C#なら参照のコピーはただのワード代入で済む メモリ確保もポインタへの加算だけで済むから圧倒的に速い 回収もマルチスレッドで処理されるから圧縮フェーズ以外はUIへの影響もなくユーザ目線では実質コストゼロ 良いコードを書いてるなら圧縮もたまにしか起こらないし起こっても大した事ない 423 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 00:26:17.07 ID:vj+h39OC.net] >>399からの流れを見ればわかるがそういう話ではない 参照カウンタ方式以外のGCは、オブジェクトがどこからも参照されなくなったことが「即座」にわからない だからRAIIが出来ない、そういう話 もちろん、参照の値が書き換わるたびに毎回マークスイープを実行すれば 即座にゴミが分かるがのでRAII出来るが、マークスイープは重いので参照が書き換わるたびに毎回実行できない その意味で、循環参照以外のGCは重いと言っている 参照カウンタ方式は軽いので毎回実行できる 即座にゴミが分かるからRAIIが出来る 参照カウンタ方式で問題になるのは循環参照が起こった場合だが 循環参照が発生する箇所は設計段階で分かるので、実際には大した問題ではない C++であれば、片方をweak_ptrにすればよいというだけの話 そこさえ気を付ければ、参照カウンタ方式とデストラクタの組み合わせは非常にうまく機能する IDisposableのようなものも要らない 424 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 00:27:10.73 ID:vj+h39OC.net] >循環参照以外のGCは重いと言っている ↑間違えた 参照カウンタ方式以外のGCは重いと言っている 425 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 00:41:23.52 ID:15KjVKPo.net] >>413 安全が何で保証されてるのかを知るためにアセンブラを勉強しなさい。 その上で「パフォーマンスは何の問題もない」かどうかを語りなさい。 426 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 00:59:17.81 ID:kBj57j3O.net] 前にも書いたが、RAIIとGCは直接の関係はないよ。 現にC++/CLIでは、ローカルスコープのオブジェクトがスコープを抜けた時点、あるいは gcnewで作成されたオブジェクトがdeleteされた時点で即座にデストラクタが実行されて メモリの回収自体はGCで行われる。 427 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 01:02:24.98 ID:MdJCnp0Y.net] >>415 そもそも不可視のコードでリソースを解放するのが愚行そのもの プログラマとしての良識があるならusingを使いなさい RAIIなどというくだらないバッドノウハウはC#では必要ない 428 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 01:31:49.74 ID:vj+h39OC.net] >ローカルスコープのオブジェクトがスコープを抜けた時点、あるいは >gcnewで作成されたオブジェクトがdeleteされた時点で即座にデストラクタが実行されて >メモリの回収自体はGCで行われる。 それはGC関係ないRAIIの話だろ C#でもusing使えばRAII出来るが usingも、ローカル変数も、deleteも、何れもGCじゃない 手動で寿命管理しているに過ぎない 寿命管理を自動化(GC)しつつ、RAIIを実現する話をしているわけだが どんな場合でも、GCで有ろうが無かろうが、手動でデストラクタなりファイナライザなり呼び出せば RAII出来るに決まっているだろ、それに何の意味が有るんだよ 自動化の話だよ 429 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 01:33:16.88 ID:vj+h39OC.net] >そもそも不可視のコードでリソースを解放するのが愚行そのもの その最たるものが、マークスイープ系GCなわけですが いつ実行されるかすら分からない まさに不可視 430 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 01:51:43.15 ID:vj+h39OC.net] 極端な話 mallocして使い終わったらfreeして はい、手動でRAII出来ました！って主張 それ何の意味が有る話なの？ってね 431 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 07:41:27.84 ID:kBj57j3O.net] >>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の有無に直接の関係はない。 432 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 10:01:03.80 ID:MdJCnp0Y.net] メモリとその他のリソースを混同して考えるからダメ まずその他のリソースは不可視のコードで解放しちゃダメ リソースのスコープは明示的でなければならない これはデストラクタにもGCにも任せられない 逆にメモリは不可視のコードで解放してもよい まずこの基本原則から話を進めよう 433 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 10:12:42.93 ID:Ap0rkncx.net] schemeにはdynamic-windみたいな他所に継続が飛んでも後処理が保証される仕掛けがあるし デストラクタがない==RAIIできないにはならないと思うの・・・ 434 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 11:03:59.82 ID:+zMq83Ww.net] >>424 んな事はない。 あらゆるリソースの寿命はライブラリでデフォルトの管理がされるべきであり、使用者の完全性を前提にすべきではない。 435 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 11:16:32.31 ID:MdJCnp0Y.net] >>426 銀の弾丸は無い あらゆるリソースのあらゆる利用形態に対してデフォルトの動作を定義できるなら話は別だが無理だよね 結局は人が方針を決めて書くしか無い 幸いにしてメインメモリにはRAIIやマークスイープという正解が見つかっているのでそれを使えばいい だが他のリソースはダメだ 436 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 16:21:42.54 ID:vj+h39OC.net] >>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はともかく、デストラクタでもダメって意味不明すぎるんだが 考えの根本がおかしい 437 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 16:43:31.54 ID:vj+h39OC.net] 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のような冗長なコードを書く必要もない 438 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 16:44:43.86 ID:vj+h39OC.net] 訂正 struct A{ *obj }; void func() { 　　A a; } ↓ struct A{ object *obj }; void func() { 　　A a; } 439 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 17:07:08.54 ID:vj+h39OC.net] 結局、C#のDisposeはどこまで行ってもどんなに進化しても手動で書かなければならない 自身のDisposeが呼ばれたからと言って、自身のメンバ変数のDisposeを芋づる式に勝手に呼び出して良いかは コンパイラにはまったく判断が付かない 他からも参照されていて今まさに使われている可能性がある以上 コンパイラが勝手に自動でDisposeを呼び出すコードを生成することはできない GCを発動してみるまでは、どこからも参照されなくなったことが保証できない しかし、GCの発動まで開放が遅延しても良いのであれば、そもそもDisposeは要らないわけで Disposeの実行はGC発動より先行していなければならず、GCに頼れないということになる なので、自身のDisposeが呼ばれたときに、自身のメンバのDisposeをしてよいかは プログラマが考え、手動で呼び出す必要が有る 所有権が単一であれば、手動でメンバのDisposeを呼び出せばよい 手動で記述しなければならないので面倒くさいし、ミスの元ではあるが、一応できる 所有権が複数であれば参照カウンタを使うしか現実的な方法は無いだろう マークスイープ系GCなのに参照カウンタで独自に管理するのは馬鹿げているがな 参照カウンタ方式＋デストラクタ であればこれらの問題は一切発生しない 参照カウンタが0になったことは即座にわかるし、デストラクタはメンバ変数に対して芋づる式に呼び出されるので 開放に関しての特別なコードを手動で書く必要は無い 開放処理も一本化される 440 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 17:16:20.56 ID:UGnRhUEw.net] 長文は漏れなく基地外 441 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 17:17:01.33 ID:MdJCnp0Y.net] >>428 バカすぎる 細かい事気にせずデストラクタで解放すりゃそれでおkって感じの適当な現場でしか働いた事無いんだろうな 442 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 17:22:53.59 ID:/D0vdPDd.net] ポインタがメンバ変数になってたら公開しちゃいかんでしょ 443 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 17:24:21.54 ID:MdJCnp0Y.net] まずDisposeは生成できる めんどくさいという奴は知識が無いだけ リソースを共有する事は少ない というか設計段階で可能な限り少なくする そして共有するならするでしっかり管理して自動解放などという手抜きはしない 基本中の基本だ 444 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 17:32:09.52 ID:+zMq83Ww.net] デストラクタで解放してはいけないリソースをデストラクタで解放しなければいいだけで、デストラクタで解放すればいいリソースはデストラクタで自動的に解放すべき。 445 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 20:12:26.78 ID:kBj57j3O.net] >参照カウンタ方式＋デストラクタ >であればこれらの問題は一切発生しない .NETのマーク&スイープGCの上でRAIIを実現している実例としてC++/CLIを説明したんだが、 「基本的なこと」とか言いながら結局何も理解してないんだな。 そもそもRAIIの話で所有権が共有されたオブジェクトを持ち出すのが意味不明すぎる。 >参照カウンタが0になったことは即座にわかるし、 「いつか」全員が所有権を手放したら「即座に」破棄される 「いつか」全員が所有権を手放したら「いつか」GCで破棄される どう違うというのか。 446 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 20:35:08.73 ID:Ng/EIIMI.net] RAII信者の痛さは異常 オブジェクトをコピーされたら破綻するのに 447 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 21:10:56.38 ID:N7IGtcj3.net] グローバルインスタンスホルダーは明確にインスタンスの状態を把握したいときに積極的に使うべき 448 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 22:32:53.86 ID:vj+h39OC.net] >「いつか」全員が所有権を手放したら「即座に」破棄される >「いつか」全員が所有権を手放したら「いつか」GCで破棄される >どう違うというのか。 少なくとも最善が尽くされるという意味で違うし 同じデータと同じプログラムで有れば、常に同じタイミングで開放処理が走るという再現性が有る それから、自分しか所有権を持っていない場合、つまり参照数が常に1というシンプルな状況ですら 参照カウンタ方式の方が開放処理が自動化されて楽 参照カウンタ方式で有れば、スマポを使っておけば済む scoped_ptrでも良い マークスイープ系GCであれば、自身しか所有権を持たない単純な場合でも 非常に面倒なことになる 自身にDisposeを実装して自身のメンバのDisposeを呼び出すコードを手動で書かなければならない 何故こういったコードをコンパイラが自動生成できず、手動で書かなければならないのかの根底に まさにマークスイープGCの存在が有る マークスイープ系GCは何処からも参照されなくなったことがその場ですぐに分からない GCを発動してみるまで保証することが出来ない 自分のDisposeが呼び出された、まさにその瞬間に、自分のメンバに対してもDisposeしてよいのかどうなのか 参照数がリアルタイムで即座に分からないので判断する材料が何も無く コンパイラはC++のデストラクタのように自動で芋づる式に開放処理を呼び出すコードを生成することが出来ない 要するにマークスイープ系GCではDisposeのコンパイラによる自動生成が出来ないという大きなマイナスが有る 449 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 22:36:05.37 ID:15KjVKPo.net] >>438 しねーよ 450 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 22:41:25.16 ID:VNvh7E4d.net] >>440 子要素をDisposeしていいかどうかもわからないってそりゃ設計サボってる以外のなんでもないだろう ちゃんと設計してればいつ削除してよいかなんてわかるはずだろ まともに設計もできないレガシーエンジニアは黙っててよ 設計に時間使わないとリソース云々以前に別のバグだらけになるぞ 451 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 23:42:37.04 ID:Ng/EIIMI.net] RAII信者は頭が悪いな 452 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 23:59:39.99 ID:15KjVKPo.net] >>443 自分の頭を検証しな 453 名前：デフォルトの名無しさん mailto:sage [2016/03/28(月) 00:10:58.97 ID:h9yZCrPP.net] メンバにDispose持たせる設計って大抵ダメだよね 454 名前：デフォルトの名無しさん mailto:sage [2016/03/28(月) 00:20:40.85 ID:j/beyn8U.net] >>440 前者(参照カウントGC)はRAIIができるが後者(マーク&スイープGC)ではできないというお前の 主張について言っているんだが？ 「最善が尽くされる」からRAIIができて、尽くされないからRAIIができないとでも言うのだろうかｗ >要するにマークスイープ系GCではDisposeのコンパイラによる自動生成が出来ないという大きなマイナスが有る 何度も例に挙げているC++/CLIでは、デストラクタを記述するとコンパイラによってDisposeが追加される。 そして、ローカルスコープに置いたオブジェクトに対してはスコープを抜ける際に自動的にdeleteが呼ばれる。 そこからdelete→Dispose→デストラクタと呼び出される。RAIIに必要なものは揃っているし、事実、可能だ。 もちろん、そのメモリ領域は別のタイミングでGCによって回収される。 ここまで説明しても理解できない低脳ならしょうがない。 やはりデストラクタとファイナライザの違いが理解できてないようだからそこから勉強しなおせ。 455 名前：デフォルトの名無しさん mailto:sage [2016/03/28(月) 00:39:52.48 ID:2h3yopdG.net] { std::shared_ptr<my_namespace::my_class> p(new my_namespace::my_class(...)); /* unko_code */ } using(var obj = new MyClass(...)) { /* GoodCode */ } 美しいという事はいい事だね C#は書いてある事がシンタックス的にもセマンティック的にも明確だ リソース管理はこうでなければならない 456 名前：デフォルトの名無しさん mailto:sage [2016/03/28(月) 01:22:52.25 ID:khgTmo3F.net] >>447 C++にもusing使えやw いらない波括弧外せやw 457 名前：デフォルトの名無しさん mailto:sage [2016/03/28(月) 03:34:15.37 ID:d3YBhLBG.net] >>447 usingの方が全然明確だね objがコピーされてても問題ない RAII脳ではわからないんだろう 458 名前：デフォルトの名無しさん mailto:sage [2016/03/28(月) 03:36:11.96 ID:d3YBhLBG.net] schemeに何十年も前から存在するwith-xxxx 系を一般化した構文だね 459 名前：デフォルトの名無しさん mailto:sage [2016/03/29(火) 01:23:53.57 ID:Qm5oX8hY.net] アレを更にtypedefされたりされると ワケワカランくなるよな 460 名前：デフォルトの名無しさん mailto:sage [2016/03/29(火) 01:50:13.51 ID:40IzaG0J.net] c++なら普通こうだな { my_class obj(...); ... } そういやc#でp.release()相当の事って簡単にできるの？ { auto p(make_unique<my_class>(...)); ... } nullって代入可能？ 461 名前：デフォルトの名無しさん mailto:sage [2016/04/04(月) 02:47:24.69 ID:+1V6ohqL.net] GCがあるのになぜJavaはメモリリークしまくるソフトウェアを量産するのか 462 名前：デフォルトの名無しさん mailto:sage [2016/04/04(月) 02:55:18.29 ID:FhdBY7IF.net] >>453 Javaだから 463 名前：デフォルトの名無しさん mailto:sage [2016/04/12(火) 23:15:42.48 ID:ZWvwh7J9.net] Rust使えばいいのさ 464 名前：デフォルトの名無しさん mailto:sage [2016/04/13(水) 10:33:47.16 ID:+hJ3fPVS.net] >>455 会社にいるよな、そういうやつ 465 名前：デフォルトの名無しさん mailto:sage [2016/04/13(水) 15:29:31.16 ID:oOcEPJTu.net] GC大好きっ子に聞きたいんだが 完璧な（理想的な）GCを搭載したメジャーな言語処理系って何があるの？ これで開発すればリークも管理も気にしないでOKってやつ 466 名前：デフォルトの名無しさん mailto:sage [2016/04/13(水) 16:22:35.14 ID:s5MRiDQ8.net] 無い マークスイープ系GC　→　循環参照OK、しかし即座に開放されない 参照カウンタGC　→　即座に開放される、しかし循環参照NG ということで、理想のGCは無い 全てのGCは何かを妥協している それから、たとえGCを使ったとしても 要らなくなったオブジェクトの参照をいつまでも握っている奴が居たら解放されないから リソースの管理をしなくてよいということは無い あと、GCは基本的にメインメモリに対してしか有効に機能しないから 例えばファイルオブジェクトなんかは要らなくなったら即座にcloseするなりすべきで リソース管理フリーというわけにはいかない 467 名前：デフォルトの名無しさん mailto:sage [2016/04/13(水) 16:54:16.68 ID:s5MRiDQ8.net] つまりは、GCを使っていたとしても 君がオブジェクトを何処かに登録したなら オブジェクトが要らなくなったら登録解除してあげないと そのオブジェクトは解放されないのだ これはちょうどmallocしたらfreeしましょうに似ていて GCを使ったとしても全てのリソースの管理が自動になるわけではないということだね 究 468 名前：極的にはGCの利点は自分でfree/deleteをしなくても良いところにある これはつまり、ダングリングポインタが発生しないということだ [] [ここ壊れてます] 469 名前：デフォルトの名無しさん mailto:sage [2016/04/14(木) 20:54:37.84 ID:f1hhftJp.net] >>457 C+BoehmGC 470 名前：デフォルトの名無しさん [2016/04/17(日) 16:17:55.58 ID:j/f/oFPY.net] そして無視されてしまうコピーGC君 GCの利点は自分で大量にメモリの確保＆解放するプログラムにおいてバグが出にくくスループットも出るってところだと思う もしheapをそんなに頻繁に確保＆解放しないんだったらGCない言語の方がいい ただ近代的な言語は少数の例外を除いて大抵GC積んでるけど 471 名前：デフォルトの名無しさん [2016/04/17(日) 16:21:44.96 ID:j/f/oFPY.net] ＞リソース管理フリーというわけにはいかない リソース管理フリーについてはrustみたいなGCない言語のほうが達成できてるよね（あとは関数型言語か） でもrustでもリソースの解放時にエラーを吐く可能性がある処理なら自分で解放する処理書かなきゃいけないっぽいけど 472 名前：デフォルトの名無しさん mailto:sage [2016/04/17(日) 18:35:17.89 ID:SAR9JCaP.net] RAIIでも結局どのタイミングで解放されるか意識しなくてもいいってわけじゃないし リソース解放処理を書かなくていいだけで 473 名前：デフォルトの名無しさん mailto:sage [2016/04/17(日) 18:43:59.82 ID:cFoKw8Zx.net] メモリ管理系のバグが顕在化しにくいだけで、そこら辺適当なまま中途半端にキャリアを積む開発者を量産するという害悪が大きい。 JNIやらで他のAPI使う必要が出てくると結局いろいろ配慮しなきゃいけなくなるし。 474 名前：デフォルトの名無しさん mailto:sage [2016/04/17(日) 19:43:44.44 ID:oNE1M7I6.net] >>460 コンサバじゃ完璧にほど遠いぞな 475 名前：デフォルトの名無しさん mailto:sage [2016/04/17(日) 19:50:47.36 ID:1R/4ebGS.net] >メモリ管理系のバグが顕在化しにくいだけ 結局これだよね 本当に丸投げできるなら乗っかるのもいいと思う 性能問題はハードの進化で一部の用途を除けば問題無くなると思うし でも現実は中途半端だから意識して書いたほうがマシだと 476 名前：デフォルトの名無しさん [2016/04/17(日) 21:19:09.59 ID:IB74e9ph.net] ムーブセマンティクスのおかげでずいぶん便利に。 477 名前：デフォルトの名無しさん mailto:sage [2016/04/17(日) 23:09:38.99 ID:j/f/oFPY.net] あと正確にはGCには含まれないけどメモリコンパクションをやってくれる処理系が多いのも GCを使う利点になるかも 478 名前：デフォルトの名無しさん mailto:sage [2016/04/17(日) 23:17:23.70 ID:cFoKw8Zx.net] 今どき意図的にやらない限りメモリフラグメンテーションで困るような場面があるか？ アドレス空間も余裕出てきたし、多少おかしな確保パターンで浪費してもGCほど実メモリを食わないし。 今どき主流のサイズ毎に空きを管理するmallocは優秀だしね。 これがダメならlinuxカーネルとか先に落ちちゃうぞ。 479 名前：デフォルトの名無しさん [2016/04/18(月) 15:56:44.18 ID:kcE0qDSU.net] >>469 昔、C/C++を駆使して日本が誇るスパコン京に投入するタスクセットを書き上げたのだが 実行するとどうも性能が出ない。 色々調べた結果、どうやらメモリーが断片化していることが分かった。 そこで多大な投資を行いJavaで書き直したらなんと100倍も性能が上がったのです！ これが>>468さんの経験してきたことなんです。 480 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 16:30:17.23 ID:BDPQ12Es.net] 自前のメモリ管理が超下手くそなだけやろ 修業して出直してこいや 481 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 16:37:09.21 ID:OvHIqTOi.net] 自慢になってないような 482 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 16:44:52.62 ID:9yQABY6F.net] ゲームだとフラグメント問題になること多いよ ゲーム専用機なら特に 最近は特にオープンワールドが当たり前になってるけど あれストリーミングでどんどんメモリ置き換えていくしね 483 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 16:47:31.98 ID:/wa5LIj ] [ここ壊れてます] 484 名前：H.net mailto: jemallocのようなモダンなmalloc実装使えば良かったのでは。 [] [ここ壊れてます] 485 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 17:47:00.91 ID:IBBVu28x.net] ゲーム専用機でフラグメンテーションおこすとか開発者としての適性を疑われても不思議ではない。 オブジェクトの寿命管理すらしないのか？ 486 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 18:51:08.61 ID:RPQ9NKJO.net] メモリのフラグメンテーションをC/C++でコントロールする方法ってあるの？ mallocの実装頼りじゃなく。 487 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 19:05:27.63 ID:OvHIqTOi.net] mallocの挙動がわかってれば、ある程度は・・・・ 488 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 19:14:30.71 ID:OvHIqTOi.net] 細かくメモリ要求するから、下回りで時間がかかる メモリ分断されてもオンメモリでの検索はさほど時間がかからない （空きができても、そこに入らないときに） 489 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 19:15:14.97 ID:9yQABY6F.net] >>475 フラグメンテーションって何かわかってないでしょ？ 寿命管理だけでは解決できないよ 490 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 19:21:39.69 ID:IBBVu28x.net] 寿命管理で解決できないとか、フラグメンテーションがどういう現象か分かっているの？ 汎用の寿命管理APIみたいなのを使うとか言うのと勘違いでもしている？ 491 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 20:02:22.75 ID:3yZKjOEp.net] >>480 おいおい・・ この場合寿命を管理できないってのはgiven conditionとして考えないと そりゃ寿命があらかじめわかってるなら苦労しないっての 大規模なプログラムでそんな恵まれた状況は例外的だよ 492 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 20:57:42.92 ID:IBBVu28x.net] 専用ゲーム機上のゲームだよ。 リソースが逼迫したら何を優先するかの戦略も含めてほぼ理想的なgiven conditionだろうに。 ユーザーの行動による不確定性も全てコントロール下にあるだろうに。 493 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 21:13:59.16 ID:RPQ9NKJO.net] >>482 専用ゲーム機と普通のPCの1アプリケーションとで何が違うのか。mallocも使わないってこと？ NoGC, 各GCでメモリ空間がどう使われるかを視覚化 ttps://spin.atomicobject.com/2014/09/03/visualizing-garbage-collection-algorithms/ 黒: 未使用 灰: 確保 緑: 読み込み 黄: 書き込み 赤: GC用のアクセス(参照カウンタ、マーク用ビットetc) 緑と黄は時間経過で退色していく メモリフラグメンテーションという観点から見ると、コピー型GCが綺麗。 494 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 21:15:59.31 ID:3yZKjOEp.net] まぁテトリスとかならその程度の理解でいいんじゃない？w 495 名前：デフォルトの名無しさん [2016/04/18(月) 21:33:24.92 ID:kcE0qDSU.net] Javaの寿命管理APIは最強ですな。 496 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 21:49:39.41 ID:9yQABY6F.net] >>482 GTAみたいなゲーム考えてみ？ あれ全てオブジェクトの寿命を事前に決められると思う？ 原理的には不可能じゃないだろうがそんな職人的な作りしてたら開発に10年かかるわw 497 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 21:56:15.95 ID:IBBVu28x.net] 普通のmallocで足りるならそれでもいいけど。 基本メモリ容量ギリギリまで使うから、最初に描画、ゲーム内部状態、音声、ディスクキャッシュなどでどのくらい使うか決めておく。 終始一貫して静的に決めるのが楽だけど、場合によっては場面ごとに配分を切り替えたりする。 で、例えば広いマップ上を自由に動き回るようなゲームだと、マップを複数のパーツに分割して、詳細モデルから簡易モデルまで用意する。 498 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 22:12:01.61 ID:3yZKjOEp.net] ゲームプログラムとかならメモリ確保は直接システムコール呼び出して ページ単位でアロケートするのが定石 必要ならmspaceとかインスタンスベースのヒープを自分で作る 499 名前：デフォルトの名無しさん mailto:sage [2016/04/19(火) 01:49:46.30 ID:KVIhh3Hm.net] 使用できるメモリのサイズも空きメモリのサイズも最初か 500 名前：ら分かってて、ユーザーからの入力も限られてて、 そいつら全部自分で管理できる「恵まれた」環境でしか通用しないアプローチだよなそれ。 [] [ここ壊れてます] 501 名前：デフォルトの名無しさん [2016/04/19(火) 01:58:46.65 ID:fq3yh1do.net] レーシングゲームは出てくる車が決まっていてコースも決まっているから。 502 名前：デフォルトの名無しさん mailto:sage [2016/04/19(火) 08:28:57.71 ID:YcewE61x.net] 昨今はレースゲームでも汎用的なゲームエンジン使うことが多いから その場合事前に寿命が決まってる前提の作りにはしていないと思うぞ GDCとかGame Gemとかでも昔からフラグメンテーション対策を含む メモリ管理の手法はいろいろ議論されているから調べてみるとよろし 503 名前：デフォルトの名無しさん mailto:sage [2016/04/20(水) 12:56:58.01 ID:r07pzD8i.net] >>489 ハードリアルタイムなシステムならごく普通 って言うかそうでないと作れない 504 名前：デフォルトの名無しさん mailto:sage [2016/04/20(水) 13:09:41.53 ID:DLw9rf+F.net] >>486 ああいうFPSのオブジェクトは全部管理されてるし gcなんか使ってないよ 505 名前：デフォルトの名無しさん mailto:sage [2016/04/20(水) 19:22:46.02 ID:bj66dBvK.net] >>493 フラグメンテーションの話だっての 506 名前：デフォルトの名無しさん mailto:sage [2016/04/20(水) 19:58:58.01 ID:CuR1I1mj.net] やり手のゲーム系の方たちに、逆らうようなことは・・・・ 507 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 01:20:25.83 ID:jf1w54Av.net] >>494 そんなのどうにでもなるでしょ 汎用のmallocなんかとは事情が違う 508 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 02:16:29.96 ID:G+xv7xqn.net] >>496 どうとでもなるって？ へーじゃあ試させてもらうわ GDC 2016でもこういう講演があった schedule.gdconf.com/session/building-a-low-fragmentation-memory-system-for-64-bit-games 64bitならなぜフラグメンテーションが軽減できるか説明してもらおうか？ 物理メモリが多いからじゃないからな あればあるだけメモリ使うのがゲームなのでメモリに余裕があるわけじゃない 509 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 11:32:02.27 ID:EjzxVVPK.net] ゲーム機含む組み込み系は結果が不確定な動的メモリー確保なんかしないのが鉄板（しようとする奴は未熟な馬鹿）だったが PCと合わせて組み込み機器もスペックが潤沢になって富豪的プログラムが一般的になってきたからね 無知ゆえ聞きたいんだが 最近のゲームソフトやら>>497やらってどういうGC使ってるの？ 510 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 13:09:31.92 ID:pog3nPgL.net] ゲームだって組込みだって今どき動的メモリー確保しないなんて化石みたいな発想が通るわけないだろ かといって普通のGCは問題外 賢いメモリアロケーションをするしかないんだよ >>497は「こんなすごい講演するぞ」って言う宣伝だけだけど中身はどこにあるの？ 511 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 16:14:15.43 ID:lEi5GQja.net] >>497 MMUが付いているから 物理メモリがフラグメンテーションすることは、ある程度これで防げる しかもハードウェアの機能だから高速だし、勝手にやってくれるから素晴らしい 速度が重要なゲームでは、これは有り難い ソフト的なアプローチでこれ以上の細工は遅くなるだけで効果が薄い 問題は論理アドレスの方 32bit空間だと例え物理メモリが余っていても 論理アドレスがフラグメンテーションを起こして連続したメモリを確保できなくなる 物理アドレスが枯渇するよりもさきに、そちらの方が問題になることが多い 64bitだと、これが防げる 512 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 16:37:13.61 ID:lEi5GQja.net] 各ゲーム機の事情は知らないが PCで有れば、64bitプロセスは、論理アドレスの空間が256TB(48bit)もある ゲーム機も似たようなものだろう 256TBもの物理メモリを積んだPCやゲーム機は存在していないし 例え論理アドレスが激しくラグメンテーションを起こしても 256TBもの論理アドレス空間を使い切るという事態は考えなくてよい つまり、64bitプロセスなら、論理アドレスの心配はしなくてよい 一方で、物理アドレスのフラグメンテーションはMMUに任せておけばよい これはハードウェアで自動で行われるし、とても高速 その余計にソフトウェア的アプローチで頑張ってみたところで 多少物理メモリのフラグメンテーションは改善されるかもしれないが 徒労というかなんというか、労力に見合わないし しかも遅くなるのでゲームには向いていないし、やらなくてよい 物理アドレスは自分だけが使っているわけではなく、OSを含めたほかのプロセスも使っているので 自分のプロセスが使っている物理メモリだけフラグメンテーションを解消しようと コンパクションするのも何か完璧感が無いし 自分のプロセス内だけで考えても、外部ライブラリやXBoxならDirectXが使用している物理メモリの フラグメンテーションは手が出せないので解消しようがない、やはりやるだけ徒労 自分の管理出来る部分だけ物理メモリのコンパクションをかけても 「これで計算上、必ずあと200MBの物理メモリを使用できる筈」とかといった保証はどこにもない 理由は、外部のライブラリ内での物理メモリの使用状況が分からないし、手が出せないから とにかく徒労であり、MMUに任せておけばよい 513 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 17:22:28.74 ID:7dcTEyv0.net] ただの物理メモリ不足の話がなんでと思ってしまった swapはじまったら、fpsなゲームはどうなるんでしょうね 514 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 19:18:25.46 ID:zEEe/DNn.net] 論理アドレスが64bitだったらフラグメンテーション対策なんていらんということ？いや自分もそうは思うんだが。 上の方で「専用ゲーム機開発ならフラグメンテーション対策も行うのが常識！」みたいに主張してる人がいて、 それって自作のmalloc相当のアロケータ作るってことだよね？と思ったんだが、 メモリ節約術とごっちゃにしてる人もいてわけが分からなくなってきた。 515 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 22:14:27.41 ID:WHT47icf.net] なんで馬鹿に限って長文書きたがるんだろうか 516 名前：デフォルトの名無しさん mailto:sage [2016/04/22(金) 08:58:47.78 ID:imh5rD9T.net] >>500 すばらしい、正解 まぁ>>488で答え言ってたわけだけど 某ゲーム機ならコンパクションも実装できるよ >>503 ページ単位という制限がつくし、速いって言ってもシステムコールなので ユーザランドで完結するヒープライブラリに比べると遅い フラグメンテーション対策がいらなくなるわけじゃないよ 517 名前：デフォルトの名無しさん mailto:sage [2016/04/22(金) 11:30:03.69 ID:+Z1ZyILi.net] わかってなさそうな方がそれっぽいこと・・・・ 518 名前：デフォルトの名無しさん mailto:sage [2016/04/22(金) 12:23:02.13 ID:UzNl+aCx.net] わかってる方は完結に書いてみればいい 519 名前：デフォルトの名無しさん mailto:sage [2016/04/22(金) 15:49:44.48 ID:+Z1ZyILi.net] 学校の先生にそう教わったんですね 520 名前：デフォルトの名無しさん mailto:sage [2016/04/22(金) 19:23:46.16 ID:cAq2nbH2.net] 用途ごとにセグメント分けて使い回すのが無難じゃないの オブジェクトの数が足りなくなったら透明でいいのよ 521 名前：デフォルトの名無しさん mailto:sage [2016/04/22(金) 20:32:21.23 ID:1FeuO5Gj.net] 結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない しかし論理アドレスの方は何にもしてくれないのでフラグメンテーション起こして 連続したアドレスが確保出来なくなると、それで終わり、どうしようもない 32bitプロセスだと4GBしか空間がないから、まれに問題になる 64bitプロセスだと無尽蔵に空間があるから問題になることは現状ありえない 522 名前：デフォルトの名無しさん mailto:sage [2016/04/22(金) 23:54:45.31 ID:imh5rD9T.net] >>510 > 結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない MMUってのはアドレス変換するハードウェア 勝手に物理メモリを仮想メモリにマップしたりはしない それをやるのはOS 523 名前：デフォルトの名無しさん mailto:sage [2016/04/23(土) 00:19:34.35 ID:43LRl8T1.net] そもそも、ページサイズより粒度が細かいフラグメンテーションにはMMUはなんの効果もないしな。 524 名前：デフォルトの名無しさん [2016/04/23(土) 05:06:22.41 ID:TwuNXQH0.net] autorelease()呼んだらコアダンプ糞osがｗｗｗ 525 名前：デフォルトの名無しさん mailto:sage [2016/04/23(土) 18:49:46.90 ID:RPK9BpXO.net] 小さな粒度のフラグメンテーションは気にする必要ない 4KBならUTF-16で2000文字ぐらいしかない 32biｔビットマップなら32x32ほとのサイズ 526 名前：デフォルトの名無しさん mailto:sage [2016/04/23(土) 20:33:25.39 ID:PodTlhvX.net] キャッシュヒット率が落ちそう(コナミ) 527 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 01:18:30.93 ID:9YSuZOIq.net] >>512 お前のプログラムはメモリを1ページしか使わんのかｗ？ フラグメンテーションで使用率が低いスカスカのページだらけになるのが問題なんだろうが。 528 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 01:38:34.87 ID:ai61/62A.net] >>516 へーお前はヒープを使わないのか 漢だな 529 名前：デフォルトの名無しさん [2016/04/24(日) 08:38:51.73 ID:65va2BTL.net] メモリー512バイトでどうやってヒープを使えと。 530 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 09:31:32.99 ID:HSA/nLEW.net] ネイティブコードが必要な場面で中途半端に GC に頼るのが問題なのかもしれないが、もうネイティブコードが必要な戦場は限られた一部だけになってて、主戦場では GC は大前提の技術なんだから必要ないとか言われましてもですわ。 531 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 10:14:15.47 ID:W23a3TIA.net] ページがスカスカになっても大丈夫 1ページ4KBとかだからね、十分小さい 32x32-32bitビットマップより小さい 最近のゲームで使われるような大きなサイズのテクスチャなど でかいサイズを確保する場合はどうせ新しいページが割り当てられるし 小さなサイズを確保する場合は、スカスカになったページから空いているところを探して割り当てられるので 問題ない 532 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 10:14:59.78 ID:TFb7efu7.net] androidしか知りませんみたいな事言われてもな 533 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 10:27:10.54 ID:W23a3TIA.net] 物理アドレスはページサイズで切り売りされるので 元から連続しているアドレスは必要ではなく フラグメンテーションは問題にならない 連続したアドレスが必要になるのは論理アドレスのほうであり 32bitプロセスでは4GBしか空間がないから問題になることがある 64bitプロセスであれば現状問題にならない 534 名前：デフォルトの名無しさん [2016/04/24(日) 10:37:41.02 ID:65va2BTL.net] 実はQtでデーモン作って動かしてるのだが、もう半年以上動き続けてる。 まさかこんなに問題が起きないとは。 案ずるより産むがやすしですぞ皆の衆。 535 名前：デフォルトの名無しさん [2016/04/24(日) 10:58:37.83 ID:65va2BTL.net] Qtで作ったのは一日ででっち上げる為だったのだが、意外なことに堅牢に動き続けてる。 536 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 12:08:49.17 ID:HSA/nLEW.net] Qt でデーモン? GUI が必要なデーモン? 537 名前：デフォルトの名無しさん [2016/04/24(日) 12:13:06.27 ID:ynYywbEh.net] >>525 デーモンは通常フォアグラウンドじゃないのでUIを持ちませんぜ旦那。 538 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 12:25:33.24 ID:HSA/nLEW.net] ならば何に何故どのように Qt を使うのだ？ 539 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 12:45:58.38 ID:TFb7efu7.net] >>526 だからQtでデーモン？(クエスチョン)…なんじゃね？ 加えてQtってGC関係あるのか？ たしかC++のライブラリーだよね？ 540 名前：デフォルトの名無しさん [2016/04/24(日) 13:02:46.55 ID:ynYywbEh.net] 等と意味不明な供述をしており。 541 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 14:52:01.10 ID:fu8W/E1c.net] >>525 Qt 使ってるからと言って QtGui 使ってるとは限らんけどね >>528 Qt 本体は C++ で書かれてるけ ど Java, Ruby, Python, Perl, C# 等からも利用できるよ 542 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 14:52:56.88 ID:UKiBgwvV.net] daemonじゃなくてdemonなんじゃない？ デスクトップマスコット的な 543 名前：デフォルトの名無しさん [2016/04/24(日) 14:59:36.53 ID:ynYywbEh.net] 俺が作ったのはウェブソケットによってサービスを提供するプログラムだ。 エンジンエックスをリバースプロキシとした。 このプログラムは常時数千の接続から大量のリクエストを受け付ける。 接続してくるクライアントは専用に作られQtで書かれている。 大量のリクエストはそれぞれ複数のデータベース検索を引き起こす。 こう書くと結構負荷が高そうなのだが、さすがC++、ほとんど塵程度の負荷しかなく、 当然のことながらリプライに遅延もない。 そこで案ずるよりも生むが易しというわけ。 Qtは出自からしてGUIのためのライブラリではあるのだが、GUIが無いと使えないというわけでもない。 むしろボリュームからすれば、GUI以外の方がより大きい。 そして、半年動きっぱなしで大丈夫ことからして、実は断片化は気にしなくても 良さそうだ。 544 名前：デフォルトの名無しさん [2016/04/24(日) 15:05:02.69 ID:ynYywbEh.net] ちなみにQt使ってなかったら一日でサービスを書き上げることは不可能だっただろう。 Qtは、その他のGUIライブラリ同様バグが多いのだが、GUIを抜いてみるとどうだろう、 意外なほどに堅牢なのだ。 何しろもう半年動きっぱなし。 俺はこの経験から一つの予測を立てた。 これからのサービスは、C++で書かれるようになる可能性がある。 何しろ圧倒的に速い。 一つのリクエストに対するレスポンスが速いため、平均負荷率が圧倒的に下がるのだ。 この事実に世の中が気づくにはそう時間がかからないはず。 そしてsystemdがこの動きを促進するはず。 ちなみにWindowsで書いてLinuxで動かしてます。 545 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 15:05:44.58 ID:ai61/62A.net] 一例をもって一般化はできないだろ 546 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 15:05:53.54 ID:TFb7efu7.net] >>530 色々な言語から使えるのか そういう場合Qtが使うメモリーなんかはどういう扱いなんだろうね GC適用外な気がするけど知らないからこれでやめとくわ 547 名前：デフォルトの名無しさん [2016/04/24(日) 15:08:01.90 ID:ynYywbEh.net] Windowsで書いてLinuxで動かすことに、systemdは大いに貢献した。 従来のデーモンの作り方では、いろいろ煩雑なことがありすぎ、時間の制限から難しかっただろう。 Qt+systemd、この直観的な選択は大成功であった。 548 名前：デフォルトの名無しさん [2016/04/24(日) 15:11:43.89 ID:ynYywbEh.net] Qtのバグの多くは、複数の環境に対応するため、その差異によって引き起こされているという結論を得た。 systemd万歳！ 549 名前：デフォルトの名無しさん [2016/04/24(日) 15:16:24.95 ID:ynYywbEh.net] 更にもう一つヒントがある。 複数のクライアントから多様なリクエストがあるとはいえ、一つのプログラムが擁する データ構造などたかが知れているのだ。 クライアントAのリクエストにこたえるため使用された記憶空間は、解放されたのち クライアントBのためにそのまま使われる可能性があるのだ。 そういったわけで断片化は気にする必要が無い。 若者よ、案ずるより産むが易しですぞ。 550 名前：デフォルトの名無しさん [2016/04/24(日) 15:28:56.74 ID:u6qUQj/U.net] ねえ訳分かんないんだけど 本人以外で理解してる人要るの？ 551 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 15:55:24.75 ID:fu8W/E1c.net] むやみに連投してる奴はたいていスルーでok 552 名前：デフォルトの名無しさん [2016/04/24(日) 20:02:15.39 ID:ynYywbEh.net] むしろ、わからないのに何故、一生懸命主張していたのかと。 553 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 20:22:44.80 ID:fcfJojCV.net] 誰と戦っているんだろう… 554 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 22:39:17.85 ID:WrdDgWl7.net] マークスイープでメモリリークってどうやって起きるんだ？ 初心者だから優しく説明してほしい 555 名前：デフォルトの名無しさん [2016/04/25(月) 01:16:56.77 ID:/Pmm49fe.net] 狭義の意味では起きない もし君が気付かない間にオブジェクトへの参照を保持していたらどんなGCだろうが解放されない それをリークというならリークする 556 名前：デフォルトの名無しさん mailto:sage [2016/04/25(月) 13:44:57.25 ID:HSarKqaj.net] 言い換えればダングリングポインタが発生しない それだけ 557 名前：デフォルトの名無しさん mailto:sage [2016/04/25(月) 14:51:13.10 ID:0xpbBk2N.net] マーク＆スイープでもポインタの型情報を記録してないとリークしまくる 無関係な数値をアドレス参照と勘違いしてマーク→未開放 某言語ではこのために巨大なメモリブロックが 558 名前：開放されない [] [ここ壊れてます] 559 名前：デフォルトの名無しさん mailto:sage [2016/04/25(月) 20:35:07.72 ID:4DDlKiNG.net] >>543 どこからマークを始めるかが問題 560 名前：デフォルトの名無しさん mailto:sage [2016/04/29(金) 18:58:56.34 ID:I1ppYkAy.net] >>10 C#はGCの掃除処理を任意で呼び出せるだけだろ C++/CLIなら自分でdelete呼べば即座に消え去るが もちろんC++と同じくデストラクタも確実に起動する。 561 名前：デフォルトの名無しさん mailto:sage [2016/04/29(金) 22:46:31.85 ID:wZxrhoKH.net] C++/CLIはデストラクタが呼ばれるだけで、managedメモリの解放がGC任せなのは変わらんよ。 562 名前：デフォルトの名無しさん [2016/05/01(日) 07:57:30.30 ID:tKi6j9CT.net] 匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、 BitTorrentがオープンソースで開発されています 言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？ Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします https://twitter.com/Lyrise_al ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ The Covenant Project 概要 Covenantは、純粋P2Pのファイル共有ソフトです 目的 インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します 特徴 Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW) 接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です DHTにはKademlia + コネクションプールを使用します UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります) 検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません w 563 名前：デフォルトの名無しさん mailto:sage [2016/05/01(日) 09:11:45.10 ID:qHyjCjkk.net] 無視リストに追加と 564 名前：デフォルトの名無しさん [2016/05/02(月) 21:54:41.51 ID:KYdaomRZ.net] GCCは失敗、Clangを使え。 565 名前：デフォルトの名無しさん mailto:sage [2016/05/02(月) 22:21:36.97 ID:btgv3pKW.net] うるせーバーカ 566 名前：デフォルトの名無しさん [2016/05/04(水) 17:42:43.75 ID:M8+arjAJ.net] gccは失敗。 567 名前：デフォルトの名無しさん [2016/05/27(金) 12:06:01.84 ID:FwT+WNvC.net] 良スレ発見した。Windowsは32bitで十分だな。32bitでもPAEで4GB超の メモリ認識するし、仮想メモリは4GBのままだが、AWEを使うことにより バンク切り替え的にメモリウインドウを切り替えられる 568 名前：デフォルトの名無しさん mailto:sage [2016/05/27(金) 19:30:30.19 ID:hSijlNU2.net] >>555 アプリはよくてもカーネルはつらい 569 名前：デフォルトの名無しさん [2016/05/28(土) 04:39:26.17 ID:rTGB9SNh.net] メモリーは俺が確保してやる、任せろ。 570 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 07:51:44.19 ID:Ai+IvVh7.net] おう、この手は絶対、絶対に、死んでも離さねぇ！！ 571 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 11:50:15.87 ID:9WWbP5OA.net] OSに載った気持ちでいなさい 572 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 22:56:21.68 ID:mtPUDASJ.net] >>1みたいなやつは 研究室にヒキって、社会に出たことないんやろ おまえ、本気の糞コードで書かれたペチプ〜とか見たらチビるで あんなんに加えてメモリ管理なんてやらせたら それこそHELLO END OF THE WORLD この世の終わりですわ 573 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 12:20:18.65 ID:4vppD7oq.net] >>558 死んだら離せw 574 名前：デフォルトの名無しさん mailto:sage [2016/06/12(日) 09:40:01.67 ID:mfUrI2Z0.net] 死後硬直ですね 575 名前：デフォルトの名無しさん [2016/06/18(土) 23:15:40.44 ID:03AgrRUX.net] 指摘してるレスがなかったので言っとくが 循環参照は参照カウント方式＋Cycle Collectorでも回収できるから GCは必須じゃないぞ 興味があるならBacon Cycle Collectorで調べてみろ 576 名前：デフォルトの名無しさん [2016/06/18(土) 23:22:46.70 ID:/B2fY0/K.net] 学生の頃は循環参照できないことに困ってたけど、今となっては何時 循環参照が必要になるかさえ思い出せんな。 577 名前：デフォルトの名無しさん mailto:sage [2016/06/19(日) 21:38:00.28 ID:evh9vaek.net] 双方向リスト構造 578 名前：デフォルトの名無しさん mailto:sage [2016/06/19(日) 22:17:16.01 ID:ao4WLgfX.net] >>563 ＞Cycle Collector いわゆるmark&sweep式とどう違うの？ 579 名前：デフォルトの名無しさん [2016/06/20(月) 01:16:50.71 ID:30YoNw6z.net] （コンパクションしてくれるんだろうか） 580 名前：デフォルトの名無しさん mailto:sage [2016/06/22(水) 08:52:46.04 ID:I9Ep4uZo.net] vmが諸悪の根源な気がしてきた 581 名前：デフォルトの名無しさん mailto:sage [2016/07/06(水) 07:12:12.60 ID:aYInvTWe.net] >>568 まずガベージだらけの頭の中を整理すべき 582 名前：デフォルトの名無しさん mailto:sage [2016/07/16(土) 10:10:08.78 ID:+8wH/95N.net] >>565 別に 単方向リストでもなるだろＪＫ ていうかリストの要素をshared_ptrにするのは現代でも有効 リストのリンクヘッダ自体の寿命は要素が明示的にdeleteされるかリスト全体が廃棄されるまでなので リンクヘッダも管理したければリスト固有のストレージ丸ごとな単位でshared_ptrにしたら良い、 希ガス 583 名前：デフォルトの名無しさん mailto:sage [2016/07/16(土) 10:13:41.67 ID:+8wH/95N.net] △: リストの要素 ○: リストの要素が保持するデータ つか開放タイミングをshared_ptrに任せておk、などという発想のは管理しているうちに含めれないがな… 584 名前：デフォルトの名無しさん mailto:sage [2016/07/16(土) 10:38:52.53 ID:6AR6MH2z.net] 一般のグラフじゃなくてリスト構造の話だろ？ 双方向リストはheadとtailへの参照があるが、単方向リストで循環参照は生じようがないが。 585 名前：デフォルトの名無しさん mailto:sage [2016/07/16(土) 11:51:50.13 ID:+8wH/95N.net] >>572 すまんの>>570の単方向リストは正確には循環リストもしくは環状リストと呼んだ方が良いかも試練、 だが、循環リストもしくは環状リストも単方向リストの実装方式の一つではある（初期の『プログラミング言語C++』か何かのslist等 のじゃ…！ 586 名前：デフォルトの名無しさん mailto:sage [2016/08/22(月) 17:06:41.08 ID:oW9zLe2W.net] 循環してるかは後付けでオブジェクトをマークすれば判るんだし 扱うデータ構造から可能性の有無は予測できるし循環自体は大した問題じゃないよ あ、これリークするなと思ったら対策すればいいだけ 問題は他人様のブラックボックスなライブラリを使う場合 587 名前：デフォルトの名無しさん mailto:sage [2016/08/22(月) 19:24:37.36 ID:csr3LedD.net] ？ 今の議論はプログラマーが何も考えないアホでもGC(言語)使ってれば問題無いのか そうでなければ結局なんらかの管理が必要でちゃんとする事しないとリークするから本質的には管理から開放されないよねって話だと思うが 588 名前：デフォルトの名無しさん mailto:sage [2016/08/22(月) 19:33:58.37 ID:01M+MFvA.net] いまどきの子はブラウザアプリしか作れないから ブラウザ再起動とかページ遷移で解決でしょうな 589 名前：デフォルトの名無しさん mailto:sage [2016/08/23(火) 19:56:22.47 ID:cEt4cHHx.net] 現在のGCが不完全なだけであって、 メモリは人が管理すべきでないという考え自体は正しいよ。 590 名前：デフォルトの名無しさん [2016/08/23(火) 20:17:10.56 ID:xIKUFX4H.net] 潤沢なメモリを用意してGCしない戦略 起動時間に限ってGCしなくても問題ない範囲であればGCしない戦略 結局こういうのが勝つ 591 名前：デフォルトの名無しさん mailto:sage [2016/08/23(火) 20:29:14.30 ID:uPhg+qti.net] プロセスを細かく分けて寿命を短くすればそんなの考えなくて済む 592 名前：デフォルトの名無しさん mailto:sage [2016/08/24(水) 13:32:09.69 ID:2RMcAgaj.net] 本当の意味での軽量プロセスをOSがサポートしてくれたら良いんだけどね メモリプールみたいなもんなんだけど、OSのリソースも紐づいてて メモリプール解放時にOSのリソースもちゃんと解放されるようなもの マルチプロセスは非常に強力で良いんだけど メモリ空間が別になるから色々面倒だしパフォーマンスも出にくい 世の中には呼び出したらしばらく処理が返ってこない時間のかかる関数があるけど とうぜんUIが固まったら困るから別スレッドで実行するわけだけど 処理中にユーザーがキャンセルボタンを押したとき 処理を中断する手段が関数側に用意されてなかったりすると、困る 外からスレッドごと殺しても、リソースリークの問題が出る 真っ先に困るのが同期オブジェクト 同期オブジェクトを握った状態で死なれると、それ以降デッドロックを引き起こす それ以外にも、プログラムの整合性が壊れているかもしれないので、以降正しく動く保証がない だから別プロセスで実行して、キャンセルされたときはプロセスごと殺すしか方法が無い しかし別プロセスにするとメモリ空間が繋がってないので面倒 だからその中間がほしい 593 名前：デフォルトの名無しさん [2016/08/24(水) 16:03:33.76 ID:Ku8YOB4B.net] erlang最強 594 名前：デフォルトの名無しさん [2016/08/24(水) 19:53:51.27 ID:B7v3wZLf.net] 軽量プロセスより重量スレッドの方が実現できそう。 595 名前：デフォルトの名無しさん mailto:sage [2016/08/24(水) 20:02:24.36 ID:971rg3P3.net] いつ無くなってしまうかわからんようなメモリのアクセスが簡単になってもほとんど使いみちないだろ。 安全性重視なら別プロセスにして、必要なデータだけ共有メモリで受け渡してのが妥当なところだろう。 596 名前：デフォルトの名無しさん mailto:sage [2016/08/24(水) 20:18:52.71 ID:2RMcAgaj.net] 結論から言うと、Windowsにforkが無いのが面倒すぎるってことなんだけどね 597 名前：デフォルトの名無しさん mailto:sage [2016/08/24(水) 20:32:21.12 ID:N/sC1Ga3.net] >>580 > 処理を中断する手段が関数側に用意されてなかったりする 具体的には？ 598 名前：デフォルトの名無しさん mailto:sage [2016/08/24(水) 22:11:21.77 ID:2RMcAgaj.net] いやそんなもん、中断する手立てが用意されている方が珍しいだろ 599 名前：デフォルトの名無しさん mailto:sage [2016/08/24(水) 22:31:11.60 ID:N/sC1Ga3.net] >>586 で、具体的には出せないと言うことね 600 名前：デフォルトの名無しさん mailto:sage [2016/08/25(木) 11:39:37.19 ID:rs2QvvZe.net] 元々はスレッドが軽量プロセスって呼ばれていたりしたんだがな（アドレス空間の切り替えが不要だからプロセスより切り替えが軽い） まあそれはおいておいて forkを使うと軽量プロセス？とやらの機能が実現できるらしい理屈がわからない forkしたら別プロセスだぞ？ vforkとかなら実行直後は共有しているけど変更を加えた時点で分かれるし まあどちらにしろGCじゃメモリーをはじめとする資源管理からは完全には解放されないって事だ 601 名前：デフォルトの名無しさん mailto:sage [2016/08/25(木) 11:59:23.81 ID:8gaIkILP.net] メモリ空間がつながっていること自体はそれほど考慮してないんよ 単にWindowsはマルチプロセスがしにくい forkあったらちょっとした処理を別プロセスで実行するの、便利じゃん 片づけはプロセスごと殺して終わりだし 602 名前：デフォルトの名無しさん mailto:sage [2016/08/25(木) 15:41:54.51 ID:8f3yfXIl.net] ほしいのはLinuxでいうclone(2)やね 603 名前：デフォルトの名無しさん [2016/09/03(土) 00:41:24.79 ID:XSHFkVCg.net] https://cedil.cesa.or.jp/cedil_sessions/view/1484 リアルタイムGCの実装が凄い 604 名前：デフォルトの名無しさん mailto:sage [2016/10/22(土) 08:52:04.68 ID:v44cYKg6.net] GCもハードウェアに支援させれば全部解決するよ リアルタイム処理含めてね 605 名前：デフォルトの名無しさん mailto:sage [2016/10/22(土) 10:51:46.42 ID:O48rD9qT.net] 再起動最強説 606 名前：デフォルトの名無しさん [2016/11/14(月) 22:33:26.01 ID:A2iFoZHP.net] 固定領域として静的にグローバル変数化、バッファ� 607 名前：ｻすればいいだろ、 それを汚い言うやつがいるが、 潜在ＢＵＧだらけでどうにもできないそれのほうが汚いわ。 [] [ここ壊れてます] 608 名前：デフォルトの名無しさん mailto:sage [2016/11/14(月) 23:45:18.91 ID:JD+cxKWX.net] 例えばChromeとかFirefoxとかが静的にメモリアロケートしてたらどうなるか 609 名前：デフォルトの名無しさん mailto:sage [2016/11/14(月) 23:59:22.37 ID:f4osfHdm.net] そういう発想、嫌いじゃないよ 静的にできるものは、なるべく静的にすべし 俺もそう思う 妙なからくりじみたことにはもう興味が湧かなくなった 最初のころはGCのメカニズムが面白いと感じていたが、もうそういうの、無い いかに静的にシンプルに書くか、こっちのがパズルみたいで面白い すべての事は明確であるべきで、コードはそのようになっているべきだ、と 俺が特に嫌いなのは、何がどの順番に実行されるか、コードを見ただけで よくわからない類のプログラムだ コールバックも基本的に嫌いだ なのでいつ実行されるか分からないマークスイープGCは好きではない 参照カウンタ方式のほうが根本的に安全であり、シンプルであると思う というのも参照カウンタ方式のGCはバグの再現性があるから 唯一の問題は循環参照だが、これも弱い参照を使えば解決する たったそれだけの工夫でマークスイープGCの複雑な仕組みがいらなくなるなら おれはそちらのほうが良いと考える 開放するというただそれだけのことに、あれだけ巨大な仕組みが必要になるのはおかしい 610 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 00:00:47.13 ID:PldPJ2O3.net] マークスイープ系GCはメモリ管理に関しては完璧かもしれないが それ以外のリソースの面倒は一切見てくれない そういったものはファイナライザで開放すればよいわけだが 要らなくなったらすぐさま開放してほしい時に困るので、例えばC#ではDisposeを用意している しかしながら根本的に本当にDisposeを呼んで良いのかは誰にもわからない部分がある もしかしたら他の誰かが使用中かもしれない、という場面もありうる だから誰も使ってないことをプログラマが保証する格好になる その意味ではfree()と大差ないわけで usingという構文が用意されていて、ある程度自動で呼ばれるというだけである 本当に誰も使ってないことを保証するにはマークスイープを走らせなければわからない しかしマークスイープはコストがかかるので、そんな都度都度気軽に走らせられない その点、参照カウンタ方式は参照カウンタを見るだけで使われているかどうかわかるので 都度都度チェックできるし、要らなくなったらその場で即開放できるので Disposeのような仕組みもいらず、解放処理をデストラクタに一本化できるし スマポを使えばデストラクタ自体、書く必要すらないかもしれない そして有り難いことに、デストラクタはメンバ変数やベースクラスに対しても 芋づる式に自動で呼ばれる これはDisposeには無い機能だ 何故無いのか？答えは、勝手にDisposeして良いのかどうか、コンパイラは判断がつかないからだ 誰か他の人が使っているかもしれないわけで、勝手にDispose出来ない Disposeして良いかどうかはプログラマが保証しなければならないので自動化できないのだ 611 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 00:02:48.22 ID:PldPJ2O3.net] 本当にC#で解放処理をまともに書こうと思うと 自身のクラスのメンバ変数にIDisposableを実装しているものがあるかどうかを調べ もし、実装しているものがあれば、自身もIDisposableにし Disposeメソッドを作り、その中で、先ほど調べたメンバのDisposeを呼び出さなければならない これを手作業でやる C#をやったことのある人なら知っている通り、マイクロソフトの示すIDisposableの実装例自体が 非常に煩雑であるわけだが、ともかく、もれがないように、手作業で頑張る まず、IDisposableかどうか調べ忘れるだろうし、Disposeの呼び出し忘れもありうる mallocしたらfreeしましょうと同レベルのことを強いられる このように面倒なIDisposableであるが IDisposableなオブジェクトをメンバに持つと、自身もIDisposableになるということは IDisposableはどんどん伝染していくわけで、手動でDisposeしまくるコードを書き続ける羽目になる このように、まじめに考えると、破たんした方法であることが分かる 根本の問題はDisposeが自動で呼ばれるコードをコンパイラが生成してくれないこであるが 確実にDisposeして良いかどうかを判断するためにはマークスイープを走らせる必要があるので どうやっても自動化は困難であり、プログラマが開放してよいことを保証するという ある種手作業なusingがせいぜいである 参照カウンタ方式であれば、ほぼノーコストで開放して良いかどうか分かるので これらの問題は一切発生しない 解放処理はデストラクタ一本であるし、芋づる式に自動的に呼ばれるので 手動でコードを書かなければならないということもない ランタイムもシンプルであり、バグった時も再現性が期待できる 612 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 00:24:03.03 ID:PldPJ2O3.net] これがC++が未だにかたくなにマークスイープ系GCを搭載しない理由である C++を書くプログラマはweak_ptrを適切に使えるものだという前提のもとに マークスイープ系GCにまつわる数々の問題点を排除したのだ マークスイープ系GCで有利なのは唯一循環参照だけであり そこさえ気を付けることができれば それ以外の部分に関しては参照カウンタのほうが優れている C++は別に時代遅れなわけじゃなく、そういう選択をしたというだけ 今になって考えるとその選択は正しかったと思う 613 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 04:04:15.16 ID:9A/eUvIY.net] メンバーにdisposeしなければならないような設計が良くない。そんなものはメソッド内のローカル変数に止めるべき。 それすらも理解できず(考え付かず)にただ一律なんにでも同じ考え方を押し込むのはただの愚行。 ありもしない、回避可能な杞憂をただ恐れるのは、勉強不足か進歩が止まっているだけ。 だから皮肉を込めて老害と呼ばれる 614 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 04:09:46.64 ID:9A/eUvIY.net] 日本語おかしかった。 メンバーにdisposeしなければならないような物を持たせるのが良くない でした。 615 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 05:19:19.06 ID:ulUg8AFG.net] >>594 参照カウンタよりも固定バッファを動的に確保ですね判ります 616 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 05:20:35.14 ID:ulUg8AFG.net] >>595 firefoxは解放が遅いのでそれやってるのと実質同じ realplayerとかもそうだったな 617 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 08:18:37.29 ID:wcWx6QZb.net] >>600-601 よくないって言われてそうせざるを得ない場合はいくらでもあるしなぁ 例えば動的に出力先を切り替えられるログクラスみたいな奴をどう書けと言うんだろ？ 618 名前：デフォルトの名無しさん [2016/11/15(火) 09:05:11.25 ID:P8K+NdWV.net] >>597 スマポとデストラクタの必要性は関係ないだろ… deleteの必要がない、とか、デストラクトを考えなくて良いってことだと思うけど。 619 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 10:48:15.69 ID:4QSE1fRA.net] スタック変数の 0 クリアすら嫌がる C/C++ が GC 搭載とか夢見すぎ 620 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 10:53:43.30 ID:PldPJ2O3.net] struct test { 　　std::shared_ptr<int> ptr; 　　test(){ ptr = new int; } }; 上のコードはデストラクタを書く必要があるのかないのか スマポを使えばデストラクタを書かなくてよい場合もあり得るということ スマポを使わないのであれば当然デストラクタでdeleteをしなければならないだろう なので、「スマポ」と「デストラクタを書く必要性」は、関係がある ちなみにC#のDisposeはただのメソッドであるので このような芋づる式にメンバ変数のDisposeを呼び出してくれる機能はないし マークスイープなので原理上不可能である 他で使用中でないことをプログラマが保証しないとにはDisposeは呼べないので 自動化できない 621 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 11:05:47.46 ID:TNYjuRyh.net] >>606 ツボったw 効率至上が利点であり特徴だもんな 622 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 12:45:52.53 ID:LZ5unIkv.net] >>607 それptr.reset()使うんじゃないの？ 623 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 13:34:38.18 ID:bbRnuBLg.net] グローバルが嫌われたのは 疑似マルチプロセスでメモリを共有していた時代の汚物だろ 今みたいなOSのメモリ管理ならアプリ単位グローバル常套 624 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 23:45:20.82 ID:nDIaGem/.net] C#/C++よりRustだろ 参照カウンタのオーバーヘッドすらない Firefoxに期待 625 名前：デフォルトの名無しさん mailto:sage [2016/11/16(水) 04:04:29.47 ID:EhKul/vA.net] >>604 ideone.com/9L3kQp これじゃいかんのか？ おかしかったら教えて 626 名前：デフォルトの名無しさん mailto:sage [2016/11/16(水) 12:42:03.97 ID:KQ3Yixih.net] >>612 Write する度に WriteTypeA とかを生成/破棄するってこと？ ログとかならその方が望ましいケースもあるかもしれないけど、例えば性能上の問題でストリームは開きっぱなしにしたいとかもあるでしょ 627 名前：デフォルトの名無しさん mailto:sage [2016/11/16(水) 14:56:37.10 ID:a2T+Z3SD.net] >>613 開きっぱなしにしたいスコープは？ スコープを一つのメソッドにして、同じようにすればいいじゃない コードが必要なら夜にでも書くよ 628 名前：デフォルトの名無しさん mailto:sage [2016/11/16(水) 19:17:42.21 ID:KQ3Yixih.net] >>614 スコープを動的に変えたい場合を想定してるんだが 実行中にログファイルを変更できるアプリケーションとか見たことないの？ 629 名前：デフォルトの名無しさん mailto:sage [2016/11/16(水) 23:34:22.54 ID:EhKul/vA.net] >>615 ログファイルであれば日付で切り替えとかあるね。 そしたらストリーム開きっぱで日付が切り替わったら、閉じて新しいの開き直すとかあるわ。 いつもlog4とか使って主処理と切り離してたから考慮から抜けてたわ。 俺の意見はdb接続とかで一部にしか当てはまらんので、 「基本的には」とか 「リソースを管理する必要があるもの」とか前提がつくね。すまん。 630 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 06:41:14.49 ID:4ie0coBz.net] ログファイルはログが確実に記録されるのが使命であって性能は二の次なのだよ よって開きっぱなしは論外 性能で問題が出るなら吐く量を調節すればいいだろう 631 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 08:38:51.71 ID:eBLDMII7.net] 開きっぱはなんでダメなん？ 632 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 08:52:00.55 ID:YtkNE2sc.net] flushすればいいな 633 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 10:16:22.36 ID:HaGDkE41.net] >>618 アプリケーションエラーとか異常終了した時にバッファされてる内容が書かれないことがあるから 異常終了した時はまさにそのエラーになる直前のログが欲しいのに〜 ってなる w ただログってそういうログばかりじゃないし Apache のアクセスログみたいにいちいち閉じてたら全然間に合わないって現実を知らない >>617 はもう少し経験積むまで黙ってた方がいいと思う 634 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 14:20:53.96 ID:YtkNE2sc.net] >>620 それは開きっぱなしが問題なんじゃなくてflushしてないことが問題なだけで見当違い 635 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 14:29:51.71 ID:HaGDkE41.net] >>621 >>604 から読み直せよ 見当違いはお前の方だよ... 636 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 14:34:26.96 ID:WWFUnGVk.net] とこのように、相手を互いに見当違いであると罵り合うのであった しかし、それは正しい 両者とも正しい 637 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 15:37:17.31 ID:O7mQP4/b.net] スコープの話してるのに flush とか頭わいてるだろ 638 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 21:51:13.35 ID:WZ8TOo4I.net] null安全をアピールしてる人間はObjCerから見ると補助輪付き自転車を渡してきてこれ安全だから絶対に乗れよと言ってくる頭おかしいおじさんにしか見えない Swift移行がこじれるだけだから黙っといて欲しい 639 名前：デフォルトの名無しさん [2016/11/21(月) 14:59:21.88 ID:qSFgYSXv.net] 浜矩子・著 『アホノミクス完全崩壊に備えよ』 『どアホノミクスへ最後の通告』 『みんなで行こうアホノミクスの向こう側』 抑制のない成長に基づく経済政策は終焉 日本国民はどう対処すればいいのか。 新しい政権は民意を反映し、 食糧、住宅、健康、教育、最後に防衛です。 国民の意志を裏切ることは、 極端な場合、自殺や殺人にまでつながります。 民衆の指導者は 職業的政治家ではない人々から見つかるのです。 世界平和の脅威は、 イスラエル、イラン、アメリカです。 イスラエルの役割は跪いて、 パレスチナに許しを請うことです。 アメリカによる他国の虐待に 反対の声を上げなければなりません。 彼らは今世紀（21世紀）を この帝国が出来上がるアメリカの世紀と呼ぶ。 しかし、そうはならないでしょう。 彼らが世界中に‘民主的’制度を確立したい という衝動(世界を支配する)をコントロール するのは、マイト レーヤの任務です。 非常に間もなく マイト レーヤをテレビで見るでしょう。 彼は「匿名」で働いております。 640 名前：デフォルトの名無しさん mailto:sage [2016/12/08(木) 09:10:56.35 ID:FEYStmIt.net] 小規模ならGCのメリットは大きいのかもしれないが、大規模または大量にメモリを食うプログラムにはGCは向いてないのではないか。 あんまり例を知らないが、JAVAで動くマインクラフトのデバッグ画面でメモリ使用量みたら、めまぐるしく増加して一気に減ってるのみてびっくりした。 641 名前：デフォルトの名無しさん [2016/12/13(火) 13:02:48.84 ID:XUF2n21y.net] GC周りに付いて書かれたネットの記事読んできたけど オブジェクトが生成されては次々と死んでいき 生きてるオブジェクトより死んだオブジェクトが多い場合の方が速くなるっぽい >>627 そう考えると長命のオブジェクトが大量にある方が(性能的には)問題だが マインクラフトがそれかは知らない 642 名前：デフォルトの名無しさん mailto:sage [2016/12/15(木) 23:33:53.51 ID:Z/98FfuD.net] >>606 C++はGC支援のメモリモデルが標準に入った と言ってもコンサバGCライブラリ向けだけどな 643 名前：デフォルトの名無しさん [2017/01/18(水) 11:38:56.79 ID:A+XqqRn6.net] 漏れたときの調査が大変 安心してると痛い目にあう 644 名前：デフォルトの名無しさん [2017/01/20(金) 16:23:16.03 ID:4Q3o1w03.net] 参照カウントは循環参照の問題が起こるだけじゃなくて 意外と遅いって聞くけどマジで？ ・メモリをOSから直接確保・解放するのは意外と遅い ・マルチスレッドで参照カウントを使うにはアトミックな操作が必要 ・カウントを自動化すると不必要な参照カウントが起こる とかで 対してトレーシングGCの弱点は回収時に止まる時間が長いところか その対策か、V8やOracle JavaにはGCの時間を制限する機能があるみたいだが それってどうなんだ？ 645 名前：デフォルトの名無しさん mailto:sage [2017/01/20(金) 23:17:39.79 ID:2XlTkpSB.net] まじ 646 名前：デフォルトの名無しさん [2017/01/22(日) 15:00:56.26 ID:lyHWqZIh.net] ^ナマポ 647 名前：デフォルトの名無しさん [2017/01/22(日) 18:20:35.13 ID:CvVvUjG5.net] ストップ・ザ・ワールドの問題さえなくなればGCが最強ってこと？ 648 名前：デフォルトの名無しさん mailto:sage [2017/01/22(日) 18:44:59.67 ID:2ikRDhsq.net] >>634 フルGCの危険があるという点で最強になりえない 649 名前：デフォルトの名無しさん mailto:sage [2017/02/20(月) 19:16:44.90 ID:NKdiRgAe.net] バイオハザード7は28万行のC#コードでできててビルド10秒らしい。 独自VM、独自GCだとか。 650 名前：デフォルトの名無しさん mailto:sage [2017/03/20(月) 22:46:15.84 ID:USOySpAW.net] >>636 ゲームで28万ステップって長すぎね？ 651 名前：デフォルトの名無しさん mailto:sage [2017/04/01(土) 12:49:43.55 ID:ZgIqHRoc.net] バイオの資料見つけた。 https://www.slideshare.net/mobile/capcom_rd/re-engine-72302524 FrameGCって独自アルゴリズムなのか。 652 名前：デフォルトの名無しさん [2017/05/26(金) 12:05:46.50 ID:uY9cFHyF.net] >>638 FrameGCはゲームというかRTSに特化したGCだね ・ローカルに発生したオブジェクトは溜め込んでフレームの終わりにまとめて開放する ・グローバルに結びついたオブジェクトにはカウンタGCを適用する ・フレーム毎に循環参照のチェックを少しずつ行う ざっくりこんな感じ？ 653 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 20:16:13.14 ID:0194UVlm.net] 内部的にC#をC++に変換してるからC#をスクリプト的に使ってるだけで実質C++だな。当然GC・メモリアロケータ周りも身内実装。 654 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 22:20:13.64 ID:uY9cFHyF.net] >>640 C++のスマートポインタみたいな形で実装できるのかな？ 俺は検討してみたけど無理だったw 655 名前：デフォルトの名無しさん mailto:sage [2017/06/03(土) 06:38:16.81 ID:MyiMvGI/.net] そこまでやって既存のフレームワーク使えるのって疑問が。 656 名前：デフォルトの名無しさん mailto:sage [2017/06/03(土) 10:06:08.23 ID:sCohk93m.net] GCがconflictするんですね判ります 657 名前：デフォルトの名無しさん [2017/09/11(月) 12:41:54.43 ID:YXmvV/7e.net] 「メモリ」+「フラグメンテーション」で検索すると色々と詳しい話が出てくるね。 658 名前：デフォルトの名無しさん [2017/09/11(月) 13:14:06.52 ID:YXmvV/7e.net] ここが分かりやすかった ttps://www.uquest.co.jp/embedded/learning/lecture17.html ttp://www.kaede-software.com/2015/06/post_655.html 659 名前：デフォルトの名無しさん mailto:sage [2017/09/11(月) 13:44:59.20 ID:I3u+9T/v.net] メモリのフラグメンテーションなど実質的には気にする必要は全くない なぜなら現実のコンピュータにはMMUが付いてるから 物理メモリの連続空間が枯渇することは考えなくてもよい あり得るとしたら32bitプロセスでの論理アドレスの連続空間の枯渇であるが 64bitプロセスにすれば問題ない もともと論理アドレス空間が枯渇するかもしれないほどメモリを使うのなら 64bitプロセスにするのが当たり前なので・・・ というわけでメモリのフラグメンテーションは気にしなくてよい CPUのキャッシュのヒット率を上げるとか、そういうことでなければ 660 名前：デフォルトの名無しさん mailto:sage [2017/09/11(月) 17:53:09.29 ID:P5pczjP2.net] そうなん？ ガベコレの回収効率が悪くなって 無駄な使用領域が増えて枯渇しやすくなるんじゃね 661 名前：デフォルトの名無しさん mailto:sage [2017/09/11(月) 18:13:16.59 ID:SGfZs9nE.net] >>647 GCのアロケートサイズとページングサイズの区別もついてないアホはスルーでよろしく 662 名前：デフォルトの名無しさん mailto:sage [2017/09/11(月) 20:33:05.66 ID:I3u+9T/v.net] 程度の問題であって 世のプログラムがフラグメンテーションなど気にせずとも 普通に動いているのを見てわかる通り、問題になってない MMUがあるから 663 名前：デフォルトの名無しさん mailto:sage [2017/09/11(月) 21:54:05.93 ID:khvQxUtn.net] >>646 そういうぬるい環境で済むところもあればそうじゃないところもある ゲームコンソールだと物理メモリサイズに最適化するからな STLとかdefault allocatorで気軽に使ってヒープ汚しまくってると そのうち物理メモリ足りなくなってページアウト 664 名前：デフォルトの名無しさん mailto:sage [2017/09/12(火) 10:09:32.99 ID:g0xsLkF6.net] 必ず来ると思った、その反論 しかし、稀な事例を持ち出して、どうこう言っても仕方がない 665 名前：デフォルトの名無しさん mailto:sage [2017/09/12(火) 12:38:17.20 ID:E3lbzyXM.net] MMU のお陰でふらぐめんてーしょんが起きない環境の方が希だと思うが 666 名前：デフォルトの名無しさん mailto:sage [2017/09/12(火) 13:22:19.16 ID:crCgFvVY.net] フラグメンテーションはアドレス空間や実メモリ量が限定される環境をどううまく使うかの話だから MMUがあって64bit空間なら平気と言われてもな 667 名前：デフォルトの名無しさん [2017/09/13(水) 03:53:58.25 ID:TAF2DPKT.net] そそ、複雑なプログラムって書こうと思えばいくらでも複雑化するからな。 で、簡潔で高度と思われる機能を追加していくほど難易度は指数関数的に増大するし。 668 名前：デフォルトの名無しさん [2017/09/13(水) 05:10:44.22 ID:t818hmCa.net] でも実際スマホアプリ作ってんのにフラグメンテーションを防ぐ為に最初に使用する分全部確保しておいて、その中で割り当てするんだーとかいって、オレオレアロケーター作ろうとする頭の悪いやつがいて困る。 逆にお前の作ったそのアロケーターの中でフラグメンテーションして枯渇するわと。 669 名前：デフォルトの名無しさん mailto:sage [2017/09/13(水) 07:42:12.50 ID:7O+lQKpp.net] 組み込みなんかでよくあるそういうのは、どっちかというと最初に確保したメモリ以上を 使用しないことを保証するためにやるもんだろう。 670 名前：デフォルトの名無しさん mailto:sage [2017/09/13(水) 08:52:01.48 ID:Vaq5SeW/.net] アロケータ置き換えるだけでは普通解決しないでしょ >>655 こそが置き換えて何するのか理解できてない気がする 671 名前：デフォルトの名無しさん mailto:sage [2017/09/13(水) 22:09:52.04 ID:PcFMQESF.net] むしろ一定時間を保証する（なのでサイズは固定長とかが多い）もんだろ 672 名前：デフォルトの名無しさん [2017/09/17(日) 13:06:26.21 ID:S40DCpdn.net] いくら64bitあっても設計が雑ならメモリ枯渇するでしょ ページング方式でメモリ消費されてんだし 673 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 13:32:06.14 ID:2kxiy1Rb.net] MMUのアドレス変換コストもタダじゃない。 TLBキャッシュ外れたら遅くなる。 674 名前：デフォルトの名無しさん [2017/09/17(日) 13:32:07.34 ID:S40DCpdn.net] 1回のメモリ取得で4kづつ消費されるわけか 675 名前：デフォルトの名無しさん [2017/09/17(日) 13:49:19.58 ID:S40DCpdn.net] ツリー状のメモリ管理するとあっという間にメモリ無くなるな class CTree{ std::vector<CTree>; }; とか 676 名前：デフォルトの名無しさん [2017/09/17(日) 14:00:55.72 ID:S40DCpdn.net] こうするとさらにメモリが消えていくな class CTree{ std::map<std::string,CTree>; }; 677 名前：デフォルトの名無しさん [2017/09/17(日) 14:12:30.87 ID:S40DCpdn.net] 間違えた。 class CTree{ std::vector<CTree> m_Tree; }; class CTree{ std::map<std::string,CTree>m_Tree; }; で、ツリーのノード一つ毎に上は4kづつ下は8kづつメモリを消費するわけで・・・ 678 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 15:23:52.56 ID:iyMogwhx.net] 一回のメモリ取得で4KBってのが嘘だから意味が無い話だね MMUついてたって、そんなアホな実装は無い 4KBだかの1ページ分の中での細かなメモリ断片化はおおむね無視できる、ということ メモリ断片化で困るのは大きなサイズのメモリを確保しようと思ったとき 連続したアドレスが確保できなくてコケる、ということだからね これに対してMMUは有効ということ メモリが断片化で多少無駄遣いされる分にはスワップしてでも動くから そんでこれは程度問題 大概の場合は問題にならない 679 名前：デフォルトの名無しさん [2017/09/17(日) 15:38:01.00 ID:S40DCpdn.net] https://ja.wikipedia.org/wiki/動的メモリ確保 ＞また、粒度の細かいページングは、ページングテーブル ＞(物理アドレスと論理アドレスの対応表)が大きくなるため、 ＞4KB程度の大きなブロック単位でしか割り当てることができない。 ウィキペディア見るとそのアフォな実装がまかり通ってると読めるんだが・・・ 680 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 15:48:55.35 ID:iyMogwhx.net] アホだなぁ OSレベルのメモリ確保と言語レベルのnew、mallocは別 681 名前：デフォルトの名無しさん [2017/09/17(日) 16:00:06.71 ID:S40DCpdn.net] こっちも参考になる https://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%A2%E3%83%AA%E7%AE%A1%E7%90%86%E3%83%A6%E3%83%8B%E3%83%83%E3%83%88 CPUによってMMUの実装が異なる点は面倒だな 682 名前：デフォルトの名無しさん [2017/09/17(日) 16:06:24.06 ID:S40DCpdn.net] >>667 ちゃんとmallocやnew時のアドレス確認はしたか？？かなりアフォな動作してるぞ？ まあ、多少のrealloc程度の処理なら何とかしてくれるけどな。 683 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 16:13:26.66 ID:iyMogwhx.net] mallocやnewは 大きなサイズを確保するときと 小さなサイズを確保するときで アルゴリズムが切り替わる 684 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 16:17:08.43 ID:iyMogwhx.net] VC++2015での実行結果 auto a = malloc( 10 ); auto b = malloc( 10 ); wchar_t tmp[ 100 ]; ::swprintf_s( tmp, 100, L"a = %x, b = %x \n", a, b ); ::OutputDebugString( tmp ); ---------------------------------------- a = 10a4f0, b = 10a508 残念でしたね 685 名前：デフォルトの名無しさん [2017/09/17(日) 16:17:49.54 ID:S40DCpdn.net] MMUは多少以上の処理をすると簡単にフォールト返すのが困りもの 結局初心者レベルのプログラマしか想定してないんだよな 686 名前：デフォルトの名無しさん [2017/09/17(日) 16:30:36.71 ID:S40DCpdn.net] >>671 realloc使った事ある？ 687 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 16:34:30.81 ID:iyMogwhx.net] お前が残念なことと何の関係が？ あほらし 688 名前：デフォルトの名無しさん [2017/09/17(日) 16:37:39.46 ID:S40DCpdn.net] 複雑なことをしていると、それがまるで正しいかのように思う点がアフォ 多少複雑なことをしていてもアフォな挙動をする可能性はあると考えるべき 689 名前：デフォルトの名無しさん [2017/09/17(日) 17:05:23.31 ID:S40DCpdn.net] malloc,newの挙動の説明ってまんまMMUの説明なんだよな だから複雑なアルゴリズムを使われていると思うのはMMUが複雑な挙動をしているから でも、そんなに複雑な挙動してるか？？ 単に過去のアプリとの互換性の問題で変な事をしているだけだぞ 690 名前：デフォルトの名無しさん [2017/09/17(日) 17:16:19.17 ID:S40DCpdn.net] たいがいのmalloc,newはMMU次第でいくらでも挙動が変化するからな ちゃんとPC毎に動作確認したか？？ 691 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 17:44:23.50 ID:4FsrO7aF.net] ID:S40DCpdn しったかしすぎ mallocの挙動はヒープのアルゴリズム次第 692 名前：デフォルトの名無しさん [2017/09/17(日) 17:55:14.06 ID:S40DCpdn.net] malloc,newの挙動はハードとOSによって変化するという記述は見たことあるけどな 693 名前：デフォルトの名無しさん [2017/09/17(日) 18:02:58.95 ID:S40DCpdn.net] ごめん、ハードとソフトウェアだった 694 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 18:10:58.66 ID:hRPbVJUN.net] ヒープの管理しないでなんとかなるレベルのものはgc言語使えばいいんでは？ このスレの趣旨的にそうでしょ？ 695 名前：デフォルトの名無しさん [2017/09/17(日) 21:59:59.26 ID:S40DCpdn.net] 自分はメモリ対策プログラムを作って対応したけどな。 メモリサイズを三種類用意して、メモリに対するガードの確実な作りにした。 現在のサイズに使われてるサイズにリミットサイズの三種類のサイズな。 外に出てくるサイズは現在のサイズ、 使われてるサイズはメモリを増やした場合の最大取得サイズで、事実上の取得サイズ、 リミットサイズは取得できるメモリの上限。 で、これらを組み合わせてスーパークラスを作って基本的に対応させてる。 696 名前：デフォルトの名無しさん [2017/09/17(日) 22:08:00.63 ID:S40DCpdn.net] メモリの増減には現在のサイズで対応し、このサイズが必要以上に大きくなると 使われてるサイズを拡張するようにした。リミットサイズは滅多に使わないけれども、 一応対応させた。 メモリに対する読み書きは専用関数を経由して読み書きするようにしたから、 素人が使っても安全なぐらいのプログラムになってる。 697 名前：デフォルトの名無しさん [2017/09/17(日) 22:27:01.93 ID:S40DCpdn.net] あと、動的配列ってのを作って、複数のメモリ取得に対応させた。 メモリにヘッダとフッタを用意して、フッタには複数配列のデータに対応させ、 ヘッダには配列数とメモリサイズを入れてる。フッタには>>682のデータを持たせた。 ある意味では拡張コンパクションみたいなモノになった。 698 名前：デフォルトの名無しさん [2017/09/17(日) 22:33:12.53 ID:S40DCpdn.net] で、アローケートが一回だけになるようにして、あとはリアロークで対応させた。 おかげでメモリの消費効率は異常なまでに効率よく使えるようになったよ。 あと、動的配列使う場合はいったんメモリをフォーマットするようにしたけどね。 699 名前：デフォルトの名無しさん [2017/09/17(日) 23:21:53.67 ID:S40DCpdn.net] それから、動的配列は入れ子構造にすれば色々と応用がきくようになってるけどな。 で、追記式みたいにデータが動くツリー構造とかが使えるようになってる。 700 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 23:27:13.12 ID:2kxiy1Rb.net] アセンブラできない馬鹿がC++使うことを想定するとGCは成功と言わざるをえない。 701 名前：デフォルトの名無しさん mailto:sage [2017/09/18(月) 05:14:41.46 ID:4HKrfROv.net] ID:S40DCpdn は壊れたプログラマ 702 名前：デフォルトの名無しさん [2017/09/19(火) 04:18:18.94 ID:GmtdcLyZ.net] メモリを動かして処理すれば出来る事なのにな 出来る事を出来ないというのは間違い 703 名前：デフォルトの名無しさん mailto:sage [2017/09/19(火) 09:15:50.12 ID:sOczhhK4.net] 誰へのレスかすらわからないというね 誰も何も「出来ない」という趣旨のレスはしてないと思うが 独り言かね 704 名前：デフォルトの名無しさん [2017/09/19(火) 12:34:55.99 ID:kI9ocUjD.net] 前日に連続して意味不明な独り言してるやつがいるからそれの続きだろ 705 名前：デフォルトの名無しさん mailto:sage [2017/09/19(火) 17:17:32.47 ID:xxOzXrDl.net] ワッチョイ推奨 706 名前：デフォルトの名無しさん mailto:sage [2017/09/23(土) 13:33:17.07 ID:J7EIO5I9.net] malloc()関数の内部はOSからメモリをまとめて取ってくる処理と、 すでに取ってきたメモリを（free()で空きが生じたとき）やりくりする処理の2本立て 前者の処理（システムコールの呼び出し）は比較的高コストなのでmalloc()の度に呼びはしない また後者の処理は、連続したアドレス範囲のメモリを確保できている前提で動く ページングはもっと下のレイヤーで行われるので、 malloc()のコード自体がMMUの有無やOSの違いを関知したりはしない 707 名前：デフォルトの名無しさん mailto:sage [2017/09/23(土) 13:35:30.80 ID:J7EIO5I9.net] 例外的な変態実装は知らんが、まあ普通は 708 名前：デフォルトの名無しさん mailto:sage [2017/09/23(土) 14:27:08.01 ID:Dvp9BlYO.net] 最近はjavascriptのレイヤーとかまで出来てさらに複雑面倒に 709 名前：デフォルトの名無しさん mailto:sage [2017/10/26(木) 07:49:10.45 ID:7YV3WIz9.net] かなり無駄な処理してそうだ 710 名前：デフォルトの名無しさん [2018/03/11(日) 23:00:34.15 ID:gpjOI+baf] スタック構造、服を着たり脱いだりすることに例えられますね。 711 名前：デフォルトの名無しさん [2018/05/23(水) 21:27:23.53 ID:Au5e7VGg.net] 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 役に立つかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』 3682F 712 名前：デフォルトの名無しさん [2018/07/05(木) 00:30:07.61 ID:RfoszcD2.net] IZ6 713 名前：デフォルトの名無しさん mailto:sage [2018/08/31(金) 07:07:54.70 ID:EIZBTnQd.net] 保守 714 名前：デフォルトの名無しさん mailto:sage [2018/08/31(金) 23:14:14.49 ID:qeyIwfZb.net] 結論：GCは失敗 715 名前：デフォルトの名無しさん [2018/10/30(火) 23:04:20.19 ID:POwfr3jz.net] GCをルンバで例えたらどうだろう 自動 しかしテーブルの上や 冷蔵庫の中は片付けない 日常生活にさしさわりなく動いてほしい 716 名前：デフォルトの名無しさん mailto:sage [2018/10/30(火) 23:46:35.14 ID:j0ABINKp.net] それに加えてルンバが動けるように床は片付けておかないといけないとか 自動で上手く機能させるために気にしないといけない事が色々ある 717 名前：デフォルトの名無しさん mailto:sage [2019/07/03(水) 08:55:46.04 ID:XKc3eOoC.net] もういらないって明示的に書かなきゃならないのなら自前で管理するのと一緒だよな。 アマチュアがサンデープログラムしたり、短時間で終了するアプリならむしろ楽チンだけど、 365日24時間稼働し続けるシステムには致命的な問題になるからなぁ 718 名前：デフォルトの名無しさん [2020/02/13(木) 08:56:02.27 ID:B+Fb/epo.net] まあ落ちるアプリの多いこと 719 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 15:29:41.61 ID:z5cRWLgY.net] GCがある言語でも、shallow copy と deep copy のどちらにすべきかの判断が難しくて、結局、間違えてバグの原因になる可能性がかなり残る。 また、C/C++ポインタのミスを危険視する人がいるが、多くの場合はプログラム開発時にテストをすれば間違いが発見できる。 C/C++でのバッファオーバーランを気にする人がいるが、逆にGCがある言語でも、間違って1つ右隣の要素にしてしまったり、処理する個数を1つ間違ったりするミスは有り得て、その場合、厳密な意味でのバッファオーバーランは無くても処理内容自体はバグる。 720 名前：デフォルトの名無しさん [2020/02/22(土) 01:52:20.63 ID:eI8xgqVo.net] No GC派なんだけど、WebサーバーをC++とかで実装しても結局力持て余す感はあるよな それだからかなり性能下げてもいいからちょっとでも早く作れるスクリプト言語採用されるってのもありそう 721 名前：デフォルトの名無しさん mailto:sage [2020/02/25(火) 21:09:3 ] [ここ壊れてます] 722 名前：6.95 ID:EsX3m3+2.net mailto: GCのメリットは言語の文法が簡単になること。 GCはスクリプト言語のためにある。 [] [ここ壊れてます] 723 名前：デフォルトの名無しさん [2020/02/26(水) 10:49:39.07 ID:wiEfavJ1.net] (destructor)() dispose() destroy() close() free() delete 724 名前：デフォルトの名無しさん [2020/12/29(火) 01:21:48.14 ID:qxevuYQ38] 数学は「定義」にかえることが大事！ https://www.youtube.com/watch?v=yhrUT4bLm7Q 大学で本気で学問をしたい人へのアドバイス https://www.youtube.com/watch?v=7G7XbRSdk9k 高校生でも雰囲気だけ分かるガロア理論 https://www.youtube.com/watch?v=LiPv0VuSvaE 高校生でも雰囲気だけわかる圏論 https://www.youtube.com/watch?v=D2GU4cmm3Ys&t=225s 高校生でも雰囲気だけ分かるゼータ関数とリーマン予想 https://www.youtube.com/watch?v=MaerL2XLaqk 高校生でもわかる】いろいろな積分　リーマン，ルベーグ.. https://www.youtube.com/watch?v=jzfaFCDn5JY 数を創る話?自然数から複素数への構成? https://www.youtube.com/watch?v=dQ2nFUTNchU 高校数学と何が違うの？大学数学でつまずかないためのアドバイス！［大学数学準備講座1/4］ https://www.youtube.com/watch?v=duXZGbRviG4 【高校数学】極限の誤解を解く https://www.youtube.com/watch?v=cPNttp7b1Gs 725 名前：デフォルトの名無しさん mailto:sage [2021/10/13(水) 08:41:51.52 ID:Qk99MJFD.net] 今やGCのない言語でweb framework書く人間は絶滅危惧種 726 名前：デフォルトの名無しさん mailto:agete [2022/12/27(火) 13:22:02.97 ID:k0608tOt.net] このスレってガイジ扱いされてたけどRustとか出てきて実は正論だったんじゃね？って見直してるわ 727 名前：デフォルトの名無しさん [2022/12/27(火) 15:08:00.70 ID:ITKU+yxr.net] てへっ(∀｀*ゞ)ﾃﾍｯ 728 名前：デフォルトの名無しさん [2022/12/28(水) 20:55:42.01 ID:kKtGrfmE.net] おれはGCが最初から分かりづらいなぁと思ってたよ。mallocやnewより 729 名前：デフォルトの名無しさん [2022/12/29(木) 10:46:26.29 ID:jCj0trE4.net] >>709 release 730 名前：デフォルトの名無しさん mailto:sage [2022/12/29(木) 16:52:23.68 ID:HWC94+Gl.net] GCは停止時間問題を解決できないまま生涯ふわふわした存在で居続けるのだよ 731 名前：デフォルトの名無しさん [2023/01/01(日) 09:16:28.52 ID:A1pcbmVG.net] >>1は、2014年に問題提起してるのか・・・。 Rustとかは2010年ころ発表だけど、実際に一般に知られるようになったのって2021年頭から >>1は、それなりに的を射た技術理解・評価をしてるんだな 俺は人気の言語を覚えて、周りが言ってるメリットを、反対派にコピペするだけだけどｗｗ ま、Pythonのお手軽さを超えることはないと思うけど、どこまでRustは伸びるのかなぁ 732 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 15:30:25.91 ID:MLBtrq1u.net] やはりGCは必要だった WebAssemblyにガベージコレクション機能が登場、Chrome 111で試験的実装に。Dartなど高級言語のWebAssembly対応へ前進 https://www.publickey1.jp/blog/23/webassemblychrome_111dartwebassembly.html 733 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 09:06:41.51 ID:fIr5pCup.net] すべてがBASICに戻る 734 名前：デフォルトの名無しさん [2023/02/11(土) 11:51:58.99 ID:2GIAa1ZP.net] >>719 それもいいな 735 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 00:10:24.00 ID:ZNO423TE.net] GCを含め、「機械に不慣れな人でも簡単にプログラミングできるようにする」という これまで高級言語が行ってきたような試みはすべてAIに取って替わられるような気がする まあ、現時点のAIは使い物にならないかもしれないが、いずれは… 736 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 23:04:44.35 ID:hNo+M64i.net] AIに「これはゴミか？」を学習させていって人間がゴミ認定される日も近い 737 名前：過去ログ ★ [[過去ログ]] ■ このスレッドは過去ログ倉庫に格納されています

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef