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
意味はあるじゃん

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

>>68
ここでおしまい！って書いてあるだけ。
こんなんで冗長とは評価されない。むしろ読みやすい。と判断した。

**デフォルトの名無しさん** · 2015/11/28(土) 18:23:41.31

変数がどこで不要になるか明示しなきゃならんほど長い関数ばっかり書いてるのか
それともローカル変数とか無い言語を想定してるのか

**デフォルトの名無しさん** · 2015/11/28(土) 18:24:46.08

無駄なことするな
どうせ最適化で削除される

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

保守性より効率重視なんかでコード書くからメモリリークするんだよ。

**デフォルトの名無しさん** · 2015/11/28(土) 19:04:25.52

どんな意味でnull代入をしてるのか他人に伝わらなきゃ保守性もクソも無いよね

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

a = null;
で伝わらない人にはどんなコメント書いても伝わらないと思うんだ。

**デフォルトの名無しさん** · 2015/11/28(土) 19:27:35.81

関数内ローカルな変数は
いくら大きくても大概スコープだけで
どうにでもなる。

javascriptみたいなのはlambdaでスコープ切ればいい。

**デフォルトの名無しさん** · 2015/11/28(土) 19:54:24.96

>>75,>>77
同じ結論ですわ。
null代入ってやっぱり特殊だから、コメントよりはるかに目が行く。
ここで使い終わったYO!！（逆に言えば、ここまでは意識してね。使ってるから。）ってわかってもらえれば良い。

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

>>77
長い関数中にそれ出てきたら変数を使い回す前に初期化したいのかな？とかも考えるな
短い関数なら変数を使い終わったとか重要な情報じゃないから無駄な行入れて可読性下げてるだけ

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

永続的な変数でもなきゃ、変数の寿命はコンパイラが把握しているから、null代入がどんな変数にも必要なら勝手に挿入するんじゃね。

そうじゃないとしたら、なんでもかんでもnull代入が必要なんてのは幻想だよ。

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

勝手にnullを代入するとか、そんな変なコンパイラは困る

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

話は変わるんだがスマートポインタのメリットって何？
コンストラクタで例外投げたとき
そこまでに初期化したメンバ変数のデストラクタを呼ぶため
みたいなのは聞いたことあるけどそれくらいのもん？

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

>>83
別にコンストラクタじゃなくて関数内で確保した場合でも、
例外じゃなくreturnで戻った時も勝手に解放してくれたほうが
有り難いし、そもそも解放処理って忘れやすいものだろ
傘を置き忘れたり洗濯物を洗濯機に入れっぱなしにしたことの
ないものだけスマートポインタに石を投げなさい

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

null 代入したら行数増えるじゃん…全部のローカル変数にやってんの？
どうしても明示したければスコープで区切った方がまし
それでもインデントが深くなるのであれだけど

**デフォルトの名無しさん** · 2015/11/28(土) 23:46:43.25

>>82
勝手にnull代入すると表現するから気持ち悪く感じるだけで、コンパイラが各変数についてもうアクセスされる可能性の無い基本ブロックに到達したら、その変数をGCのマークの起点として使用しないようにフラグを管理すると言えば当たり前の話じゃね。
フラグの持ち方として変数にnullを代入しているだけで。

**デフォルトの名無しさん** · 2015/11/29(日) 00:14:42.24

>>84
> そもそも解放処理って忘れやすいものだろ

それを忘れるなどとんでもない
確保＆開放なんてプログラミングの花じゃん
キモじゃん
そこを工夫するのが楽しいんじゃん
設計も楽しいし
チマチマテストすんのも楽しい
温泉行って湯につかり忘れる心配はない

**デフォルトの名無しさん** · 2015/11/29(日) 00:30:29.12

>>87
まあ勉強目的でやるならいいんじゃね
俺は元々ゲームプログラマだったからもう嫌になるほどやったし
メモリ周り工夫するなら言語設計からしたいわ

**デフォルトの名無しさん** · 2015/11/29(日) 13:48:13.85

信じて送り出した >>87 がわがままな顧客を✕✕して三面記事に載るなんて…

