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/11/19(木) 00:01:54.17

なるべくスコープを狭くして長時間存在するオブジェクトを無くす
以上

**デフォルトの名無しさん** · 2015/11/19(木) 00:14:59.30

仮にmalloc/free型を長時間動かしてたらフラグメントが酷いことになるぞ
そういう問題もコピーGCなら一気に解消できるしGCの方が耐久力があるよね

**デフォルトの名無しさん** · 2015/11/19(木) 01:28:02.40

GCの無い時代のプログラムでフラグメントが問題になった例をあげてみろよゴミッカスｗ

**デフォルトの名無しさん** · 2015/11/19(木) 02:10:36.00

>>3
それGCのない言語の問題じゃなくてC/C++の問題だろ
コンパクションとGCはあくまで別だし

**デフォルトの名無しさん** · 2015/11/19(木) 08:58:13.78

ブラッド・コックスとトム・ラブがObjective-Cを作り「この言語はCのメモリ安全性とSmalltalkの高速性を合わせたものだ」と宣言する。
現代の歴史家は2人が失読症ではないかと疑っている。
https://twitter.com/okdshin/status/666903312151613440

**デフォルトの名無しさん** · 2015/11/19(木) 23:17:01.16

519 ：名無し~3.EXE：2015/11/19(木) 21:49:08.84 ID:CEKgHuEl
他のアプリを使用しながらSleipnirを使う

メモリー不足でのメッセージは良心的
https://i.gyazo.com/57e93e426e7a2b5fe7ba4dcf19a432c8.png
問題点として、場合によってはメモリー不足で
メッセージされずに展開されなくなる
Sleipnirが不安定で信頼感を得られない要因

520 ：名無し~3.EXE：2015/11/19(木) 21:51:47.06 ID:CEKgHuEl
6で書き込み欄が展開されなくなった・・・再起動してカキコした

521 ：名無し~3.EXE：2015/11/19(木) 21:52:39.96 ID:CEKgHuEl
◆重要◆Sleipnirが不安定で信頼感を得られない要因

**デフォルトの名無しさん** · 2015/11/19(木) 23:18:18.19

525 ：名無し~3.EXE：2015/11/19(木) 22:13:05.49 ID:CEKgHuEl
展開されない時
リロードで展開される場合もあるが
リロードで展開ない場合もある

**デフォルトの名無しさん** · 2015/11/20(金) 09:27:53.75

メモリ管理は自分でやった方が漏れが出るでしょ
規模がでかくなればなるほどリスクが大きくなる

**デフォルトの名無しさん** · 2015/11/20(金) 15:32:07.18

C#の基本は自動だけど部分的に手動にできるハイブリッドがいいと思うよ
確保量の大きい画像なんかを扱っているとどうしても手動で解放したいタイミングもあるし

uy ◆Qawu9.2l1E · 2015/11/20(金) 20:28:57.10

まともな言語ならオプションくらいついてる

**デフォルトの名無しさん** · 2015/11/20(金) 22:40:56.83

>>10
それが理想的だけど、C#ってそんなことできたっけ？

**デフォルトの名無しさん** · 2015/11/21(土) 09:07:54.65

>>12
出来るよ。
ポインタも使える

**デフォルトの名無しさん** · 2015/11/21(土) 10:29:39.51

調べてみたけどよくわからんな。
もしかしてアンマネージなメモリを確保してデータ領域に使う話？

**デフォルトの名無しさん** · 2015/11/21(土) 16:16:49.90

アンｗｗｗｗマネージｗｗｗｗ
無理に横文字使わなくていいですよｗｗｗ

**デフォルトの名無しさん** · 2015/11/21(土) 17:40:45.99

横文字じゃなくてマイクロソフトの用語なんだが？

**デフォルトの名無しさん** · 2015/11/21(土) 17:47:25.64

c#が残念なんのはC++とデストラクタの呼ぶれるタイミングが違いすぎて移行が大変すぎることだ。
結局、手動でデストラクタを呼ばなきゃならない。GCの利便性がほとんどなし。

**デフォルトの名無しさん** · 2015/11/21(土) 19:18:42.53

>>16
涙ふけよｗｗｗｗ

**デフォルトの名無しさん** · 2015/11/21(土) 21:36:26.09

>>9
自動ならメモリリーク等々発生するわけがないのに発生している
この原因はプログラマなんだけど、結局メモリ管理から解放されてないなら最初から管理する方針でいいじゃん

**デフォルトの名無しさん** · 2015/11/22(日) 01:48:28.16

メモリ管理を楽にするためにあるわけで人間が全部面倒みんのとは違うだろ

**デフォルトの名無しさん** · 2015/11/22(日) 04:41:20.06

やっぱりGCのほうがいいかな大規模になってくると
Cでリークはしてないけど本来開放すべきタイミングで開放してないでメモリいっぱいになるのは防ぎやすいと思うし

