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/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

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

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

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