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/
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] バグ(リソースへのポインタやハンドルを壊しちゃったとか)以外で リソース解放に失敗するケースなんて1つも思いつかない
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() しとけばOK
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] いちおう訂正しとこw 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かどうかとGCは無関係
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し忘れるとか、そんな超ウルトラ素人ミスを大前提に議論するのは間違いだよなw freeしきれないとかwwww
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++使えよ。いつまで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が五万といるのかよw
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] そもそも実務でスレッド使うPGなんてゴマンもいない
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