**デフォルトの名無しさん** · 2015/11/22(日) 07:04:28.69

>>20
楽になってメモリリークがなくなるならいいけど、メモリリーク発生するわ
プログラマがメモリ管理なんてしなくて大丈夫、とメモリの扱いが雑になって意図しないタイミングで解放されたりされなかったり
最初から管理するという方針で教えないから、こんなことになる
管理漏れをGCがうまいことやってくれる。でもGCにやらせるようだと恥。
というくらいで教育すべき

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

メモリ管理すらまともにできないやつが寿命や世代やら管理できるわけがない。

**デフォルトの名無しさん** · 2015/11/22(日) 10:54:50.51

GCそのものではなく新人教育や解説書が最初のスタンス間違えたんだよ。
GC=メモリ管理適当
という認識作ったから、GCに新しい名称つけて
教育や解説書では、メモリーの確保から解放まできちっと説明し直したほうがいい

**デフォルトの名無しさん** · 2015/11/22(日) 12:31:51.68

GCって完全なものだと思ってたから、C#案件でメモリリークの調査にえらく手間がかかった
GCはダメな子って認識は必要だな

**デフォルトの名無しさん** · 2015/11/22(日) 12:38:37.22

C/C++はライブラリレベルでメモリリリークの検査もテストも書けるけど
GC前提言語だとその辺がごっそり抜け落ちて後で問題になる

**デフォルトの名無しさん** · 2015/11/22(日) 12:42:49.74

メモリ管理できない人がお気楽で作れば、GCあっても・・・・

**デフォルトの名無しさん** · 2015/11/22(日) 13:08:14.89

>>25
結局どんなバグだったんだい？

**デフォルトの名無しさん** · 2015/11/22(日) 16:57:06.63

C++でもスマートポインタ使えば勝手に開放されるよ

所謂GC任せだと、いつ開放処理が走るか分らなくなるから
その事に対する新たな対策が必要になるよ
http://ufcpp.net/study/csharp/rm_disposable.html

手続き型言語は処理の順番が重要なのに
いつ実行されるか分からないってのは中々チャレンジャーだし大掛かりな話だね

**デフォルトの名無しさん** · 2015/11/22(日) 17:32:48.70

前スレでも書いたけど、C#のDisposeの問題を紹介しよう
IDisposableなオブジェクトをコンポジションしてメンバに持つと自身もIDisposableにしなければならない
だから自分がコンポジションしているオブジェクトがIDisposableかどうか一々調べなければならないし
IDisposableなオブジェクトがメンバにあれば、自身もIDisposableにしなければならない
さらに、その作ったクラスをコンポジションして使うクラスもIDisposableにする必要があり・・・
という風にIDisposableはクラスで閉じずコンポジションで伝染する
というか、むしろ手動で伝染させなければならないという
しかもIDisposableの一連のイディオムはとても長くて煩雑
http://ufcpp.net/study/csharp/rm_disposable.html
こういうものを書いて、マネッジドリソースとアンマネッジドリソースで場合わけをしつつ
IDisposableなオブジェクトに関しては
手動で自分のメンバのDisposeを漏れなく呼び出すコードを書かなければならない
当たり前だが、どのメンバがIDisposableか完全に把握しておく必要が有る
手動で自分のメンバのDisposeを呼び出す作業は、まるでCのmallocを思い起こさせる
問題点は明確で、DisposeがC++のデストラクタのように芋づる式に勝手に呼ばれない事に有る
だから手動で芋づる式に呼び出すコードを書かなくてはならない

**デフォルトの名無しさん** · 2015/11/22(日) 18:20:40.59

Formなんかも参照が亡くなったら強制的に殺すべきだったと思うわ
ファイナライザーの処理がひどいことになると思うけど

**デフォルトの名無しさん** · 2015/11/22(日) 22:36:02.07

またお前か
メンバに持つのが間違い

**デフォルトの名無しさん** · 2015/11/22(日) 23:18:34.23

無茶いうな

**デフォルトの名無しさん** · 2015/11/23(月) 08:11:32.17

解放処理をしなくてもGCがやってくれる。
でも、ソースに解放処理が書いてあれば、後から見たらあぁここで用済みになったのかとわかる。

可読性は非常に重要よ。

**デフォルトの名無しさん** · 2015/11/23(月) 15:41:37.20

解放処理のタイミングが制御できないと、解放して欲しくないタイミングで解放されて
挙動が変わることがある
リアルタイム性が要求されるシステムでこれで困ったことがある（そもそもそんな言語使うなって話だが）

◆QZaw55cn4c · 2015/11/23(月) 17:14:59.57

>>35
それはあまりない
挙動が変わるというか停止するというのならあるのかもしれないが

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

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