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
それはあまりない
挙動が変わるというか停止するというのならあるのかもしれないが

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

うわっ頭のおかしいQだ

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

＞解放して欲しくないタイミングで解放

なんでそんなことになったの？
参照切ってなきゃGCの対象にならないはず

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

空きメモリによって使用するアルゴリズム変えたりする。
だから実行前にGC手動で走らせて、できるだけ空きメモリ増やしたりとかする。
できるだけ開放したいのに過負荷でまだメモリに余裕あるからGC走らないってのが困る。

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

メモリの解放漏れってさ、とどのつまり下手だからするんだよね
下手なやつにはプログラムを組ませないってのが鉄則だと思うの

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

c++11のshared_ptrの参照カウンタってそもそも要るんだろうか？
複数のオブジェクトが所有権を持ちあう必要性に迫られる事がないんだけど
weak_ptrの対応だけあれば良くない？

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

リソースを共有する場合なんかは使うと楽だよ

まーshared_ptrが有れば、いつ実行されるか分からないような、手の込んだGCは要らないよな
巡回参照が有る場合はどちらかをweak_ptrにする、これだけを守ってれば問題は起きない
大体の場合は所有権というか上下関係がはっきりしているからな

巡回参照のある場合も自動で開放したいという、たったこれだけのために
いつ実行されるか分からない上に重いマークスイープ式GCを導入するのは
業界全体の早とちりだったようだね

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

最近のC++はdeleteを直接書かないだけでなく、最早newも直接書かない方向
std::make_shared<int>()　って書くよね
始めからshread_ptrで受け取るから、循環参照だけ気をつければ
リークする余地がないよね
RAIIも健在で、C#みたいにIDisposableとか要らない
デストラクタも芋づる式に呼び出されるから
>>30で書いたような問題も起きないよ

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

C++は益々混沌としているのか。手に負えん。

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

>>41
糞便利な参照カウンタを使わないなんてＣ＋＋使う意味なし

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

>>42
それはManagerやHolder的なものを書かなくて良いってことを言ってるの？
それって大体一時しのぎで大抵後々リソース管理以外にもそういった管理クラスが必要になるケースがほとんどじゃない？

>>45
ねーよ

**デフォルトの名無しさん** · 2015/11/24(火) 00:26:10.23

うーん質問がアバウトすぎたな。もう少し具体的に書くわ

例えば2chのある板を管理するプログラムを書くとして
BoardクラスとThreadクラスを想像してみてくれ
BoardはThreadオブジェクトを管理するが、Threadは
産まれたり死んだりと揮発的で寿命が定まらないと。
で各Threadは何らかの共有リソースを持つと。
例えば一度読み込んだ画像を各スレッドで共有したいとかが
考えられるけど、画像オブジェクトをshared_ptrで共有するのは
適切ではない
なぜならある瞬間に産まれたThread群がひとつの画像を共有する
からといってshared_ptrで持たせたとしても、後の更新時に
更にその画像を共有したいThreadが現れたときに、画像が
すでにあることを何らかの形で知れないといけないから。
結局Boardなんかが画像オブジェクトのコンテナを持つ必要が
あってそのコンテナへの追加と削除のために別の共有の
仕組みが必要になるんだよ。例えばThreadがBoardに画像を
リクエストして参照カウンタを持ったアクセサを返すようなもの
だから所有権はBoardひとりが持てばよくてshared_ptrを
使う必要がなくなるという理屈
こういったケースを踏まえてもshared_ptr使うケースって
ほとんどなくね

**デフォルトの名無しさん** · 2015/11/24(火) 01:21:45.79

IDisposableの問題はDisposeを呼ばなければリークするものとそうでないものの混在だろ

**デフォルトの名無しさん** · 2015/11/24(火) 03:22:06.30

>>47
マルチスレッドプログラム書いてみろよ
shared_ptrがないと泣くぞ

**デフォルトの名無しさん** · 2015/11/24(火) 05:26:33.27

>>49
いやいくらでも書いてるけど基本一緒
というか上の例もそのままマルチスレッドに適用できる話でしょ

例えばproducer consumerならproducerが所有権を持つし
thread per messageなら共有データはホストが持って固有データは
個別スレッドで持つだけ
むしろマルチスレッドの場合、所有者をより厳格に決めとかないと
泣く事になるぞ

**デフォルトの名無しさん** · 2015/11/24(火) 12:31:47.38

所有権って・・・・