**デフォルトの名無しさん** · 2015/11/29(日) 14:29:40.51

マークスイープ型のGCが必要かどうかについて、もう少し建設的な会話をしようよ
リソースを自動で開放してくれる機能は、無いよりは有った方が絶対に良い、と言い切ってよいよね
ただ、その方式が話の焦点だと思う

C++のスマポの参照カウンタ方式はデストラクタとの相性が良いし、RAIIもよく機能するし
開放されるタイミングもはっきりしているのて、手続き型言語と相性が良いし、軽い
ただし、循環参照があるとリークする
解決策として、片方をweak_ptrにするという方法が用意されている
weak_ptrは対象オブジェクトが開放されると勝手にヌルポみたいになるのでいろいろと悪用ができる

一方でマークスイープ系のGCは、循環参照があってもリークしない
しかし参照カウンタ方式に比べてマークスイープ系のGCが優れている点は、それだけ
重いし、いつ開放処理が実行されるか分からないので
リソース開放のタイミングを明確に行いたい場合のための別の仕組みが必要になった

どちらを選ぶ？

**デフォルトの名無しさん** · 2015/11/29(日) 14:58:17.95

GCの意見・・・OSではページファイル関連？
http://peace.2ch.net/test/read.cgi/tech/1447856699/l50

**デフォルトの名無しさん** · 2015/11/29(日) 15:57:55.75

そもそもc++においてメモリリークって対策も発見も
大して難しい部類のバグではないんだよなぁ
GCの優位性をアピールするために過剰に恐怖心を煽ってる気がする

**デフォルトの名無しさん** · 2015/11/29(日) 16:00:08.95

>>92
その程度の案件しか受けてないからだろう。

**デフォルトの名無しさん** · 2015/11/29(日) 16:05:07.63

>>90
つ世代別GC

immutableオブジェクトをバンバンnewしまくる関数型プログラミングに慣れてると
やっぱGCないとキツイわ

**デフォルトの名無しさん** · 2015/11/29(日) 16:15:05.64

>>93
いやいや普通難しいとされるバグってメモリ破壊とか同期周りだから
メモリリークなんてデバッガがチェックして丁寧なダンプ出してくれるし
組み込みとかの貧弱な環境なら専用のメモリ管理を用意して
いくらでも好きなチェックや情報出せるから

**デフォルトの名無しさん** · 2015/11/29(日) 16:17:37.80

>>92
それな
メモリの確保と開放の対応すら管理できない奴は
なんかもう何をどうしたってダメな気がする
初歩の初歩の初歩の話題を何度も何度も何度も繰り返しすぎ

**デフォルトの名無しさん** · 2015/11/29(日) 16:20:05.34

忘れるとか忘れないとか池沼レベルの話じゃん。
ゴミクズ。

メモリの解放が必要ならそれは必要な機能の実装ってことになる。
それを忘れるってことはプログラムを組んでいて必要な機能の実装を忘れるってことだ。
必要な機能の実装を忘れるということは、例えば通販サイトのシステム開発請け負っておきながら、決済システムを実装し忘れるのと同等。
ありえない。
プログラム云々以前に頭の問題だろう。

必要な機能の実装を忘れる可能性におびえる池沼プログラマ。
最近流行りのADHD？なんじゃねえの。

**デフォルトの名無しさん** · 2015/11/29(日) 16:24:33.80

>>95
なるほど。経験の少なさがすぐ分るな。ログ出したらで数十ギガなんてよくあるよ。
ログから問題点をスクリプトで抽出するにも何時間とかかるとかいろいろ。
マルチスレッド絡んで特定のパターンだけだったりして再現性がなかったりする。
他システムの連携だと手が出せない部分の挙動がおかしい可能性もある。結局、oracleのバグだったとかね。

**デフォルトの名無しさん** · 2015/11/29(日) 16:25:01.11

>>97
決済システムとメモリ解放は違うよ。
通販サイトのシステムをC言語で実装してみればわかるかと。

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

