GCは失敗。メモリは自分で管理せよ！ その2
- 1 ：デフォルトの名無しさん：2015/11/18(水) 23:24:59.79 ID:BUQ68wTG.net
- GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。
以下GCと記す
プログラマをメモリ管理から開放する！
といいつつ、メモリリーク問題の文献が大量にある。
これすなわち、メモリリーク問題が全然解決していないということ。
さらに、メモリ解放のタイミングの文献まで大量に生み出した。
これすなわち、新たなるメモリ管理に関する問題を生み出したということ。
malloc、freeじゃないが
結局のところ、メモリを管理するという技術は、今しばらくは、身につける・教える・学ぶべきではないだろうか？
使って、そのまま放置しても、基本的にはGCがなんとかしてくれている。
ランジョブからジョブ終了までさほどの時間を要さない。メモリも大して使わないならいいだろう。
しかし、規模が大きくなり常駐ジョブやメモリ大量使用のジョブになってくると、そんなメモリ管理の方法でやっていると、
上記「文献」を生み出されてしまう。
入門時は、メモリに無頓着でもいいだろう。それよりも、目的を達成することが先決だ。
しかし、慣れてきたら、やはりメモリの管理まで余裕を持って自分で行うべきだろう。
前スレ
GCは失敗。メモリは自分で管理せよ！
http://peace.2ch.net/test/read.cgi/tech/1412986420/
- 2 ：デフォルトの名無しさん：2015/11/19(木) 00:01:54.17 ID:6rd98MPK.net
- なるべくスコープを狭くして長時間存在するオブジェクトを無くす
以上
- 3 ：デフォルトの名無しさん：2015/11/19(木) 00:14:59.30 ID:d0YkbYhs.net
- 仮にmalloc/free型を長時間動かしてたらフラグメントが酷いことになるぞ
そういう問題もコピーGCなら一気に解消できるしGCの方が耐久力があるよね
- 4 ：デフォルトの名無しさん：2015/11/19(木) 01:28:02.40 ID:6x5+bHoL.net
- GCの無い時代のプログラムでフラグメントが問題になった例をあげてみろよゴミッカスｗ
- 5 ：デフォルトの名無しさん：2015/11/19(木) 02:10:36.00 ID:C+wDd3AI.net
- >>3
それGCのない言語の問題じゃなくてC/C++の問題だろ
コンパクションとGCはあくまで別だし
- 6 ：デフォルトの名無しさん：2015/11/19(木) 08:58:13.78 ID:JIJtk7D/.net
- ブラッド・コックスとトム・ラブがObjective-Cを作り「この言語はCのメモリ安全性とSmalltalkの高速性を合わせたものだ」と宣言する。
現代の歴史家は2人が失読症ではないかと疑っている。
https://twitter.com/okdshin/status/666903312151613440
- 7 ：デフォルトの名無しさん：2015/11/19(木) 23:17:01.16 ID:SYMznuBH.net
- 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が不安定で信頼感を得られない要因
- 8 ：デフォルトの名無しさん：2015/11/19(木) 23:18:18.19 ID:SYMznuBH.net
- 525 ：名無し~3.EXE：2015/11/19(木) 22:13:05.49 ID:CEKgHuEl
展開されない時
リロードで展開される場合もあるが
リロードで展開ない場合もある
- 9 ：デフォルトの名無しさん：2015/11/20(金) 09:27:53.75 ID:em+ldceb.net
- メモリ管理は自分でやった方が漏れが出るでしょ
規模がでかくなればなるほどリスクが大きくなる
- 10 ：デフォルトの名無しさん：2015/11/20(金) 15:32:07.18 ID:hg0nWx/i.net
- C#の基本は自動だけど部分的に手動にできるハイブリッドがいいと思うよ
確保量の大きい画像なんかを扱っているとどうしても手動で解放したいタイミングもあるし
- 11 ：uy ◆Qawu9.2l1E ：2015/11/20(金) 20:28:57.10 ID:QlSu2hgW.net
- まともな言語ならオプションくらいついてる
- 12 ：デフォルトの名無しさん：2015/11/20(金) 22:40:56.83 ID:h5Le2W6O.net
- >>10
それが理想的だけど、C#ってそんなことできたっけ？
- 13 ：デフォルトの名無しさん：2015/11/21(土) 09:07:54.65 ID:+qGvO8oq.net
- >>12
出来るよ。
ポインタも使える
- 14 ：デフォルトの名無しさん：2015/11/21(土) 10:29:39.51 ID:7nxNhgSu.net
- 調べてみたけどよくわからんな。
もしかしてアンマネージなメモリを確保してデータ領域に使う話？
- 15 ：デフォルトの名無しさん：2015/11/21(土) 16:16:49.90 ID:iOucF00Z.net
- アンｗｗｗｗマネージｗｗｗｗ
無理に横文字使わなくていいですよｗｗｗ
- 16 ：デフォルトの名無しさん：2015/11/21(土) 17:40:45.99 ID:7nxNhgSu.net
- 横文字じゃなくてマイクロソフトの用語なんだが？
- 17 ：デフォルトの名無しさん：2015/11/21(土) 17:47:25.64 ID:/uyrLxeD.net
- c#が残念なんのはC++とデストラクタの呼ぶれるタイミングが違いすぎて移行が大変すぎることだ。
結局、手動でデストラクタを呼ばなきゃならない。GCの利便性がほとんどなし。
- 18 ：デフォルトの名無しさん：2015/11/21(土) 19:18:42.53 ID:iOucF00Z.net
- >>16
涙ふけよｗｗｗｗ
- 19 ：デフォルトの名無しさん：2015/11/21(土) 21:36:26.09 ID:tqUpuiXF.net
- >>9
自動ならメモリリーク等々発生するわけがないのに発生している
この原因はプログラマなんだけど、結局メモリ管理から解放されてないなら最初から管理する方針でいいじゃん
- 20 ：デフォルトの名無しさん：2015/11/22(日) 01:48:28.16 ID:7AflF1fM.net
- メモリ管理を楽にするためにあるわけで人間が全部面倒みんのとは違うだろ
- 21 ：デフォルトの名無しさん：2015/11/22(日) 04:41:20.06 ID:WFE6EpHf.net
- やっぱりGCのほうがいいかな大規模になってくると
Cでリークはしてないけど本来開放すべきタイミングで開放してないでメモリいっぱいになるのは防ぎやすいと思うし
- 22 ：デフォルトの名無しさん：2015/11/22(日) 07:04:28.69 ID:MUaNGGyB.net
- >>20
楽になってメモリリークがなくなるならいいけど、メモリリーク発生するわ
プログラマがメモリ管理なんてしなくて大丈夫、とメモリの扱いが雑になって意図しないタイミングで解放されたりされなかったり
最初から管理するという方針で教えないから、こんなことになる
管理漏れをGCがうまいことやってくれる。でもGCにやらせるようだと恥。
というくらいで教育すべき
- 23 ：デフォルトの名無しさん：2015/11/22(日) 07:12:51.89 ID:MUaNGGyB.net
- メモリ管理すらまともにできないやつが寿命や世代やら管理できるわけがない。
- 24 ：デフォルトの名無しさん：2015/11/22(日) 10:54:50.51 ID:MJCWCZ10.net
- GCそのものではなく新人教育や解説書が最初のスタンス間違えたんだよ。
GC=メモリ管理適当
という認識作ったから、GCに新しい名称つけて
教育や解説書では、メモリーの確保から解放まできちっと説明し直したほうがいい
- 25 ：デフォルトの名無しさん：2015/11/22(日) 12:31:51.68 ID:Qlq25ltW.net
- GCって完全なものだと思ってたから、C#案件でメモリリークの調査にえらく手間がかかった
GCはダメな子って認識は必要だな
- 26 ：デフォルトの名無しさん：2015/11/22(日) 12:38:37.22 ID:mfzN9aoV.net
- C/C++はライブラリレベルでメモリリリークの検査もテストも書けるけど
GC前提言語だとその辺がごっそり抜け落ちて後で問題になる
- 27 ：デフォルトの名無しさん：2015/11/22(日) 12:42:49.74 ID:zNwKjU3u.net
- メモリ管理できない人がお気楽で作れば、GCあっても・・・・
- 28 ：デフォルトの名無しさん：2015/11/22(日) 13:08:14.89 ID:KDgQ57Ye.net
- >>25
結局どんなバグだったんだい？
- 29 ：デフォルトの名無しさん：2015/11/22(日) 16:57:06.63 ID:vggKhYqJ.net
- C++でもスマートポインタ使えば勝手に開放されるよ
所謂GC任せだと、いつ開放処理が走るか分らなくなるから
その事に対する新たな対策が必要になるよ
http://ufcpp.net/study/csharp/rm_disposable.html
手続き型言語は処理の順番が重要なのに
いつ実行されるか分からないってのは中々チャレンジャーだし大掛かりな話だね
- 30 ：デフォルトの名無しさん：2015/11/22(日) 17:32:48.70 ID:vggKhYqJ.net
- 前スレでも書いたけど、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++のデストラクタのように芋づる式に勝手に呼ばれない事に有る
だから手動で芋づる式に呼び出すコードを書かなくてはならない
- 31 ：デフォルトの名無しさん：2015/11/22(日) 18:20:40.59 ID:WFE6EpHf.net
- Formなんかも参照が亡くなったら強制的に殺すべきだったと思うわ
ファイナライザーの処理がひどいことになると思うけど
- 32 ：デフォルトの名無しさん：2015/11/22(日) 22:36:02.07 ID:iT1tZCI1.net
- またお前か
メンバに持つのが間違い
- 33 ：デフォルトの名無しさん：2015/11/22(日) 23:18:34.23 ID:7zQV9dKP.net
- 無茶いうな
- 34 ：デフォルトの名無しさん：2015/11/23(月) 08:11:32.17 ID:XNOSKZeE.net
- 解放処理をしなくてもGCがやってくれる。
でも、ソースに解放処理が書いてあれば、後から見たらあぁここで用済みになったのかとわかる。
可読性は非常に重要よ。
- 35 ：デフォルトの名無しさん：2015/11/23(月) 15:41:37.20 ID:qRZYsqEh.net
- 解放処理のタイミングが制御できないと、解放して欲しくないタイミングで解放されて
挙動が変わることがある
リアルタイム性が要求されるシステムでこれで困ったことがある（そもそもそんな言語使うなって話だが）
- 36 ： ◆QZaw55cn4c ：2015/11/23(月) 17:14:59.57 ID:JWzW06M6.net
- >>35
それはあまりない
挙動が変わるというか停止するというのならあるのかもしれないが
- 37 ：デフォルトの名無しさん：2015/11/23(月) 17:21:44.69 ID:y4njP/wV.net
- うわっ頭のおかしいQだ
- 38 ：デフォルトの名無しさん：2015/11/23(月) 17:22:22.95 ID:9XGqpqVu.net
- ＞解放して欲しくないタイミングで解放
なんでそんなことになったの？
参照切ってなきゃGCの対象にならないはず
- 39 ：デフォルトの名無しさん：2015/11/23(月) 17:24:18.17 ID:OK+rBFmG.net
- 空きメモリによって使用するアルゴリズム変えたりする。
だから実行前にGC手動で走らせて、できるだけ空きメモリ増やしたりとかする。
できるだけ開放したいのに過負荷でまだメモリに余裕あるからGC走らないってのが困る。
- 40 ：デフォルトの名無しさん：2015/11/23(月) 17:46:43.41 ID:XNOSKZeE.net
- メモリの解放漏れってさ、とどのつまり下手だからするんだよね
下手なやつにはプログラムを組ませないってのが鉄則だと思うの
- 41 ：デフォルトの名無しさん：2015/11/23(月) 19:25:05.71 ID:6m6E/SfN.net
- c++11のshared_ptrの参照カウンタってそもそも要るんだろうか？
複数のオブジェクトが所有権を持ちあう必要性に迫られる事がないんだけど
weak_ptrの対応だけあれば良くない？
- 42 ：デフォルトの名無しさん：2015/11/23(月) 19:56:47.15 ID:+Ddm9172.net
- リソースを共有する場合なんかは使うと楽だよ
まーshared_ptrが有れば、いつ実行されるか分からないような、手の込んだGCは要らないよな
巡回参照が有る場合はどちらかをweak_ptrにする、これだけを守ってれば問題は起きない
大体の場合は所有権というか上下関係がはっきりしているからな
巡回参照のある場合も自動で開放したいという、たったこれだけのために
いつ実行されるか分からない上に重いマークスイープ式GCを導入するのは
業界全体の早とちりだったようだね
- 43 ：デフォルトの名無しさん：2015/11/23(月) 20:06:26.94 ID:+Ddm9172.net
- 最近のC++はdeleteを直接書かないだけでなく、最早newも直接書かない方向
std::make_shared<int>() って書くよね
始めからshread_ptrで受け取るから、循環参照だけ気をつければ
リークする余地がないよね
RAIIも健在で、C#みたいにIDisposableとか要らない
デストラクタも芋づる式に呼び出されるから
>>30で書いたような問題も起きないよ
- 44 ：デフォルトの名無しさん：2015/11/23(月) 20:09:18.99 ID:OK+rBFmG.net
- C++は益々混沌としているのか。手に負えん。
- 45 ：デフォルトの名無しさん：2015/11/23(月) 20:35:23.62 ID:PopzBtGV.net
- >>41
糞便利な参照カウンタを使わないなんてＣ＋＋使う意味なし
- 46 ：デフォルトの名無しさん：2015/11/23(月) 22:58:10.32 ID:6m6E/SfN.net
- >>42
それはManagerやHolder的なものを書かなくて良いってことを言ってるの？
それって大体一時しのぎで大抵後々リソース管理以外にもそういった管理クラスが必要になるケースがほとんどじゃない？
>>45
ねーよ
- 47 ：デフォルトの名無しさん：2015/11/24(火) 00:26:10.23 ID:f4S6RtN7.net
- うーん質問がアバウトすぎたな。もう少し具体的に書くわ
例えば2chのある板を管理するプログラムを書くとして
BoardクラスとThreadクラスを想像してみてくれ
BoardはThreadオブジェクトを管理するが、Threadは
産まれたり死んだりと揮発的で寿命が定まらないと。
で各Threadは何らかの共有リソースを持つと。
例えば一度読み込んだ画像を各スレッドで共有したいとかが
考えられるけど、画像オブジェクトをshared_ptrで共有するのは
適切ではない
なぜならある瞬間に産まれたThread群がひとつの画像を共有する
からといってshared_ptrで持たせたとしても、後の更新時に
更にその画像を共有したいThreadが現れたときに、画像が
すでにあることを何らかの形で知れないといけないから。
結局Boardなんかが画像オブジェクトのコンテナを持つ必要が
あってそのコンテナへの追加と削除のために別の共有の
仕組みが必要になるんだよ。例えばThreadがBoardに画像を
リクエストして参照カウンタを持ったアクセサを返すようなもの
だから所有権はBoardひとりが持てばよくてshared_ptrを
使う必要がなくなるという理屈
こういったケースを踏まえてもshared_ptr使うケースって
ほとんどなくね
- 48 ：デフォルトの名無しさん：2015/11/24(火) 01:21:45.79 ID:0dqdPvnh.net
- IDisposableの問題はDisposeを呼ばなければリークするものとそうでないものの混在だろ
- 49 ：デフォルトの名無しさん：2015/11/24(火) 03:22:06.30 ID:fjQi4YH+.net
- >>47
マルチスレッドプログラム書いてみろよ
shared_ptrがないと泣くぞ
- 50 ：デフォルトの名無しさん：2015/11/24(火) 05:26:33.27 ID:f4S6RtN7.net
- >>49
いやいくらでも書いてるけど基本一緒
というか上の例もそのままマルチスレッドに適用できる話でしょ
例えばproducer consumerならproducerが所有権を持つし
thread per messageなら共有データはホストが持って固有データは
個別スレッドで持つだけ
むしろマルチスレッドの場合、所有者をより厳格に決めとかないと
泣く事になるぞ
- 51 ：デフォルトの名無しさん：2015/11/24(火) 12:31:47.38 ID:HvLaDP3z.net
- 所有権って・・・・
unique_ptrを使うと勝手に所有権が移動してしまうし
生のポインタを使うんならわかるけど
- 52 ：デフォルトの名無しさん：2015/11/24(火) 12:53:55.99 ID:2IyJeQ15.net
- shared_ptrで複数人が所有権を持っても良いんだぞ
上下関係さえしっかりしていれば良い
- 53 ：デフォルトの名無しさん：2015/11/24(火) 13:15:01.57 ID:HvLaDP3z.net
- そんなの分かってるんだが
>>50の人はどう考えてるのか
- 54 ：デフォルトの名無しさん：2015/11/24(火) 16:23:15.08 ID:f4S6RtN7.net
- >>51
今のC++からshared_ptrをそのまま無くせって言ってるんじゃないぞ
shared_ptrのコピーを禁止にしてweak_ptrの対応だけあれば良くないかって事
そもそも何でそんなこと言うかっていうと、
GCない言語→循環参照ガー。みたいによく言われるけど使わないで
済むなら静的解析で循環参照の起こり得るケースをエラーにしてしまう
って解決方法もあるかなと思っただけ
あとshared_ptrとweak_ptrはアトミック操作とメモリバリアを必要としうるから
それに頼った設計は疑問を感じる
- 55 ：デフォルトの名無しさん：2015/11/24(火) 16:37:54.42 ID:f4S6RtN7.net
- 一応言っとくと静的解析のくだりは新しい言語を
設計するとした場合の話ね
C++だとほぼ不可能だろうから
- 56 ：デフォルトの名無しさん：2015/11/24(火) 16:39:45.81 ID:1SleeXaD.net
- せっかくC#は新設計なのにいろいろ失敗が含まれてるよな。
ヘジはなにやってんだか。
- 57 ：uy ◆Qawu9.2l1E ：2015/11/24(火) 18:29:34.50 ID:lNjW2jss.net
- 大企業は、
中小企業を奴隷にさせる事を第一に考えたツールしかリリースしてないよ
失敗ではなく全部わざと。
- 58 ：デフォルトの名無しさん：2015/11/25(水) 07:39:30.16 ID:JnM8vxaH.net
- メモリ管理テケトーなやつはその他のリソース管理もテケトー
- 59 ：デフォルトの名無しさん：2015/11/25(水) 17:12:00.25 ID:Sra0FKsR.net
- そもそも自分のリソース管理がしっかり出来てる人は・・・
- 60 ：デフォルトの名無しさん：2015/11/27(金) 12:24:34.85 ID:ZRdaHx9T.net
- >>31
Formはnull入れてあげないといけないんだっけ？
なんか、場合場合によってnull入れてあげないといけなかったり入れなくてもよかったり。
ならnull入れるで統一でいいじゃんと思った
- 61 ：デフォルトの名無しさん：2015/11/27(金) 22:35:05.80 ID:CyIO1ZuX.net
- Rust使えば解決
- 62 ：デフォルトの名無しさん：2015/11/28(土) 06:44:39.29 ID:CKvy7+My.net
- 中の細かい実装まで知らないんだけど、
A = new A()
Loop Begin
処理
A = null
A = new A()
Loop End
とか、nullをセットをGCって見張ってるの？又はGCに伝えているとかあるの？
- 63 ：デフォルトの名無しさん：2015/11/28(土) 13:02:34.51 ID:Qyl/1Ad+.net
- 違うよ
newが動いた時点で中の人がメモリが足りない！って騒いで初めてGCさんお願いします！GC「やれやれ・・・
っていう仕組みなんで
>>62の例のnullの代入は無駄
- 64 ：デフォルトの名無しさん：2015/11/28(土) 13:08:02.55 ID:Qyl/1Ad+.net
- いや無駄じゃないか
代入演算子の順序の関係でnewの後に代入が起こるから
Aを事前にnullすることでGCさんが回収できるオブジェクトが1個増える
- 65 ：デフォルトの名無しさん：2015/11/28(土) 13:10:10.16 ID:rTI66XO9.net
- 書いたほうが保守性は高く、意味がある。
- 66 ：デフォルトの名無しさん：2015/11/28(土) 13:34:46.98 ID:CKvy7+My.net
- >>64
つまり、使い終わったら、スグにnullっておいたほうがいいってことか。
・・・とも言い切れないな。
でも、ここで使い終わったってわかるから、書いたほうがいいか。
よし。決めた。全部書こう。
- 67 ：デフォルトの名無しさん：2015/11/28(土) 13:55:47.33 ID:pohBt4lh.net
- null代入なんていちいち書いていたら
コードが冗長になって保守性が落ちる。
メモリ食いのオブジェクトなど、クリティカルな部分でのみ使うべき
- 68 ：デフォルトの名無しさん：2015/11/28(土) 14:16:02.55 ID:81goelDj.net
- お前らか。無意味なnull代入書き散らしてるのは
- 69 ：デフォルトの名無しさん：2015/11/28(土) 14:42:43.95 ID:DqKP/LxN.net
- null代入とか結局やってることc++以下なんだよなぁ
- 70 ：デフォルトの名無しさん：2015/11/28(土) 14:48:25.74 ID:Fi4wDTmy.net
- ダングリングポインタが出ないって利点は有るにはあるが
スマートポインタ使えば済む話だしなぁ
weak_ptrもあるし
- 71 ：デフォルトの名無しさん：2015/11/28(土) 15:20:08.61 ID:vL/aYykM.net
- >>68
意味はあるじゃん
- 72 ：デフォルトの名無しさん：2015/11/28(土) 17:52:47.31 ID:CKvy7+My.net
- >>68
ここでおしまい！って書いてあるだけ。
こんなんで冗長とは評価されない。むしろ読みやすい。と判断した。
- 73 ：デフォルトの名無しさん：2015/11/28(土) 18:23:41.31 ID:ekTV2Qou.net
- 変数がどこで不要になるか明示しなきゃならんほど長い関数ばっかり書いてるのか
それともローカル変数とか無い言語を想定してるのか
- 74 ：デフォルトの名無しさん：2015/11/28(土) 18:24:46.08 ID:q5KJxTWt.net
- 無駄なことするな
どうせ最適化で削除される
- 75 ：デフォルトの名無しさん：2015/11/28(土) 18:28:07.06 ID:rTI66XO9.net
- 保守性より効率重視なんかでコード書くからメモリリークするんだよ。
- 76 ：デフォルトの名無しさん：2015/11/28(土) 19:04:25.52 ID:ekTV2Qou.net
- どんな意味でnull代入をしてるのか他人に伝わらなきゃ保守性もクソも無いよね
- 77 ：デフォルトの名無しさん：2015/11/28(土) 19:08:04.34 ID:rTI66XO9.net
- a = null;
で伝わらない人にはどんなコメント書いても伝わらないと思うんだ。
- 78 ：デフォルトの名無しさん：2015/11/28(土) 19:27:35.81 ID:pohBt4lh.net
- 関数内ローカルな変数は
いくら大きくても大概スコープだけで
どうにでもなる。
javascriptみたいなのはlambdaでスコープ切ればいい。
- 79 ：デフォルトの名無しさん：2015/11/28(土) 19:54:24.96 ID:CKvy7+My.net
- >>75,>>77
同じ結論ですわ。
null代入ってやっぱり特殊だから、コメントよりはるかに目が行く。
ここで使い終わったYO!！（逆に言えば、ここまでは意識してね。使ってるから。）ってわかってもらえれば良い。
- 80 ：デフォルトの名無しさん：2015/11/28(土) 20:10:37.33 ID:ekTV2Qou.net
- >>77
長い関数中にそれ出てきたら変数を使い回す前に初期化したいのかな？とかも考えるな
短い関数なら変数を使い終わったとか重要な情報じゃないから無駄な行入れて可読性下げてるだけ
- 81 ：デフォルトの名無しさん：2015/11/28(土) 20:14:43.65 ID:pohBt4lh.net
- 永続的な変数でもなきゃ、変数の寿命はコンパイラが把握しているから、null代入がどんな変数にも必要なら勝手に挿入するんじゃね。
そうじゃないとしたら、なんでもかんでもnull代入が必要なんてのは幻想だよ。
- 82 ：デフォルトの名無しさん：2015/11/28(土) 20:16:46.53 ID:Fi4wDTmy.net
- 勝手にnullを代入するとか、そんな変なコンパイラは困る
- 83 ：デフォルトの名無しさん：2015/11/28(土) 20:47:03.48 ID:03HlMXbm.net
- 話は変わるんだがスマートポインタのメリットって何？
コンストラクタで例外投げたとき
そこまでに初期化したメンバ変数のデストラクタを呼ぶため
みたいなのは聞いたことあるけどそれくらいのもん？
- 84 ：デフォルトの名無しさん：2015/11/28(土) 21:01:25.91 ID:DqKP/LxN.net
- >>83
別にコンストラクタじゃなくて関数内で確保した場合でも、
例外じゃなくreturnで戻った時も勝手に解放してくれたほうが
有り難いし、そもそも解放処理って忘れやすいものだろ
傘を置き忘れたり洗濯物を洗濯機に入れっぱなしにしたことの
ないものだけスマートポインタに石を投げなさい
- 85 ：デフォルトの名無しさん：2015/11/28(土) 21:20:40.16 ID:ETFlkHGB.net
- null 代入したら行数増えるじゃん…全部のローカル変数にやってんの？
どうしても明示したければスコープで区切った方がまし
それでもインデントが深くなるのであれだけど
- 86 ：デフォルトの名無しさん：2015/11/28(土) 23:46:43.25 ID:pohBt4lh.net
- >>82
勝手にnull代入すると表現するから気持ち悪く感じるだけで、コンパイラが各変数についてもうアクセスされる可能性の無い基本ブロックに到達したら、その変数をGCのマークの起点として使用しないようにフラグを管理すると言えば当たり前の話じゃね。
フラグの持ち方として変数にnullを代入しているだけで。
- 87 ：デフォルトの名無しさん：2015/11/29(日) 00:14:42.24 ID:qbMwzV1h.net
- >>84
> そもそも解放処理って忘れやすいものだろ
それを忘れるなどとんでもない
確保＆開放なんてプログラミングの花じゃん
キモじゃん
そこを工夫するのが楽しいんじゃん
設計も楽しいし
チマチマテストすんのも楽しい
温泉行って湯につかり忘れる心配はない
- 88 ：デフォルトの名無しさん：2015/11/29(日) 00:30:29.12 ID:Co3W2iFa.net
- >>87
まあ勉強目的でやるならいいんじゃね
俺は元々ゲームプログラマだったからもう嫌になるほどやったし
メモリ周り工夫するなら言語設計からしたいわ
- 89 ：デフォルトの名無しさん：2015/11/29(日) 13:48:13.85 ID:U49gaUJj.net
- 信じて送り出した >>87 がわがままな顧客を✕✕して三面記事に載るなんて…
- 90 ：デフォルトの名無しさん：2015/11/29(日) 14:29:40.51 ID:c+9MHjtm.net
- マークスイープ型のGCが必要かどうかについて、もう少し建設的な会話をしようよ
リソースを自動で開放してくれる機能は、無いよりは有った方が絶対に良い、と言い切ってよいよね
ただ、その方式が話の焦点だと思う
C++のスマポの参照カウンタ方式はデストラクタとの相性が良いし、RAIIもよく機能するし
開放されるタイミングもはっきりしているのて、手続き型言語と相性が良いし、軽い
ただし、循環参照があるとリークする
解決策として、片方をweak_ptrにするという方法が用意されている
weak_ptrは対象オブジェクトが開放されると勝手にヌルポみたいになるのでいろいろと悪用ができる
一方でマークスイープ系のGCは、循環参照があってもリークしない
しかし参照カウンタ方式に比べてマークスイープ系のGCが優れている点は、それだけ
重いし、いつ開放処理が実行されるか分からないので
リソース開放のタイミングを明確に行いたい場合のための別の仕組みが必要になった
どちらを選ぶ？
- 91 ：デフォルトの名無しさん：2015/11/29(日) 14:58:17.95 ID:7vkfzAlt.net
- GCの意見・・・OSではページファイル関連？
http://peace.2ch.net/test/read.cgi/tech/1447856699/l50
- 92 ：デフォルトの名無しさん：2015/11/29(日) 15:57:55.75 ID:Co3W2iFa.net
- そもそもc++においてメモリリークって対策も発見も
大して難しい部類のバグではないんだよなぁ
GCの優位性をアピールするために過剰に恐怖心を煽ってる気がする
- 93 ：デフォルトの名無しさん：2015/11/29(日) 16:00:08.95 ID:sCmmZzWu.net
- >>92
その程度の案件しか受けてないからだろう。
- 94 ：デフォルトの名無しさん：2015/11/29(日) 16:05:07.63 ID:QSPcxrGF.net
- >>90
つ世代別GC
immutableオブジェクトをバンバンnewしまくる関数型プログラミングに慣れてると
やっぱGCないとキツイわ
- 95 ：デフォルトの名無しさん：2015/11/29(日) 16:15:05.64 ID:Co3W2iFa.net
- >>93
いやいや普通難しいとされるバグってメモリ破壊とか同期周りだから
メモリリークなんてデバッガがチェックして丁寧なダンプ出してくれるし
組み込みとかの貧弱な環境なら専用のメモリ管理を用意して
いくらでも好きなチェックや情報出せるから
- 96 ：デフォルトの名無しさん：2015/11/29(日) 16:17:37.80 ID:AV0cYAnH.net
- >>92
それな
メモリの確保と開放の対応すら管理できない奴は
なんかもう何をどうしたってダメな気がする
初歩の初歩の初歩の話題を何度も何度も何度も繰り返しすぎ
- 97 ：デフォルトの名無しさん：2015/11/29(日) 16:20:05.34 ID:3h4H/kBH.net
- 忘れるとか忘れないとか池沼レベルの話じゃん。
ゴミクズ。
メモリの解放が必要ならそれは必要な機能の実装ってことになる。
それを忘れるってことはプログラムを組んでいて必要な機能の実装を忘れるってことだ。
必要な機能の実装を忘れるということは、例えば通販サイトのシステム開発請け負っておきながら、決済システムを実装し忘れるのと同等。
ありえない。
プログラム云々以前に頭の問題だろう。
必要な機能の実装を忘れる可能性におびえる池沼プログラマ。
最近流行りのADHD？なんじゃねえの。
- 98 ：デフォルトの名無しさん：2015/11/29(日) 16:24:33.80 ID:sCmmZzWu.net
- >>95
なるほど。経験の少なさがすぐ分るな。ログ出したらで数十ギガなんてよくあるよ。
ログから問題点をスクリプトで抽出するにも何時間とかかるとかいろいろ。
マルチスレッド絡んで特定のパターンだけだったりして再現性がなかったりする。
他システムの連携だと手が出せない部分の挙動がおかしい可能性もある。結局、oracleのバグだったとかね。
- 99 ：デフォルトの名無しさん：2015/11/29(日) 16:25:01.11 ID:1uX74bCE.net
- >>97
決済システムとメモリ解放は違うよ。
通販サイトのシステムをC言語で実装してみればわかるかと。
- 100 ：デフォルトの名無しさん：2015/11/29(日) 16:36:20.27 ID:Co3W2iFa.net
- >>98
はあ？なんでリーク箇所ダンプするだけの話でログ全部吐き出すことになってんの
普通確保する際にヘッダにそのブロックの確保場所埋め込んでるし
アロケータで生存期間のスコープを切り分けといてすぐ分かるようにするけど？
お前の関わったプロジェクトが糞なだけじゃね？
211 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★