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/ 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 タモリが昔宣伝してやつ？

---

---

[ 続きを読む ] / [ 携帯版 ]

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