- 1 名前:デフォルトの名無しさん mailto:sageteoff [2015/11/18(水) 23:24:59.79 ID:BUQ68wTG.net]
- GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。
以下GCと記す プログラマをメモリ管理から開放する! といいつつ、メモリリーク問題の文献が大量にある。 これすなわち、メモリリーク問題が全然解決していないということ。 さらに、メモリ解放のタイミングの文献まで大量に生み出した。 これすなわち、新たなるメモリ管理に関する問題を生み出したということ。 malloc、freeじゃないが 結局のところ、メモリを管理するという技術は、今しばらくは、身につける・教える・学ぶべきではないだろうか? 使って、そのまま放置しても、基本的にはGCがなんとかしてくれている。 ランジョブからジョブ終了までさほどの時間を要さない。メモリも大して使わないならいいだろう。 しかし、規模が大きくなり常駐ジョブやメモリ大量使用のジョブになってくると、そんなメモリ管理の方法でやっていると、 上記「文献」を生み出されてしまう。 入門時は、メモリに無頓着でもいいだろう。それよりも、目的を達成することが先決だ。 しかし、慣れてきたら、やはりメモリの管理まで余裕を持って自分で行うべきだろう。 前スレ GCは失敗。メモリは自分で管理せよ! peace.2ch.net/test/read.cgi/tech/1412986420/
- 528 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 01:38:34.87 ID:ai61/62A.net]
- >>516
へーお前はヒープを使わないのか 漢だな
- 529 名前:デフォルトの名無しさん [2016/04/24(日) 08:38:51.73 ID:65va2BTL.net]
- メモリー512バイトでどうやってヒープを使えと。
- 530 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 09:31:32.99 ID:HSA/nLEW.net]
- ネイティブコードが必要な場面で中途半端に GC に頼るのが問題なのかもしれないが、もうネイティブコードが必要な戦場は限られた一部だけになってて、主戦場では GC は大前提の技術なんだから必要ないとか言われましてもですわ。
- 531 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 10:14:15.47 ID:W23a3TIA.net]
- ページがスカスカになっても大丈夫
1ページ4KBとかだからね、十分小さい 32x32-32bitビットマップより小さい 最近のゲームで使われるような大きなサイズのテクスチャなど でかいサイズを確保する場合はどうせ新しいページが割り当てられるし 小さなサイズを確保する場合は、スカスカになったページから空いているところを探して割り当てられるので 問題ない
- 532 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 10:14:59.78 ID:TFb7efu7.net]
- androidしか知りませんみたいな事言われてもな
- 533 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 10:27:10.54 ID:W23a3TIA.net]
- 物理アドレスはページサイズで切り売りされるので
元から連続しているアドレスは必要ではなく フラグメンテーションは問題にならない 連続したアドレスが必要になるのは論理アドレスのほうであり 32bitプロセスでは4GBしか空間がないから問題になることがある 64bitプロセスであれば現状問題にならない
- 534 名前:デフォルトの名無しさん [2016/04/24(日) 10:37:41.02 ID:65va2BTL.net]
- 実はQtでデーモン作って動かしてるのだが、もう半年以上動き続けてる。
まさかこんなに問題が起きないとは。 案ずるより産むがやすしですぞ皆の衆。
- 535 名前:デフォルトの名無しさん [2016/04/24(日) 10:58:37.83 ID:65va2BTL.net]
- Qtで作ったのは一日ででっち上げる為だったのだが、意外なことに堅牢に動き続けてる。
- 536 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 12:08:49.17 ID:HSA/nLEW.net]
- Qt でデーモン?
GUI が必要なデーモン?
- 537 名前:デフォルトの名無しさん [2016/04/24(日) 12:13:06.27 ID:ynYywbEh.net]
- >>525
デーモンは通常フォアグラウンドじゃないのでUIを持ちませんぜ旦那。
- 538 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 12:25:33.24 ID:HSA/nLEW.net]
- ならば何に何故どのように Qt を使うのだ?
- 539 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 12:45:58.38 ID:TFb7efu7.net]
- >>526
だからQtでデーモン?(クエスチョン)…なんじゃね? 加えてQtってGC関係あるのか? たしかC++のライブラリーだよね?
- 540 名前:デフォルトの名無しさん [2016/04/24(日) 13:02:46.55 ID:ynYywbEh.net]
- 等と意味不明な供述をしており。
- 541 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 14:52:01.10 ID:fu8W/E1c.net]
- >>525
Qt 使ってるからと言って QtGui 使ってるとは限らんけどね >>528 Qt 本体は C++ で書かれてるけ ど Java, Ruby, Python, Perl, C# 等からも利用できるよ
- 542 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 14:52:56.88 ID:UKiBgwvV.net]
- daemonじゃなくてdemonなんじゃない?
デスクトップマスコット的な
- 543 名前:デフォルトの名無しさん [2016/04/24(日) 14:59:36.53 ID:ynYywbEh.net]
- 俺が作ったのはウェブソケットによってサービスを提供するプログラムだ。
エンジンエックスをリバースプロキシとした。 このプログラムは常時数千の接続から大量のリクエストを受け付ける。 接続してくるクライアントは専用に作られQtで書かれている。 大量のリクエストはそれぞれ複数のデータベース検索を引き起こす。 こう書くと結構負荷が高そうなのだが、さすがC++、ほとんど塵程度の負荷しかなく、 当然のことながらリプライに遅延もない。 そこで案ずるよりも生むが易しというわけ。 Qtは出自からしてGUIのためのライブラリではあるのだが、GUIが無いと使えないというわけでもない。 むしろボリュームからすれば、GUI以外の方がより大きい。 そして、半年動きっぱなしで大丈夫ことからして、実は断片化は気にしなくても 良さそうだ。
- 544 名前:デフォルトの名無しさん [2016/04/24(日) 15:05:02.69 ID:ynYywbEh.net]
- ちなみにQt使ってなかったら一日でサービスを書き上げることは不可能だっただろう。
Qtは、その他のGUIライブラリ同様バグが多いのだが、GUIを抜いてみるとどうだろう、 意外なほどに堅牢なのだ。 何しろもう半年動きっぱなし。 俺はこの経験から一つの予測を立てた。 これからのサービスは、C++で書かれるようになる可能性がある。 何しろ圧倒的に速い。 一つのリクエストに対するレスポンスが速いため、平均負荷率が圧倒的に下がるのだ。 この事実に世の中が気づくにはそう時間がかからないはず。 そしてsystemdがこの動きを促進するはず。 ちなみにWindowsで書いてLinuxで動かしてます。
- 545 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 15:05:44.58 ID:ai61/62A.net]
- 一例をもって一般化はできないだろ
- 546 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 15:05:53.54 ID:TFb7efu7.net]
- >>530
色々な言語から使えるのか そういう場合Qtが使うメモリーなんかはどういう扱いなんだろうね GC適用外な気がするけど知らないからこれでやめとくわ
- 547 名前:デフォルトの名無しさん [2016/04/24(日) 15:08:01.90 ID:ynYywbEh.net]
- Windowsで書いてLinuxで動かすことに、systemdは大いに貢献した。
従来のデーモンの作り方では、いろいろ煩雑なことがありすぎ、時間の制限から難しかっただろう。 Qt+systemd、この直観的な選択は大成功であった。
- 548 名前:デフォルトの名無しさん [2016/04/24(日) 15:11:43.89 ID:ynYywbEh.net]
- Qtのバグの多くは、複数の環境に対応するため、その差異によって引き起こされているという結論を得た。
systemd万歳!
- 549 名前:デフォルトの名無しさん [2016/04/24(日) 15:16:24.95 ID:ynYywbEh.net]
- 更にもう一つヒントがある。
複数のクライアントから多様なリクエストがあるとはいえ、一つのプログラムが擁する データ構造などたかが知れているのだ。 クライアントAのリクエストにこたえるため使用された記憶空間は、解放されたのち クライアントBのためにそのまま使われる可能性があるのだ。 そういったわけで断片化は気にする必要が無い。 若者よ、案ずるより産むが易しですぞ。
- 550 名前:デフォルトの名無しさん [2016/04/24(日) 15:28:56.74 ID:u6qUQj/U.net]
- ねえ訳分かんないんだけど
本人以外で理解してる人要るの?
- 551 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 15:55:24.75 ID:fu8W/E1c.net]
- むやみに連投してる奴はたいていスルーでok
- 552 名前:デフォルトの名無しさん [2016/04/24(日) 20:02:15.39 ID:ynYywbEh.net]
- むしろ、わからないのに何故、一生懸命主張していたのかと。
- 553 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 20:22:44.80 ID:fcfJojCV.net]
- 誰と戦っているんだろう…
- 554 名前:デフォルトの名無しさん mailto:sage [2016/04/24(日) 22:39:17.85 ID:WrdDgWl7.net]
- マークスイープでメモリリークってどうやって起きるんだ?
初心者だから優しく説明してほしい
- 555 名前:デフォルトの名無しさん [2016/04/25(月) 01:16:56.77 ID:/Pmm49fe.net]
- 狭義の意味では起きない
もし君が気付かない間にオブジェクトへの参照を保持していたらどんなGCだろうが解放されない それをリークというならリークする
- 556 名前:デフォルトの名無しさん mailto:sage [2016/04/25(月) 13:44:57.25 ID:HSarKqaj.net]
- 言い換えればダングリングポインタが発生しない
それだけ
- 557 名前:デフォルトの名無しさん mailto:sage [2016/04/25(月) 14:51:13.10 ID:0xpbBk2N.net]
- マーク&スイープでもポインタの型情報を記録してないとリークしまくる
無関係な数値をアドレス参照と勘違いしてマーク→未開放 某言語ではこのために巨大なメモリブロックが
- 558 名前:開放されない []
- [ここ壊れてます]
- 559 名前:デフォルトの名無しさん mailto:sage [2016/04/25(月) 20:35:07.72 ID:4DDlKiNG.net]
- >>543
どこからマークを始めるかが問題
- 560 名前:デフォルトの名無しさん mailto:sage [2016/04/29(金) 18:58:56.34 ID:I1ppYkAy.net]
- >>10
C#はGCの掃除処理を任意で呼び出せるだけだろ C++/CLIなら自分でdelete呼べば即座に消え去るが もちろんC++と同じくデストラクタも確実に起動する。
- 561 名前:デフォルトの名無しさん mailto:sage [2016/04/29(金) 22:46:31.85 ID:wZxrhoKH.net]
- C++/CLIはデストラクタが呼ばれるだけで、managedメモリの解放がGC任せなのは変わらんよ。
- 562 名前:デフォルトの名無しさん [2016/05/01(日) 07:57:30.30 ID:tKi6j9CT.net]
- 匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、
BitTorrentがオープンソースで開発されています 言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか? Covenantの作者(Lyrise)がそういう人と話したいそうなので、よろしければツイートお願いします https://twitter.com/Lyrise_al ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーw The Covenant Project 概要 Covenantは、純粋P2Pのファイル共有ソフトです 目的 インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します 特徴 Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW) 接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です DHTにはKademlia + コネクションプールを使用します UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります) 検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません w
- 563 名前:デフォルトの名無しさん mailto:sage [2016/05/01(日) 09:11:45.10 ID:qHyjCjkk.net]
- 無視リストに追加と
- 564 名前:デフォルトの名無しさん [2016/05/02(月) 21:54:41.51 ID:KYdaomRZ.net]
- GCCは失敗、Clangを使え。
- 565 名前:デフォルトの名無しさん mailto:sage [2016/05/02(月) 22:21:36.97 ID:btgv3pKW.net]
- うるせーバーカ
- 566 名前:デフォルトの名無しさん [2016/05/04(水) 17:42:43.75 ID:M8+arjAJ.net]
- gccは失敗。
- 567 名前:デフォルトの名無しさん [2016/05/27(金) 12:06:01.84 ID:FwT+WNvC.net]
- 良スレ発見した。Windowsは32bitで十分だな。32bitでもPAEで4GB超の
メモリ認識するし、仮想メモリは4GBのままだが、AWEを使うことにより バンク切り替え的にメモリウインドウを切り替えられる
- 568 名前:デフォルトの名無しさん mailto:sage [2016/05/27(金) 19:30:30.19 ID:hSijlNU2.net]
- >>555
アプリはよくてもカーネルはつらい
- 569 名前:デフォルトの名無しさん [2016/05/28(土) 04:39:26.17 ID:rTGB9SNh.net]
- メモリーは俺が確保してやる、任せろ。
- 570 名前:デフォルトの名無しさん mailto:sage [2016/05/29(日) 07:51:44.19 ID:Ai+IvVh7.net]
- おう、この手は絶対、絶対に、死んでも離さねぇ!!
- 571 名前:デフォルトの名無しさん mailto:sage [2016/05/29(日) 11:50:15.87 ID:9WWbP5OA.net]
- OSに載った気持ちでいなさい
- 572 名前:デフォルトの名無しさん mailto:sage [2016/05/31(火) 22:56:21.68 ID:mtPUDASJ.net]
- >>1みたいなやつは
研究室にヒキって、社会に出たことないんやろ おまえ、本気の糞コードで書かれたペチプ〜とか見たらチビるで あんなんに加えてメモリ管理なんてやらせたら それこそHELLO END OF THE WORLD この世の終わりですわ
- 573 名前:デフォルトの名無しさん mailto:sage [2016/06/07(火) 12:20:18.65 ID:4vppD7oq.net]
- >>558
死んだら離せw
- 574 名前:デフォルトの名無しさん mailto:sage [2016/06/12(日) 09:40:01.67 ID:mfUrI2Z0.net]
- 死後硬直ですね
- 575 名前:デフォルトの名無しさん [2016/06/18(土) 23:15:40.44 ID:03AgrRUX.net]
- 指摘してるレスがなかったので言っとくが
循環参照は参照カウント方式+Cycle Collectorでも回収できるから GCは必須じゃないぞ 興味があるならBacon Cycle Collectorで調べてみろ
- 576 名前:デフォルトの名無しさん [2016/06/18(土) 23:22:46.70 ID:/B2fY0/K.net]
- 学生の頃は循環参照できないことに困ってたけど、今となっては何時
循環参照が必要になるかさえ思い出せんな。
- 577 名前:デフォルトの名無しさん mailto:sage [2016/06/19(日) 21:38:00.28 ID:evh9vaek.net]
- 双方向リスト構造
- 578 名前:デフォルトの名無しさん mailto:sage [2016/06/19(日) 22:17:16.01 ID:ao4WLgfX.net]
- >>563
>Cycle Collector いわゆるmark&sweep式とどう違うの?
- 579 名前:デフォルトの名無しさん [2016/06/20(月) 01:16:50.71 ID:30YoNw6z.net]
- (コンパクションしてくれるんだろうか)
- 580 名前:デフォルトの名無しさん mailto:sage [2016/06/22(水) 08:52:46.04 ID:I9Ep4uZo.net]
- vmが諸悪の根源な気がしてきた
- 581 名前:デフォルトの名無しさん mailto:sage [2016/07/06(水) 07:12:12.60 ID:aYInvTWe.net]
- >>568
まずガベージだらけの頭の中を整理すべき
- 582 名前:デフォルトの名無しさん mailto:sage [2016/07/16(土) 10:10:08.78 ID:+8wH/95N.net]
- >>565
別に 単方向リストでもなるだろJK ていうかリストの要素をshared_ptrにするのは現代でも有効 リストのリンクヘッダ自体の寿命は要素が明示的にdeleteされるかリスト全体が廃棄されるまでなので リンクヘッダも管理したければリスト固有のストレージ丸ごとな単位でshared_ptrにしたら良い、 希ガス
- 583 名前:デフォルトの名無しさん mailto:sage [2016/07/16(土) 10:13:41.67 ID:+8wH/95N.net]
- △: リストの要素
○: リストの要素が保持するデータ つか開放タイミングをshared_ptrに任せておk、などという発想のは管理しているうちに含めれないがな…
- 584 名前:デフォルトの名無しさん mailto:sage [2016/07/16(土) 10:38:52.53 ID:6AR6MH2z.net]
- 一般のグラフじゃなくてリスト構造の話だろ?
双方向リストはheadとtailへの参照があるが、単方向リストで循環参照は生じようがないが。
- 585 名前:デフォルトの名無しさん mailto:sage [2016/07/16(土) 11:51:50.13 ID:+8wH/95N.net]
- >>572
すまんの>>570の単方向リストは正確には循環リストもしくは環状リストと呼んだ方が良いかも試練、 だが、循環リストもしくは環状リストも単方向リストの実装方式の一つではある(初期の『プログラミング言語C++』か何かのslist等 のじゃ…!
- 586 名前:デフォルトの名無しさん mailto:sage [2016/08/22(月) 17:06:41.08 ID:oW9zLe2W.net]
- 循環してるかは後付けでオブジェクトをマークすれば判るんだし
扱うデータ構造から可能性の有無は予測できるし循環自体は大した問題じゃないよ あ、これリークするなと思ったら対策すればいいだけ 問題は他人様のブラックボックスなライブラリを使う場合
- 587 名前:デフォルトの名無しさん mailto:sage [2016/08/22(月) 19:24:37.36 ID:csr3LedD.net]
- ?
今の議論はプログラマーが何も考えないアホでもGC(言語)使ってれば問題無いのか そうでなければ結局なんらかの管理が必要でちゃんとする事しないとリークするから本質的には管理から開放されないよねって話だと思うが
- 588 名前:デフォルトの名無しさん mailto:sage [2016/08/22(月) 19:33:58.37 ID:01M+MFvA.net]
- いまどきの子はブラウザアプリしか作れないから
ブラウザ再起動とかページ遷移で解決でしょうな
- 589 名前:デフォルトの名無しさん mailto:sage [2016/08/23(火) 19:56:22.47 ID:cEt4cHHx.net]
- 現在のGCが不完全なだけであって、
メモリは人が管理すべきでないという考え自体は正しいよ。
- 590 名前:デフォルトの名無しさん [2016/08/23(火) 20:17:10.56 ID:xIKUFX4H.net]
- 潤沢なメモリを用意してGCしない戦略
起動時間に限ってGCしなくても問題ない範囲であればGCしない戦略 結局こういうのが勝つ
- 591 名前:デフォルトの名無しさん mailto:sage [2016/08/23(火) 20:29:14.30 ID:uPhg+qti.net]
- プロセスを細かく分けて寿命を短くすればそんなの考えなくて済む
- 592 名前:デフォルトの名無しさん mailto:sage [2016/08/24(水) 13:32:09.69 ID:2RMcAgaj.net]
- 本当の意味での軽量プロセスをOSがサポートしてくれたら良いんだけどね
メモリプールみたいなもんなんだけど、OSのリソースも紐づいてて メモリプール解放時にOSのリソースもちゃんと解放されるようなもの マルチプロセスは非常に強力で良いんだけど メモリ空間が別になるから色々面倒だしパフォーマンスも出にくい 世の中には呼び出したらしばらく処理が返ってこない時間のかかる関数があるけど とうぜんUIが固まったら困るから別スレッドで実行するわけだけど 処理中にユーザーがキャンセルボタンを押したとき 処理を中断する手段が関数側に用意されてなかったりすると、困る 外からスレッドごと殺しても、リソースリークの問題が出る 真っ先に困るのが同期オブジェクト 同期オブジェクトを握った状態で死なれると、それ以降デッドロックを引き起こす それ以外にも、プログラムの整合性が壊れているかもしれないので、以降正しく動く保証がない だから別プロセスで実行して、キャンセルされたときはプロセスごと殺すしか方法が無い しかし別プロセスにするとメモリ空間が繋がってないので面倒 だからその中間がほしい
- 593 名前:デフォルトの名無しさん [2016/08/24(水) 16:03:33.76 ID:Ku8YOB4B.net]
- erlang最強
- 594 名前:デフォルトの名無しさん [2016/08/24(水) 19:53:51.27 ID:B7v3wZLf.net]
- 軽量プロセスより重量スレッドの方が実現できそう。
- 595 名前:デフォルトの名無しさん mailto:sage [2016/08/24(水) 20:02:24.36 ID:971rg3P3.net]
- いつ無くなってしまうかわからんようなメモリのアクセスが簡単になってもほとんど使いみちないだろ。
安全性重視なら別プロセスにして、必要なデータだけ共有メモリで受け渡してのが妥当なところだろう。
- 596 名前:デフォルトの名無しさん mailto:sage [2016/08/24(水) 20:18:52.71 ID:2RMcAgaj.net]
- 結論から言うと、Windowsにforkが無いのが面倒すぎるってことなんだけどね
- 597 名前:デフォルトの名無しさん mailto:sage [2016/08/24(水) 20:32:21.12 ID:N/sC1Ga3.net]
- >>580
> 処理を中断する手段が関数側に用意されてなかったりする 具体的には?
- 598 名前:デフォルトの名無しさん mailto:sage [2016/08/24(水) 22:11:21.77 ID:2RMcAgaj.net]
- いやそんなもん、中断する手立てが用意されている方が珍しいだろ
- 599 名前:デフォルトの名無しさん mailto:sage [2016/08/24(水) 22:31:11.60 ID:N/sC1Ga3.net]
- >>586
で、具体的には出せないと言うことね
- 600 名前:デフォルトの名無しさん mailto:sage [2016/08/25(木) 11:39:37.19 ID:rs2QvvZe.net]
- 元々はスレッドが軽量プロセスって呼ばれていたりしたんだがな(アドレス空間の切り替えが不要だからプロセスより切り替えが軽い)
まあそれはおいておいて forkを使うと軽量プロセス?とやらの機能が実現できるらしい理屈がわからない forkしたら別プロセスだぞ? vforkとかなら実行直後は共有しているけど変更を加えた時点で分かれるし まあどちらにしろGCじゃメモリーをはじめとする資源管理からは完全には解放されないって事だ
- 601 名前:デフォルトの名無しさん mailto:sage [2016/08/25(木) 11:59:23.81 ID:8gaIkILP.net]
- メモリ空間がつながっていること自体はそれほど考慮してないんよ
単にWindowsはマルチプロセスがしにくい forkあったらちょっとした処理を別プロセスで実行するの、便利じゃん 片づけはプロセスごと殺して終わりだし
- 602 名前:デフォルトの名無しさん mailto:sage [2016/08/25(木) 15:41:54.51 ID:8f3yfXIl.net]
- ほしいのはLinuxでいうclone(2)やね
- 603 名前:デフォルトの名無しさん [2016/09/03(土) 00:41:24.79 ID:XSHFkVCg.net]
- https://cedil.cesa.or.jp/cedil_sessions/view/1484
リアルタイムGCの実装が凄い
- 604 名前:デフォルトの名無しさん mailto:sage [2016/10/22(土) 08:52:04.68 ID:v44cYKg6.net]
- GCもハードウェアに支援させれば全部解決するよ
リアルタイム処理含めてね
- 605 名前:デフォルトの名無しさん mailto:sage [2016/10/22(土) 10:51:46.42 ID:O48rD9qT.net]
- 再起動最強説
- 606 名前:デフォルトの名無しさん [2016/11/14(月) 22:33:26.01 ID:A2iFoZHP.net]
- 固定領域として静的にグローバル変数化、バッファ
- 607 名前:サすればいいだろ、
それを汚い言うやつがいるが、 潜在BUGだらけでどうにもできないそれのほうが汚いわ。 [] - [ここ壊れてます]
- 608 名前:デフォルトの名無しさん mailto:sage [2016/11/14(月) 23:45:18.91 ID:JD+cxKWX.net]
- 例えばChromeとかFirefoxとかが静的にメモリアロケートしてたらどうなるか
- 609 名前:デフォルトの名無しさん mailto:sage [2016/11/14(月) 23:59:22.37 ID:f4osfHdm.net]
- そういう発想、嫌いじゃないよ
静的にできるものは、なるべく静的にすべし 俺もそう思う 妙なからくりじみたことにはもう興味が湧かなくなった 最初のころはGCのメカニズムが面白いと感じていたが、もうそういうの、無い いかに静的にシンプルに書くか、こっちのがパズルみたいで面白い すべての事は明確であるべきで、コードはそのようになっているべきだ、と 俺が特に嫌いなのは、何がどの順番に実行されるか、コードを見ただけで よくわからない類のプログラムだ コールバックも基本的に嫌いだ なのでいつ実行されるか分からないマークスイープGCは好きではない 参照カウンタ方式のほうが根本的に安全であり、シンプルであると思う というのも参照カウンタ方式のGCはバグの再現性があるから 唯一の問題は循環参照だが、これも弱い参照を使えば解決する たったそれだけの工夫でマークスイープGCの複雑な仕組みがいらなくなるなら おれはそちらのほうが良いと考える 開放するというただそれだけのことに、あれだけ巨大な仕組みが必要になるのはおかしい
- 610 名前:デフォルトの名無しさん mailto:sage [2016/11/15(火) 00:00:47.13 ID:PldPJ2O3.net]
- マークスイープ系GCはメモリ管理に関しては完璧かもしれないが
それ以外のリソースの面倒は一切見てくれない そういったものはファイナライザで開放すればよいわけだが 要らなくなったらすぐさま開放してほしい時に困るので、例えばC#ではDisposeを用意している しかしながら根本的に本当にDisposeを呼んで良いのかは誰にもわからない部分がある もしかしたら他の誰かが使用中かもしれない、という場面もありうる だから誰も使ってないことをプログラマが保証する格好になる その意味ではfree()と大差ないわけで usingという構文が用意されていて、ある程度自動で呼ばれるというだけである 本当に誰も使ってないことを保証するにはマークスイープを走らせなければわからない しかしマークスイープはコストがかかるので、そんな都度都度気軽に走らせられない その点、参照カウンタ方式は参照カウンタを見るだけで使われているかどうかわかるので 都度都度チェックできるし、要らなくなったらその場で即開放できるので Disposeのような仕組みもいらず、解放処理をデストラクタに一本化できるし スマポを使えばデストラクタ自体、書く必要すらないかもしれない そして有り難いことに、デストラクタはメンバ変数やベースクラスに対しても 芋づる式に自動で呼ばれる これはDisposeには無い機能だ 何故無いのか?答えは、勝手にDisposeして良いのかどうか、コンパイラは判断がつかないからだ 誰か他の人が使っているかもしれないわけで、勝手にDispose出来ない Disposeして良いかどうかはプログラマが保証しなければならないので自動化できないのだ
- 611 名前:デフォルトの名無しさん mailto:sage [2016/11/15(火) 00:02:48.22 ID:PldPJ2O3.net]
- 本当にC#で解放処理をまともに書こうと思うと
自身のクラスのメンバ変数にIDisposableを実装しているものがあるかどうかを調べ もし、実装しているものがあれば、自身もIDisposableにし Disposeメソッドを作り、その中で、先ほど調べたメンバのDisposeを呼び出さなければならない これを手作業でやる C#をやったことのある人なら知っている通り、マイクロソフトの示すIDisposableの実装例自体が 非常に煩雑であるわけだが、ともかく、もれがないように、手作業で頑張る まず、IDisposableかどうか調べ忘れるだろうし、Disposeの呼び出し忘れもありうる mallocしたらfreeしましょうと同レベルのことを強いられる このように面倒なIDisposableであるが IDisposableなオブジェクトをメンバに持つと、自身もIDisposableになるということは IDisposableはどんどん伝染していくわけで、手動でDisposeしまくるコードを書き続ける羽目になる このように、まじめに考えると、破たんした方法であることが分かる 根本の問題はDisposeが自動で呼ばれるコードをコンパイラが生成してくれないこであるが 確実にDisposeして良いかどうかを判断するためにはマークスイープを走らせる必要があるので どうやっても自動化は困難であり、プログラマが開放してよいことを保証するという ある種手作業なusingがせいぜいである 参照カウンタ方式であれば、ほぼノーコストで開放して良いかどうか分かるので これらの問題は一切発生しない 解放処理はデストラクタ一本であるし、芋づる式に自動的に呼ばれるので 手動でコードを書かなければならないということもない ランタイムもシンプルであり、バグった時も再現性が期待できる
- 612 名前:デフォルトの名無しさん mailto:sage [2016/11/15(火) 00:24:03.03 ID:PldPJ2O3.net]
- これがC++が未だにかたくなにマークスイープ系GCを搭載しない理由である
C++を書くプログラマはweak_ptrを適切に使えるものだという前提のもとに マークスイープ系GCにまつわる数々の問題点を排除したのだ マークスイープ系GCで有利なのは唯一循環参照だけであり そこさえ気を付けることができれば それ以外の部分に関しては参照カウンタのほうが優れている C++は別に時代遅れなわけじゃなく、そういう選択をしたというだけ 今になって考えるとその選択は正しかったと思う
- 613 名前:デフォルトの名無しさん mailto:sage [2016/11/15(火) 04:04:15.16 ID:9A/eUvIY.net]
- メンバーにdisposeしなければならないような設計が良くない。そんなものはメソッド内のローカル変数に止めるべき。
それすらも理解できず(考え付かず)にただ一律なんにでも同じ考え方を押し込むのはただの愚行。 ありもしない、回避可能な杞憂をただ恐れるのは、勉強不足か進歩が止まっているだけ。 だから皮肉を込めて老害と呼ばれる
- 614 名前:デフォルトの名無しさん mailto:sage [2016/11/15(火) 04:09:46.64 ID:9A/eUvIY.net]
- 日本語おかしかった。
メンバーにdisposeしなければならないような物を持たせるのが良くない でした。
- 615 名前:デフォルトの名無しさん mailto:sage [2016/11/15(火) 05:19:19.06 ID:ulUg8AFG.net]
- >>594
参照カウンタよりも固定バッファを動的に確保ですね判ります
- 616 名前:デフォルトの名無しさん mailto:sage [2016/11/15(火) 05:20:35.14 ID:ulUg8AFG.net]
- >>595
firefoxは解放が遅いのでそれやってるのと実質同じ realplayerとかもそうだったな
- 617 名前:デフォルトの名無しさん mailto:sage [2016/11/15(火) 08:18:37.29 ID:wcWx6QZb.net]
- >>600-601
よくないって言われてそうせざるを得ない場合はいくらでもあるしなぁ 例えば動的に出力先を切り替えられるログクラスみたいな奴をどう書けと言うんだろ?
- 618 名前:デフォルトの名無しさん [2016/11/15(火) 09:05:11.25 ID:P8K+NdWV.net]
- >>597
スマポとデストラクタの必要性は関係ないだろ… deleteの必要がない、とか、デストラクトを考えなくて良いってことだと思うけど。
- 619 名前:デフォルトの名無しさん mailto:sage [2016/11/15(火) 10:48:15.69 ID:4QSE1fRA.net]
- スタック変数の 0 クリアすら嫌がる C/C++ が GC 搭載とか夢見すぎ
- 620 名前:デフォルトの名無しさん mailto:sage [2016/11/15(火) 10:53:43.30 ID:PldPJ2O3.net]
- struct test
{ std::shared_ptr<int> ptr; test(){ ptr = new int; } }; 上のコードはデストラクタを書く必要があるのかないのか スマポを使えばデストラクタを書かなくてよい場合もあり得るということ スマポを使わないのであれば当然デストラクタでdeleteをしなければならないだろう なので、「スマポ」と「デストラクタを書く必要性」は、関係がある ちなみにC#のDisposeはただのメソッドであるので このような芋づる式にメンバ変数のDisposeを呼び出してくれる機能はないし マークスイープなので原理上不可能である 他で使用中でないことをプログラマが保証しないとにはDisposeは呼べないので 自動化できない
- 621 名前:デフォルトの名無しさん mailto:sage [2016/11/15(火) 11:05:47.46 ID:TNYjuRyh.net]
- >>606
ツボったw 効率至上が利点であり特徴だもんな
- 622 名前:デフォルトの名無しさん mailto:sage [2016/11/15(火) 12:45:52.53 ID:LZ5unIkv.net]
- >>607
それptr.reset()使うんじゃないの?
- 623 名前:デフォルトの名無しさん mailto:sage [2016/11/15(火) 13:34:38.18 ID:bbRnuBLg.net]
- グローバルが嫌われたのは
疑似マルチプロセスでメモリを共有していた時代の汚物だろ 今みたいなOSのメモリ管理ならアプリ単位グローバル常套
- 624 名前:デフォルトの名無しさん mailto:sage [2016/11/15(火) 23:45:20.82 ID:nDIaGem/.net]
- C#/C++よりRustだろ
参照カウンタのオーバーヘッドすらない Firefoxに期待
- 625 名前:デフォルトの名無しさん mailto:sage [2016/11/16(水) 04:04:29.47 ID:EhKul/vA.net]
- >>604
ideone.com/9L3kQp これじゃいかんのか? おかしかったら教えて
- 626 名前:デフォルトの名無しさん mailto:sage [2016/11/16(水) 12:42:03.97 ID:KQ3Yixih.net]
- >>612
Write する度に WriteTypeA とかを生成/破棄するってこと? ログとかならその方が望ましいケースもあるかもしれないけど、例えば性能上の問題でストリームは開きっぱなしにしたいとかもあるでしょ
- 627 名前:デフォルトの名無しさん mailto:sage [2016/11/16(水) 14:56:37.10 ID:a2T+Z3SD.net]
- >>613
開きっぱなしにしたいスコープは? スコープを一つのメソッドにして、同じようにすればいいじゃない コードが必要なら夜にでも書くよ
- 628 名前:デフォルトの名無しさん mailto:sage [2016/11/16(水) 19:17:42.21 ID:KQ3Yixih.net]
- >>614
スコープを動的に変えたい場合を想定してるんだが 実行中にログファイルを変更できるアプリケーションとか見たことないの?
|

|