>>98
はあ？なんでリーク箇所ダンプするだけの話でログ全部吐き出すことになってんの
普通確保する際にヘッダにそのブロックの確保場所埋め込んでるし
アロケータで生存期間のスコープを切り分けといてすぐ分かるようにするけど？
お前の関わったプロジェクトが糞なだけじゃね？

**デフォルトの名無しさん** · 2015/11/29(日) 16:42:54.34

そもそも今時c++でgcならなんとかなる類いのメモリリーク起こすなんて、プログラマが屑なだけ。
リソースリークやその他の問題も確実に起こすこと請け合い。
GC言語でそのレベルのプログラマを使うような案件はGCによるメモリオーバーヘッドが気にならず、リソースリークも問題にならないような非常に緩い案件でしかない。

**デフォルトの名無しさん** · 2015/11/29(日) 16:46:22.91

>>100
はぁ。話にならんな。扱ってる規模が違いすぎる。

**デフォルトの名無しさん** · 2015/11/29(日) 16:52:06.50

>>102
おいおい反論できずに捨て台詞かよ
上でも書いたがコンシューマで開発してたから
100人*数年の規模でやってたんだけど
もしかしてC++みたいな危険な言語使ってて
今の今まで解析ツールなり自前のメモリ管理なり知らなかったの？

**デフォルトの名無しさん** · 2015/11/29(日) 19:41:19.37

お前ら派遣だろw
全体規模とお前らが任されてる範囲を都合よく混ぜるな。

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

ほーら、自分の知能が一般人より低いと認めたくないがゆえにレッテル貼りが始まった。
普通の人が当たり前にできることができないってかわいそうだな。
もしADHD？だったら治療法あるらしいから病院行ってみたら？
ここでレッテル貼りやってるよりよっぽど解決する可能性が高いぞ。

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

レッテル貼りは2chの華

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

>>100
リーク箇所がわかってればログ出力の必要なくね？
ホントに開発したことあるのかな？

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

>>107
普通C++のプロジェクトは専用のメモリ管理を用意するから
リークしたメモリはそれを確保したクラスとその行数まで特定できるようにしてるよ
アロケーターも分離しとけばアプリケーション終了させなくても
管理オブジェクトを破棄した時点でリークの判定できるし

リーク箇所特定するのに全ログから解析とか複合的なバグでもない限りしない
そんな状況許してる時点で負け

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

100人で数年のシステムなら
10人で一年でやるべきだな。
人を無駄に増やせば、意思疎通や連携に無駄に労力を割く。
開放云々より仕様レベルで齟齬が出やすくなるわ。

**デフォルトの名無しさん** · 2015/11/30(月) 15:00:18.02

>>108
リークしたクラスが分ればリーク原因が分るとかお花畑杉w

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

>>110
誰もリークしたクラスの事なんて言ってないんだが…理解できてる？(笑)
解らないなら解るだけの情報埋めたら？

**デフォルトの名無しさん** · 2015/11/30(月) 19:24:12.90

おいおいw

**デフォルトの名無しさん** · 2015/11/30(月) 19:31:17.77

>>112
そもそもGCがあろうとコンテナに突っ込んで消し忘れれば
オブジェクト破棄するまでメモリ圧迫し続けるって理解できてる？
リーク単体ならC++はそれと同等のレベルまで分かりやすく出来るんだよ
C++が困難なのはそういった管理情報も簡単に破壊出来てしまう点
リーク単体なら怖くはない

**デフォルトの名無しさん** · 2015/11/30(月) 19:47:37.41

なんかだんだん笑えて来たんだけど、ろくに理由も言わずに
「わかんないんですけど！？わかる奴はお花畑(怒)！！」って
なかなか面白い奴だな

**デフォルトの名無しさん** · 2015/11/30(月) 19:50:22.70

メモリの解放すら管理できない奴が、複雑な仕様を管理できるとは到底思えない・・・。
メモリの解放なんてなんの苦にもならんが・・・。

**デフォルトの名無しさん** · 2015/11/30(月) 20:14:21.83

やれやれw

MSやLinuxやFreeBSDまでメモリリークやらかす理由が分らないのか。

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