unique_ptrを使うと勝手に所有権が移動してしまうし
生のポインタを使うんならわかるけど

**デフォルトの名無しさん** · 2015/11/24(火) 12:53:55.99

shared_ptrで複数人が所有権を持っても良いんだぞ
上下関係さえしっかりしていれば良い

**デフォルトの名無しさん** · 2015/11/24(火) 13:15:01.57

そんなの分かってるんだが
>>50の人はどう考えてるのか

**デフォルトの名無しさん** · 2015/11/24(火) 16:23:15.08

>>51
今のC++からshared_ptrをそのまま無くせって言ってるんじゃないぞ
shared_ptrのコピーを禁止にしてweak_ptrの対応だけあれば良くないかって事
そもそも何でそんなこと言うかっていうと、
GCない言語→循環参照ガー。みたいによく言われるけど使わないで
済むなら静的解析で循環参照の起こり得るケースをエラーにしてしまう
って解決方法もあるかなと思っただけ
あとshared_ptrとweak_ptrはアトミック操作とメモリバリアを必要としうるから
それに頼った設計は疑問を感じる

**デフォルトの名無しさん** · 2015/11/24(火) 16:37:54.42

一応言っとくと静的解析のくだりは新しい言語を
設計するとした場合の話ね
C++だとほぼ不可能だろうから

**デフォルトの名無しさん** · 2015/11/24(火) 16:39:45.81

せっかくC#は新設計なのにいろいろ失敗が含まれてるよな。

ヘジはなにやってんだか。

uy ◆Qawu9.2l1E · 2015/11/24(火) 18:29:34.50

大企業は、
中小企業を奴隷にさせる事を第一に考えたツールしかリリースしてないよ
失敗ではなく全部わざと。

**デフォルトの名無しさん** · 2015/11/25(水) 07:39:30.16

メモリ管理テケトーなやつはその他のリソース管理もテケトー

**デフォルトの名無しさん** · 2015/11/25(水) 17:12:00.25

そもそも自分のリソース管理がしっかり出来てる人は・・・

**デフォルトの名無しさん** · 2015/11/27(金) 12:24:34.85

>>31
Formはnull入れてあげないといけないんだっけ？

なんか、場合場合によってnull入れてあげないといけなかったり入れなくてもよかったり。
ならnull入れるで統一でいいじゃんと思った

**デフォルトの名無しさん** · 2015/11/27(金) 22:35:05.80

Rust使えば解決

**デフォルトの名無しさん** · 2015/11/28(土) 06:44:39.29

中の細かい実装まで知らないんだけど、
A = new A()
Loop Begin
　処理
　 A = null
　 A = new A()
Loop End
とか、nullをセットをGCって見張ってるの？又はGCに伝えているとかあるの？

**デフォルトの名無しさん** · 2015/11/28(土) 13:02:34.51

違うよ
newが動いた時点で中の人がメモリが足りない！って騒いで初めてGCさんお願いします！GC「やれやれ・・・
っていう仕組みなんで
>>62の例のnullの代入は無駄

**デフォルトの名無しさん** · 2015/11/28(土) 13:08:02.55

いや無駄じゃないか
代入演算子の順序の関係でnewの後に代入が起こるから
Aを事前にnullすることでGCさんが回収できるオブジェクトが1個増える

**デフォルトの名無しさん** · 2015/11/28(土) 13:10:10.16

書いたほうが保守性は高く、意味がある。

**デフォルトの名無しさん** · 2015/11/28(土) 13:34:46.98

>>64
つまり、使い終わったら、スグにnullっておいたほうがいいってことか。
・・・とも言い切れないな。

でも、ここで使い終わったってわかるから、書いたほうがいいか。
よし。決めた。全部書こう。

**デフォルトの名無しさん** · 2015/11/28(土) 13:55:47.33

null代入なんていちいち書いていたら
コードが冗長になって保守性が落ちる。

メモリ食いのオブジェクトなど、クリティカルな部分でのみ使うべき

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

お前らか。無意味なnull代入書き散らしてるのは

**デフォルトの名無しさん** · 2015/11/28(土) 14:42:43.95

null代入とか結局やってることc++以下なんだよなぁ

**デフォルトの名無しさん** · 2015/11/28(土) 14:48:25.74

ダングリングポインタが出ないって利点は有るにはあるが
スマートポインタ使えば済む話だしなぁ
weak_ptrもあるし

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

>>68
意味はあるじゃん

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

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