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/

**デフォルトの名無しさん** · 2016/04/23(土) 20:33:25.39

キャッシュヒット率が落ちそう(コナミ)

**デフォルトの名無しさん** · 2016/04/24(日) 01:18:30.93

>>512
お前のプログラムはメモリを1ページしか使わんのかｗ？
フラグメンテーションで使用率が低いスカスカのページだらけになるのが問題なんだろうが。

**デフォルトの名無しさん** · 2016/04/24(日) 01:38:34.87

>>516
へーお前はヒープを使わないのか
漢だな

**デフォルトの名無しさん** · 2016/04/24(日) 08:38:51.73

メモリー512バイトでどうやってヒープを使えと。

**デフォルトの名無しさん** · 2016/04/24(日) 09:31:32.99

ネイティブコードが必要な場面で中途半端に GC に頼るのが問題なのかもしれないが、もうネイティブコードが必要な戦場は限られた一部だけになってて、主戦場では GC は大前提の技術なんだから必要ないとか言われましてもですわ。

**デフォルトの名無しさん** · 2016/04/24(日) 10:14:15.47

ページがスカスカになっても大丈夫
1ページ4KBとかだからね、十分小さい
32x32-32bitビットマップより小さい

最近のゲームで使われるような大きなサイズのテクスチャなど
でかいサイズを確保する場合はどうせ新しいページが割り当てられるし
小さなサイズを確保する場合は、スカスカになったページから空いているところを探して割り当てられるので
問題ない

**デフォルトの名無しさん** · 2016/04/24(日) 10:14:59.78

androidしか知りませんみたいな事言われてもな

**デフォルトの名無しさん** · 2016/04/24(日) 10:27:10.54

物理アドレスはページサイズで切り売りされるので
元から連続しているアドレスは必要ではなく
フラグメンテーションは問題にならない

連続したアドレスが必要になるのは論理アドレスのほうであり
32bitプロセスでは4GBしか空間がないから問題になることがある
64bitプロセスであれば現状問題にならない

**デフォルトの名無しさん** · 2016/04/24(日) 10:37:41.02

実はQtでデーモン作って動かしてるのだが、もう半年以上動き続けてる。
まさかこんなに問題が起きないとは。
案ずるより産むがやすしですぞ皆の衆。

**デフォルトの名無しさん** · 2016/04/24(日) 10:58:37.83

Qtで作ったのは一日ででっち上げる為だったのだが、意外なことに堅牢に動き続けてる。

**デフォルトの名無しさん** · 2016/04/24(日) 12:08:49.17

Qt でデーモン?
GUI が必要なデーモン?

**デフォルトの名無しさん** · 2016/04/24(日) 12:13:06.27

>>525
デーモンは通常フォアグラウンドじゃないのでUIを持ちませんぜ旦那。

**デフォルトの名無しさん** · 2016/04/24(日) 12:25:33.24

ならば何に何故どのように Qt を使うのだ？

**デフォルトの名無しさん** · 2016/04/24(日) 12:45:58.38

>>526
だからQtでデーモン？(クエスチョン)…なんじゃね？
加えてQtってGC関係あるのか？
たしかC++のライブラリーだよね？

**デフォルトの名無しさん** · 2016/04/24(日) 13:02:46.55

等と意味不明な供述をしており。

**デフォルトの名無しさん** · 2016/04/24(日) 14:52:01.10

>>525
Qt 使ってるからと言って QtGui 使ってるとは限らんけどね

>>528
Qt 本体は C++ で書かれてるけ
ど Java, Ruby, Python, Perl, C# 等からも利用できるよ

**デフォルトの名無しさん** · 2016/04/24(日) 14:52:56.88

daemonじゃなくてdemonなんじゃない？
デスクトップマスコット的な

**デフォルトの名無しさん** · 2016/04/24(日) 14:59:36.53

俺が作ったのはウェブソケットによってサービスを提供するプログラムだ。
エンジンエックスをリバースプロキシとした。
このプログラムは常時数千の接続から大量のリクエストを受け付ける。
接続してくるクライアントは専用に作られQtで書かれている。
大量のリクエストはそれぞれ複数のデータベース検索を引き起こす。