>>116
また反論できずに逃走かよw
そもそも欧米は原因分かっててもバグ無視する連中だろうがw
ライセンスで守られてりゃ平気で放置するぞ

**デフォルトの名無しさん** · 2015/11/30(月) 20:33:04.33

人生の管理ができない奴が、メモリを管理できるとは到底思えない

**デフォルトの名無しさん** · 2015/11/30(月) 20:49:26.08

そもそもLinuxカーネルもFreeBSDカーネルもC言語だろ
馬鹿丸出しだなw

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

>>115
それな
プログラミングにおいてメモリ周囲はまだ初歩だよな
そしてマルチスレッドはそれよりは大変だがこれも慣れると
結局大事なところをガッチリ排他処理するだけのことだしな

プログラミングって最後はインタフェース設計だけだから
使いやすくてコンパクトなインタフェースを求めていくだけ
これがプログラミング道の後半の道のり

**デフォルトの名無しさん** · 2015/11/30(月) 21:18:50.76

>>120
で例外系の実装がないから破綻するんだよ。実務経験ないとすぐ短絡的になるのが分る。

**デフォルトの名無しさん** · 2015/11/30(月) 21:25:49.32

意味が不明すぐるｗ

**デフォルトの名無しさん** · 2015/11/30(月) 21:28:33.92

うむ。まだおまえには早いかもしれない。

**デフォルトの名無しさん** · 2015/11/30(月) 21:47:43.54

>>122
馬鹿相手にしても時間の無駄だぞ
こいつ具体的なこと何も言わんし

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

>>124
そやね
一連のレスの意図すらよーわからんわ

**デフォルトの名無しさん** · 2015/12/01(火) 00:23:09.00

Guilty Crown?
たしかに失敗作だったなあ…

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

GCが云々というより抽象的なプログラミングしたい時は基本的なメモリ管理を言語に任せたいという欲求

**デフォルトの名無しさん** · 2015/12/01(火) 01:27:09.96

>>113
c++素人なんだけどリーク単体はともかくそれにメモリ破壊が合わさると頭がおかしくなって死ぬ
みたいな感じ？

**デフォルトの名無しさん** · 2015/12/01(火) 01:30:32.01

GCは関数型プログラミングでのみ正当化される
命令型プログラミングでは全く正当化されない

命令型プログラミング（＝チューリングマシンに基づく計算モデル）は読み書きの「順序」こそがネ申なので
命令コードの「順序」を横断して存続するブツは善と悪の最終戦争で滅ぼされるであろう
つまり確保し、使ったら後開放する、これを明示的に書き下す姿勢こそが正しい

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

>GCは関数型プログラミングでのみ正当化される
ちな、これは処理系の裏方としての存在が許される、の意味

**デフォルトの名無しさん** · 2015/12/01(火) 01:36:31.76

関数型プログラミング好きだけど
代数型データ型と型クラスでモナドとかアプリカティブとかtraverse、free monadとかやってる時に
メモリ管理だの言われたら余裕で死ねるな
本物のhaskellプログラマはhaskellで低レイヤを書くらしいけど

**Office & Gamers @ 試験運用中（トリなしｗ** · 2015/12/01(火) 04:32:07.54

口先人間展覧会。（ｱﾊ

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

>>128
> メモリ破壊が合わさると

これが合わさるとなんでもありありなので何が起きても不思議はない
なので、ダングリングポインタの管理と配列のレンジチェックはちゃんとやるべし

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

ここでメモリ確保
ここでメモリ解放

たったこれだけが書けない管理できないとかw

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

知らないでやるって幸せなことなんですね

**デフォルトの名無しさん** · 2015/12/03(木) 13:19:32.39

>>134
下には下がいるんだよ

**デフォルトの名無しさん** · 2015/12/03(木) 13:29:54.15

メモリリークは開放忘れでなると思ってる低レベルがいるのか。

**デフォルトの名無しさん** · 2015/12/03(木) 14:07:05.91

低レベルなことを舐めるなよ

**デフォルトの名無しさん** · 2015/12/03(木) 16:32:54.69

