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

**デフォルトの名無しさん転載ダメ©2ch.net** · 2015/11/18(水) 23:24:59.79

GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。
以下GCと記す

プログラマをメモリ管理から開放する！
といいつつ、メモリリーク問題の文献が大量にある。
これすなわち、メモリリーク問題が全然解決していないということ。
さらに、メモリ解放のタイミングの文献まで大量に生み出した。
これすなわち、新たなるメモリ管理に関する問題を生み出したということ。

malloc、freeじゃないが
結局のところ、メモリを管理するという技術は、今しばらくは、身につける・教える・学ぶべきではないだろうか？
使って、そのまま放置しても、基本的にはGCがなんとかしてくれている。
ランジョブからジョブ終了までさほどの時間を要さない。メモリも大して使わないならいいだろう。
しかし、規模が大きくなり常駐ジョブやメモリ大量使用のジョブになってくると、そんなメモリ管理の方法でやっていると、
上記「文献」を生み出されてしまう。

入門時は、メモリに無頓着でもいいだろう。それよりも、目的を達成することが先決だ。
しかし、慣れてきたら、やはりメモリの管理まで余裕を持って自分で行うべきだろう。

前スレ
GCは失敗。メモリは自分で管理せよ！
http://peace.2ch.net/test/read.cgi/tech/1412986420/

**デフォルトの名無しさん** · 2015/12/06(日) 21:28:20.04

いちおう訂正しとこｗ

StringBuilder sb = 略
s = sb.Append(a)中略.Append(d).ToString()

**デフォルトの名無しさん** · 2015/12/06(日) 21:50:20.98

そもそもその最適化は仕様なのか

**デフォルトの名無しさん** · 2015/12/06(日) 22:27:08.91

>>218
？？、これJavaだぞ。演算子オーバーロードなんて出来ないから
>>219
違う違う。+の連結がStringじゃなくてStringBufferに
最適化されるらしいって話だけで、StringBulderって
必要ないでしょ？レガプロ？(笑)、って認識レベル

しかもそいつ一人ならまだしもスレに同じレベルの
認識の奴結構多かったよ。レベルの低さ舐めたらあかんで

**デフォルトの名無しさん** · 2015/12/07(月) 01:50:02.58

>>222
実装云々でなんで演算子オーバーロードがでてくるんだ？

**デフォルトの名無しさん** · 2015/12/07(月) 05:22:13.32

逆だろ？
C#との勘違いでないなら、その最適化されるJVM実装とやらを示さないと

**デフォルトの名無しさん** · 2015/12/07(月) 07:11:57.22

>>219
全く逆の認識してないか？
classファイル解析したら分かるけど、ループ中の+=の方が問題で毎回newされるから遅い

s = a + b + c + d の方は一つしかStringBuilderのインスタンスは作られない

**デフォルトの名無しさん** · 2015/12/07(月) 08:02:18.14

こうやって、比較的プログラミングという行為を好きでいる・好きでやっている・興味を持っているという人ですらまともに言語仕様を理解出来ていない。
malloc、freeで管理、GCで管理だと、機構の複雑さは後者。
結局GCもその機構を正しく理解しないと参照が切れてない、参照が切れていても別のリソースが・・・と。
機構を正しく理解していることが前提なら、機構はシンプルなほうがいい。
その点を誤ったから
>プログラマをメモリ管理から開放する！
>といいつつ、メモリリーク問題の文献が大量にある。
>これすなわち、メモリリーク問題が全然解決していないということ。
>さらに、メモリ解放のタイミングの文献まで大量に生み出した。
>これすなわち、新たなるメモリ管理に関する問題を生み出したということ。
なんてことになったんだろうね

**デフォルトの名無しさん** · 2015/12/07(月) 08:12:44.70

そもそもプログラマの大半にマネージリソース、アンマネージリソースとはなに？
って質問してまともに回答できる割合がどんなもんになるのか
始めたら終わらせる
これワンセットね
にしたほうがミスはなくなるかと
ファイル開いたら閉じる
メモリ確保したら解放する
通信接続したら切断する