こう書くと結構負荷が高そうなのだが、さすがC++、ほとんど塵程度の負荷しかなく、
当然のことながらリプライに遅延もない。
そこで案ずるよりも生むが易しというわけ。

Qtは出自からしてGUIのためのライブラリではあるのだが、GUIが無いと使えないというわけでもない。
むしろボリュームからすれば、GUI以外の方がより大きい。
そして、半年動きっぱなしで大丈夫ことからして、実は断片化は気にしなくても
良さそうだ。

**デフォルトの名無しさん** · 2016/04/24(日) 15:05:02.69

ちなみにQt使ってなかったら一日でサービスを書き上げることは不可能だっただろう。
Qtは、その他のGUIライブラリ同様バグが多いのだが、GUIを抜いてみるとどうだろう、
意外なほどに堅牢なのだ。
何しろもう半年動きっぱなし。

俺はこの経験から一つの予測を立てた。
これからのサービスは、C++で書かれるようになる可能性がある。
何しろ圧倒的に速い。
一つのリクエストに対するレスポンスが速いため、平均負荷率が圧倒的に下がるのだ。
この事実に世の中が気づくにはそう時間がかからないはず。

そしてsystemdがこの動きを促進するはず。

ちなみにWindowsで書いてLinuxで動かしてます。

**デフォルトの名無しさん** · 2016/04/24(日) 15:05:44.58

一例をもって一般化はできないだろ

**デフォルトの名無しさん** · 2016/04/24(日) 15:05:53.54

>>530
色々な言語から使えるのか
そういう場合Qtが使うメモリーなんかはどういう扱いなんだろうね
GC適用外な気がするけど知らないからこれでやめとくわ

**デフォルトの名無しさん** · 2016/04/24(日) 15:08:01.90

Windowsで書いてLinuxで動かすことに、systemdは大いに貢献した。
従来のデーモンの作り方では、いろいろ煩雑なことがありすぎ、時間の制限から難しかっただろう。

Qt+systemd、この直観的な選択は大成功であった。

**デフォルトの名無しさん** · 2016/04/24(日) 15:11:43.89

Qtのバグの多くは、複数の環境に対応するため、その差異によって引き起こされているという結論を得た。

systemd万歳！

**デフォルトの名無しさん** · 2016/04/24(日) 15:16:24.95

更にもう一つヒントがある。

複数のクライアントから多様なリクエストがあるとはいえ、一つのプログラムが擁する
データ構造などたかが知れているのだ。

クライアントAのリクエストにこたえるため使用された記憶空間は、解放されたのち
クライアントBのためにそのまま使われる可能性があるのだ。

そういったわけで断片化は気にする必要が無い。

若者よ、案ずるより産むが易しですぞ。

**デフォルトの名無しさん** · 2016/04/24(日) 15:28:56.74

ねえ訳分かんないんだけど
本人以外で理解してる人要るの？

**デフォルトの名無しさん** · 2016/04/24(日) 15:55:24.75

むやみに連投してる奴はたいていスルーでok

**デフォルトの名無しさん** · 2016/04/24(日) 20:02:15.39

むしろ、わからないのに何故、一生懸命主張していたのかと。

**デフォルトの名無しさん** · 2016/04/24(日) 20:22:44.80

誰と戦っているんだろう…

**デフォルトの名無しさん** · 2016/04/24(日) 22:39:17.85

マークスイープでメモリリークってどうやって起きるんだ？

初心者だから優しく説明してほしい

**デフォルトの名無しさん** · 2016/04/25(月) 01:16:56.77

狭義の意味では起きない
もし君が気付かない間にオブジェクトへの参照を保持していたらどんなGCだろうが解放されない
それをリークというならリークする

**デフォルトの名無しさん** · 2016/04/25(月) 13:44:57.25

言い換えればダングリングポインタが発生しない
それだけ

**デフォルトの名無しさん** · 2016/04/25(月) 14:51:13.10

マーク＆スイープでもポインタの型情報を記録してないとリークしまくる