>>134
mallocでOSから確保したメモリはfreeで解放されないんだが、

「ここで解放」はどうやって書くんでしょう?

**デフォルトの名無しさん** · 2015/12/03(木) 19:43:25.89

>>137や>>139みたいのが知識や技術に溺れて本質を見失い、
人と会話ができなくなった人の見本なんだろうか

**デフォルトの名無しさん** · 2015/12/03(木) 19:47:17.15

>>140
今まで正しいと信じきってた鰯の頭が迷信だと指摘され発狂中

**デフォルトの名無しさん** · 2015/12/03(木) 19:53:39.75

>>141おｗ　おまえ会社で孤立してるだろ派遣ｗ

**デフォルトの名無しさん** · 2015/12/03(木) 20:32:35.32

確保したやつが解放するんだぞ。大丈夫か？

**デフォルトの名無しさん** · 2015/12/03(木) 20:33:46.24

想像を絶するアホは居るもんだよ
if (cond) exp; の場合も中カッコを必ず付ける流派ってのがあって
理由を聞くと
if (cond) {exp1; exp2;}とするはずが
if (cond) exp1; exp2;としてしまうのを防ぐための常に中カッコらしい

中カッコを書き忘れるくらいの意識レベルで書かれたコードって
他のとこももう全部ダメだろそれは

**デフォルトの名無しさん** · 2015/12/03(木) 20:52:03.75

>>144
お前がアホなｗｗｗ

**デフォルトの名無しさん** · 2015/12/03(木) 21:25:03.70

カッコ先につけといたほうが　後々、都合がいいことも

**デフォルトの名無しさん** · 2015/12/03(木) 21:30:08.65