**デフォルトの名無しさん** · 2015/12/07(月) 09:22:45.43

やっぱりARC最強だな

**デフォルトの名無しさん** · 2015/12/07(月) 15:38:30.00

結局いつ開放されるか分からないってのが曲者で
使い終わったら確実にリソースを開放してほしいときは
別の仕組みが必要になってしまったってのが問題だろう
その別の仕組も、C++のデストラクタのようにクラスのメンバに関して
芋づる式に呼び出す仕組みがないから
C++のデストラクタがやっていることを手動で再現しなければならない始末

一方でC++のスマポなどの参照カウンタ方式は循環参照だけが問題だが
それ以外の問題が一切発生しない、デメリットは循環参照だけ
しかも循環参照が発生する場合は片方をweak_ptrにすれば良い
ということが分かりきっているし、循環参照が発生する箇所も
設計段階でわかる

循環参照に気を配れる知能が有るのであれば、参照カウンタ方式のほうがスマート

**デフォルトの名無しさん** · 2015/12/07(月) 17:29:26.60

>>229
処理速度やタイミングがシビアな組み込みや科学技術計算系とかならいざしらず、
ソレ以外は、実際の解放のタイミング自体は問題にならんでしょ。(膨大なメモリの使用も別だけど)
問題は、使い終わったよーって明示しないで良い。という運用が結局、悪い結果をもたらしているという点。
メモリの管理をしっかり最後までやるクセのないプログラマは、
平然と参照が途切れている可能性のあるポイントで参照しに行こうとする。
結局は、そいつがバカだからに集約されてしまうんだけど、使い終わりの明示をしない文化がバカを生む土壌となっている

**デフォルトの名無しさん** · 2015/12/07(月) 18:21:02.44

そういう事になる原因ってさ、構造がぐちゃぐちゃでオブジェクト間も依存しまくって、
いつ解放していいのかわかんねえーというヘボいプログラミングなんだろうなと思う。

**デフォルトの名無しさん** · 2015/12/07(月) 18:23:12.12

と馬鹿なSEやPGはそう思うだろうなとも思う。

**デフォルトの名無しさん** · 2015/12/07(月) 19:54:31.23

ある意味メモリなんて一番扱いやすいリソースだからな。
メモリの管理すら適当なプログラマが、他のリソースを適切に扱える訳がないのに、GC前提の言語ではそちらのケアが言語側でやりづらくなってしまっている。

**デフォルトの名無しさん** · 2015/12/07(月) 20:05:22.53

メモリ意識した時点で雑魚プログラマ決定だろ。
JavaScriptもPascalも使えないんじゃ話にならないよ。
おちんぽ見られることを意識しすぎて温泉に入れないようなもの。
癒やしのない人生に刺激なんてない。←これ名言

**デフォルトの名無しさん** · 2015/12/07(月) 20:07:43.02

>>231
そう。そういう状態にしちゃう原因が、いい加減なメモリの管理で教育された結果にあるのではないか？ということで。

**デフォルトの名無しさん** · 2015/12/07(月) 20:09:47.14

>>234
だれの名言かしらんが、

刺激のない人生に癒やしはない。

ならなんかしっくりくる。まぁ逆とっても同じ意味だからいいんだけど・・・。

**デフォルトの名無しさん** · 2015/12/07(月) 20:16:31.05

メモリ意識しないプログラマとかカスだろ。

**デフォルトの名無しさん** · 2015/12/07(月) 20:42:25.43

JavaやC#ではリソースをプログラマが管理してはいけない
せっかくメモリ管理を透過的にしたのにリソース管理でコードをより複雑化させては意味がない
真っ当な教育を受けた少数のプログラマがSafeHandleを作成する
末端のプログラマはSafeHandleのファイナライザに全てを任せてメモリと同様にリソースを完全に透過的に扱うべきだ

**デフォルトの名無しさん** · 2015/12/07(月) 23:25:36.31