無関係な数値をアドレス参照と勘違いしてマーク→未開放
某言語ではこのために巨大なメモリブロックが開放されない

**デフォルトの名無しさん** · 2016/04/25(月) 20:35:07.72

>>543
どこからマークを始めるかが問題

**デフォルトの名無しさん** · 2016/04/29(金) 18:58:56.34

>>10
C#はGCの掃除処理を任意で呼び出せるだけだろ

C++/CLIなら自分でdelete呼べば即座に消え去るが
もちろんC++と同じくデストラクタも確実に起動する。

**デフォルトの名無しさん** · 2016/04/29(金) 22:46:31.85

C++/CLIはデストラクタが呼ばれるだけで、managedメモリの解放がGC任せなのは変わらんよ。

**デフォルトの名無しさん** · 2016/05/01(日) 07:57:30.30

匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？

Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ

The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
w

**デフォルトの名無しさん** · 2016/05/01(日) 09:11:45.10

無視リストに追加と

**デフォルトの名無しさん** · 2016/05/02(月) 21:54:41.51

GCCは失敗、Clangを使え。

**デフォルトの名無しさん** · 2016/05/02(月) 22:21:36.97

うるせーバーカ

**デフォルトの名無しさん** · 2016/05/04(水) 17:42:43.75

gccは失敗。

**デフォルトの名無しさん** · 2016/05/27(金) 12:06:01.84

良スレ発見した。Windowsは32bitで十分だな。32bitでもPAEで4GB超の
メモリ認識するし、仮想メモリは4GBのままだが、AWEを使うことにより
バンク切り替え的にメモリウインドウを切り替えられる

**デフォルトの名無しさん** · 2016/05/27(金) 19:30:30.19

>>555
アプリはよくてもカーネルはつらい

**デフォルトの名無しさん** · 2016/05/28(土) 04:39:26.17

メモリーは俺が確保してやる、任せろ。

**デフォルトの名無しさん** · 2016/05/29(日) 07:51:44.19

おう、この手は絶対、絶対に、死んでも離さねぇ！！

**デフォルトの名無しさん** · 2016/05/29(日) 11:50:15.87

OSに載った気持ちでいなさい

**デフォルトの名無しさん** · 2016/05/31(火) 22:56:21.68

>>1みたいなやつは
研究室にヒキって、社会に出たことないんやろ

おまえ、本気の糞コードで書かれたペチプ～とか見たらチビるで
あんなんに加えてメモリ管理なんてやらせたら
それこそHELLO END OF THE WORLD
この世の終わりですわ

**デフォルトの名無しさん** · 2016/06/07(火) 12:20:18.65

>>558
死んだら離せw

**デフォルトの名無しさん** · 2016/06/12(日) 09:40:01.67

死後硬直ですね

**デフォルトの名無しさん** · 2016/06/18(土) 23:15:40.44

指摘してるレスがなかったので言っとくが
循環参照は参照カウント方式＋Cycle Collectorでも回収できるから
GCは必須じゃないぞ
興味があるならBacon Cycle Collectorで調べてみろ

**デフォルトの名無しさん** · 2016/06/18(土) 23:22:46.70

学生の頃は循環参照できないことに困ってたけど、今となっては何時
循環参照が必要になるかさえ思い出せんな。

**デフォルトの名無しさん** · 2016/06/19(日) 21:38:00.28

双方向リスト構造

**デフォルトの名無しさん** · 2016/06/19(日) 22:17:16.01

>>563
＞Cycle Collector
いわゆるmark&sweep式とどう違うの？

**デフォルトの名無しさん** · 2016/06/20(月) 01:16:50.71

（コンパクションしてくれるんだろうか）

**デフォルトの名無しさん** · 2016/06/22(水) 08:52:46.04

vmが諸悪の根源な気がしてきた

**デフォルトの名無しさん** · 2016/07/06(水) 07:12:12.60

>>568
まずガベージだらけの頭の中を整理すべき

**デフォルトの名無しさん** · 2016/07/16(土) 10:10:08.78

>>565
別に
単方向リストでもなるだろＪＫ