アホな書き方といえば
　if ( 1 == a ) {
って比較元と先を逆にしてる奴

**デフォルトの名無しさん** · 2015/12/03(木) 21:41:57.39

別におかしくない
基準値が先にあって、それと比べてaがどうなのか、と考えるか
aが先にあって、基準値と比べてどうなのか、と考えるかの違いでしか無いから
どっちでも良い

**デフォルトの名無しさん** · 2015/12/03(木) 21:59:47.07

>>147
知ってて言ってると思うが、定数を==の左辺にするのは
if (a=1) { ...
と書き間違うのを恐れているらしい

>>139
free()から設計し直す、
まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ

>>135
スレッド安全に書かない奴が悪いていうかそれは別の話
シングルスレッド状況（またはそれと等価な状況）では>>134の言っていることは全く正しい

**デフォルトの名無しさん** · 2015/12/03(木) 22:27:47.14

ここ数日一気にレベルが下がったなw
ＧＣの話しろよw

**デフォルトの名無しさん** · 2015/12/03(木) 22:46:13.76

つーか前スレと同じこと書いてる人多数
頼むから前スレ読んできて

**デフォルトの名無しさん** · 2015/12/04(金) 04:37:18.54

【　オンラインTCGエディター　】　>>1

デュエル・マスターズ的な非電源TCGの　《　オンライン化ツクール系ソフト　》　制作の企画。

例えば、ガチンコ・ジャッジを直ぐにでも導入できる機能を持っておりながら、
当面それを扱わず単純化させておいて、事後的に導入拡張する際に当該システムを
ブロック構造の組み合わせで後付け挿入できるように予めシステム化してあるソフト（エディター）。
既存の非電源TCGを劣らずに再現できるならば大概のニーズに応えられる筈。
バトスピ、ヴァンガ、ウィクロス、ポケカ、デジモン、ゼクス、モンコレ、ガンダム・ウォー、ライブオン、ディメンション・ゼロ、カードヒーロー、シャーマン・キングなど
のシステムを完全再現できるように設計するけど、他に此のTCGの此のシステムは再現希望とか有ったら書いて。
マジック：ザ・ギャザリングの全システムを完全に再現するのは無理だから、此れだけは必用だ！って部分のみリクエストして。
WEB通信での対戦は、個vs個、多数乱戦、チームvsチーム、個vsチームを可能な仕様とする方針。

設計思想は　《　RPGツクール　》　が良いかな？　　他に、優れたエディター有ったら挙げてみて。

個人や企業などのベンダーが提示する開発費（見積もり）で折り合えば、発注する。
↓
エディター群から基本コンセプトを絞り込む（もちろんオリジナルで優れた新ネタが有れば導入する）。
↓
遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。
なるべく前述３つで可能な再現は全て実装させる方向を目指す。　まぁ努力する・・・
バトスピ、ヴァンガ、バディ、デュエマなど発売済みゲームソフトが存在してるケースはベンダーに研究させる。
↓
各社TCGを再現するテストプレイ　⇒　更に改良や修正。
↓
機能制限した下位版を５万円以上で発売　＋　デュエリ－グ用に改造した上位版でサーバー稼動＝営業開始。
↑
下位版の改造および商用利用には、別途で当社との契約が必要。

さ～て、製作ベンダー見つけよっと！ｗｗ（ｸｽ
http://wc2014.2ch.net/test/read.cgi/entrance2/1449039272/-18

**デフォルトの名無しさん** · 2015/12/04(金) 12:21:13.29

>>149
>free()から設計し直す、
>まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ

じゃ>>134は設計し直してから言うんだな。坊や。
って、事でオッケーね。

**デフォルトの名無しさん** · 2015/12/04(金) 20:05:33.81

>>137これって何が言いたいの？OSやライブラリ自体にミスがあるって言いたいの？
wikiより
>メモリリーク (Memory leak) とは、プログラミングにおけるバグの一種。
>プログラムが確保したメモリの一部、または全部を解放するのを忘れ、確保したままになってしまうことを言う。
>プログラマによる単純なミスやプログラムの論理的欠陥によって発生することが多い。

>>137みたいなこと言う奴って、電磁波からデータが盗まれる！対応しないと！とか言い出すタイプ？

**デフォルトの名無しさん** · 2015/12/04(金) 21:16:45.71

>>151
そもそも１５年ぐらい前から延々繰り返されてるんだが…

**デフォルトの名無しさん** · 2015/12/04(金) 23:45:19.53

>>154
開放コードを忘れずに書いたのに開放されないという怪奇現象がマルチスレッド状況ではしばしばあるんじゃー！
マルチコア時代になってこれはますます危険になった
見ただけで正しさがわかる系のスレッド安全策はクロックサイクルを糞のごとく消費するし…

こういうのは専門家が徹底的にデバッグしたGCで面倒を見て欲しいと思う反面、
やっぱプロセス全体のごみ処理を選任モジュールにやらせるのはクロックサイクルをドブに捨てるがごとき
センス無い設計なｷﾓｽ、、

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

それ単にメモリバリアの問題じゃ…

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

>>154
入門書に書いてるコードしか見たことないんだね。
スレッドプールみたいなテクニックは高速化のためにみな普通に使うんだよ。
OSやライブラリにもメモリリークなんてよくあることだし、それらのバグも開放忘れて起きてるイージーなバグじゃないよ。
他のバグやトラブルがメモリリークという形で表面化してるにすぎない。

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

>>158
具体的にいつのどのバージョンのライブラリで起きてるの？
使い終わったらメモリを開放しろ。使い終わってないなら開放する必要はない。これとスレッドプールとどこに関連性があるの？

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

>>159詰めても無意味。
こういう連中は、まず自分の考えややり方が絶対正しく絶対に曲げない。曲げないために無理やり理由を当てはめようとしている。
で、さもそれを自分はやってるように言っているが、実際は単に本に載ってることを言ってるだけ。
実装もできない。面前で詰めてやれば発狂して勝敗がハッキリつくけどネット上では無理だね。

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

メモリの話とスレッドの話を混ぜ込んでしまうタイプは
問題の切り分けがそもそも出来ないタイプ
だからメモリリーク（）に悩まされる

スレッド間の協調と、メモリのケアは直交する別の話題

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

>>158
ちょっ漏れが作ったわけでも漏れの使い方に問題があるわけでもない階層で起きるメモリリークの責任を漏れに負わされても困る…
それに他人が作ったモジュール内でのメモリリークも結局は開放が書かれていなかったか、書かれていても正しくなかったからリークしているはず…

>>161
全面同意だが同意したからと言ってメモリリークがゼロになるかっていうと以下略
単純にクリティカルセクションとかキューによるシリアライズ（Active Objectパターン）で排他して
マルチコアを活かさずパフォーマンスをドブに捨てて良ければ平和なんだが…

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

だからメモリを自動開放してほしいときはスマートポインタを使えばよいだろ
循環参照が無い限りshared_ptrで問題ないだろ
循環参照がある場合はどちらかをweak_ptrにすれば済む話だろ

現実にshared_ptrの様な物が存在して無いなら、そういう議論も意味があるが
実際にはshared_ptrは現実に有るのだから、自動管理したい場合は使えばよいだけの話でしかない

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

むしろ議論すべきはshared_ptrのような参照カウンタ方式のスマポと
言語ビルドインのマークスイープ系のGCとで
どちらが良いか、だろう

参照カウンタ方式は循環参照で問題を起こすし
マークスイープ系のGCはいつ実行されるか分からない

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

つまり、完璧なGCは無いということだ

完璧なGCが無い以上、使う側が状況に合わせて選べた方が良いわけだが
そうなるとC++/CLIのような変体言語しかないのが残念だ

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

普通に言語を選べば良いだけの話では

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

このスレ論点が一致してないよね。
　freeやdeleteを記述すべきという論点で話をしている人
　freeやdeleteしたところでメモリが解放されてるわけではないですがという論点の人
　freeやdeleteは当然、さらにnull等を記述すべきという論点で話をしている人
　GCの実装そのものを論点にしている人
論点がばらっばらだから咬み合わない

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

>>158
> OSやライブラリにもメモリリークなんてよくあることだし

よくあると言うなら１０個ぐらいすぐにあげられるよな
もちろん最新版でリークする奴ね

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

MSのサイトにfix分と調査中のものが全部公開されてる。他のOSもlog、mlみれば腐るほど出てくる。

10個上げろとか、ほんと幼稚園児かよ、おまえらは。頭悪すぎw

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

C++でRAIIを徹底しておくのが一番いいよ
解放タイミングのコントロールが必要になったら後からでも柔軟に対応できるし
GCは解放に係る少し変わった条件が発生した時に滅茶汚いことをしなきゃならなくなる

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

shareed_ptrはC++で比較的効率よくやれることと、GCしたい人が真にやりたいことの妥協の産物であって
どんなシチュでもベストにフィットするような一押しの決定版ってほどでも無い…

参照カウンタの排他が不要で循環参照が無いことも保証できるまで設計が詰められているなら
スレッドごとに、メモリを確保して使って返す処理を直に書くのが一番良い

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

確保／解放を直に書くのはスピード的には一番速いだろうけど解放漏れバグの温床過ぎてネ
特に例外が絡むとやってられない状況になる

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

>>167
null云々は別言語だ馬鹿

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

>>169
> もちろん最新版でリークする奴ね

早くあげてよね w

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

>>172
>特に例外が絡むとやってられない状況になる
そこだけはstd::unique_ptr<T>の一押し
これで例外状況でのRAIIが完成するので真にGCが要らんところまで逝く

ていうか大概のアプリなら、例外を生じたらFatal errorなことをユーザーに知らせて終了、でいいんじゃ…

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

>>175
いやーリソース獲得した状態でファイルI/Oとかネットワークとかが絡む場合は終了じゃすまん場合が多いでしょ

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

昔C言語で数珠繋ぎの独自スコープとしてblock_enter/block_leaveというのを作って

{
block_handle h = block_enter(b)

object = block_create_object(h)

block_leave(h)
}

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

書き損じた
昔C言語で数珠繋ぎの独自スコープとしてblock_enter/block_leaveというのを作って

func(b){
block_handle h = block_enter(b)

object = block_create_object(h)

block_leave(b, h)
}
というので例外にも対応したリソースマネージャ作った
block_leave(b, h)せずにスコープ抜けても上位のblock_leaveで開放が保証されたり
block_leave(b, 0)で全開放とかそんなの

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

デメリットはblock_create～で作成するものは全部ヒープに確保されること
結局C言語でここまで必要な案件てのが回ってこなくてあんま使ってないけどリーク予防法の参考程度に

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

例外にも対応って？

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

C#でアンマネージドなメモリを扱えるのはわかった
確保したメモリ領域にオブジェクトを配置する事は出来ない？
C++で言うところの配置newを再現したいんだ
メモリの確保解放はプログラマが特別に管理してその間は普通のオブジェクトと同じように透過的に扱いたい

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

>>180
例外つってるのは具体的にはSEHの話
どっかで止めた時点のblock_leave(b, h)でそれまでの開放が保証されるってこと

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

C++にfinallyが無いのが気に食わない
今はラムダが有るのでマクロでそれっぽいものを自作したが
標準で用意しておいてほしい
C++はリソースを自分で管理する傾向のある言語なのに
finallyが無いのは本来おかしいよな
ラッパー作ってRAIIを徹底しろってことなんだろうけど
すべてのリソースに対してラッパーを用意するのは面倒だよ
fainallyが有ったって邪魔になるわけでもないのに
最終的に使うかどうかは利用者が選べばよいことだし
C++ってそういう言語だろ

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

>>183
C++にはテンプレートがあるからリソースの型をテンプレート引数とするラッパーを作るのは
そんなに面倒なことじゃないと思う
あとC++でRAIIを徹底してればfainallyの必要性を感じたことはない
fainallyを書かなければいけない時点で危なっかしいコードだと思う

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

むしろfinallyってデストラクタがない言語だから
必要なものなんじゃ…
どうしても必要ならデストラクタで任意のラムダ呼ぶ
ユーティリティクラス作れば同じこと出来るし

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

98以前でもローカルクラス定義できるんだからすこし冗長なだけで同じだし

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

例外発生はバグ、というプログラミングしかしたことないからよくは知らんが、
try {
　try {
　　/*...*/
　} catch (std::badalloc()) {
　　/*...*/
} catch (UserException e) {
　　/*...*/
}
} catch (...) { // fainally節の代わり
　/*...*/
}
じゃあいかんの？実行時コストは知らん

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

ｽﾏﾝ
誤： } catch (std::badalloc()) {
正： } catch (std::badalloc e) {

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

違う。そんぐらいググれ

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

デストラクタの問題点は不可視なところだな
usingやfinallyは目に見えるから安心する

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

>>189
内側のtry～catchから再throwするのを忘れたorz
内側のtry～catchから再throwして外側ので再捕捉したらいいんじゃ…

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

例外をロジックとして使うなってばっちゃんが言ってた

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

>>191
throwせずにreturnするパスが有ったらどうするんだよ
そういうのを防ぐためのfinallyやRAIIなのに
まったくちんぷんかんぷん
結局returnする前に手動で忘れないようにthrowすることを強制するんなら
goto文とか開放用ラムダ呼び出すのとかと替わらないだろ

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

だから忘れる忘れないレベルをぶち込んでくるのは止めようやｗ
これをぶち込むから全ての議論が池沼レベルになってる

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

異常系で例外返す仕様のライブラリが失敗。

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

>>194
GCなんて池沼のために生まれたようなものだし・・・
NULLったりfreeったりすることすらまともに把握、指示しきれない

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

c++のデストラクタって後処理に失敗しても
例外投げられないからウンコ
結果的にエラーを握り潰すゴミコードを量産する原因になってる

**デフォルトの名無しさん** · 2015/12/06(日) 11:40:47.08

そのクラスが管理してる範囲で後処理の失敗って何が起こるの？

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

どうしてもやりたいなら対処法はあるしなぁ。

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

現実的な確率で発生して無視出来ないリスクが有る解放処理はデストラクタでやるべきじゃない
そういうリソースに対してデストラクタがやる事はプログラマに対しいて未解放のリソースを通知する事だけでよい

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

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