>>230
JavaのGCでサーバー応答が止まるなんてザラにある話だよ
それを聞いたことがないなら文系SEと同レベルだね

>>238
管理放棄して開くだけ開いて計算資源を食い潰す玄人気取りプログラマ

**デフォルトの名無しさん** · 2015/12/08(火) 00:48:22.00

full GCが頻繁に生じちゃうのは明らかに設計ミスやな
immutableな短命objectを使いまくるのだ。。
つかimmutableなオブジェクト使いまくるとGCないときつくね？

**デフォルトの名無しさん** · 2015/12/08(火) 02:05:45.39

RAIIで事足りる
immutableかどうかとＧＣは無関係

**デフォルトの名無しさん** · 2015/12/08(火) 02:21:53.95

むしろ短命なオブジェクトなんてスタックで十分だし
管理するならshared_ptrのが優れてる

**デフォルトの名無しさん** · 2015/12/08(火) 03:41:28.67

ライブラリ、アプリ、ユーザの三者で考えないと
一部リソースはユーザがを閉じることができる。
そのときアプリの参照を消す仕組みがどのライブラリにもない

**デフォルトの名無しさん** · 2015/12/08(火) 08:07:46.77

>>243
よくわからんが、それは階層的におかしいのでは？
ユーザーがアプリを通さずにリソースを閉じる事ができるって事？

**デフォルトの名無しさん** · 2015/12/08(火) 12:16:07.11

Manager.Execute((res) => ...);

これが終着点
短命なリソースは全てこの形式で事足りし長命なリソースはファイナライザにでも任せればよい
ユーザーが管理しちゃ絶対にダメ

**デフォルトの名無しさん** · 2015/12/08(火) 15:11:36.25

このスレでGCいらんて言ってる人たちは環境に恵まれてるんだなぁって思う

**デフォルトの名無しさん** · 2015/12/08(火) 15:20:06.88

GC
タモリが昔宣伝してやつ？

**デフォルトの名無しさん** · 2015/12/08(火) 15:28:54.90

むしろGCなんて環境良くないと使えないだろ

**デフォルトの名無しさん** · 2015/12/08(火) 16:16:30.38

参照がなくなったタイミングで必ず開放してくれて
かつ
循環参照でも問題ない
パーフェクトなGCが有れば最高なわけだが
実際にはそんなGCは無い

となれば、通常であれば言語側は性質の異なる複数のGCを用意しておいて
使う側はシチュエーションに合わせて選べるようにしておくのが自然な発想
しかしそういう言語は殆ど無い、これが問題

といってもマークスイープ系GCが前提のC#やJavaのような言語に
RAIIの発想を持ち込もうとしても
C++のデストラクタのように自身のメンバのデストラクタを自動で芋づる式に呼び出す仕組みが
元々無いので、手動で芋づる式に解放関数を呼び出すコードを書かなければならなく
うまく行っていない

**デフォルトの名無しさん** · 2015/12/08(火) 16:25:08.60

>>246
JavaでPhantomReferenceも使ったこと無い人って恵まれてるんだなあって思う

>>249
無いのでってもろにAutoCloseableとかあるやん

**デフォルトの名無しさん** · 2015/12/08(火) 16:37:24.80

>>250
自分のクラスがファイルなんかのcloseを持つリソースをメンバに持っていたとする
そうすると、それらのメンバのリソースを明示的にcloseできるようにするために
自身もcloseを実装することになるだろう
それで、自身のcloseが呼ばれた時、勝手にメンバのcloseが呼ばれるか？
結局手動でメンバのcloseを呼び出しまわるコードを書かなければならない

C++のデストラクタならメンバのデストラクタが芋づる式に勝手に呼び出されるから
気にしなくて良い

**デフォルトの名無しさん** · 2015/12/08(火) 17:08:50.17

強参照、ソフト参照、弱参照、ファントム参照
この字面だけで糞言語って察せられるから凄い

**デフォルトの名無しさん** · 2015/12/08(火) 19:22:21.31