ていうかリストの要素をshared_ptrにするのは現代でも有効
リストのリンクヘッダ自体の寿命は要素が明示的にdeleteされるかリスト全体が廃棄されるまでなので
リンクヘッダも管理したければリスト固有のストレージ丸ごとな単位でshared_ptrにしたら良い、
希ガス

**デフォルトの名無しさん** · 2016/07/16(土) 10:13:41.67

△: リストの要素
○: リストの要素が保持するデータ

つか開放タイミングをshared_ptrに任せておk、などという発想のは管理しているうちに含めれないがな…

**デフォルトの名無しさん** · 2016/07/16(土) 10:38:52.53

一般のグラフじゃなくてリスト構造の話だろ？
双方向リストはheadとtailへの参照があるが、単方向リストで循環参照は生じようがないが。

**デフォルトの名無しさん** · 2016/07/16(土) 11:51:50.13

>>572
すまんの>>570の単方向リストは正確には循環リストもしくは環状リストと呼んだ方が良いかも試練、

だが、循環リストもしくは環状リストも単方向リストの実装方式の一つではある（初期の『プログラミング言語C++』か何かのslist等
のじゃ…！

**デフォルトの名無しさん** · 2016/08/22(月) 17:06:41.08

循環してるかは後付けでオブジェクトをマークすれば判るんだし
扱うデータ構造から可能性の有無は予測できるし循環自体は大した問題じゃないよ
あ、これリークするなと思ったら対策すればいいだけ
問題は他人様のブラックボックスなライブラリを使う場合

**デフォルトの名無しさん** · 2016/08/22(月) 19:24:37.36

？
今の議論はプログラマーが何も考えないアホでもGC(言語)使ってれば問題無いのか
そうでなければ結局なんらかの管理が必要でちゃんとする事しないとリークするから本質的には管理から開放されないよねって話だと思うが

**デフォルトの名無しさん** · 2016/08/22(月) 19:33:58.37

いまどきの子はブラウザアプリしか作れないから
ブラウザ再起動とかページ遷移で解決でしょうな

**デフォルトの名無しさん** · 2016/08/23(火) 19:56:22.47

現在のGCが不完全なだけであって、
メモリは人が管理すべきでないという考え自体は正しいよ。

**デフォルトの名無しさん** · 2016/08/23(火) 20:17:10.56

潤沢なメモリを用意してGCしない戦略
起動時間に限ってGCしなくても問題ない範囲であればGCしない戦略
結局こういうのが勝つ

**デフォルトの名無しさん** · 2016/08/23(火) 20:29:14.30

プロセスを細かく分けて寿命を短くすればそんなの考えなくて済む

**デフォルトの名無しさん** · 2016/08/24(水) 13:32:09.69

本当の意味での軽量プロセスをOSがサポートしてくれたら良いんだけどね
メモリプールみたいなもんなんだけど、OSのリソースも紐づいてて
メモリプール解放時にOSのリソースもちゃんと解放されるようなもの
マルチプロセスは非常に強力で良いんだけど
メモリ空間が別になるから色々面倒だしパフォーマンスも出にくい

世の中には呼び出したらしばらく処理が返ってこない時間のかかる関数があるけど
とうぜんUIが固まったら困るから別スレッドで実行するわけだけど
処理中にユーザーがキャンセルボタンを押したとき
処理を中断する手段が関数側に用意されてなかったりすると、困る
外からスレッドごと殺しても、リソースリークの問題が出る
真っ先に困るのが同期オブジェクト
同期オブジェクトを握った状態で死なれると、それ以降デッドロックを引き起こす
それ以外にも、プログラムの整合性が壊れているかもしれないので、以降正しく動く保証がない

だから別プロセスで実行して、キャンセルされたときはプロセスごと殺すしか方法が無い
しかし別プロセスにするとメモリ空間が繋がってないので面倒
だからその中間がほしい

**デフォルトの名無しさん** · 2016/08/24(水) 16:03:33.76

erlang最強

**デフォルトの名無しさん** · 2016/08/24(水) 19:53:51.27

軽量プロセスより重量スレッドの方が実現できそう。

