- 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/
- 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
ファイルの分割は必ずしも必要ではないし更新モデルから読み取りモデルへの同期も必要ないよ
|
 |