Rustはどう？
明文化されたmoveセマンティクスと、オブジェクトの寿命と参照のチェッカを型システムに組み込んでるおかげで、
リソース管理の実行時コストをゼロにしつつ、メモリリークが発生しないプログラムが書ける。
shared_ptrに相当するRcもあるから、所有者を複数にしたい場合のコストもそれなりに抑えられる。

**デフォルトの名無しさん** · 2015/12/08(火) 19:35:14.32

>>253
すげえ難しいらしいじゃん

**デフォルトの名無しさん** · 2015/12/08(火) 19:52:40.51

rustの清貧さは好みだけどまだ触った事ないな
同期処理を省略するためかshared_ptr相当がタスク間跨げないらしいけど
そこら辺の使い勝手ってどうなんだろう

**デフォルトの名無しさん** · 2015/12/08(火) 21:00:06.21

>>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)と等しいけど、それと同じことをやっていた。
型情報なんてコンパイル時に全部消えちゃうから、実行コストも無いんじゃないかと今では思う。

メモリ/リソースの所有権を意識してコードを書くこと、が身について面白いよ。
ヒープを贅沢に使ってコピーしまくりなコードを書くと汚いし遅いしなんで、ちょっとダイエットする気分も出てくる。

**デフォルトの名無しさん** · 2015/12/08(火) 22:39:35.60

>>251
C++もヒープ相手は自分で呼ぶので、実装は必要だよ
Javaでもメンバの特定メソッド呼び出しはやろうと思えばできる
現実に横断的な呼び出しをやる場合はある

結局要求される物と実装の問題

**デフォルトの名無しさん** · 2015/12/08(火) 22:59:22.32

>>255 shared_ptrと恒等なものは無いけど、ポインタ的に使える型がBox, Rc, Cell(あるいはRefCell)とあって、
Boxはヒープ領域であること、Rcは複数の所有者がいる(つまり所有者全員が死ぬまでは生きている)こと、Cellは複数の書き込みが作れること、
とか機能とコストが別れているから、これらを組み合わせて使う。

で、Thread Safetyを実現させる機構は上記には無いので、Atomicityを導入させるRcの類似形であるArcと、
書き込みもしたいならMutexっていう型も合わせて使う。
すると、例えば整数のベクトルをスレッド間で共有したい、とかになるとArc<Mutex<Vec<i32>>>という目が滑るような型表記をすることになる。
あんま詳しくないので、ケース毎にもっと簡単なやり方があるとは思うんだけどね。

**デフォルトの名無しさん** · 2015/12/08(火) 23:55:28.64

>>258
ああ、Arcってのが別にいるのね。納得
個人的にもう一点気になる所があるから聞いてしまう
BoxやDropを使ってるとコピー禁止になるらしいけど
これ面倒な場合ない？
最初はコピー可能な型としてガンガンコピーしてたけど
途中から終了処理を書きたくなったらコピーしてる箇所
全部直すって事？

ちなみにググってたらRWArcっての見つけたんだけど
これ読み書き可能なArcなんじゃね

**デフォルトの名無しさん** · 2015/12/09(水) 00:46:02.26

>>249
javaは世代別管理でGCの種類は色々選べるはずでは

**デフォルトの名無しさん** · 2015/12/09(水) 01:14:15.85

>>260
起動時に切り替えられるだけであって
オブジェクトごとには切り替えられないのでは

**デフォルトの名無しさん** · 2015/12/09(水) 01:50:08.36

>>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できるようには決してできない。メモリ以外の資源管理も安全だよ。

**デフォルトの名無しさん** · 2015/12/12(土) 10:36:13.53

freeし忘れるとか、そんな超ウルトラ素人ミスを大前提に議論するのは間違いだよなｗ
freeしきれないとかｗｗｗｗ

**デフォルトの名無しさん** · 2015/12/12(土) 11:52:29.69

>>263
規模が大きくなれば管理が難しくなるのは普通のことだよ。
ライフサイクルはオブジェクトごとに異なるものだし、
人間に頼らずにGCにメモリ管理を任せるっていうのは良いやり方だよ。