**デフォルトの名無しさん** · 2016/08/24(水) 20:02:24.36

いつ無くなってしまうかわからんようなメモリのアクセスが簡単になってもほとんど使いみちないだろ。
安全性重視なら別プロセスにして、必要なデータだけ共有メモリで受け渡してのが妥当なところだろう。

**デフォルトの名無しさん** · 2016/08/24(水) 20:18:52.71

結論から言うと、Windowsにforkが無いのが面倒すぎるってことなんだけどね

**デフォルトの名無しさん** · 2016/08/24(水) 20:32:21.12

>>580
> 処理を中断する手段が関数側に用意されてなかったりする
具体的には？

**デフォルトの名無しさん** · 2016/08/24(水) 22:11:21.77

いやそんなもん、中断する手立てが用意されている方が珍しいだろ

**デフォルトの名無しさん** · 2016/08/24(水) 22:31:11.60

>>586
で、具体的には出せないと言うことね

**デフォルトの名無しさん** · 2016/08/25(木) 11:39:37.19

元々はスレッドが軽量プロセスって呼ばれていたりしたんだがな（アドレス空間の切り替えが不要だからプロセスより切り替えが軽い）

まあそれはおいておいて
forkを使うと軽量プロセス？とやらの機能が実現できるらしい理屈がわからない
forkしたら別プロセスだぞ？
vforkとかなら実行直後は共有しているけど変更を加えた時点で分かれるし

まあどちらにしろGCじゃメモリーをはじめとする資源管理からは完全には解放されないって事だ

**デフォルトの名無しさん** · 2016/08/25(木) 11:59:23.81

メモリ空間がつながっていること自体はそれほど考慮してないんよ
単にWindowsはマルチプロセスがしにくい
forkあったらちょっとした処理を別プロセスで実行するの、便利じゃん
片づけはプロセスごと殺して終わりだし

**デフォルトの名無しさん** · 2016/08/25(木) 15:41:54.51

ほしいのはLinuxでいうclone(2)やね

**デフォルトの名無しさん** · 2016/09/03(土) 00:41:24.79

https://cedil.cesa.or.jp/cedil_sessions/view/1484
リアルタイムGCの実装が凄い

**デフォルトの名無しさん** · 2016/10/22(土) 08:52:04.68

GCもハードウェアに支援させれば全部解決するよ
リアルタイム処理含めてね

**デフォルトの名無しさん** · 2016/10/22(土) 10:51:46.42

再起動最強説

**デフォルトの名無しさん** · 2016/11/14(月) 22:33:26.01

固定領域として静的にグローバル変数化、バッファ化すればいいだろ、
それを汚い言うやつがいるが、

潜在ＢＵＧだらけでどうにもできないそれのほうが汚いわ。

**デフォルトの名無しさん** · 2016/11/14(月) 23:45:18.91

例えばChromeとかFirefoxとかが静的にメモリアロケートしてたらどうなるか

**デフォルトの名無しさん** · 2016/11/14(月) 23:59:22.37

そういう発想、嫌いじゃないよ
静的にできるものは、なるべく静的にすべし
俺もそう思う
妙なからくりじみたことにはもう興味が湧かなくなった
最初のころはGCのメカニズムが面白いと感じていたが、もうそういうの、無い

いかに静的にシンプルに書くか、こっちのがパズルみたいで面白い
すべての事は明確であるべきで、コードはそのようになっているべきだ、と
俺が特に嫌いなのは、何がどの順番に実行されるか、コードを見ただけで
よくわからない類のプログラムだ
コールバックも基本的に嫌いだ
なのでいつ実行されるか分からないマークスイープGCは好きではない
参照カウンタ方式のほうが根本的に安全であり、シンプルであると思う
というのも参照カウンタ方式のGCはバグの再現性があるから
唯一の問題は循環参照だが、これも弱い参照を使えば解決する
たったそれだけの工夫でマークスイープGCの複雑な仕組みがいらなくなるなら
おれはそちらのほうが良いと考える
開放するというただそれだけのことに、あれだけ巨大な仕組みが必要になるのはおかしい