**デフォルトの名無しさん** · 2015/12/12(土) 12:05:07.06

shared_ptrって参照カウント式のGCじゃないの？

**デフォルトの名無しさん** · 2015/12/12(土) 12:44:09.71

循環を綺麗に扱えるなら参照カウントの方が良いと思うけど
VB6は循環参照の扱いどうやってるんだろう

**デフォルトの名無しさん** · 2015/12/12(土) 14:25:51.97

>>265
RAIIじゃろ

**デフォルトの名無しさん** · 2015/12/12(土) 15:20:38.55

>>265
GCの一種だけど、文脈的にはプログラマが
管理が非局所的で明確な型宣言もなしに使えるのをGCと言ってるわけで
議論で揚げ足にしかならない野暮な突っ込みはやめようぜ

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 08:16:09.53

>>264
いや、下手って一言で片付けられるよ。
よっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっぽど、出ない限り

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 08:38:44.84

片付ける奴が馬鹿なのだ。素人ほど簡単だと言いたがり、上級者ほど簡単ではないとはっきり言うものだ。
どの分野でもな。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:09:02.89

freeとか言ってる奴はC++使えよ。いつまでＣ使ってんだ。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:20:53.11

>>270
東大生が人に教えるとき、何がわからないのかわからないというのがわからない。
上級者になればなるほど自分がやってることなんて簡単に見えてくる

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:35:23.70

>>272
何が分らないか分らない、つまり東大生も生徒がどういう思考をしてるか分析できず分らないと言ってるのだ。
低学歴ほど、分らないのはおまえが馬鹿だからと簡単に片付けるものだ。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:37:05.77

それ中級者
あと、東大生は教えるの上手いのもいるから想像で話すな馬鹿

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:41:37.74

このようにおまえのようなコンテキストすらまともに読めないPGは五万といる。
スレッドがデッドロックしてメモリを開放できないなんてよくあることだ。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 10:59:16.82

>>275
。。。。。完全な設計ミスじゃん

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 11:15:19.23

>>275
俺は272に向けてたんだが
そりゃコンテキスト読めてないように見えるよなw

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 11:40:27.14

スレッドがデッドロックしたらメモリリークどころじゃないじゃないかwww

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 14:48:51.74

スレッドがデッドロックしちゃってメモリ解放できない（泣）
っていうPGが五万といるのかよｗ

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 15:51:19.55

まぁfreeやdeleteやnullやらすらできないPGに、「僕はそんなこと管理しきれる脳みそ持ってない！」って言われたらソレは真実なんだろうけど・・・。
そんな脳みそPGに「もっと複雑な業務使用」を理解できるとは思えないんだ。

そんなPGにプログラミングの場を与えるのが間違い。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 15:58:21.86

そもそも実務でスレッド使うＰＧなんてゴマンもいない

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 17:06:58.52

Javaのプロジェクトだとほぼ使ってるけどな隠蔽してるだけで
そのせいで共有リソース壊したり、逆に個人情報の領域が共有されたりして、とんでもないインシデントが発生する
そんな奴等にメモリ管理なんて任せられんし、共有リソースも触らせたくないから
更に隠蔽したフレームワークもどきが出来上がる

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 17:59:33.07

>>282
勝手に使うな。勝手にトリッキーコードにすんな。
素直に、設計書通りに作れ。
勝手なことやって勝手に自爆してるだけじゃねーか。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 18:15:27.90

javaってc++のconst参照に対応するものが無いのに、素人みたいなプログラマを大量にかき集めているのが怖すぎる。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 18:28:13.63

>>283
理解してないのに無理してレスしなくていいから

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 18:42:08.38

C#はマルチスレッド使いまくりだけど事故の話はあまり聞かないな
マイクロソフトが優秀なのか低品質プログラマがいないのか

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 19:01:59.11

JAVA自体がDQN

uy ◆Qawu9.2l1E · 2015/12/14(月) 20:57:26.55

Freeし忘れ

↑これ。

ソースコード書いてる人間の注意力次第でバグが入るなら
言語も設計も間違ってるよ

**デフォルトの名無しさん** · 2015/12/14(月) 21:54:10.80

動的型言語
↑
これ

コード書いている人間の注意力次第でtypoするだけで
実行するまでわからないバグが入るなら
言語も設計も間違ってるよ

**デフォルトの名無しさん** · 2015/12/14(月) 22:23:00.81

C#でcatchやfinally書くの嫌すぎる
C++に戻りたい

**デフォルトの名無しさん** · 2015/12/14(月) 22:43:08.79

>>290
おかえり

**デフォルトの名無しさん** · 2015/12/15(火) 06:39:51.52

(ヽ´ω`)眠い

**デフォルトの名無しさん** · 2015/12/16(水) 08:46:15.45

>>290
C++/CLR「こっちこいよ」

**デフォルトの名無しさん** · 2015/12/17(木) 17:18:40.36

COMのVariantとかJSとかリークしまくりだし

**デフォルトの名無しさん** · 2015/12/17(木) 23:16:36.40

そういやVBScriptって参照カウンタ以外のGC積んでんのあれ
必要には見えないんだけど

**デフォルトの名無しさん** · 2015/12/18(金) 23:17:49.50

プログラマはMacを使ってるってマジ？
http://hayabusa3.2ch.net/test/read.cgi/news/1450395043/

**デフォルトの名無しさん** · 2015/12/19(土) 07:07:37.11

マカーってどんだけアホなの？

**デフォルトの名無しさん** · 2015/12/19(土) 12:49:09.79

解放処理
すら、まともにお前ら管理できねーのかよ・・・・・・・・・・・・・・・・。そらオレが完璧な仕様書渡してもバグってるわけだ

**デフォルトの名無しさん** · 2015/12/19(土) 13:38:07.82

開放処理を手動でやれって書いてある仕様書かw
御免こうむるwwwww

**デフォルトの名無しさん** · 2015/12/19(土) 14:42:49.35

ガベコレのあるPyObjectをラップするクラスをガベコレのあるDで書いたら
wxPythonで書いたクラスをDから使ったとき意味不明なタイミングで落ちるようになった
二重に管理するとだめなんかな

**デフォルトの名無しさん** · 2015/12/19(土) 15:57:38.71

>>298
ﾌﾟﾌﾟﾌﾟ　馬鹿だこいつw

**デフォルトの名無しさん** · 2015/12/20(日) 08:46:23.14

ガベージコレクションはたしかに便利だ
だからといって「本来はてめぇのケツはてめぇで拭け＝自分で解放すること」を忘れてはならない

そんだけ

**デフォルトの名無しさん** · 2015/12/20(日) 11:55:11.08

C#ではSafeHandleだけ作って後は放置
usingも使わないってのがトレンドだけどね
自分で解放とかバカバカしい
面倒はランタイムに見させて開発者はドメイン設計に集中するって目的を見失うな

**デフォルトの名無しさん** · 2015/12/20(日) 12:13:23.36

>>303
オブジェクトの開放を他と独立にやれるケースばかりならそう言えるかもしれんが
オブジェクトAとBがリソースCに依存しているケースでA、Bの開放の少なくとも片方をGCに任せる場合、
リソースCの参照カウンタなりをつかった防護策をプログラマーが書かねばならない
しかしそんな嫌ったらしい雑用を増やすぐらいなら
　Cオープン
　A生成
　B生成
　A, B使用
　B開放
　A開放
　Cクローズ
でええやん？

さらにダンプファイルとかからの障害解析において、オブジェクトが生きているべきなのか死んでいるべきなのか決まっていないとか、
アドレスがはっきりしないとか言う状況は地獄

**デフォルトの名無しさん** · 2015/12/20(日) 12:21:54.48

つかこの世はうつろうもののであって、物理的ハードウェアでプログラムを実行する限り、
計算モデルは明らかに状態遷移ベース（チューリングマシン）の方に分がある
GCとかチューリングマシンで無理矢理関数型プログラミングを行うためのつなぎの技術、
いわば邪道
どんだけ蛇が出てくるか、GCの方がかえってわからん

**デフォルトの名無しさん** · 2015/12/20(日) 13:48:14.94

>>304
設計が悪い
使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
知らなきゃ困るような設計にしたのが間違いだね

**デフォルトの名無しさん** · 2015/12/20(日) 13:52:55.68

メモリ空間は無限であるべき
使い終わったメモリの断片化なにそれ？
仮想メモリを管理するのはCPUの責任だろ

**デフォルトの名無しさん** · 2015/12/20(日) 14:03:49.29

>>306
>>304の例で、さらにCを上書き更新したいオブジェクトDがいたらどうすんの？
GCがA、B両方開放してくれるまでDは期限不定で待たされるけどそれが>>306的に良い設計なの？

つまり、ハードウェアリソースの有限性を考慮する限り
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
が常に成立はしないという話

**デフォルトの名無しさん** · 2015/12/20(日) 14:28:20.48

>>308
そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？
意見を否定するためだけの極端な反例(この場合は例にすらなっていないが)を引き合いに出すのは不毛だよ

**デフォルトの名無しさん** · 2015/12/20(日) 14:35:53.96

>>303
いい加減だなぁw

**デフォルトの名無しさん** · 2015/12/20(日) 14:36:58.02

>>309
>そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？
極論なもんｶﾖ；
例：　表示デバイスの数＞表示したいスレッドの数
というのはざらにある

で、>>308のオブジェクトDのケースはどう解決すんのさ…
GCが「いつ開放してくれるかわからない」ブツである以上解消しない問題だとおもうんだけど
（A、BにCのための明示的closeメソッドを付けるぐらいならGCに頼らずに順序管理するわ；

**デフォルトの名無しさん** · 2015/12/20(日) 14:42:20.07

解決策の一つはActive ObjectパターンでリソースCの管理を1スレッドXにやらせて
Cに対する要求を全部Xのキューにシリアル化して入れさせるというのがあるが、それはそれで
リソースCを使う全てのオブジェクトがスレッドXに依存するから、Xの開放コードが面倒なことになりかねない
かつ、シリアル化はマルチコア時代のせっかくの並列実行性能を殺してしまう

GCに合わせて生きることは、神仙にでもならねば到底かなわぬ…

**デフォルトの名無しさん** · 2015/12/20(日) 14:44:35.05

つくづく、ARC最強だな。

**デフォルトの名無しさん** · 2015/12/20(日) 14:46:27.58

>>311
その例じゃ308の状況にならないよ
どんなコード書いてんだよw

**デフォルトの名無しさん** · 2015/12/20(日) 14:48:11.36

>>314
>その例じゃ308の状況にならないよ
なんで？ビデオメモリに2スレッドから同時に書いて無事に済むと思ってるの…；

**デフォルトの名無しさん** · 2015/12/20(日) 14:51:52.93

だから同時に書く設計が悪いんだって
気合入れて設計を見直してみろ
そんな必要はないってわかるから

**デフォルトの名無しさん** · 2015/12/20(日) 14:55:30.48

ていうか>>316の言っていることはますます矛盾で、
>同時に書く設計が悪い
>そんな必要はないってわかる
というのは明白に「書き込みの順序を設計できる」ということを言っていて、
それはその通り（チューリングマシンの計算モデルに合致する）ので別段漏れの立場と対立するものではなく、
かつ気合を入れて設計すれば順序で全て解決する（GCは不要である）という言明でもある

**デフォルトの名無しさん** · 2015/12/20(日) 15:17:45.93

>>315
もはやGCがどう関係するのかわからない

**デフォルトの名無しさん** · 2015/12/20(日) 15:20:28.11

>>318
彼は敵対意見に反論する材料が欲しいというだけで変な例をでっち上げて出してしまったんだ
本人も今頃困ってるんじゃないかな

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

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