**デフォルトの名無しさん** · 2016/11/15(火) 00:00:47.13

マークスイープ系GCはメモリ管理に関しては完璧かもしれないが
それ以外のリソースの面倒は一切見てくれない
そういったものはファイナライザで開放すればよいわけだが
要らなくなったらすぐさま開放してほしい時に困るので、例えばC#ではDisposeを用意している
しかしながら根本的に本当にDisposeを呼んで良いのかは誰にもわからない部分がある
もしかしたら他の誰かが使用中かもしれない、という場面もありうる
だから誰も使ってないことをプログラマが保証する格好になる
その意味ではfree()と大差ないわけで
usingという構文が用意されていて、ある程度自動で呼ばれるというだけである
本当に誰も使ってないことを保証するにはマークスイープを走らせなければわからない
しかしマークスイープはコストがかかるので、そんな都度都度気軽に走らせられない
その点、参照カウンタ方式は参照カウンタを見るだけで使われているかどうかわかるので
都度都度チェックできるし、要らなくなったらその場で即開放できるので
Disposeのような仕組みもいらず、解放処理をデストラクタに一本化できるし
スマポを使えばデストラクタ自体、書く必要すらないかもしれない
そして有り難いことに、デストラクタはメンバ変数やベースクラスに対しても
芋づる式に自動で呼ばれる
これはDisposeには無い機能だ
何故無いのか？答えは、勝手にDisposeして良いのかどうか、コンパイラは判断がつかないからだ
誰か他の人が使っているかもしれないわけで、勝手にDispose出来ない
Disposeして良いかどうかはプログラマが保証しなければならないので自動化できないのだ

**デフォルトの名無しさん** · 2016/11/15(火) 00:02:48.22

本当にC#で解放処理をまともに書こうと思うと
自身のクラスのメンバ変数にIDisposableを実装しているものがあるかどうかを調べ
もし、実装しているものがあれば、自身もIDisposableにし
Disposeメソッドを作り、その中で、先ほど調べたメンバのDisposeを呼び出さなければならない
これを手作業でやる
C#をやったことのある人なら知っている通り、マイクロソフトの示すIDisposableの実装例自体が
非常に煩雑であるわけだが、ともかく、もれがないように、手作業で頑張る
まず、IDisposableかどうか調べ忘れるだろうし、Disposeの呼び出し忘れもありうる
mallocしたらfreeしましょうと同レベルのことを強いられる
このように面倒なIDisposableであるが
IDisposableなオブジェクトをメンバに持つと、自身もIDisposableになるということは
IDisposableはどんどん伝染していくわけで、手動でDisposeしまくるコードを書き続ける羽目になる
このように、まじめに考えると、破たんした方法であることが分かる
根本の問題はDisposeが自動で呼ばれるコードをコンパイラが生成してくれないこであるが
確実にDisposeして良いかどうかを判断するためにはマークスイープを走らせる必要があるので
どうやっても自動化は困難であり、プログラマが開放してよいことを保証するという
ある種手作業なusingがせいぜいである
参照カウンタ方式であれば、ほぼノーコストで開放して良いかどうか分かるので
これらの問題は一切発生しない
解放処理はデストラクタ一本であるし、芋づる式に自動的に呼ばれるので
手動でコードを書かなければならないということもない
ランタイムもシンプルであり、バグった時も再現性が期待できる

**デフォルトの名無しさん** · 2016/11/15(火) 00:24:03.03

これがC++が未だにかたくなにマークスイープ系GCを搭載しない理由である
C++を書くプログラマはweak_ptrを適切に使えるものだという前提のもとに
マークスイープ系GCにまつわる数々の問題点を排除したのだ
マークスイープ系GCで有利なのは唯一循環参照だけであり
そこさえ気を付けることができれば
それ以外の部分に関しては参照カウンタのほうが優れている
C++は別に時代遅れなわけじゃなく、そういう選択をしたというだけ
今になって考えるとその選択は正しかったと思う

**デフォルトの名無しさん** · 2016/11/15(火) 04:04:15.16

メンバーにdisposeしなければならないような設計が良くない。そんなものはメソッド内のローカル変数に止めるべき。
それすらも理解できず(考え付かず)にただ一律なんにでも同じ考え方を押し込むのはただの愚行。
ありもしない、回避可能な杞憂をただ恐れるのは、勉強不足か進歩が止まっているだけ。
だから皮肉を込めて老害と呼ばれる

**デフォルトの名無しさん** · 2016/11/15(火) 04:09:46.64

日本語おかしかった。
メンバーにdisposeしなければならないような物を持たせるのが良くない
でした。

**デフォルトの名無しさん** · 2016/11/15(火) 05:19:19.06

>>594
参照カウンタよりも固定バッファを動的に確保ですね判ります

**デフォルトの名無しさん** · 2016/11/15(火) 05:20:35.14

>>595
firefoxは解放が遅いのでそれやってるのと実質同じ
realplayerとかもそうだったな

**デフォルトの名無しさん** · 2016/11/15(火) 08:18:37.29

>>600-601
よくないって言われてそうせざるを得ない場合はいくらでもあるしなぁ
例えば動的に出力先を切り替えられるログクラスみたいな奴をどう書けと言うんだろ？

**デフォルトの名無しさん** · 2016/11/15(火) 09:05:11.25

>>597
スマポとデストラクタの必要性は関係ないだろ…
deleteの必要がない、とか、デストラクトを考えなくて良いってことだと思うけど。

**デフォルトの名無しさん** · 2016/11/15(火) 10:48:15.69

スタック変数の 0 クリアすら嫌がる C/C++ が GC 搭載とか夢見すぎ

**デフォルトの名無しさん** · 2016/11/15(火) 10:53:43.30

struct test
{
　　std::shared_ptr<int> ptr;
　　test(){ ptr = new int; }
};

上のコードはデストラクタを書く必要があるのかないのか
スマポを使えばデストラクタを書かなくてよい場合もあり得るということ
スマポを使わないのであれば当然デストラクタでdeleteをしなければならないだろう
なので、「スマポ」と「デストラクタを書く必要性」は、関係がある

ちなみにC#のDisposeはただのメソッドであるので
このような芋づる式にメンバ変数のDisposeを呼び出してくれる機能はないし
マークスイープなので原理上不可能である
他で使用中でないことをプログラマが保証しないとにはDisposeは呼べないので
自動化できない

**デフォルトの名無しさん** · 2016/11/15(火) 11:05:47.46

>>606
ツボったw
効率至上が利点であり特徴だもんな

**デフォルトの名無しさん** · 2016/11/15(火) 12:45:52.53

>>607
それptr.reset()使うんじゃないの？

**デフォルトの名無しさん** · 2016/11/15(火) 13:34:38.18

グローバルが嫌われたのは
疑似マルチプロセスでメモリを共有していた時代の汚物だろ
今みたいなOSのメモリ管理ならアプリ単位グローバル常套

**デフォルトの名無しさん** · 2016/11/15(火) 23:45:20.82

C#/C++よりRustだろ
参照カウンタのオーバーヘッドすらない
Firefoxに期待

**デフォルトの名無しさん** · 2016/11/16(水) 04:04:29.47

>>604

http://ideone.com/9L3kQp

これじゃいかんのか？
おかしかったら教えて

**デフォルトの名無しさん** · 2016/11/16(水) 12:42:03.97

>>612
Write する度に WriteTypeA とかを生成/破棄するってこと？
ログとかならその方が望ましいケースもあるかもしれないけど、例えば性能上の問題でストリームは開きっぱなしにしたいとかもあるでしょ

**デフォルトの名無しさん** · 2016/11/16(水) 14:56:37.10

>>613
開きっぱなしにしたいスコープは？
スコープを一つのメソッドにして、同じようにすればいいじゃない

コードが必要なら夜にでも書くよ

**デフォルトの名無しさん** · 2016/11/16(水) 19:17:42.21

>>614
スコープを動的に変えたい場合を想定してるんだが
実行中にログファイルを変更できるアプリケーションとか見たことないの？

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

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