板検索:
GCは失敗。メモリは自分で管理せよ! その2 (638)
まとめビュー
1
デフォルトの名無しさん[sageteoff]   投稿日:2015/11/18 23:24:59  ID:BUQ68wTG.net
GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。
以下GCと記す

プログラマをメモリ管理から開放する!
といいつつ、メモリリーク問題の文献が大量にある。
これすなわち、メモリリーク問題が全然解決していないということ。
さらに、メモリ解放のタイミングの文献まで大量に生み出した。
これすなわち、新たなるメモリ管理に関する問題を生み出したということ。

malloc、freeじゃないが
結局のところ、メモリを管理するという技術は、今しばらくは、身につける・教える・学ぶべきではないだろうか?
使って、そのまま放置しても、基本的にはGCがなんとかしてくれている。
ランジョブからジョブ終了までさほどの時間を要さない。メモリも大して使わないならいいだろう。
しかし、規模が大きくなり常駐ジョブやメモリ大量使用のジョブになってくると、そんなメモリ管理の方法でやっていると、
上記「文献」を生み出されてしまう。

入門時は、メモリに無頓着でもいいだろう。それよりも、目的を達成することが先決だ。
しかし、慣れてきたら、やはりメモリの管理まで余裕を持って自分で行うべきだろう。

前スレ
GCは失敗。メモリは自分で管理せよ!
コメント2件


2
デフォルトの名無しさん[sage]   投稿日:2015/11/19 00:01:54  ID:6rd98MPK.net
なるべくスコープを狭くして長時間存在するオブジェクトを無くす
以上

3
デフォルトの名無しさん[sage]   投稿日:2015/11/19 00:14:59  ID:d0YkbYhs.net
仮にmalloc/free型を長時間動かしてたらフラグメントが酷いことになるぞ
そういう問題もコピーGCなら一気に解消できるしGCの方が耐久力があるよね
コメント1件

4
デフォルトの名無しさん[]   投稿日:2015/11/19 01:28:02  ID:6x5+bHoL.net
GCの無い時代のプログラムでフラグメントが問題になった例をあげてみろよゴミッカスw

5
デフォルトの名無しさん[sage]   投稿日:2015/11/19 02:10:36  ID:C+wDd3AI.net
>3
それGCのない言語の問題じゃなくてC/C++の問題だろ
コンパクションとGCはあくまで別だし

6
デフォルトの名無しさん[]   投稿日:2015/11/19 08:58:13  ID:JIJtk7D/.net
ブラッド・コックスとトム・ラブがObjective-Cを作り「この言語はCのメモリ安全性とSmalltalkの高速性を合わせたものだ」と宣言する。
現代の歴史家は2人が失読症ではないかと疑っている。
https://twitter.com/okdshin/status/666903312151613440

7
デフォルトの名無しさん[sage]   投稿日:2015/11/19 23:17:01  ID:SYMznuBH.net(2)
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
デフォルトの名無しさん[sage]   投稿日:2015/11/19 23:18:18  ID:SYMznuBH.net(2)
525 :名無し~3.EXE:2015/11/19(木) 22:13:05.49 ID:CEKgHuEl
展開されない時
リロードで展開される場合もあるが
リロードで展開ない場合もある

9
デフォルトの名無しさん[sage]   投稿日:2015/11/20 09:27:53  ID:em+ldceb.net
メモリ管理は自分でやった方が漏れが出るでしょ
規模がでかくなればなるほどリスクが大きくなる
コメント1件

10
デフォルトの名無しさん[]   投稿日:2015/11/20 15:32:07  ID:hg0nWx/i.net
C#の基本は自動だけど部分的に手動にできるハイブリッドがいいと思うよ
確保量の大きい画像なんかを扱っているとどうしても手動で解放したいタイミングもあるし
コメント2件

11
uy ◆Qawu9.2l1E [sage]   投稿日:2015/11/20 20:28:57  ID:QlSu2hgW.net
まともな言語ならオプションくらいついてる

12
デフォルトの名無しさん[sage]   投稿日:2015/11/20 22:40:56  ID:h5Le2W6O.net
>10
それが理想的だけど、C#ってそんなことできたっけ?
コメント1件


13
デフォルトの名無しさん[sage]   投稿日:2015/11/21 09:07:54  ID:+qGvO8oq.net
>12
出来るよ。
ポインタも使える

14
デフォルトの名無しさん[sage]   投稿日:2015/11/21 10:29:39  ID:7nxNhgSu.net(2)
調べてみたけどよくわからんな。
もしかしてアンマネージなメモリを確保してデータ領域に使う話?

15
デフォルトの名無しさん[]   投稿日:2015/11/21 16:16:49  ID:iOucF00Z.net(2)
アンwwwwマネージwwww
無理に横文字使わなくていいですよwww

16
デフォルトの名無しさん[sage]   投稿日:2015/11/21 17:40:45  ID:7nxNhgSu.net(2)
横文字じゃなくてマイクロソフトの用語なんだが?
コメント1件

17
デフォルトの名無しさん[sage]   投稿日:2015/11/21 17:47:25  ID:/uyrLxeD.net
c#が残念なんのはC++とデストラクタの呼ぶれるタイミングが違いすぎて移行が大変すぎることだ。
結局、手動でデストラクタを呼ばなきゃならない。GCの利便性がほとんどなし。

18
デフォルトの名無しさん[]   投稿日:2015/11/21 19:18:42  ID:iOucF00Z.net(2)
>16
涙ふけよwwww

19
デフォルトの名無しさん[]   投稿日:2015/11/21 21:36:26  ID:tqUpuiXF.net
>9
自動ならメモリリーク等々発生するわけがないのに発生している
この原因はプログラマなんだけど、結局メモリ管理から解放されてないなら最初から管理する方針でいいじゃん

20
デフォルトの名無しさん[]   投稿日:2015/11/22 01:48:28  ID:7AflF1fM.net
メモリ管理を楽にするためにあるわけで人間が全部面倒みんのとは違うだろ
コメント1件

21
デフォルトの名無しさん[]   投稿日:2015/11/22 04:41:20  ID:WFE6EpHf.net(2)
やっぱりGCのほうがいいかな大規模になってくると
Cでリークはしてないけど本来開放すべきタイミングで開放してないでメモリいっぱいになるのは防ぎやすいと思うし

22
デフォルトの名無しさん[]   投稿日:2015/11/22 07:04:28  ID:MUaNGGyB.net(2)
>20
楽になってメモリリークがなくなるならいいけど、メモリリーク発生するわ
プログラマがメモリ管理なんてしなくて大丈夫、とメモリの扱いが雑になって意図しないタイミングで解放されたりされなかったり
最初から管理するという方針で教えないから、こんなことになる
管理漏れをGCがうまいことやってくれる。でもGCにやらせるようだと恥。
というくらいで教育すべき

23
デフォルトの名無しさん[]   投稿日:2015/11/22 07:12:51  ID:MUaNGGyB.net(2)
メモリ管理すらまともにできないやつが寿命や世代やら管理できるわけがない。

24
デフォルトの名無しさん[sage]   投稿日:2015/11/22 10:54:50  ID:MJCWCZ10.net
GCそのものではなく新人教育や解説書が最初のスタンス間違えたんだよ。
GC=メモリ管理適当
という認識作ったから、GCに新しい名称つけて
教育や解説書では、メモリーの確保から解放まできちっと説明し直したほうがいい

25
デフォルトの名無しさん[sage]   投稿日:2015/11/22 12:31:51  ID:Qlq25ltW.net
GCって完全なものだと思ってたから、C#案件でメモリリークの調査にえらく手間がかかった
GCはダメな子って認識は必要だな
コメント1件

26
デフォルトの名無しさん[sage]   投稿日:2015/11/22 12:38:37  ID:mfzN9aoV.net
C/C++はライブラリレベルでメモリリリークの検査もテストも書けるけど
GC前提言語だとその辺がごっそり抜け落ちて後で問題になる

27
デフォルトの名無しさん[sage]   投稿日:2015/11/22 12:42:49  ID:zNwKjU3u.net
メモリ管理できない人がお気楽で作れば、GCあっても・・・・

28
デフォルトの名無しさん[sage]   投稿日:2015/11/22 13:08:14  ID:KDgQ57Ye.net
>25
結局どんなバグだったんだい?

29
デフォルトの名無しさん[sage]   投稿日:2015/11/22 16:57:06  ID:vggKhYqJ.net(2)
C++でもスマートポインタ使えば勝手に開放されるよ

所謂GC任せだと、いつ開放処理が走るか分らなくなるから
その事に対する新たな対策が必要になるよ
http://ufcpp.net/study/csharp/rm_disposable.html

手続き型言語は処理の順番が重要なのに
いつ実行されるか分からないってのは中々チャレンジャーだし大掛かりな話だね

30
デフォルトの名無しさん[sage]   投稿日:2015/11/22 17:32:48  ID:vggKhYqJ.net(2)
前スレでも書いたけど、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++のデストラクタのように芋づる式に勝手に呼ばれない事に有る
だから手動で芋づる式に呼び出すコードを書かなくてはならない
コメント1件

31
デフォルトの名無しさん[]   投稿日:2015/11/22 18:20:40  ID:WFE6EpHf.net(2)
Formなんかも参照が亡くなったら強制的に殺すべきだったと思うわ
ファイナライザーの処理がひどいことになると思うけど
コメント1件

32
デフォルトの名無しさん[sage]   投稿日:2015/11/22 22:36:02  ID:iT1tZCI1.net
またお前か
メンバに持つのが間違い

33
デフォルトの名無しさん[sage]   投稿日:2015/11/22 23:18:34  ID:7zQV9dKP.net
無茶いうな

34
デフォルトの名無しさん[]   投稿日:2015/11/23 08:11:32  ID:XNOSKZeE.net(2)
解放処理をしなくてもGCがやってくれる。
でも、ソースに解放処理が書いてあれば、後から見たらあぁここで用済みになったのかとわかる。

可読性は非常に重要よ。

35
デフォルトの名無しさん[sage]   投稿日:2015/11/23 15:41:37  ID:qRZYsqEh.net
解放処理のタイミングが制御できないと、解放して欲しくないタイミングで解放されて
挙動が変わることがある
リアルタイム性が要求されるシステムでこれで困ったことがある(そもそもそんな言語使うなって話だが)
コメント1件

36
◆QZaw55cn4c [sage]   投稿日:2015/11/23 17:14:59  ID:JWzW06M6.net
>35
それはあまりない
挙動が変わるというか停止するというのならあるのかもしれないが

37
デフォルトの名無しさん[sage]   投稿日:2015/11/23 17:21:44  ID:y4njP/wV.net
うわっ頭のおかしいQだ

38
デフォルトの名無しさん[sage]   投稿日:2015/11/23 17:22:22  ID:9XGqpqVu.net
>解放して欲しくないタイミングで解放

なんでそんなことになったの?
参照切ってなきゃGCの対象にならないはず

39
デフォルトの名無しさん[sage]   投稿日:2015/11/23 17:24:18  ID:OK+rBFmG.net(2)
空きメモリによって使用するアルゴリズム変えたりする。
だから実行前にGC手動で走らせて、できるだけ空きメモリ増やしたりとかする。
できるだけ開放したいのに過負荷でまだメモリに余裕あるからGC走らないってのが困る。

40
デフォルトの名無しさん[]   投稿日:2015/11/23 17:46:43  ID:XNOSKZeE.net(2)
メモリの解放漏れってさ、とどのつまり下手だからするんだよね
下手なやつにはプログラムを組ませないってのが鉄則だと思うの

41
デフォルトの名無しさん[sage]   投稿日:2015/11/23 19:25:05  ID:6m6E/SfN.net(2)
c++11のshared_ptrの参照カウンタってそもそも要るんだろうか?
複数のオブジェクトが所有権を持ちあう必要性に迫られる事がないんだけど
weak_ptrの対応だけあれば良くない?
コメント1件

42
デフォルトの名無しさん[sage]   投稿日:2015/11/23 19:56:47  ID:+Ddm9172.net(2)
リソースを共有する場合なんかは使うと楽だよ

まーshared_ptrが有れば、いつ実行されるか分からないような、手の込んだGCは要らないよな
巡回参照が有る場合はどちらかをweak_ptrにする、これだけを守ってれば問題は起きない
大体の場合は所有権というか上下関係がはっきりしているからな

巡回参照のある場合も自動で開放したいという、たったこれだけのために
いつ実行されるか分からない上に重いマークスイープ式GCを導入するのは
業界全体の早とちりだったようだね
コメント1件

43
デフォルトの名無しさん[sage]   投稿日:2015/11/23 20:06:26  ID:+Ddm9172.net(2)
最近のC++はdeleteを直接書かないだけでなく、最早newも直接書かない方向
std::make_shared<int>() って書くよね
始めからshread_ptrで受け取るから、循環参照だけ気をつければ
リークする余地がないよね
RAIIも健在で、C#みたいにIDisposableとか要らない
デストラクタも芋づる式に呼び出されるから
>30で書いたような問題も起きないよ

44
デフォルトの名無しさん[sage]   投稿日:2015/11/23 20:09:18  ID:OK+rBFmG.net(2)
C++は益々混沌としているのか。手に負えん。

45
デフォルトの名無しさん[sage]   投稿日:2015/11/23 20:35:23  ID:PopzBtGV.net
>41
糞便利な参照カウンタを使わないなんてC++使う意味なし
コメント1件

46
デフォルトの名無しさん[sage]   投稿日:2015/11/23 22:58:10  ID:6m6E/SfN.net(2)
>42
それはManagerやHolder的なものを書かなくて良いってことを言ってるの?
それって大体一時しのぎで大抵後々リソース管理以外にもそういった管理クラスが必要になるケースがほとんどじゃない?

>45
ねーよ

47
デフォルトの名無しさん[sage]   投稿日:2015/11/24 00:26:10  ID:f4S6RtN7.net(4)
うーん質問がアバウトすぎたな。もう少し具体的に書くわ

例えば2chのある板を管理するプログラムを書くとして
BoardクラスとThreadクラスを想像してみてくれ
BoardはThreadオブジェクトを管理するが、Threadは
産まれたり死んだりと揮発的で寿命が定まらないと。
で各Threadは何らかの共有リソースを持つと。
例えば一度読み込んだ画像を各スレッドで共有したいとかが
考えられるけど、画像オブジェクトをshared_ptrで共有するのは
適切ではない
なぜならある瞬間に産まれたThread群がひとつの画像を共有する
からといってshared_ptrで持たせたとしても、後の更新時に
更にその画像を共有したいThreadが現れたときに、画像が
すでにあることを何らかの形で知れないといけないから。
結局Boardなんかが画像オブジェクトのコンテナを持つ必要が
あってそのコンテナへの追加と削除のために別の共有の
仕組みが必要になるんだよ。例えばThreadがBoardに画像を
リクエストして参照カウンタを持ったアクセサを返すようなもの
だから所有権はBoardひとりが持てばよくてshared_ptrを
使う必要がなくなるという理屈
こういったケースを踏まえてもshared_ptr使うケースって
ほとんどなくね
コメント1件

48
デフォルトの名無しさん[]   投稿日:2015/11/24 01:21:45  ID:0dqdPvnh.net
IDisposableの問題はDisposeを呼ばなければリークするものとそうでないものの混在だろ

49
デフォルトの名無しさん[sage]   投稿日:2015/11/24 03:22:06  ID:fjQi4YH+.net
>47
マルチスレッドプログラム書いてみろよ
shared_ptrがないと泣くぞ
コメント1件

50
デフォルトの名無しさん[sage]   投稿日:2015/11/24 05:26:33  ID:f4S6RtN7.net(4)
>49
いやいくらでも書いてるけど基本一緒
というか上の例もそのままマルチスレッドに適用できる話でしょ

例えばproducer consumerならproducerが所有権を持つし
thread per messageなら共有データはホストが持って固有データは
個別スレッドで持つだけ
むしろマルチスレッドの場合、所有者をより厳格に決めとかないと
泣く事になるぞ
コメント1件

51
デフォルトの名無しさん[sage]   投稿日:2015/11/24 12:31:47  ID:HvLaDP3z.net(2)
所有権って・・・・

unique_ptrを使うと勝手に所有権が移動してしまうし
生のポインタを使うんならわかるけど
コメント1件

52
デフォルトの名無しさん[sage]   投稿日:2015/11/24 12:53:55  ID:2IyJeQ15.net
shared_ptrで複数人が所有権を持っても良いんだぞ
上下関係さえしっかりしていれば良い

53
デフォルトの名無しさん[sage]   投稿日:2015/11/24 13:15:01  ID:HvLaDP3z.net(2)
そんなの分かってるんだが
>50の人はどう考えてるのか

54
デフォルトの名無しさん[sage]   投稿日:2015/11/24 16:23:15  ID:f4S6RtN7.net(4)
>51
今のC++からshared_ptrをそのまま無くせって言ってるんじゃないぞ
shared_ptrのコピーを禁止にしてweak_ptrの対応だけあれば良くないかって事
そもそも何でそんなこと言うかっていうと、
GCない言語→循環参照ガー。みたいによく言われるけど使わないで
済むなら静的解析で循環参照の起こり得るケースをエラーにしてしまう
って解決方法もあるかなと思っただけ
あとshared_ptrとweak_ptrはアトミック操作とメモリバリアを必要としうるから
それに頼った設計は疑問を感じる

55
デフォルトの名無しさん[sage]   投稿日:2015/11/24 16:37:54  ID:f4S6RtN7.net(4)
一応言っとくと静的解析のくだりは新しい言語を
設計するとした場合の話ね
C++だとほぼ不可能だろうから

56
デフォルトの名無しさん[sage]   投稿日:2015/11/24 16:39:45  ID:1SleeXaD.net
せっかくC#は新設計なのにいろいろ失敗が含まれてるよな。

ヘジはなにやってんだか。

57
uy ◆Qawu9.2l1E [sage]   投稿日:2015/11/24 18:29:34  ID:lNjW2jss.net
大企業は、
中小企業を奴隷にさせる事を第一に考えたツールしかリリースしてないよ
失敗ではなく全部わざと。

58
デフォルトの名無しさん[sage]   投稿日:2015/11/25 07:39:30  ID:JnM8vxaH.net
メモリ管理テケトーなやつはその他のリソース管理もテケトー

59
デフォルトの名無しさん[sage]   投稿日:2015/11/25 17:12:00  ID:Sra0FKsR.net
そもそも自分のリソース管理がしっかり出来てる人は・・・

60
デフォルトの名無しさん[sage]   投稿日:2015/11/27 12:24:34  ID:ZRdaHx9T.net
>31
Formはnull入れてあげないといけないんだっけ?

なんか、場合場合によってnull入れてあげないといけなかったり入れなくてもよかったり。
ならnull入れるで統一でいいじゃんと思った

61
デフォルトの名無しさん[sage]   投稿日:2015/11/27 22:35:05  ID:CyIO1ZuX.net
Rust使えば解決

62
デフォルトの名無しさん[]   投稿日:2015/11/28 06:44:39  ID:CKvy7+My.net(4)
中の細かい実装まで知らないんだけど、
A = new A()
Loop Begin
  処理
  A = null
  A = new A()
Loop End
とか、nullをセットをGCって見張ってるの?又はGCに伝えているとかあるの?
コメント1件

63
デフォルトの名無しさん[sage]   投稿日:2015/11/28 13:02:34  ID:Qyl/1Ad+.net(2)
違うよ
newが動いた時点で中の人がメモリが足りない!って騒いで初めてGCさんお願いします!GC「やれやれ・・・
っていう仕組みなんで
>62の例のnullの代入は無駄

64
デフォルトの名無しさん[sage]   投稿日:2015/11/28 13:08:02  ID:Qyl/1Ad+.net(2)
いや無駄じゃないか
代入演算子の順序の関係でnewの後に代入が起こるから
Aを事前にnullすることでGCさんが回収できるオブジェクトが1個増える
コメント1件

65
デフォルトの名無しさん[sage]   投稿日:2015/11/28 13:10:10  ID:rTI66XO9.net(3)
書いたほうが保守性は高く、意味がある。

66
デフォルトの名無しさん[]   投稿日:2015/11/28 13:34:46  ID:CKvy7+My.net(4)
>64
つまり、使い終わったら、スグにnullっておいたほうがいいってことか。
・・・とも言い切れないな。

でも、ここで使い終わったってわかるから、書いたほうがいいか。
よし。決めた。全部書こう。

67
デフォルトの名無しさん[sage]   投稿日:2015/11/28 13:55:47  ID:pohBt4lh.net(4)
null代入なんていちいち書いていたら
コードが冗長になって保守性が落ちる。

メモリ食いのオブジェクトなど、クリティカルな部分でのみ使うべき

68
デフォルトの名無しさん[sage]   投稿日:2015/11/28 14:16:02  ID:81goelDj.net
お前らか。無意味なnull代入書き散らしてるのは
コメント2件

69
デフォルトの名無しさん[sage]   投稿日:2015/11/28 14:42:43  ID:DqKP/LxN.net(2)
null代入とか結局やってることc++以下なんだよなぁ

70
デフォルトの名無しさん[sage]   投稿日:2015/11/28 14:48:25  ID:Fi4wDTmy.net(2)
ダングリングポインタが出ないって利点は有るにはあるが
スマートポインタ使えば済む話だしなぁ
weak_ptrもあるし

71
デフォルトの名無しさん[sage]   投稿日:2015/11/28 15:20:08  ID:vL/aYykM.net
>68
意味はあるじゃん

72
デフォルトの名無しさん[]   投稿日:2015/11/28 17:52:47  ID:CKvy7+My.net(4)
>68
ここでおしまい!って書いてあるだけ。
こんなんで冗長とは評価されない。むしろ読みやすい。と判断した。

73
デフォルトの名無しさん[sage]   投稿日:2015/11/28 18:23:41  ID:ekTV2Qou.net(3)
変数がどこで不要になるか明示しなきゃならんほど長い関数ばっかり書いてるのか
それともローカル変数とか無い言語を想定してるのか

74
デフォルトの名無しさん[sage]   投稿日:2015/11/28 18:24:46  ID:q5KJxTWt.net
無駄なことするな
どうせ最適化で削除される

75
デフォルトの名無しさん[sage]   投稿日:2015/11/28 18:28:07  ID:rTI66XO9.net(3)
保守性より効率重視なんかでコード書くからメモリリークするんだよ。
コメント1件

76
デフォルトの名無しさん[sage]   投稿日:2015/11/28 19:04:25  ID:ekTV2Qou.net(3)
どんな意味でnull代入をしてるのか他人に伝わらなきゃ保守性もクソも無いよね

77
デフォルトの名無しさん[sage]   投稿日:2015/11/28 19:08:04  ID:rTI66XO9.net(3)
a = null;
で伝わらない人にはどんなコメント書いても伝わらないと思うんだ。
コメント2件

78
デフォルトの名無しさん[sage]   投稿日:2015/11/28 19:27:35  ID:pohBt4lh.net(4)
関数内ローカルな変数は
いくら大きくても大概スコープだけで
どうにでもなる。

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

79
デフォルトの名無しさん[]   投稿日:2015/11/28 19:54:24  ID:CKvy7+My.net(4)
>75,>77
同じ結論ですわ。
null代入ってやっぱり特殊だから、コメントよりはるかに目が行く。
ここで使い終わったYO!!(逆に言えば、ここまでは意識してね。使ってるから。)ってわかってもらえれば良い。

80
デフォルトの名無しさん[sage]   投稿日:2015/11/28 20:10:37  ID:ekTV2Qou.net(3)
>77
長い関数中にそれ出てきたら変数を使い回す前に初期化したいのかな?とかも考えるな
短い関数なら変数を使い終わったとか重要な情報じゃないから無駄な行入れて可読性下げてるだけ

81
デフォルトの名無しさん[sage]   投稿日:2015/11/28 20:14:43  ID:pohBt4lh.net(4)
永続的な変数でもなきゃ、変数の寿命はコンパイラが把握しているから、null代入がどんな変数にも必要なら勝手に挿入するんじゃね。

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

82
デフォルトの名無しさん[sage]   投稿日:2015/11/28 20:16:46  ID:Fi4wDTmy.net(2)
勝手にnullを代入するとか、そんな変なコンパイラは困る
コメント1件

83
デフォルトの名無しさん[sage]   投稿日:2015/11/28 20:47:03  ID:03HlMXbm.net
話は変わるんだがスマートポインタのメリットって何?
コンストラクタで例外投げたとき
そこまでに初期化したメンバ変数のデストラクタを呼ぶため
みたいなのは聞いたことあるけどそれくらいのもん?
コメント1件

84
デフォルトの名無しさん[sage]   投稿日:2015/11/28 21:01:25  ID:DqKP/LxN.net(2)
>83
別にコンストラクタじゃなくて関数内で確保した場合でも、
例外じゃなくreturnで戻った時も勝手に解放してくれたほうが
有り難いし、そもそも解放処理って忘れやすいものだろ
傘を置き忘れたり洗濯物を洗濯機に入れっぱなしにしたことの
ないものだけスマートポインタに石を投げなさい
コメント1件

85
デフォルトの名無しさん[sage]   投稿日:2015/11/28 21:20:40  ID:ETFlkHGB.net
null 代入したら行数増えるじゃん…全部のローカル変数にやってんの?
どうしても明示したければスコープで区切った方がまし
それでもインデントが深くなるのであれだけど

86
デフォルトの名無しさん[sage]   投稿日:2015/11/28 23:46:43  ID:pohBt4lh.net(4)
>82
勝手にnull代入すると表現するから気持ち悪く感じるだけで、コンパイラが各変数についてもうアクセスされる可能性の無い基本ブロックに到達したら、その変数をGCのマークの起点として使用しないようにフラグを管理すると言えば当たり前の話じゃね。
フラグの持ち方として変数にnullを代入しているだけで。

87
デフォルトの名無しさん[sage]   投稿日:2015/11/29 00:14:42  ID:qbMwzV1h.net
>84
> そもそも解放処理って忘れやすいものだろ

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

88
デフォルトの名無しさん[sage]   投稿日:2015/11/29 00:30:29  ID:Co3W2iFa.net(5)
>87
まあ勉強目的でやるならいいんじゃね
俺は元々ゲームプログラマだったからもう嫌になるほどやったし
メモリ周り工夫するなら言語設計からしたいわ

89
デフォルトの名無しさん[sage]   投稿日:2015/11/29 13:48:13  ID:U49gaUJj.net
信じて送り出した >87 がわがままな顧客を✕✕して三面記事に載るなんて…

90
デフォルトの名無しさん[sage]   投稿日:2015/11/29 14:29:40  ID:c+9MHjtm.net
マークスイープ型のGCが必要かどうかについて、もう少し建設的な会話をしようよ
リソースを自動で開放してくれる機能は、無いよりは有った方が絶対に良い、と言い切ってよいよね
ただ、その方式が話の焦点だと思う

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

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

どちらを選ぶ?
コメント1件

91
デフォルトの名無しさん[sage]   投稿日:2015/11/29 14:58:17  ID:7vkfzAlt.net
GCの意見・・・OSではページファイル関連?
GCは失敗。メモリは自分で管理せよ! その2

92
デフォルトの名無しさん[sage]   投稿日:2015/11/29 15:57:55  ID:Co3W2iFa.net(5)
そもそもc++においてメモリリークって対策も発見も
大して難しい部類のバグではないんだよなぁ
GCの優位性をアピールするために過剰に恐怖心を煽ってる気がする
コメント2件

93
デフォルトの名無しさん[sage]   投稿日:2015/11/29 16:00:08  ID:sCmmZzWu.net(3)
>92
その程度の案件しか受けてないからだろう。
コメント1件

94
デフォルトの名無しさん[sage]   投稿日:2015/11/29 16:05:07  ID:QSPcxrGF.net(2)
>90
つ世代別GC

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

95
デフォルトの名無しさん[sage]   投稿日:2015/11/29 16:15:05  ID:Co3W2iFa.net(5)
>93
いやいや普通難しいとされるバグってメモリ破壊とか同期周りだから
メモリリークなんてデバッガがチェックして丁寧なダンプ出してくれるし
組み込みとかの貧弱な環境なら専用のメモリ管理を用意して
いくらでも好きなチェックや情報出せるから
コメント1件

96
デフォルトの名無しさん[sage]   投稿日:2015/11/29 16:17:37  ID:AV0cYAnH.net
>92
それな
メモリの確保と開放の対応すら管理できない奴は
なんかもう何をどうしたってダメな気がする
初歩の初歩の初歩の話題を何度も何度も何度も繰り返しすぎ

97
デフォルトの名無しさん[]   投稿日:2015/11/29 16:20:05  ID:3h4H/kBH.net(2)
忘れるとか忘れないとか池沼レベルの話じゃん。
ゴミクズ。

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

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

98
デフォルトの名無しさん[sage]   投稿日:2015/11/29 16:24:33  ID:sCmmZzWu.net(3)
>95
なるほど。経験の少なさがすぐ分るな。ログ出したらで数十ギガなんてよくあるよ。
ログから問題点をスクリプトで抽出するにも何時間とかかるとかいろいろ。
マルチスレッド絡んで特定のパターンだけだったりして再現性がなかったりする。
他システムの連携だと手が出せない部分の挙動がおかしい可能性もある。結局、oracleのバグだったとかね。
コメント1件

99
デフォルトの名無しさん[]   投稿日:2015/11/29 16:25:01  ID:1uX74bCE.net
>97
決済システムとメモリ解放は違うよ。
通販サイトのシステムをC言語で実装してみればわかるかと。

100
デフォルトの名無しさん[sage]   投稿日:2015/11/29 16:36:20  ID:Co3W2iFa.net(5)
>98
はあ?なんでリーク箇所ダンプするだけの話でログ全部吐き出すことになってんの
普通確保する際にヘッダにそのブロックの確保場所埋め込んでるし
アロケータで生存期間のスコープを切り分けといてすぐ分かるようにするけど?
お前の関わったプロジェクトが糞なだけじゃね?
コメント2件

101
デフォルトの名無しさん[sage]   投稿日:2015/11/29 16:42:54  ID:snjMtaUP.net
そもそも今時c++でgcならなんとかなる類いのメモリリーク起こすなんて、プログラマが屑なだけ。
リソースリークやその他の問題も確実に起こすこと請け合い。
GC言語でそのレベルのプログラマを使うような案件はGCによるメモリオーバーヘッドが気にならず、リソースリークも問題にならないような非常に緩い案件でしかない。

102
デフォルトの名無しさん[sage]   投稿日:2015/11/29 16:46:22  ID:sCmmZzWu.net(3)
>100
はぁ。話にならんな。扱ってる規模が違いすぎる。
コメント1件

103
デフォルトの名無しさん[sage]   投稿日:2015/11/29 16:52:06  ID:Co3W2iFa.net(5)
>102
おいおい反論できずに捨て台詞かよ
上でも書いたがコンシューマで開発してたから
100人*数年の規模でやってたんだけど
もしかしてC++みたいな危険な言語使ってて
今の今まで解析ツールなり自前のメモリ管理なり知らなかったの?

104
デフォルトの名無しさん[sage]   投稿日:2015/11/29 19:41:19  ID:GW0SCIDI.net
お前ら派遣だろw
全体規模とお前らが任されてる範囲を都合よく混ぜるな。

105
デフォルトの名無しさん[]   投稿日:2015/11/29 22:07:37  ID:3h4H/kBH.net(2)
ほーら、自分の知能が一般人より低いと認めたくないがゆえにレッテル貼りが始まった。
普通の人が当たり前にできることができないってかわいそうだな。
もしADHD?だったら治療法あるらしいから病院行ってみたら?
ここでレッテル貼りやってるよりよっぽど解決する可能性が高いぞ。

106
デフォルトの名無しさん[sage]   投稿日:2015/11/29 22:12:02  ID:QSPcxrGF.net(2)
レッテル貼りは2chの華

107
デフォルトの名無しさん[sage]   投稿日:2015/11/30 08:34:00  ID:qSWjFIuy.net
>100
リーク箇所がわかってればログ出力の必要なくね?
ホントに開発したことあるのかな?
コメント1件

108
デフォルトの名無しさん[sage]   投稿日:2015/11/30 09:12:24  ID:UQyKbzCH.net(7)
>107
普通C++のプロジェクトは専用のメモリ管理を用意するから
リークしたメモリはそれを確保したクラスとその行数まで特定できるようにしてるよ
アロケーターも分離しとけばアプリケーション終了させなくても
管理オブジェクトを破棄した時点でリークの判定できるし

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

109
デフォルトの名無しさん[sage]   投稿日:2015/11/30 12:11:48  ID:fg7tHWVi.net
100人で数年のシステムなら
10人で一年でやるべきだな。
人を無駄に増やせば、意思疎通や連携に無駄に労力を割く。
開放云々より仕様レベルで齟齬が出やすくなるわ。

110
デフォルトの名無しさん[sage]   投稿日:2015/11/30 15:00:18  ID:Ee9Jt/HC.net(5)
>108
リークしたクラスが分ればリーク原因が分るとかお花畑杉w
コメント1件

111
デフォルトの名無しさん[sage]   投稿日:2015/11/30 19:23:16  ID:UQyKbzCH.net(7)
>110
誰もリークしたクラスの事なんて言ってないんだが…理解できてる?(笑)
解らないなら解るだけの情報埋めたら?

112
デフォルトの名無しさん[sage]   投稿日:2015/11/30 19:24:12  ID:Ee9Jt/HC.net(5)
おいおいw
コメント1件

113
デフォルトの名無しさん[sage]   投稿日:2015/11/30 19:31:17  ID:UQyKbzCH.net(7)
>112
そもそもGCがあろうとコンテナに突っ込んで消し忘れれば
オブジェクト破棄するまでメモリ圧迫し続けるって理解できてる?
リーク単体ならC++はそれと同等のレベルまで分かりやすく出来るんだよ
C++が困難なのはそういった管理情報も簡単に破壊出来てしまう点
リーク単体なら怖くはない
コメント1件

114
デフォルトの名無しさん[sage]   投稿日:2015/11/30 19:47:37  ID:UQyKbzCH.net(7)
なんかだんだん笑えて来たんだけど、ろくに理由も言わずに
「わかんないんですけど!?わかる奴はお花畑(怒)!!」って
なかなか面白い奴だな

115
デフォルトの名無しさん[]   投稿日:2015/11/30 19:50:22  ID:isQX20zS.net
メモリの解放すら管理できない奴が、複雑な仕様を管理できるとは到底思えない・・・。
メモリの解放なんてなんの苦にもならんが・・・。
コメント1件

116
デフォルトの名無しさん[sage]   投稿日:2015/11/30 20:14:21  ID:Ee9Jt/HC.net(5)
やれやれw

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

117
デフォルトの名無しさん[sage]   投稿日:2015/11/30 20:30:16  ID:UQyKbzCH.net(7)
>116
また反論できずに逃走かよw
そもそも欧米は原因分かっててもバグ無視する連中だろうがw
ライセンスで守られてりゃ平気で放置するぞ

118
デフォルトの名無しさん[sage]   投稿日:2015/11/30 20:33:04  ID:V9s4KAVu.net
人生の管理ができない奴が、メモリを管理できるとは到底思えない

119
デフォルトの名無しさん[sage]   投稿日:2015/11/30 20:49:26  ID:UQyKbzCH.net(7)
そもそもLinuxカーネルもFreeBSDカーネルもC言語だろ
馬鹿丸出しだなw

120
デフォルトの名無しさん[sage]   投稿日:2015/11/30 21:16:22  ID:zT+q2mn+.net(3)
>115
それな
プログラミングにおいてメモリ周囲はまだ初歩だよな
そしてマルチスレッドはそれよりは大変だがこれも慣れると
結局大事なところをガッチリ排他処理するだけのことだしな

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

121
デフォルトの名無しさん[sage]   投稿日:2015/11/30 21:18:50  ID:Ee9Jt/HC.net(5)
>120
で例外系の実装がないから破綻するんだよ。実務経験ないとすぐ短絡的になるのが分る。

122
デフォルトの名無しさん[sage]   投稿日:2015/11/30 21:25:49  ID:zT+q2mn+.net(3)
意味が不明すぐるw
コメント1件

123
デフォルトの名無しさん[sage]   投稿日:2015/11/30 21:28:33  ID:Ee9Jt/HC.net(5)
うむ。まだおまえには早いかもしれない。

124
デフォルトの名無しさん[sage]   投稿日:2015/11/30 21:47:43  ID:UQyKbzCH.net(7)
>122
馬鹿相手にしても時間の無駄だぞ
こいつ具体的なこと何も言わんし
コメント1件

125
デフォルトの名無しさん[sage]   投稿日:2015/11/30 22:07:34  ID:zT+q2mn+.net(3)
>124
そやね
一連のレスの意図すらよーわからんわ

126
デフォルトの名無しさん[sage]   投稿日:2015/12/01 00:23:09  ID:s1rcgCDh.net(3)
Guilty Crown?
たしかに失敗作だったなあ…

127
デフォルトの名無しさん[sage]   投稿日:2015/12/01 01:24:29  ID:mVPa8mQr.net(3)
GCが云々というより抽象的なプログラミングしたい時は基本的なメモリ管理を言語に任せたいという欲求

128
デフォルトの名無しさん[sage]   投稿日:2015/12/01 01:27:09  ID:mVPa8mQr.net(3)
>113
c++素人なんだけどリーク単体はともかくそれにメモリ破壊が合わさると頭がおかしくなって死ぬ
みたいな感じ?
コメント1件

129
デフォルトの名無しさん[sage]   投稿日:2015/12/01 01:30:32  ID:s1rcgCDh.net(3)
GCは関数型プログラミングでのみ正当化される
命令型プログラミングでは全く正当化されない

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

130
デフォルトの名無しさん[sage]   投稿日:2015/12/01 01:31:50  ID:s1rcgCDh.net(3)
>GCは関数型プログラミングでのみ正当化される
ちな、これは処理系の裏方としての存在が許される、の意味

131
デフォルトの名無しさん[sage]   投稿日:2015/12/01 01:36:31  ID:mVPa8mQr.net(3)
関数型プログラミング好きだけど
代数型データ型と型クラスでモナドとかアプリカティブとかtraverse、free monadとかやってる時に
メモリ管理だの言われたら余裕で死ねるな
本物のhaskellプログラマはhaskellで低レイヤを書くらしいけど

132
Office & Gamers @ 試験運用中(トリなしw[アハ♪” uh huh]   投稿日:2015/12/01 04:32:07  ID:79aHC4wo.net
口 先 人 間 展 覧 会 。(アハ

133
デフォルトの名無しさん[sage]   投稿日:2015/12/01 12:55:11  ID:S8usJREu.net
>128
> メモリ破壊が合わさると

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

134
デフォルトの名無しさん[sage]   投稿日:2015/12/03 12:20:09  ID:AuS7g0FI.net
ここでメモリ確保
ここでメモリ解放

たったこれだけが書けない管理できないとかw
コメント4件

135
デフォルトの名無しさん[sage]   投稿日:2015/12/03 12:23:19  ID:n26CULk9.net(3)
知らないでやるって幸せなことなんですね
コメント1件

136
デフォルトの名無しさん[sage]   投稿日:2015/12/03 13:19:32  ID:N5r0JkUz.net
>134
下には下がいるんだよ

137
デフォルトの名無しさん[sage]   投稿日:2015/12/03 13:29:54  ID:JbiOZ/E3.net
メモリリークは開放忘れでなると思ってる低レベルがいるのか。
コメント3件

138
デフォルトの名無しさん[sage]   投稿日:2015/12/03 14:07:05  ID:n26CULk9.net(3)
低レベルなことを舐めるなよ

139
デフォルトの名無しさん[]   投稿日:2015/12/03 16:32:54  ID:JraK7tKY.net(2)
>134
mallocでOSから確保したメモリはfreeで解放されないんだが、

「ここで解放」はどうやって書くんでしょう?
コメント2件

140
デフォルトの名無しさん[]   投稿日:2015/12/03 19:43:25  ID:R/g8PPkY.net(2)
>137>139みたいのが知識や技術に溺れて本質を見失い、
人と会話ができなくなった人の見本なんだろうか
コメント1件

141
デフォルトの名無しさん[]   投稿日:2015/12/03 19:47:17  ID:JraK7tKY.net(2)
>140
今まで正しいと信じきってた鰯の頭が迷信だと指摘され発狂中
コメント1件

142
デフォルトの名無しさん[]   投稿日:2015/12/03 19:53:39  ID:R/g8PPkY.net(2)
>141おw おまえ会社で孤立してるだろ派遣w

143
デフォルトの名無しさん[]   投稿日:2015/12/03 20:32:35  ID:R04IP6VM.net
確保したやつが解放するんだぞ。大丈夫か?

144
デフォルトの名無しさん[sage]   投稿日:2015/12/03 20:33:46  ID:cWTIfUD3.net
想像を絶するアホは居るもんだよ
if (cond) exp; の場合も中カッコを必ず付ける流派ってのがあって
理由を聞くと
if (cond) {exp1; exp2;}とするはずが
if (cond) exp1; exp2;としてしまうのを防ぐための常に中カッコらしい

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

145
デフォルトの名無しさん[sage]   投稿日:2015/12/03 20:52:03  ID:s/TINiTx.net
>144
お前がアホなwww

146
デフォルトの名無しさん[sage]   投稿日:2015/12/03 21:25:03  ID:n26CULk9.net(3)
カッコ先につけといたほうが 後々、都合がいいことも

147
デフォルトの名無しさん[sage]   投稿日:2015/12/03 21:30:08  ID:WeEbsZB7.net
アホな書き方といえば
 if ( 1 == a ) {
って比較元と先を逆にしてる奴
コメント1件

148
デフォルトの名無しさん[sage]   投稿日:2015/12/03 21:41:57  ID:4rUKwdGH.net
別におかしくない
基準値が先にあって、それと比べてaがどうなのか、と考えるか
aが先にあって、基準値と比べてどうなのか、と考えるかの違いでしか無いから
どっちでも良い

149
デフォルトの名無しさん[sage]   投稿日:2015/12/03 21:59:47  ID:/xqyH1ID.net
>147
知ってて言ってると思うが、定数を==の左辺にするのは
if (a=1) { ...
と書き間違うのを恐れているらしい

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

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

150
デフォルトの名無しさん[sage]   投稿日:2015/12/03 22:27:47  ID:zepIVOGi.net
ここ数日一気にレベルが下がったなw
GCの話しろよw

151
デフォルトの名無しさん[sage]   投稿日:2015/12/03 22:46:13  ID:srgQPG9D.net
つーか前スレと同じこと書いてる人多数
頼むから前スレ読んできて
コメント1件

152
デフォルトの名無しさん[]   投稿日:2015/12/04 04:37:18  ID:HtuddwW0.net
【 オンラインTCGエディター 】 >1

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

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

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

個人や企業などのベンダーが提示する開発費(見積もり)で折り合えば、発注する。

エディター群から基本コンセプトを絞り込む(もちろんオリジナルで優れた新ネタが有れば導入する)。

遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。
なるべく前述3つで可能な再現は全て実装させる方向を目指す。 まぁ努力する・・・
バトスピ、ヴァンガ、バディ、デュエマなど発売済みゲームソフトが存在してるケースはベンダーに研究させる。

各社TCGを再現するテストプレイ ⇒ 更に改良や修正。

機能制限した下位版を5万円以上で発売 + デュエリ−グ用に改造した上位版でサーバー稼動=営業開始。

下位版の改造および商用利用には、別途で当社との契約が必要。

さ〜て、製作ベンダー見つけよっと!ww(クス
【報酬制カード】DUELEAGUE【デュエリーグ】14 /ラウンジクラシック板-18

153
デフォルトの名無しさん[sage]   投稿日:2015/12/04 12:21:13  ID:GzeAUkqU.net
>149
>free()から設計し直す、
>まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ

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

154
デフォルトの名無しさん[]   投稿日:2015/12/04 20:05:33  ID:SAJ9n/s7.net
>137これって何が言いたいの?OSやライブラリ自体にミスがあるって言いたいの?
wikiより
>メモリリーク (Memory leak) とは、プログラミングにおけるバグの一種。
>プログラムが確保したメモリの一部、または全部を解放するのを忘れ、確保したままになってしまうことを言う。
>プログラマによる単純なミスやプログラムの論理的欠陥によって発生することが多い。

>137みたいなこと言う奴って、電磁波からデータが盗まれる!対応しないと!とか言い出すタイプ?
コメント2件

155
デフォルトの名無しさん[sage]   投稿日:2015/12/04 21:16:45  ID:7W1HEY29.net
>151
そもそも15年ぐらい前から延々繰り返されてるんだが…

156
デフォルトの名無しさん[sage]   投稿日:2015/12/04 23:45:19  ID:j6MEWqDN.net
>154
開放コードを忘れずに書いたのに開放されないという怪奇現象がマルチスレッド状況ではしばしばあるんじゃー!
マルチコア時代になってこれはますます危険になった
見ただけで正しさがわかる系のスレッド安全策はクロックサイクルを糞のごとく消費するし…

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

157
デフォルトの名無しさん[sage]   投稿日:2015/12/05 00:08:28  ID:+HxrBEdK.net(5)
それ単にメモリバリアの問題じゃ…

158
デフォルトの名無しさん[sage]   投稿日:2015/12/05 04:01:37  ID:2vAbbe+i.net(2)
>154
入門書に書いてるコードしか見たことないんだね。
スレッドプールみたいなテクニックは高速化のためにみな普通に使うんだよ。
OSやライブラリにもメモリリークなんてよくあることだし、それらのバグも開放忘れて起きてるイージーなバグじゃないよ。
他のバグやトラブルがメモリリークという形で表面化してるにすぎない。
コメント3件

159
デフォルトの名無しさん[]   投稿日:2015/12/05 08:28:25  ID:Pfi54LUx.net(2)
>158
具体的にいつのどのバージョンのライブラリで起きてるの?
使い終わったらメモリを開放しろ。使い終わってないなら開放する必要はない。これとスレッドプールとどこに関連性があるの?
コメント1件

160
デフォルトの名無しさん[sage]   投稿日:2015/12/05 09:45:44  ID:P9ivIQ+p.net
>159詰めても無意味。
こういう連中は、まず自分の考えややり方が絶対正しく絶対に曲げない。曲げないために無理やり理由を当てはめようとしている。
で、さもそれを自分はやってるように言っているが、実際は単に本に載ってることを言ってるだけ。
実装もできない。面前で詰めてやれば発狂して勝敗がハッキリつくけどネット上では無理だね。

161
デフォルトの名無しさん[sage]   投稿日:2015/12/05 09:48:00  ID:BOwcKS4A.net
メモリの話とスレッドの話を混ぜ込んでしまうタイプは
問題の切り分けがそもそも出来ないタイプ
だからメモリリーク()に悩まされる

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

162
デフォルトの名無しさん[sage]   投稿日:2015/12/05 10:18:00  ID:NRX1k+Is.net(6)
>158
ちょっ漏れが作ったわけでも漏れの使い方に問題があるわけでもない階層で起きるメモリリークの責任を漏れに負わされても困る…
それに他人が作ったモジュール内でのメモリリークも結局は開放が書かれていなかったか、書かれていても正しくなかったからリークしているはず…

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

163
デフォルトの名無しさん[sage]   投稿日:2015/12/05 12:34:30  ID:eGerJrSR.net(5)
だからメモリを自動開放してほしいときはスマートポインタを使えばよいだろ
循環参照が無い限りshared_ptrで問題ないだろ
循環参照がある場合はどちらかをweak_ptrにすれば済む話だろ

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

164
デフォルトの名無しさん[sage]   投稿日:2015/12/05 12:38:09  ID:eGerJrSR.net(5)
むしろ議論すべきはshared_ptrのような参照カウンタ方式のスマポと
言語ビルドインのマークスイープ系のGCとで
どちらが良いか、だろう

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

165
デフォルトの名無しさん[sage]   投稿日:2015/12/05 13:11:12  ID:eGerJrSR.net(5)
つまり、完璧なGCは無いということだ

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

166
デフォルトの名無しさん[sage]   投稿日:2015/12/05 13:42:35  ID:FurPG6R/.net
普通に言語を選べば良いだけの話では

167
デフォルトの名無しさん[]   投稿日:2015/12/05 13:49:45  ID:Pfi54LUx.net(2)
このスレ論点が一致してないよね。
 freeやdeleteを記述すべきという論点で話をしている人
 freeやdeleteしたところでメモリが解放されてるわけではないですがという論点の人
 freeやdeleteは当然、さらにnull等を記述すべきという論点で話をしている人
 GCの実装そのものを論点にしている人
論点がばらっばらだから咬み合わない
コメント1件

168
デフォルトの名無しさん[sage]   投稿日:2015/12/05 13:58:32  ID:wharPYQR.net(2)
>158
> OSやライブラリにもメモリリークなんてよくあることだし

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

169
デフォルトの名無しさん[sage]   投稿日:2015/12/05 14:16:25  ID:2vAbbe+i.net(2)
MSのサイトにfix分と調査中のものが全部公開されてる。他のOSもlog、mlみれば腐るほど出てくる。

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

170
デフォルトの名無しさん[sage]   投稿日:2015/12/05 14:33:31  ID:9PUwCRa0.net(4)
C++でRAIIを徹底しておくのが一番いいよ
解放タイミングのコントロールが必要になったら後からでも柔軟に対応できるし
GCは解放に係る少し変わった条件が発生した時に滅茶汚いことをしなきゃならなくなる

171
デフォルトの名無しさん[sage]   投稿日:2015/12/05 14:36:53  ID:NRX1k+Is.net(6)
shareed_ptrはC++で比較的効率よくやれることと、GCしたい人が真にやりたいことの妥協の産物であって
どんなシチュでもベストにフィットするような一押しの決定版ってほどでも無い…

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

172
デフォルトの名無しさん[sage]   投稿日:2015/12/05 14:43:55  ID:9PUwCRa0.net(4)
確保/解放を直に書くのはスピード的には一番速いだろうけど解放漏れバグの温床過ぎてネ
特に例外が絡むとやってられない状況になる
コメント1件

173
デフォルトの名無しさん[sage]   投稿日:2015/12/05 14:45:23  ID:+HxrBEdK.net(5)
>167
null云々は別言語だ馬鹿

174
デフォルトの名無しさん[sage]   投稿日:2015/12/05 14:47:17  ID:wharPYQR.net(2)
>169
> もちろん最新版でリークする奴ね

早くあげてよね w

175
デフォルトの名無しさん[sage]   投稿日:2015/12/05 14:52:20  ID:NRX1k+Is.net(6)
>172
>特に例外が絡むとやってられない状況になる
そこだけはstd::unique_ptr<T>の一押し
これで例外状況でのRAIIが完成するので真にGCが要らんところまで逝く

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

176
デフォルトの名無しさん[sage]   投稿日:2015/12/05 14:59:01  ID:9PUwCRa0.net(4)
>175
いやーリソース獲得した状態でファイルI/Oとかネットワークとかが絡む場合は終了じゃすまん場合が多いでしょ

177
デフォルトの名無しさん[sage]   投稿日:2015/12/05 15:06:58  ID:MOG2PmhH.net(4)
昔C言語で数珠繋ぎの独自スコープとしてblock_enter/block_leaveというのを作って

{
block_handle h = block_enter(b)

object = block_create_object(h)

block_leave(h)
}

178
デフォルトの名無しさん[sage]   投稿日:2015/12/05 15:10:52  ID:MOG2PmhH.net(4)
書き損じた
昔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)で全開放とかそんなの

179
デフォルトの名無しさん[sage]   投稿日:2015/12/05 15:15:45  ID:MOG2PmhH.net(4)
デメリットはblock_create〜で作成するものは全部ヒープに確保されること
結局C言語でここまで必要な案件てのが回ってこなくてあんま使ってないけどリーク予防法の参考程度に

180
デフォルトの名無しさん[sage]   投稿日:2015/12/05 15:24:40  ID:4CEShJeO.net
例外にも対応って?
コメント1件

181
デフォルトの名無しさん[sage]   投稿日:2015/12/05 15:29:31  ID:KdBqlpoa.net(2)
C#でアンマネージドなメモリを扱えるのはわかった
確保したメモリ領域にオブジェクトを配置する事は出来ない?
C++で言うところの配置newを再現したいんだ
メモリの確保解放はプログラマが特別に管理してその間は普通のオブジェクトと同じように透過的に扱いたい

182
デフォルトの名無しさん[sage]   投稿日:2015/12/05 15:30:53  ID:MOG2PmhH.net(4)
>180
例外つってるのは具体的にはSEHの話
どっかで止めた時点のblock_leave(b, h)でそれまでの開放が保証されるってこと

183
デフォルトの名無しさん[sage]   投稿日:2015/12/05 15:39:23  ID:eGerJrSR.net(5)
C++にfinallyが無いのが気に食わない
今はラムダが有るのでマクロでそれっぽいものを自作したが
標準で用意しておいてほしい
C++はリソースを自分で管理する傾向のある言語なのに
finallyが無いのは本来おかしいよな
ラッパー作ってRAIIを徹底しろってことなんだろうけど
すべてのリソースに対してラッパーを用意するのは面倒だよ
fainallyが有ったって邪魔になるわけでもないのに
最終的に使うかどうかは利用者が選べばよいことだし
C++ってそういう言語だろ
コメント1件

184
デフォルトの名無しさん[sage]   投稿日:2015/12/05 15:50:01  ID:9PUwCRa0.net(4)
>183
C++にはテンプレートがあるからリソースの型をテンプレート引数とするラッパーを作るのは
そんなに面倒なことじゃないと思う
あとC++でRAIIを徹底してればfainallyの必要性を感じたことはない
fainallyを書かなければいけない時点で危なっかしいコードだと思う

185
デフォルトの名無しさん[sage]   投稿日:2015/12/05 16:34:34  ID:+HxrBEdK.net(5)
むしろfinallyってデストラクタがない言語だから
必要なものなんじゃ…
どうしても必要ならデストラクタで任意のラムダ呼ぶ
ユーティリティクラス作れば同じこと出来るし

186
デフォルトの名無しさん[sage]   投稿日:2015/12/05 16:50:13  ID:+HxrBEdK.net(5)
98以前でもローカルクラス定義できるんだからすこし冗長なだけで同じだし

187
デフォルトの名無しさん[sage]   投稿日:2015/12/05 16:59:06  ID:NRX1k+Is.net(6)
例外発生はバグ、というプログラミングしかしたことないからよくは知らんが、
try {
 try {
  /*...*/
 } catch (std::badalloc()) {
  /*...*/
} catch (UserException e) {
  /*...*/
}
} catch (...) { // fainally節の代わり
 /*...*/
}
じゃあいかんの?実行時コストは知らん

188
デフォルトの名無しさん[sage]   投稿日:2015/12/05 17:00:08  ID:NRX1k+Is.net(6)
スマン
誤: } catch (std::badalloc()) {
正: } catch (std::badalloc e) {

189
デフォルトの名無しさん[sage]   投稿日:2015/12/05 17:32:52  ID:+HxrBEdK.net(5)
違う。そんぐらいググれ
コメント1件

190
デフォルトの名無しさん[sage]   投稿日:2015/12/05 17:37:26  ID:KdBqlpoa.net(2)
デストラクタの問題点は不可視なところだな
usingやfinallyは目に見えるから安心する

191
デフォルトの名無しさん[sage]   投稿日:2015/12/05 18:00:14  ID:NRX1k+Is.net(6)
>189
内側のtry〜catchから再throwするのを忘れたorz
内側のtry〜catchから再throwして外側ので再捕捉したらいいんじゃ…
コメント1件

192
デフォルトの名無しさん[sage]   投稿日:2015/12/05 18:22:16  ID:0v99S3Ys.net
例外をロジックとして使うなってばっちゃんが言ってた

193
デフォルトの名無しさん[sage]   投稿日:2015/12/05 19:38:41  ID:eGerJrSR.net(5)
>191
throwせずにreturnするパスが有ったらどうするんだよ
そういうのを防ぐためのfinallyやRAIIなのに
まったくちんぷんかんぷん
結局returnする前に手動で忘れないようにthrowすることを強制するんなら
goto文とか開放用ラムダ呼び出すのとかと替わらないだろ

194
デフォルトの名無しさん[sage]   投稿日:2015/12/05 20:44:27  ID:ZNw2R9x1.net
だから忘れる忘れないレベルをぶち込んでくるのは止めようやw
これをぶち込むから全ての議論が池沼レベルになってる
コメント1件

195
デフォルトの名無しさん[sage]   投稿日:2015/12/06 06:02:02  ID:JYyEEHci.net(2)
異常系で例外返す仕様のライブラリが失敗。

196
デフォルトの名無しさん[]   投稿日:2015/12/06 08:06:42  ID:XhferEg+.net(3)
>194
GCなんて池沼のために生まれたようなものだし・・・
NULLったりfreeったりすることすらまともに把握、指示しきれない

197
デフォルトの名無しさん[sage]   投稿日:2015/12/06 11:36:02  ID:G3VNQyn5.net(3)
c++のデストラクタって後処理に失敗しても
例外投げられないからウンコ
結果的にエラーを握り潰すゴミコードを量産する原因になってる

198
デフォルトの名無しさん[sage]   投稿日:2015/12/06 11:40:47  ID:zGnP2wpv.net
そのクラスが管理してる範囲で後処理の失敗って何が起こるの?

199
デフォルトの名無しさん[sage]   投稿日:2015/12/06 12:05:41  ID:kVHO13oj.net
どうしてもやりたいなら対処法はあるしなぁ。

200
デフォルトの名無しさん[sage]   投稿日:2015/12/06 12:23:19  ID:MkaxAbH2.net(2)
現実的な確率で発生して無視出来ないリスクが有る解放処理はデストラクタでやるべきじゃない
そういうリソースに対してデストラクタがやる事はプログラマに対しいて未解放のリソースを通知する事だけでよい
コメント1件

201
デフォルトの名無しさん[]   投稿日:2015/12/06 12:30:12  ID:XhferEg+.net(3)
具体的に何があるん???
クラス内で使っているリソースで解放に失敗(失敗し続ける)するって。

202
デフォルトの名無しさん[sage]   投稿日:2015/12/06 13:14:17  ID:lk97yytv.net
どっか他のオブジェクトと共有してるものを解放しようとして失敗するとか?
それはそもそもの設計に問題ありすぎだが。。
コメント1件

203
デフォルトの名無しさん[]   投稿日:2015/12/06 15:01:28  ID:XhferEg+.net(3)
>202
だよね。
否定しようとして無理やり現象を創りだそうとしているとしか・・・。
でもその無理やりつくった現象は、そもそも論理設計のミスが大前提だったりする。
論理設計のミスまで言われたらなんにも組めないわ。

204
デフォルトの名無しさん[sage]   投稿日:2015/12/06 15:42:32  ID:wxELMJDc.net(2)
>200
デストラクタの中で起きた例外については
try { } catch (...) { }で囲った上で、リカバリ処理(何とかしてリソース解法漏れをなくす)を行えばいいじゃない?

もし例外発生後に行うべき適切なリカバリ処理が書けない(存在しない)んだとすると、
もはやデストラクタ内に限った話ではなくなって、例外を発生させた時点で設計か実装にバグが居たとしか…

205
デフォルトの名無しさん[sage]   投稿日:2015/12/06 16:03:58  ID:5cQQ9Lrm.net(2)
バグ(リソースへのポインタやハンドルを壊しちゃったとか)以外で
リソース解放に失敗するケースなんて1つも思いつかない

206
◆QZaw55cn4c [sage]   投稿日:2015/12/06 16:19:39  ID:4bjdt2kC.net
fclose() にも失敗があるじゃないか?
コメント1件

207
デフォルトの名無しさん[sage]   投稿日:2015/12/06 16:54:30  ID:djRjUyAt.net
fflush() しとけばOK

208
デフォルトの名無しさん[sage]   投稿日:2015/12/06 16:59:21  ID:5cQQ9Lrm.net(2)
>206
fcloseの失敗はハンドルが正しい限りflush時のI/Oエラーの通知であって、その場合でもリソースは解放されるよ

209
デフォルトの名無しさん[sage]   投稿日:2015/12/06 17:35:51  ID:G3VNQyn5.net(3)
c++信者ってアホだなー
みんなこんなんなの?

http://cpplover.blogspot.jp/2011/01/fclose.html?m=1

210
デフォルトの名無しさん[sage]   投稿日:2015/12/06 17:44:16  ID:G3VNQyn5.net(3)
fcloseに失敗してファイルに正常に書き込みされなくてもシカトしてるんだよね?
それともerrnoとかチェックしちゃってるの?

211
デフォルトの名無しさん[sage]   投稿日:2015/12/06 19:05:12  ID:RyqEmv/A.net(3)
まあC++の例外を援護するつもりはないがそういう場合は
普通にフラッシュしろよ
そもそもC++が二重例外時にstd::terminate呼ぶのはGCのあるなしに
関係ないからスレ違いだお前ら。よそでやれ

212
デフォルトの名無しさん[]   投稿日:2015/12/06 19:24:21  ID:XJADMoL5.net(2)
GCというよりライブラリとの関係だな
.net framework libraryのいくつかのクラスは中で自分自身をロックするから
プログラマ側で参照が切れてもGCされない

213
デフォルトの名無しさん[]   投稿日:2015/12/06 19:25:02  ID:XJADMoL5.net(2)
今日一日なんでFormがGCされないのか調べてて大変な思いしたわ
コメント1件

214
デフォルトの名無しさん[]   投稿日:2015/12/06 19:31:56  ID:bkfT5adp.net
>213
よくそこまで調べたな。( ・∀・)つ旦 お茶ドゾー

215
デフォルトの名無しさん[sage]   投稿日:2015/12/06 19:37:02  ID:Gxx7TgqC.net
いまだにプログラマはアセンブリ言語を使えるべきだ派?

216
デフォルトの名無しさん[sage]   投稿日:2015/12/06 19:40:49  ID:JYyEEHci.net(2)
アセンブラ知ってると知らないとじゃスキルレベル全然違うからな。話にならないぐらいのレベル差。

217
デフォルトの名無しさん[sage]   投稿日:2015/12/06 20:22:00  ID:RyqEmv/A.net(3)
まあ実際Java屋とかってコンパイラやメモリ意識できない奴多いよね
以前2chで↓みたいなコードが勝手に最適化されると思って
StringBuilder使う奴は馬鹿!とか言い出す奴いて目眩したわ
String s;
for(int i = 0; i < strarray.length; ++i){ s += strarray[i]; }
コメント2件

218
デフォルトの名無しさん[sage]   投稿日:2015/12/06 20:58:14  ID:wxELMJDc.net(2)
>217
それはStringの+=の実装次第ではあんまり差が付かないケースなんじゃ…
(左辺と右辺が別の実体である(アドレスが違う)ケースでは多分右辺を左辺の末尾に1回コピーするだけという実装が有り得る
真に糞なのは
StringBuilder sb;
String s = "Hello";
sb.Append("[" + s + "]");
が遅いからStringBuilderは糞、と結論付けるニンゲンであってコードではない、
みたいな?
コメント1件

219
デフォルトの名無しさん[sage]   投稿日:2015/12/06 21:26:17  ID:IAFYzi6n.net(2)
>217みたいにループ中で一個づつくっつける場合は別にして
s = a + b + c + d; // このように、高々数個をくっつけてる場合は
Javaだと無駄にStringBufferが作られてダメと言うのが定説だったが
C#の場合は内部的にString#Concatに置き換えられて
それによって
StringBuilder b = 略
s = a.Append(b)中略.Append(d).ToString()
するより早い、という話題があってそれと勘違いしたのかもね
コメント2件

220
デフォルトの名無しさん[sage]   投稿日:2015/12/06 21:28:20  ID:IAFYzi6n.net(2)
いちおう訂正しとこw

StringBuilder sb = 略
s = sb.Append(a)中略.Append(d).ToString()

221
デフォルトの名無しさん[sage]   投稿日:2015/12/06 21:50:20  ID:MkaxAbH2.net(2)
そもそもその最適化は仕様なのか

222
デフォルトの名無しさん[sage]   投稿日:2015/12/06 22:27:08  ID:RyqEmv/A.net(3)
>218
??、これJavaだぞ。演算子オーバーロードなんて出来ないから
>219
違う違う。+の連結がStringじゃなくてStringBufferに
最適化されるらしいって話だけで、StringBulderって
必要ないでしょ?レガプロ?(笑)、って認識レベル

しかもそいつ一人ならまだしもスレに同じレベルの
認識の奴結構多かったよ。レベルの低さ舐めたらあかんで
コメント1件

223
デフォルトの名無しさん[]   投稿日:2015/12/07 01:50:02  ID:3Z+aJEnB.net
>222
実装云々でなんで演算子オーバーロードがでてくるんだ?

224
デフォルトの名無しさん[sage]   投稿日:2015/12/07 05:22:13  ID:QznWTKRS.net(2)
逆だろ?
C#との勘違いでないなら、その最適化されるJVM実装とやらを示さないと

225
デフォルトの名無しさん[sage]   投稿日:2015/12/07 07:11:57  ID:X5Y+ON7N.net
>219
全く逆の認識してないか?
classファイル解析したら分かるけど、ループ中の+=の方が問題で毎回newされるから遅い

s = a + b + c + d の方は一つしかStringBuilderのインスタンスは作られない

226
デフォルトの名無しさん[]   投稿日:2015/12/07 08:02:18  ID:nEG5/lEo.net(4)
こうやって、比較的プログラミングという行為を好きでいる・好きでやっている・興味を持っているという人ですらまともに言語仕様を理解出来ていない。
malloc、freeで管理、GCで管理だと、機構の複雑さは後者。
結局GCもその機構を正しく理解しないと参照が切れてない、参照が切れていても別のリソースが・・・と。
機構を正しく理解していることが前提なら、機構はシンプルなほうがいい。
その点を誤ったから
>プログラマをメモリ管理から開放する!
>といいつつ、メモリリーク問題の文献が大量にある。
>これすなわち、メモリリーク問題が全然解決していないということ。
>さらに、メモリ解放のタイミングの文献まで大量に生み出した。
>これすなわち、新たなるメモリ管理に関する問題を生み出したということ。
なんてことになったんだろうね

227
デフォルトの名無しさん[sage]   投稿日:2015/12/07 08:12:44  ID:EA/TwAsy.net
そもそもプログラマの大半にマネージリソース、アンマネージリソースとはなに?
って質問してまともに回答できる割合がどんなもんになるのか
始めたら終わらせる
これワンセットね
にしたほうがミスはなくなるかと
ファイル開いたら閉じる
メモリ確保したら解放する
通信接続したら切断する

228
デフォルトの名無しさん[]   投稿日:2015/12/07 09:22:45  ID:q5G1dKJA.net(2)
やっぱりARC最強だな

229
デフォルトの名無しさん[sage]   投稿日:2015/12/07 15:38:30  ID:6rSJBSiX.net
結局いつ開放されるか分からないってのが曲者で
使い終わったら確実にリソースを開放してほしいときは
別の仕組みが必要になってしまったってのが問題だろう
その別の仕組も、C++のデストラクタのようにクラスのメンバに関して
芋づる式に呼び出す仕組みがないから
C++のデストラクタがやっていることを手動で再現しなければならない始末

一方でC++のスマポなどの参照カウンタ方式は循環参照だけが問題だが
それ以外の問題が一切発生しない、デメリットは循環参照だけ
しかも循環参照が発生する場合は片方をweak_ptrにすれば良い
ということが分かりきっているし、循環参照が発生する箇所も
設計段階でわかる

循環参照に気を配れる知能が有るのであれば、参照カウンタ方式のほうがスマート
コメント1件

230
デフォルトの名無しさん[]   投稿日:2015/12/07 17:29:26  ID:nEG5/lEo.net(4)
>229
処理速度やタイミングがシビアな組み込みや科学技術計算系とかならいざしらず、
ソレ以外は、実際の解放のタイミング自体は問題にならんでしょ。(膨大なメモリの使用も別だけど)
問題は、使い終わったよーって明示しないで良い。という運用が結局、悪い結果をもたらしているという点。
メモリの管理をしっかり最後までやるクセのないプログラマは、
平然と参照が途切れている可能性のあるポイントで参照しに行こうとする。
結局は、そいつがバカだからに集約されてしまうんだけど、使い終わりの明示をしない文化がバカを生む土壌となっている
コメント1件

231
デフォルトの名無しさん[]   投稿日:2015/12/07 18:21:02  ID:q5G1dKJA.net(2)
そういう事になる原因ってさ、構造がぐちゃぐちゃでオブジェクト間も依存しまくって、
いつ解放していいのかわかんねえーというヘボいプログラミングなんだろうなと思う。
コメント1件

232
デフォルトの名無しさん[sage]   投稿日:2015/12/07 18:23:12  ID:tBfENkIS.net
と馬鹿なSEやPGはそう思うだろうなとも思う。

233
デフォルトの名無しさん[sage]   投稿日:2015/12/07 19:54:31  ID:GogXEvJk.net
ある意味メモリなんて一番扱いやすいリソースだからな。
メモリの管理すら適当なプログラマが、他のリソースを適切に扱える訳がないのに、GC前提の言語ではそちらのケアが言語側でやりづらくなってしまっている。

234
デフォルトの名無しさん[]   投稿日:2015/12/07 20:05:22  ID:W4QZalq7.net
健全でない言葉が含まれているため表示しません 内容を確認する
コメント1件

235
デフォルトの名無しさん[]   投稿日:2015/12/07 20:07:43  ID:nEG5/lEo.net(4)
>231
そう。そういう状態にしちゃう原因が、いい加減なメモリの管理で教育された結果にあるのではないか?ということで。

236
デフォルトの名無しさん[]   投稿日:2015/12/07 20:09:47  ID:nEG5/lEo.net(4)
>234
だれの名言かしらんが、

刺激のない人生に癒やしはない。

ならなんかしっくりくる。まぁ逆とっても同じ意味だからいいんだけど・・・。

237
デフォルトの名無しさん[sage]   投稿日:2015/12/07 20:16:31  ID:ZNsl6+sP.net
メモリ意識しないプログラマとかカスだろ。

238
デフォルトの名無しさん[sage]   投稿日:2015/12/07 20:42:25  ID:wP/KA6jo.net
JavaやC#ではリソースをプログラマが管理してはいけない
せっかくメモリ管理を透過的にしたのにリソース管理でコードをより複雑化させては意味がない
真っ当な教育を受けた少数のプログラマがSafeHandleを作成する
末端のプログラマはSafeHandleのファイナライザに全てを任せてメモリと同様にリソースを完全に透過的に扱うべきだ
コメント1件

239
デフォルトの名無しさん[sage]   投稿日:2015/12/07 23:25:36  ID:QznWTKRS.net(2)
>230
JavaのGCでサーバー応答が止まるなんてザラにある話だよ
それを聞いたことがないなら文系SEと同レベルだね

>238
管理放棄して開くだけ開いて計算資源を食い潰す玄人気取りプログラマ

240
デフォルトの名無しさん[sage]   投稿日:2015/12/08 00:48:22  ID:pyjW8EMu.net
full GCが頻繁に生じちゃうのは明らかに設計ミスやな
immutableな短命objectを使いまくるのだ。。
つかimmutableなオブジェクト使いまくるとGCないときつくね?

241
デフォルトの名無しさん[sage]   投稿日:2015/12/08 02:05:45  ID:H3TgUaFB.net
RAIIで事足りる
immutableかどうかとGCは無関係

242
デフォルトの名無しさん[sage]   投稿日:2015/12/08 02:21:53  ID:RVFMry3L.net(3)
むしろ短命なオブジェクトなんてスタックで十分だし
管理するならshared_ptrのが優れてる

243
デフォルトの名無しさん[]   投稿日:2015/12/08 03:41:28  ID:pU1qoPPC.net
ライブラリ、アプリ、ユーザの三者で考えないと
一部リソースはユーザがを閉じることができる。
そのときアプリの参照を消す仕組みがどのライブラリにもない
コメント1件

244
デフォルトの名無しさん[]   投稿日:2015/12/08 08:07:46  ID:rWJ9nJMw.net
>243
よくわからんが、それは階層的におかしいのでは?
ユーザーがアプリを通さずにリソースを閉じる事ができるって事?

245
デフォルトの名無しさん[sage]   投稿日:2015/12/08 12:16:07  ID:VV6tYNBF.net
Manager.Execute((res) => ...);

これが終着点
短命なリソースは全てこの形式で事足りし長命なリソースはファイナライザにでも任せればよい
ユーザーが管理しちゃ絶対にダメ

246
デフォルトの名無しさん[sage]   投稿日:2015/12/08 15:11:36  ID:DYNM3xm/.net
このスレでGCいらんて言ってる人たちは環境に恵まれてるんだなぁって思う
コメント1件

247
デフォルトの名無しさん[sage]   投稿日:2015/12/08 15:20:06  ID:Bkt0caBE.net
GC
タモリが昔宣伝してやつ?

248
デフォルトの名無しさん[sage]   投稿日:2015/12/08 15:28:54  ID:NMHe7TFl.net(4)
むしろGCなんて環境良くないと使えないだろ

249
デフォルトの名無しさん[sage]   投稿日:2015/12/08 16:16:30  ID:zjJIjn6V.net(2)
参照がなくなったタイミングで必ず開放してくれて
かつ
循環参照でも問題ない
パーフェクトなGCが有れば最高なわけだが
実際にはそんなGCは無い

となれば、通常であれば言語側は性質の異なる複数のGCを用意しておいて
使う側はシチュエーションに合わせて選べるようにしておくのが自然な発想
しかしそういう言語は殆ど無い、これが問題

といってもマークスイープ系GCが前提のC#やJavaのような言語に
RAIIの発想を持ち込もうとしても
C++のデストラクタのように自身のメンバのデストラクタを自動で芋づる式に呼び出す仕組みが
元々無いので、手動で芋づる式に解放関数を呼び出すコードを書かなければならなく
うまく行っていない
コメント2件

250
デフォルトの名無しさん[sage]   投稿日:2015/12/08 16:25:08  ID:RVFMry3L.net(3)
>246
JavaでPhantomReferenceも使ったこと無い人って恵まれてるんだなあって思う

>249
無いのでってもろにAutoCloseableとかあるやん
コメント1件

251
デフォルトの名無しさん[sage]   投稿日:2015/12/08 16:37:24  ID:zjJIjn6V.net(2)
>250
自分のクラスがファイルなんかのcloseを持つリソースをメンバに持っていたとする
そうすると、それらのメンバのリソースを明示的にcloseできるようにするために
自身もcloseを実装することになるだろう
それで、自身のcloseが呼ばれた時、勝手にメンバのcloseが呼ばれるか?
結局手動でメンバのcloseを呼び出しまわるコードを書かなければならない

C++のデストラクタならメンバのデストラクタが芋づる式に勝手に呼び出されるから
気にしなくて良い
コメント1件

252
デフォルトの名無しさん[sage]   投稿日:2015/12/08 17:08:50  ID:NMHe7TFl.net(4)
強参照、ソフト参照、弱参照、ファントム参照
この字面だけで糞言語って察せられるから凄い

253
デフォルトの名無しさん[sage]   投稿日:2015/12/08 19:22:21  ID:RKxPG6yJ.net(3)
Rustはどう?
明文化されたmoveセマンティクスと、オブジェクトの寿命と参照のチェッカを型システムに組み込んでるおかげで、
リソース管理の実行時コストをゼロにしつつ、メモリリークが発生しないプログラムが書ける。
shared_ptrに相当するRcもあるから、所有者を複数にしたい場合のコストもそれなりに抑えられる。
コメント1件

254
デフォルトの名無しさん[]   投稿日:2015/12/08 19:35:14  ID:Hrv9Cion.net
>253
すげえ難しいらしいじゃん
コメント1件

255
デフォルトの名無しさん[sage]   投稿日:2015/12/08 19:52:40  ID:NMHe7TFl.net(4)
rustの清貧さは好みだけどまだ触った事ないな
同期処理を省略するためかshared_ptr相当がタスク間跨げないらしいけど
そこら辺の使い勝手ってどうなんだろう
コメント1件

256
デフォルトの名無しさん[sage]   投稿日:2015/12/08 21:00:06  ID:RKxPG6yJ.net(3)
>254 難しいのは難しいが、低レベルの世界に相応な難易度であって、理不尽さはあまり無いと思う。
自分が遭遇した理不尽というか不便は、トレイト(型クラスみたいなの)を戻り値にした、ジェネリックな関数の型注釈の煩雑さで、
そのworkaroundが、その関数の返り値専用の型を定義する、ってのがカルチャーショックだった。
https://doc.rust-lang.org/std/iter/trait.Iterator.html
↑はIteratorトレイト(Listインターフェイスみたいなもの)のドキュメントだけど、mapとかfoldとかよくある高階関数の戻り値が、それ専用の型(MapとかFold)になってる。
だから、よくある関数型言語のイメージで、何か高階関数を利用したアダプタ関数を試しに定義してみよう!ってやると、
型注釈のエラー、ライフタイムのエラー等が一辺に出てきてわけが分からなくなる。

その関数の戻り値専用の型、なんて贅沢に見えるけど、返り値のサイズを見る限り、余計なデータで膨れているわけでもなかった。
Cでstruct wrap_int { int c; };とやったときにsizeof(wrap_int)がsizeof(int)と等しいけど、それと同じことをやっていた。
型情報なんてコンパイル時に全部消えちゃうから、実行コストも無いんじゃないかと今では思う。

メモリ/リソースの所有権を意識してコードを書くこと、が身について面白いよ。
ヒープを贅沢に使ってコピーしまくりなコードを書くと汚いし遅いしなんで、ちょっとダイエットする気分も出てくる。

257
デフォルトの名無しさん[sage]   投稿日:2015/12/08 22:39:35  ID:RVFMry3L.net(3)
>251
C++もヒープ相手は自分で呼ぶので、実装は必要だよ
Javaでもメンバの特定メソッド呼び出しはやろうと思えばできる
現実に横断的な呼び出しをやる場合はある

結局要求される物と実装の問題

258
デフォルトの名無しさん[sage]   投稿日:2015/12/08 22:59:22  ID:RKxPG6yJ.net(3)
>255 shared_ptrと恒等なものは無いけど、ポインタ的に使える型がBox, Rc, Cell(あるいはRefCell)とあって、
Boxはヒープ領域であること、Rcは複数の所有者がいる(つまり所有者全員が死ぬまでは生きている)こと、Cellは複数の書き込みが作れること、
とか機能とコストが別れているから、これらを組み合わせて使う。

で、Thread Safetyを実現させる機構は上記には無いので、Atomicityを導入させるRcの類似形であるArcと、
書き込みもしたいならMutexっていう型も合わせて使う。
すると、例えば整数のベクトルをスレッド間で共有したい、とかになるとArc<Mutex<Vec<i32>>>という目が滑るような型表記をすることになる。
あんま詳しくないので、ケース毎にもっと簡単なやり方があるとは思うんだけどね。
コメント1件

259
デフォルトの名無しさん[sage]   投稿日:2015/12/08 23:55:28  ID:NMHe7TFl.net(4)
>258
ああ、Arcってのが別にいるのね。納得
個人的にもう一点気になる所があるから聞いてしまう
BoxやDropを使ってるとコピー禁止になるらしいけど
これ面倒な場合ない?
最初はコピー可能な型としてガンガンコピーしてたけど
途中から終了処理を書きたくなったらコピーしてる箇所
全部直すって事?

ちなみにググってたらRWArcっての見つけたんだけど
これ読み書き可能なArcなんじゃね
コメント1件

260
デフォルトの名無しさん[sage]   投稿日:2015/12/09 00:46:02  ID:WVnNYSfg.net
>249
javaは世代別管理でGCの種類は色々選べるはずでは
コメント1件

261
デフォルトの名無しさん[]   投稿日:2015/12/09 01:14:15  ID:wAGGTtTq.net
>260
起動時に切り替えられるだけであって
オブジェクトごとには切り替えられないのでは

262
デフォルトの名無しさん[sage]   投稿日:2015/12/09 01:50:08  ID:x/ryIvcR.net
>259 コピーしまくっているような変数の型をTからBox<T>に変えた場合、確かに面倒なことになる。
けど、基本的に単純な代入(let x = y)はコピーじゃなくてmoveになるし、
Box<T>の値をコピーしてBox<T>の値を生成するっていうのは、同じヒープ領域を指すポインタを作るんじゃなく、
新しいヒープ領域を確保して中身をコピーし、そのポインタを返すという意味なんで、
変数の型を後でTをBox<T>に変える、という場面はあまり無い(少なくとも自分は学んでいる最中にそういうことをしたくなったことがない)

値をコピーする場面では、元の変数の型がBox<T>であってもTであっても、参照型&Tを受け取ってTを生成、ということをするのが定石。
&Tはほぼ無制限に安全に作ることができるし、安全じゃない可能性があったらコンパイルが通らない。
で、コピーした型Tの値は呼び出し元がBoxに包んでヒープ領域に置いたりするのが定石

Dropも別にコピーを禁止することは無いよ。後からつけたらエラーまみれ、ということにはならない。

あと、自作じゃない型に自作じゃないトレイト(インターフェイスみたいなもの)をつけることができないので、
例えば標準ライブラリのFileやTcpStreamはCopyできるようには決してできない。メモリ以外の資源管理も安全だよ。

263
デフォルトの名無しさん[]   投稿日:2015/12/12 10:36:13  ID:mXWFWn5f.net
freeし忘れるとか、そんな超ウルトラ素人ミスを大前提に議論するのは間違いだよなw
freeしきれないとかwwww
コメント1件

264
デフォルトの名無しさん[]   投稿日:2015/12/12 11:52:29  ID:v/VbuB+R.net
>263
規模が大きくなれば管理が難しくなるのは普通のことだよ。
ライフサイクルはオブジェクトごとに異なるものだし、
人間に頼らずにGCにメモリ管理を任せるっていうのは良いやり方だよ。
コメント1件

265
デフォルトの名無しさん[sage]   投稿日:2015/12/12 12:05:07  ID:yfUf7LLZ.net
shared_ptrって参照カウント式のGCじゃないの?
コメント2件

266
デフォルトの名無しさん[sage]   投稿日:2015/12/12 12:44:09  ID:7G0ybzbE.net
循環を綺麗に扱えるなら参照カウントの方が良いと思うけど
VB6は循環参照の扱いどうやってるんだろう

267
デフォルトの名無しさん[sage]   投稿日:2015/12/12 14:25:51  ID:npRd3MLZ.net
>265
RAIIじゃろ

268
デフォルトの名無しさん[sage]   投稿日:2015/12/12 15:20:38  ID:tVgJgcBS.net
>265
GCの一種だけど、文脈的にはプログラマが
管理が非局所的で明確な型宣言もなしに使えるのをGCと言ってるわけで
議論で揚げ足にしかならない野暮な突っ込みはやめようぜ

269
名無しさん@そうだ選挙に行こう[]   投稿日:2015/12/14 08:16:09  ID:hn3965Zz.net(4)
>264
いや、下手って一言で片付けられるよ。
よっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっぽど、出ない限り

270
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 08:38:44  ID:sXTPVO5Q.net(3)
片付ける奴が馬鹿なのだ。素人ほど簡単だと言いたがり、上級者ほど簡単ではないとはっきり言うものだ。
どの分野でもな。
コメント1件

271
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 09:09:02  ID:lNUL9lX8.net(2)
freeとか言ってる奴はC++使えよ。いつまでC使ってんだ。

272
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 09:20:53  ID:MauTQhQ/.net
>270
東大生が人に教えるとき、何がわからないのかわからないというのがわからない。
上級者になればなるほど自分がやってることなんて簡単に見えてくる
コメント1件

273
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 09:35:23  ID:sXTPVO5Q.net(3)
>272
何が分らないか分らない、つまり東大生も生徒がどういう思考をしてるか分析できず分らないと言ってるのだ。
低学歴ほど、分らないのはおまえが馬鹿だからと簡単に片付けるものだ。

274
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 09:37:05  ID:eBJzgHzn.net(4)
それ中級者
あと、東大生は教えるの上手いのもいるから想像で話すな馬鹿

275
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 09:41:37  ID:sXTPVO5Q.net(3)
このようにおまえのようなコンテキストすらまともに読めないPGは五万といる。
スレッドがデッドロックしてメモリを開放できないなんてよくあることだ。
コメント2件

276
名無しさん@そうだ選挙に行こう[]   投稿日:2015/12/14 10:59:16  ID:hn3965Zz.net(4)
>275
。。。。。完全な設計ミスじゃん

277
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 11:15:19  ID:eBJzgHzn.net(4)
>275
俺は272に向けてたんだが
そりゃコンテキスト読めてないように見えるよなw

278
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 11:40:27  ID:ETDpPCfc.net(2)
スレッドがデッドロックしたらメモリリークどころじゃないじゃないかwww

279
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 14:48:51  ID:MOnxQz3f.net
スレッドがデッドロックしちゃってメモリ解放できない(泣)
っていうPGが五万といるのかよw

280
名無しさん@そうだ選挙に行こう[]   投稿日:2015/12/14 15:51:19  ID:hn3965Zz.net(4)
まぁfreeやdeleteやnullやらすらできないPGに、「僕はそんなこと管理しきれる脳みそ持ってない!」って言われたらソレは真実なんだろうけど・・・。
そんな脳みそPGに「もっと複雑な業務使用」を理解できるとは思えないんだ。

そんなPGにプログラミングの場を与えるのが間違い。


281
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 15:58:21  ID:2JSVZtRY.net
そもそも実務でスレッド使うPGなんてゴマンもいない

282
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 17:06:58  ID:eBJzgHzn.net(4)
Javaのプロジェクトだとほぼ使ってるけどな隠蔽してるだけで
そのせいで共有リソース壊したり、逆に個人情報の領域が共有されたりして、とんでもないインシデントが発生する
そんな奴等にメモリ管理なんて任せられんし、共有リソースも触らせたくないから
更に隠蔽したフレームワークもどきが出来上がる
コメント1件

283
名無しさん@そうだ選挙に行こう[]   投稿日:2015/12/14 17:59:33  ID:hn3965Zz.net(4)
>282
勝手に使うな。勝手にトリッキーコードにすんな。
素直に、設計書通りに作れ。
勝手なことやって勝手に自爆してるだけじゃねーか。
コメント1件

284
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 18:15:27  ID:Z4FycFda.net
javaってc++のconst参照に対応するものが無いのに、素人みたいなプログラマを大量にかき集めているのが怖すぎる。

285
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 18:28:13  ID:eBJzgHzn.net(4)
>283
理解してないのに無理してレスしなくていいから

286
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 18:42:08  ID:CJqGCki1.net
C#はマルチスレッド使いまくりだけど事故の話はあまり聞かないな
マイクロソフトが優秀なのか低品質プログラマがいないのか

287
名無しさん@そうだ選挙に行こう[sage]   投稿日:2015/12/14 19:01:59  ID:2+GDL4RD.net
JAVA自体がDQN

288
uy ◆Qawu9.2l1E []   投稿日:2015/12/14 20:57:26  ID:J5PYIleC.net
Freeし忘れ

↑これ。


ソースコード書いてる人間の注意力次第でバグが入るなら
言語も設計も間違ってるよ

289
デフォルトの名無しさん[sage]   投稿日:2015/12/14 21:54:10  ID:ETDpPCfc.net(2)
動的型言語

これ

コード書いている人間の注意力次第でtypoするだけで
実行するまでわからないバグが入るなら
言語も設計も間違ってるよ

290
デフォルトの名無しさん[sage]   投稿日:2015/12/14 22:23:00  ID:lNUL9lX8.net(2)
C#でcatchやfinally書くの嫌すぎる
C++に戻りたい
コメント2件

291
デフォルトの名無しさん[sage]   投稿日:2015/12/14 22:43:08  ID:bhzmg0NL.net
>290
おかえり

292
デフォルトの名無しさん[sage]   投稿日:2015/12/15 06:39:51  ID:gQhFMQgY.net
(ヽ´ω`)眠い

293
デフォルトの名無しさん[sage]   投稿日:2015/12/16 08:46:15  ID:fgV80IeN.net
>290
C++/CLR「こっちこいよ」

294
デフォルトの名無しさん[]   投稿日:2015/12/17 17:18:40  ID:Szn4FINI.net
COMのVariantとかJSとかリークしまくりだし

295
デフォルトの名無しさん[sage]   投稿日:2015/12/17 23:16:36  ID:kltDf5Nv.net
そういやVBScriptって参照カウンタ以外のGC積んでんのあれ
必要には見えないんだけど

296
デフォルトの名無しさん[]   投稿日:2015/12/18 23:17:49  ID:b1Otx84Y.net

297
デフォルトの名無しさん[sage]   投稿日:2015/12/19 07:07:37  ID:qL4RiVer.net(2)
マカーってどんだけアホなの?

298
デフォルトの名無しさん[]   投稿日:2015/12/19 12:49:09  ID:EW8XrhCB.net
解放処理
すら、まともにお前ら管理できねーのかよ・・・・・・・・・・・・・・・・。そらオレが完璧な仕様書渡してもバグってるわけだ
コメント1件

299
デフォルトの名無しさん[sage]   投稿日:2015/12/19 13:38:07  ID:i3zp3GbO.net
開放処理を手動でやれって書いてある仕様書かw
御免こうむるwwwww

300
デフォルトの名無しさん[]   投稿日:2015/12/19 14:42:49  ID:iG82T79N.net
ガベコレのあるPyObjectをラップするクラスをガベコレのあるDで書いたら
wxPythonで書いたクラスをDから使ったとき意味不明なタイミングで落ちるようになった
二重に管理するとだめなんかな

301
デフォルトの名無しさん[]   投稿日:2015/12/19 15:57:38  ID:qL4RiVer.net(2)
>298
プププ 馬鹿だこいつw

302
デフォルトの名無しさん[sage]   投稿日:2015/12/20 08:46:23  ID:gr0U1KS4.net
ガベージコレクションはたしかに便利だ
だからといって「本来はてめぇのケツはてめぇで拭け=自分で解放すること」を忘れてはならない

そんだけ

303
デフォルトの名無しさん[sage]   投稿日:2015/12/20 11:55:11  ID:HXRBhwTH.net(3)
C#ではSafeHandleだけ作って後は放置
usingも使わないってのがトレンドだけどね
自分で解放とかバカバカしい
面倒はランタイムに見させて開発者はドメイン設計に集中するって目的を見失うな
コメント2件

304
デフォルトの名無しさん[sage]   投稿日:2015/12/20 12:13:23  ID:ofrSOHxv.net(7)
>303
オブジェクトの開放を他と独立にやれるケースばかりならそう言えるかもしれんが
オブジェクトAとBがリソースCに依存しているケースでA、Bの開放の少なくとも片方をGCに任せる場合、
リソースCの参照カウンタなりをつかった防護策をプログラマーが書かねばならない
しかしそんな嫌ったらしい雑用を増やすぐらいなら
 Cオープン
 A生成
 B生成
 A, B使用
 B開放
 A開放
 Cクローズ
でええやん?

さらにダンプファイルとかからの障害解析において、オブジェクトが生きているべきなのか死んでいるべきなのか決まっていないとか、
アドレスがはっきりしないとか言う状況は地獄
コメント2件

305
デフォルトの名無しさん[sage]   投稿日:2015/12/20 12:21:54  ID:ofrSOHxv.net(7)
つかこの世はうつろうもののであって、物理的ハードウェアでプログラムを実行する限り、
計算モデルは明らかに状態遷移ベース(チューリングマシン)の方に分がある
GCとかチューリングマシンで無理矢理関数型プログラミングを行うためのつなぎの技術、
いわば邪道
どんだけ蛇が出てくるか、GCの方がかえってわからん

306
デフォルトの名無しさん[sage]   投稿日:2015/12/20 13:48:14  ID:HXRBhwTH.net(3)
>304
設計が悪い
使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
知らなきゃ困るような設計にしたのが間違いだね
コメント2件

307
デフォルトの名無しさん[sage]   投稿日:2015/12/20 13:52:55  ID:8RLYRFXT.net
メモリ空間は無限であるべき
使い終わったメモリの断片化なにそれ?
仮想メモリを管理するのはCPUの責任だろ

308
デフォルトの名無しさん[sage]   投稿日:2015/12/20 14:03:49  ID:ofrSOHxv.net(7)
>306
>304の例で、さらにCを上書き更新したいオブジェクトDがいたらどうすんの?
GCがA、B両方開放してくれるまでDは期限不定で待たされるけどそれが>306的に良い設計なの?

つまり、ハードウェアリソースの有限性を考慮する限り
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
が常に成立はしないという話
コメント5件

309
デフォルトの名無しさん[sage]   投稿日:2015/12/20 14:28:20  ID:i39XsMQ2.net(5)
>308
そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ?
意見を否定するためだけの極端な反例(この場合は例にすらなっていないが)を引き合いに出すのは不毛だよ
コメント1件

310
デフォルトの名無しさん[sage]   投稿日:2015/12/20 14:35:53  ID:xl2QwS3M.net
>303
いい加減だなぁw

311
デフォルトの名無しさん[sage]   投稿日:2015/12/20 14:36:58  ID:ofrSOHxv.net(7)
>309
>そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ?
極論なもんカヨ;
例: 表示デバイスの数>表示したいスレッドの数
というのはざらにある

で、>308のオブジェクトDのケースはどう解決すんのさ…
GCが「いつ開放してくれるかわからない」ブツである以上解消しない問題だとおもうんだけど
(A、BにCのための明示的closeメソッドを付けるぐらいならGCに頼らずに順序管理するわ;
コメント1件

312
デフォルトの名無しさん[sage]   投稿日:2015/12/20 14:42:20  ID:ofrSOHxv.net(7)
解決策の一つはActive ObjectパターンでリソースCの管理を1スレッドXにやらせて
Cに対する要求を全部Xのキューにシリアル化して入れさせるというのがあるが、それはそれで
リソースCを使う全てのオブジェクトがスレッドXに依存するから、Xの開放コードが面倒なことになりかねない
かつ、シリアル化はマルチコア時代のせっかくの並列実行性能を殺してしまう

GCに合わせて生きることは、神仙にでもならねば到底かなわぬ…

313
デフォルトの名無しさん[sage]   投稿日:2015/12/20 14:44:35  ID:ZDEpjFBd.net(3)
つくづく、ARC最強だな。

314
デフォルトの名無しさん[sage]   投稿日:2015/12/20 14:46:27  ID:i39XsMQ2.net(5)
>311
その例じゃ308の状況にならないよ
どんなコード書いてんだよw
コメント1件

315
デフォルトの名無しさん[sage]   投稿日:2015/12/20 14:48:11  ID:ofrSOHxv.net(7)
>314
>その例じゃ308の状況にならないよ
なんで?ビデオメモリに2スレッドから同時に書いて無事に済むと思ってるの…;
コメント1件

316
デフォルトの名無しさん[sage]   投稿日:2015/12/20 14:51:52  ID:i39XsMQ2.net(5)
だから同時に書く設計が悪いんだって
気合入れて設計を見直してみろ
そんな必要はないってわかるから
コメント1件

317
デフォルトの名無しさん[sage]   投稿日:2015/12/20 14:55:30  ID:ofrSOHxv.net(7)
ていうか>316の言っていることはますます矛盾で、
>同時に書く設計が悪い
>そんな必要はないってわかる
というのは明白に「書き込みの順序を設計できる」ということを言っていて、
それはその通り(チューリングマシンの計算モデルに合致する)ので別段漏れの立場と対立するものではなく、
かつ気合を入れて設計すれば順序で全て解決する(GCは不要である)という言明でもある

318
デフォルトの名無しさん[sage]   投稿日:2015/12/20 15:17:45  ID:14eB8c4R.net
>315
もはやGCがどう関係するのかわからない
コメント2件

319
デフォルトの名無しさん[sage]   投稿日:2015/12/20 15:20:28  ID:i39XsMQ2.net(5)
>318
彼は敵対意見に反論する材料が欲しいというだけで変な例をでっち上げて出してしまったんだ
本人も今頃困ってるんじゃないかな
コメント1件

320
デフォルトの名無しさん[sage]   投稿日:2015/12/20 17:05:42  ID:6vo8OCaj.net(3)
>319
>308を変な例変な例というばかりでGCを用いた正しい解決方法が一向に示されない件について:
繰り返しになるが、>308のオブジェクトDのケースはどう解決すんのさ…
たとえ変でも反例は反例だし
>308のリソースCがファイルなのだとしたら、病的な反例というほど例外的想定でもない

読み書き順序の設計の必要性(破壊的代入前提のプログラミング)を口にしつつ
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない (>306)
と言い切ることはできないとかそういう話

で、現実のハードウェアは破壊的代入前提のブツばかりであるという、(>306)

>318
ウィンドウシステムでの描画は一般に裏VRAMに描いてハードウェアでBitBlt転送するが
裏VRAMに書く際のデバイスコンテキストが複数使えるが数に限りがある場合…
とか細かい話をしても通じないようならリソースCをファイルと考えてくんな

321
デフォルトの名無しさん[sage]   投稿日:2015/12/20 17:12:24  ID:6vo8OCaj.net(3)
プチ訂正
誤: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、(>306)
正: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、(>308)

322
デフォルトの名無しさん[sage]   投稿日:2015/12/20 17:19:25  ID:HXRBhwTH.net(3)
読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
書き込みたいから読み込み終わるの待ってますってリソースの無駄だろ
コメント1件

323
デフォルトの名無しさん[sage]   投稿日:2015/12/20 17:21:31  ID:ZDEpjFBd.net(3)
なんか参照カウントの話とマルチスレッドの話がごっちゃになってね?
コメント1件

324
デフォルトの名無しさん[sage]   投稿日:2015/12/20 17:33:49  ID:6vo8OCaj.net(3)
>322
>読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
破壊的代入の世界ではそいつは常に可能とは限らない

>308の例で、リソースCがファイルXなのだとしたら、オブジェクトDが上書きすべきもあくまでファイルXでないといけない。
つまりリソース分離の余地など無い
(正確には、無理矢理ファイルA、BはファイルX、DはファイルYに分ける設計もありえるが、XとYに対する変更をいつどのように統合するかという超難題が生じる

この手の混乱は、A、BがアクセスするリソースCの開放タイミングの決定をGCに任せてサボったがために生じるのである
コメント1件

325
デフォルトの名無しさん[sage]   投稿日:2015/12/20 18:10:09  ID:ZDEpjFBd.net(3)
おいおい、バージョン管理のマージの話にまで拡張したら収集つかなくなるぞw

326
デフォルトの名無しさん[sage]   投稿日:2015/12/20 19:32:49  ID:i39XsMQ2.net(5)
>324
ファイルの分割は必ずしも必要ではないし更新モデルから読み取りモデルへの同期も必要ないよ

327
デフォルトの名無しさん[sage]   投稿日:2015/12/20 19:44:06  ID:9YX+2XWA.net
>323 (Rust信者で)すまんな。
http://smallcultfollowing.com/babysteps/blog/2015/12/18/rayon-data-parallel...#data-race-freedom
マルチスレッドで起きるデータ競合といった問題も、シングルスレッドで起きうるdangling pointerなどの問題も、
どっちも所有権を持つオブジェクトが無闇にいたり、変な参照関係があるから起きるんじゃないか?って言う人がおる。
根っこが同じ、あるいは近しい問題なんで、横滑りに見えても堪忍な。

328
デフォルトの名無しさん[sage]   投稿日:2015/12/20 19:49:46  ID:kaqci566.net
メモリ管理もできないんだから
データの依存関係とか関係ねえ〜〜〜〜〜〜〜〜〜〜〜〜
でおわりでは

329
デフォルトの名無しさん[sage]   投稿日:2015/12/21 05:26:25  ID:ejqZ3DMD.net(26)
GoogleChrome動作中のタスクマネージャーのイメージ名にsvchost.exeが見当たらない
GoogleChromeでは、svchost.exeを使用せずに、chrome.exe自身で制御しているらしい
Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36 Width/1360px/1920px

330
デフォルトの名無しさん[sage]   投稿日:2015/12/21 05:32:28  ID:ejqZ3DMD.net(26)
その理由・・・GCは失敗。メモリは自分で管理せよ!
GCは失敗。メモリは自分で管理せよ! その2

331
デフォルトの名無しさん[sage]   投稿日:2015/12/21 05:35:31  ID:ejqZ3DMD.net(26)
メインメモリに対するGC・・・MGC
HDDならストレージGC・・・SGC

332
デフォルトの名無しさん[sage]   投稿日:2015/12/21 05:38:11  ID:ejqZ3DMD.net(26)
GoogleChromeかsvchost.exeを使わなくなった理由・・・ページメモリGC制御が遅過ぎでお粗末だからか?

333
デフォルトの名無しさん[sage]   投稿日:2015/12/21 05:42:27  ID:ejqZ3DMD.net(26)
GoogleChrome動作中のタスクマネージャーのイメージ名にsvchost.exeが見当たらない
GoogleChromeでは、svchost.exeを使用せずに、chrome.exe自身で制御しているらしい
Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36 Width/1360px/1920px

334
デフォルトの名無しさん[sage]   投稿日:2015/12/21 05:45:15  ID:ejqZ3DMD.net(26)
「Svchost Process Analyzer」
svchost.exeのプロセスの中身が何かを調べて表示するフリーソフト
http://gigazine.net/news/20131114-svchost-process-analyzer/

335
デフォルトの名無しさん[sage]   投稿日:2015/12/21 05:51:39  ID:ejqZ3DMD.net(26)
そろそろsvchost.exeを使うソフトは使用禁止なのかも?

336
デフォルトの名無しさん[sage]   投稿日:2015/12/21 06:11:17  ID:ejqZ3DMD.net(26)
svchost.exeを使わないことでGoogleChromeは確実に応答性能が速くなっている
・・・動画マルチ再生でクラッシュしたFirefoxは見習うべき
コメント1件

337
デフォルトの名無しさん[sage]   投稿日:2015/12/21 06:17:26  ID:ejqZ3DMD.net(26)

338
デフォルトの名無しさん[sage]   投稿日:2015/12/21 06:40:32  ID:ejqZ3DMD.net(26)

339
デフォルトの名無しさん[sage]   投稿日:2015/12/21 06:42:41  ID:ejqZ3DMD.net(26)

340
デフォルトの名無しさん[sage]   投稿日:2015/12/21 06:43:24  ID:ejqZ3DMD.net(26)

341
デフォルトの名無しさん[sage]   投稿日:2015/12/21 07:08:24  ID:ejqZ3DMD.net(26)

342
デフォルトの名無しさん[sage]   投稿日:2015/12/21 09:26:05  ID:ejqZ3DMD.net(26)

343
デフォルトの名無しさん[sage]   投稿日:2015/12/21 09:41:02  ID:ejqZ3DMD.net(26)

344
デフォルトの名無しさん[sage]   投稿日:2015/12/21 09:44:40  ID:ejqZ3DMD.net(26)
京がお仕置き候補に???
http://gigazine.net/news/20130618-fastest-supercomputers/

◆1位:Tianhe-2(天河二号)、中国人民解放軍国防科学技術大学
http://i.gzn.jp/img/2013/06/18/fastest-supercomputers/01_m.jp...
IntelのIvy Bridge(12コア・2.2GHz)とXeon Phi(57コア・1.1GHz)を採用し、
コア数は312万、計算速度は33.9ペタフロップス、消費電力は17.8MW

◆2位:Titan、アメリカのオークリッジ国立研究所
http://i.gzn.jp/img/2013/06/18/fastest-supercomputers/02_tita...
AMD Opteron 6274(16コア・2.2GHz)とNvidia Kepler(14コア・0.732GHz)を採用し、
コア数は56万640、計算速度は17.6ペタフロップス、消費電力は8.3MW

◆3位:Sequoia、アメリカのローレンス・リバモア国立研究所
http://i.gzn.jp/img/2013/06/18/fastest-supercomputers/03_8716...
IBM BlueGene/Qを採用し、中のプロセッサーはPower BQC(16コア・1.60GHz)、
コア数は157万2864、計算速度は17.2ペタフロップス、消費電力は7.9MW

◆4位:スーパーコンピュータ京、独立行政法人理化学研究所 計算科学研究機構(AICS)
http://i.gzn.jp/img/2013/06/18/fastest-supercomputers/04_01_m...
富士通 SPARC64 VIIIfx(8コア・2.0GHz)を採用し、コア数は70万5204、
計算速度は10.5ペタフロップス、消費電力は12.7MW

◆5位:Mira、アメリカのアルゴンヌ国立研究所のエネルギー部門
http://i.gzn.jp/img/2013/06/18/fastest-supercomputers/05_3029...
BM BlueGene/Qを採用し、中のプロセッサーはPower BQC(16コア・1.60GHz)、
コア数は78万6432、計算速度は8.6ペタフロップス、消費電力は3.95MW
コメント1件

345
デフォルトの名無しさん[sage]   投稿日:2015/12/21 09:50:17  ID:ejqZ3DMD.net(26)
気づかないかISOは中国のためにある
http://www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1742-a...

346
デフォルトの名無しさん[sage]   投稿日:2015/12/21 10:45:57  ID:1HvlxK+M.net(2)
>344
蓮舫さんに次の選挙は次点で良いですよねって言ってきて

347
デフォルトの名無しさん[sage]   投稿日:2015/12/21 11:12:03  ID:1HvlxK+M.net(2)
>336
ほんそれ

348
デフォルトの名無しさん[sage]   投稿日:2015/12/21 12:31:40  ID:ejqZ3DMD.net(26)

349
デフォルトの名無しさん[sage]   投稿日:2015/12/21 12:34:04  ID:ejqZ3DMD.net(26)

350
デフォルトの名無しさん[sage]   投稿日:2015/12/21 12:36:38  ID:x6st9rMu.net
ただしChromeはプロセスが一杯できるから
タスクマネージャ覗いた時に気持ち悪い

351
デフォルトの名無しさん[sage]   投稿日:2015/12/21 16:06:45  ID:ejqZ3DMD.net(26)

352
デフォルトの名無しさん[sage]   投稿日:2015/12/21 16:21:26  ID:ejqZ3DMD.net(26)

353
デフォルトの名無しさん[sage]   投稿日:2015/12/21 16:33:49  ID:ejqZ3DMD.net(26)

354
デフォルトの名無しさん[sage]   投稿日:2015/12/21 16:35:11  ID:ejqZ3DMD.net(26)
diginnos stickpc_02
http://www.youtube.com/watch?v=OPt0OGNQhnU&;list=RDOPt0OGNQhnU

355
デフォルトの名無しさん[sage]   投稿日:2015/12/21 18:37:51  ID:ejqZ3DMD.net(26)

356
デフォルトの名無しさん[sage]   投稿日:2015/12/21 18:38:29  ID:ejqZ3DMD.net(26)

357
デフォルトの名無しさん[sage]   投稿日:2015/12/21 18:43:07  ID:ejqZ3DMD.net(26)
Chromeの調子が良い件について・・・TCL 4K Demo: Ultra-Running Beauty
http://aurorawave.atspace.tv/?sop:v/Gg54Miwa8K4!RDHi_WWhih4n4 http://i1.ytimg.com/vi/Gg54Miwa8K4/mqdefault.jpg #AuroraWaveTV

358
デフォルトの名無しさん[]   投稿日:2016/01/10 12:45:59  ID:LOFSek54.net(3)
723 : 名無しさん@お腹いっぱい。 2016/01/10(日) 12:24:00.06 ID:rlcuxF0A0
Vivaldiの起動が遅いのは
タブのサムネイルに関係しているかもしれない
Blinkは負荷分散のため?かHDDアクセスも遅いらしい
ローカルストレージ関係がとても遅いからだ
724 : 名無しさん@お腹いっぱい。 2016/01/10(日) 12:31:29.50 ID:rlcuxF0A0
タブサムネイルを
ローカルストレージで保存するのは止めたほうがいい

タブサムネイルは直接アクセスする事
fopen();ランダム書込:fclose();ランダム読込:fopen();
読取だけならオーバーヘッドを避けるためfopen();しない
725 : 名無しさん@お腹いっぱい。 2016/01/10(日) 12:33:41.35 ID:rlcuxF0A0
命題・・・Vivaldiは遅い起動を早期解消せよ!
726 : 名無しさん@お腹いっぱい。 2016/01/10(日) 12:37:50.17 ID:rlcuxF0A0
ランダム書込用HDDスペースを作る 個数*固定サイズ 
1トランザクション 個数1024個、固定サイズ256kバイト 
727 : 名無しさん@お腹いっぱい。 2016/01/10(日) 12:40:34.65 ID:rlcuxF0A0
そしたら、ランダム読み書きでfopen()すればいい
オーバーヘッドを避けるためfopen();は終了のときだけ
オーバーヘッド無いだけで1000倍ほど速くなるケースも
728 : 名無しさん@お腹いっぱい。 2016/01/10(日) 12:44:26.42 ID:rlcuxF0A0
オーバーヘッドはドコにあるのか?
それはWindowsOSのフォルダ構造検索にある
フォルダ構造検索回数を省けば速くなるのだ

359
デフォルトの名無しさん[]   投稿日:2016/01/10 12:47:28  ID:LOFSek54.net(3)
Vivaldiの起動が遅いのは
タブのサムネイルに関係しているかもしれない
Blinkは負荷分散のため?かHDDアクセスも遅いらしい
ローカルストレージ関係がとても遅いからだ
タブサムネイルを
ローカルストレージで保存するのは止めたほうがいい
タブサムネイルは直接アクセスする事
fopen();ランダム書込:fclose();ランダム読込:fopen();
読取だけならオーバーヘッドを避けるためfopen();しない
命題・・・Vivaldiは遅い起動を早期解消せよ!
ランダム書込用HDDスペースを作る 個数*固定サイズ 
1トランザクション 個数1024個、固定サイズ256kバイト 
そしたら、ランダム読み書きでfopen()すればいい
オーバーヘッドを避けるためfopen();は終了のときだけ
オーバーヘッド無いだけで1000倍ほど速くなるケースも
オーバーヘッドはドコにあるのか?
それはWindowsOSのフォルダ構造検索にある
フォルダ構造検索回数を省けば速くなるのだ

360
デフォルトの名無しさん[]   投稿日:2016/01/10 12:52:32  ID:LOFSek54.net(3)
fopen();のときフォルダ構造検索するようだ

361
デフォルトの名無しさん[]   投稿日:2016/01/26 06:48:44  ID:v48l+1vS.net
やっとこの気色の悪い仕組みにトドメが刺されたか
javaとかGCが基本だけどflash();とかできるの?

362
デフォルトの名無しさん[sage]   投稿日:2016/01/26 07:35:03  ID:RBo8KHcc.net
ゴミ言語は所詮ゴミ

363
デフォルトの名無しさん[sage]   投稿日:2016/01/27 17:10:09  ID:eULyfEEH.net(3)
健全でない言葉が含まれているため表示しません 内容を確認する

364
デフォルトの名無しさん[sage]   投稿日:2016/01/27 17:24:38  ID:eULyfEEH.net(3)
謎だといったが、理由ははっきりしていて
メンバのDisposableを自動で呼び出す為には
他で使われてないことを保証する必要があって
参照カウンタ方式のようにローコストなものなら簡単に分かるが
これでは循環参照の問題が出る
プログラマが循環参照を気にしなくてもよいことが前提の
マークスイープ系のGCを搭載した言語では設計思想が破たんするので
参照カウンタ方式は採用できないし
マークスイープ系GCでは何処からも参照されていないことがローコストに分からないので
自動でDisposeを呼び出す仕組みを用意できない
どうにもならない

結局C++の方式が一番優れている
循環参照が発生する場合はweak_ptrを使う事だけ注意を払えば
GCにまつわる他の問題が一切発生しない

365
デフォルトの名無しさん[sage]   投稿日:2016/01/27 17:46:52  ID:eULyfEEH.net(3)
もっと言えばC#でDisposeを実装する場合でも↑は問題になる
自身のメンバのDisposeを呼んでよいのかどうなのか

完全に自分しか使ってないことが分かっているのであればDisposeを呼び出して問題ないが
あちこちから参照されている可能性があるメンバなら勝手にDisposeを呼び出してはいけない

GC任せにするか、自分で参照カウンタを実装するか
どちらにせよ、RAIIと相性が悪い

366
デフォルトの名無しさん[sage]   投稿日:2016/01/27 17:58:09  ID:aloDWtjb.net
前から何度も言ってるがDisposeの実装はしていいが呼び出しは禁止
これがC#では基本だからね
リソースの使用効率が悪いとか軟弱な反論をするバカがたまにいるが
実行効率気にするならそもそも別の言語使えって話になるからな
C++CLIを使えってこった
本質を見誤るなよ

367
デフォルトの名無しさん[sage]   投稿日:2016/01/27 18:38:52  ID:XmqLFQFE.net
c#の欠点はデストラクタが呼び出されるタイミングが分からないこと。
不便で仕方ないや。

368
デフォルトの名無しさん[sage]   投稿日:2016/01/27 18:56:08  ID:VDkVQpP+.net
最近VB.NETを使い始めたんだけど
new したオブジェクトが不要になった時にDispose()よんだり参照にNothing代入する必要ってない(やってもいいが無意味・無駄)なのかな?

369
デフォルトの名無しさん[sage]   投稿日:2016/01/28 08:05:17  ID:oip5UtLa.net
c++のデストラクタは例外投げられないウンコ仕様
だから皆デストラクタ内で発生したエラーは握り潰してる

他の言語はあんなバカなの真似する必要ない

370
デフォルトの名無しさん[sage]   投稿日:2016/01/28 17:53:06  ID:M0BYpVOa.net
デストラクタで投げるなよ。迷惑な奴だな。

371
デフォルトの名無しさん[sage]   投稿日:2016/01/28 18:02:00  ID:xwQj4KRs.net
javaはファイナライザで発生した例外は握りつぶすことが仕様で決まっているな。
c++の場合は、デストラクタでどうしても例外を外に伝えたかったらやりようはある。

372
デフォルトの名無しさん[sage]   投稿日:2016/01/30 01:11:50  ID:QZN0GaAw.net
そら伝えたかったらやりようはいくらでもあるでしょう?C++に限らず

373
デフォルトの名無しさん[]   投稿日:2016/02/10 11:29:59  ID:lL2Wg2mH.net
Javaは強制的に解放させることもできるようにすべきだったな。

374
デフォルトの名無しさん[sage]   投稿日:2016/02/10 11:41:46  ID:83b7Yxnh.net
Java(VM)は(すべてのプラットフォームで)強制的に解放させることもできるようにすべきだったな。

375
デフォルトの名無しさん[sage]   投稿日:2016/02/10 12:19:44  ID:k9iR7lzz.net
都度メモリ管理するよか、GCに任せた方がスループット的に有利な場合も多いでしょ。

376
デフォルトの名無しさん[sage]   投稿日:2016/02/10 14:29:59  ID:CcpqYYAq.net
GCはメモリ管理に関しては成功してる、
でも、メモリブロックをオブジェクトに昇格させたにも関わらず、相変わらず「メモリ管理」だから失敗。

377
デフォルトの名無しさん[sage]   投稿日:2016/02/10 17:29:46  ID:+sMp0qjD.net
そうそう、メインメモリの管理に関しては100%成功している
しかし、今やメインメモリはそれほど貴重なものではないわけだがな
コンシューマでも数十GB積んでたりは珍しくない
メインメモリがなくなるより他のリソースが枯渇する方が現実的
だからメインメモリ以外のリソースに関しては使い終わったら即座に開放してほしいから
GCとは別にRAIIを行う仕組みを導入するわけだが
真剣に考えていくと、RAIIはGCと相性が悪い
そもそも使い終わったら自動で即座に開放(RAII)できるなら全てのGCはそう実装すべきで
それが出来ないからわざわざコストのかかるマークスイープを遅延して実行しているわけだからな
C++みたいにGCを参照カウンタ方式にして、プログラマが人力で循環参照が無いことを保証する以外に
あちこちから参照されるオブジェクトのRAIIを自動化する方法は無い
コメント1件

378
デフォルトの名無しさん[sage]   投稿日:2016/02/10 20:59:51  ID:rEABlirv.net
JAVAはクソ

379
デフォルトの名無しさん[sage]   投稿日:2016/02/10 21:00:45  ID:ZQ/yQmxu.net
簡単だよ
スレッド立ててGCをフルサイクル実行し続けるだけ

380
デフォルトの名無しさん[sage]   投稿日:2016/02/11 16:22:39  ID:vxbPXQEr.net
javaもsandy-bridge以降でSSDとかならそれほど重いってわけじゃないけど
相変わらずatomでeMMCだったりする環境も並行して存在してて
そこで動かすと改めて糞だと思うわけよ
GCが悪いんじゃなくてjavaランタイムが悪いんだろうけどね

381
デフォルトの名無しさん[sage]   投稿日:2016/02/11 19:04:56  ID:EuRhj+pR.net
フラッシュとJAVAは、システムに見つかり次第、速攻アンインストールしている

382
デフォルトの名無しさん[sage]   投稿日:2016/02/12 08:32:20  ID:Uwfak+5B.net
>377
Pythonみたいに参照カウント+GC(循環参照を解放するため)が最強ってこと?

383
デフォルトの名無しさん[sage]   投稿日:2016/02/13 15:34:22  ID:OKKAbu21.net
最近のPC環境でも贅沢が過ぎるプログラムは動かん。
最近の奴だと、Node.jsのパッケージマネージャnpmが`npm search`と初回に打つとパッケージ検索用のインデックスを作ろうとするんだけど、
1つのjsonオブジェクトにまとめようとするからかOOMエラーを吐いて失敗するっていう不具合。
npmに登録されてるパッケージ数が膨大になったせいもあるが、設計を間違えると遅いどころか動かなくなる。

384
デフォルトの名無しさん[sage]   投稿日:2016/02/13 22:32:48  ID:6Xm9VASh.net
GCがある言語でRAIIみたいな事したいのなら
loan patten使えばいいだけでは

385
デフォルトの名無しさん[sage]   投稿日:2016/02/13 23:42:47  ID:VLo29AwR.net
リソースを共有した上で最後の参照が切れた時点で回収してほしい
しかし誰が共有するかもその寿命も実行時までわからない
そういう前時代的なダサい設計をした時の話しなんだろ
Loan Patternはこの状況では役に立たない

386
デフォルトの名無しさん[sage]   投稿日:2016/02/14 00:56:38  ID:mwiD0ozs.net
しかし、言語側は、そういうダサい設計も許さないといけないので
マークスイープ系GC搭載で、循環参照が有っても良いことが前提になっている言語で
「使い終わったら自動で即座に開放」を実現するのは困難
そんなことが可能なら、マークスイープは要らないからな

387
デフォルトの名無しさん[sage]   投稿日:2016/02/14 19:42:04  ID:I7Qc+kxz.net
循環参照なんて放置すればいいの
どうせプロセスが終了すればOSが開放してくれるの
コメント1件

388
デフォルトの名無しさん[]   投稿日:2016/02/14 20:10:25  ID:EqhxGdNa.net
>387
Windowsのように定期的に再起動しなければいけないソフトウェアができあがっちゃいそう

389
デフォルトの名無しさん[sage]   投稿日:2016/02/15 18:16:17  ID:TvNTryet.net
ErlangでOS作るか

390
デフォルトの名無しさん[]   投稿日:2016/02/15 19:50:44  ID:L+A+Kd2h.net
そこはRustで

391
デフォルトの名無しさん[sage]   投稿日:2016/03/01 15:00:17  ID:QERDe7Jh.net
5分でわかるガベージコレクションの仕組み
https://geechs-magazine.com/tag/tech/20160229

392
デフォルトの名無しさん[]   投稿日:2016/03/23 02:31:06  ID:MFzvJNSi.net
常識的に考えてカーネルの実装にはGCなんて使えないし
業務アプリケーションではパフォーマンスより開発速度がはるかに重要になる
結局適材適所だ
GCを強制されるのは苦痛だが使えないのも苦痛だ
好きな時に使える言語がいいよね!

393
デフォルトの名無しさん[sage]   投稿日:2016/03/23 03:41:39  ID:SoMbpeP6.net(2)
パフォーマンスが問題にならないGCが一つだけあって、それが参照カウンタ方式のGC
パフォーマンスが問題にならない→即座に逐一削除できる→RAIIが出来る
非常に強力だがプログラマが循環参照が無いことを保証しなければならない
しかし、循環参照が発生する場合は設計段階で分かるのでそれほど深刻では無いのだ!
コメント1件

394
デフォルトの名無しさん[sage]   投稿日:2016/03/23 03:47:03  ID:VzK80P8k.net
androidでもう何も判らん状態でプログラミングして
それなりに動くのができたからおれは許したよ
でもサービスまで勝手に回収されちゃうとは思わなかったわ
アホだろグーグル

395
デフォルトの名無しさん[sage]   投稿日:2016/03/23 07:53:14  ID:JT2FURwc.net(2)
RAIIに必要なのはデストラクタが呼ばれることであって実際にメモリが解放されることじゃないから
GC言語でもRAIIができないわけじゃない。

396
デフォルトの名無しさん[sage]   投稿日:2016/03/23 10:07:19  ID:SB04Y3rp.net
RAIIに必要なのは適切なタイミングで確実に解放処理が呼ばれることであって
いつ呼ばれるかわからないデストラクタではだめ
コメント1件

397
デフォルトの名無しさん[sage]   投稿日:2016/03/23 18:24:05  ID:jWiL+V+6.net
かつてStandard MLの実装で、GCじゃないメモリ管理方法をやってみたのがあったな。
コンパイラが全部自動でやるからコードの見た目はSMLなんだけど、いざ動かすとGCより遅かった。

ある程度プログラマがリソース管理のためのヒントを与えないと、GCを捨てられない。

398
デフォルトの名無しさん[sage]   投稿日:2016/03/23 20:05:29  ID:JT2FURwc.net(2)
>396
おまえが言っているのはファイナライザ。
それと、デストラクタはメモリの解放なんかしないよ。デストラクトするだけ。

399
デフォルトの名無しさん[sage]   投稿日:2016/03/23 21:43:30  ID:SoMbpeP6.net(2)
この際、呼び名はどうでも良い
参照カウンタ方式以外のGCでは、どこからも参照されなくなったことが、即座にはわからない
だから、自動で即座に開放関数を呼び出すことが出来ない→RAIIが出来ない

C#で言うところのusingみたいに、プログラマが手動で情報を与えるなら出来る
だが、usingはGCでは無い
コメント1件

400
デフォルトの名無しさん[sage]   投稿日:2016/03/24 00:53:54  ID:smGLwjga.net
いまさら、ゲームキューブ叩いてどうするんだ?

401
デフォルトの名無しさん[]   投稿日:2016/03/26 05:40:22  ID:vD3g1idC.net
>393
間違い
マークスイープのように負荷が集中しないだけでありパフォーマンスへの影響はある
特にツリー状のデータついてルートが削除された時子要素もデクリメントする必要があるため負荷が大きい
カウンタはオブジェクト毎に持つためコピーオンライトとの相性が悪い
また言語の機能として実装されなければ明示的に行う必要がある(例えばCとか)
そのためgcない言語ではマークスイープと比べ非常に面倒なことになる
コメント1件

402
デフォルトの名無しさん[sage]   投稿日:2016/03/26 10:35:48  ID:GKwGPSgf.net
androidで原因不明のフリーズが発生、プロジェクトはデスマーチに突入した
これだからGCは

403
デフォルトの名無しさん[sage]   投稿日:2016/03/26 11:39:27  ID:drxQ1xsy.net
これだからGCに頼りきった未熟者は

404
デフォルトの名無しさん[sage]   投稿日:2016/03/26 11:39:40  ID:MgEq8J/o.net(2)
>401
そりゃどんなものだって多少の負荷は有るよ
しかし参照カウンタの上げ下げの負荷なんか
マークスイープに比べれば無いも同然

405
デフォルトの名無しさん[sage]   投稿日:2016/03/26 18:02:09  ID:2IjmMYr5.net(2)
マルチスレッド環境だと参照カウンタとかいうクソアルゴリズムは使い物にならない
コメント1件

406
デフォルトの名無しさん[sage]   投稿日:2016/03/26 18:52:26  ID:QL60ocAy.net(2)
参照カウンタがオーバーフローしたらどうなんの?
コメント2件

407
デフォルトの名無しさん[sage]   投稿日:2016/03/26 19:10:36  ID:nXtJgRqN.net
>405
SSOのが遅いだろ
>406
size_t にしとけばオーバーフローしない
コメント1件

408
デフォルトの名無しさん[sage]   投稿日:2016/03/26 19:44:45  ID:R9brpoqy.net
>406
殿堂入りさせて、回収しない

409
デフォルトの名無しさん[sage]   投稿日:2016/03/26 20:22:44  ID:QL60ocAy.net(2)
>407
確かに現実的にオーバーフローしないと言えると思うけど
STLとかもそういう実装になってる?

410
デフォルトの名無しさん[sage]   投稿日:2016/03/26 20:52:01  ID:rTAUpSul.net
使う側は少なくとも1つのポインタを持たなくちゃいけないんだからオーバーフローし得ないだろ

411
デフォルトの名無しさん[sage]   投稿日:2016/03/26 22:10:23  ID:6zuFQelp.net
マルチスレッドでGCスレッド立ち上げて、再配置起こる可能性のある普通のGCだと、オブジェクト毎にLock,Unlockできる何らかの機構が必要だし、参照カウンタ増減するより高頻度でその機構使うよね。

412
デフォルトの名無しさん[sage]   投稿日:2016/03/26 22:34:25  ID:2IjmMYr5.net(2)
そうでもない

413
デフォルトの名無しさん[sage]   投稿日:2016/03/26 23:56:59  ID:MgEq8J/o.net(2)
例えばWindowsだとInterlocked系のAPIを使えば
マルチスレッドでも安全に参照カウンタを増減できるから
パフォーマンスは何の問題もない
コメント1件

414
デフォルトの名無しさん[sage]   投稿日:2016/03/27 00:13:33  ID:MdJCnp0Y.net(6)
C#なら参照のコピーはただのワード代入で済む
メモリ確保もポインタへの加算だけで済むから圧倒的に速い
回収もマルチスレッドで処理されるから圧縮フェーズ以外はUIへの影響もなくユーザ目線では実質コストゼロ
良いコードを書いてるなら圧縮もたまにしか起こらないし起こっても大した事ない

415
デフォルトの名無しさん[sage]   投稿日:2016/03/27 00:26:17  ID:vj+h39OC.net(10)
>399からの流れを見ればわかるがそういう話ではない
参照カウンタ方式以外のGCは、オブジェクトがどこからも参照されなくなったことが「即座」にわからない
だからRAIIが出来ない、そういう話

もちろん、参照の値が書き換わるたびに毎回マークスイープを実行すれば
即座にゴミが分かるがのでRAII出来るが、マークスイープは重いので参照が書き換わるたびに毎回実行できない
その意味で、循環参照以外のGCは重いと言っている

参照カウンタ方式は軽いので毎回実行できる
即座にゴミが分かるからRAIIが出来る

参照カウンタ方式で問題になるのは循環参照が起こった場合だが
循環参照が発生する箇所は設計段階で分かるので、実際には大した問題ではない
C++であれば、片方をweak_ptrにすればよいというだけの話
そこさえ気を付ければ、参照カウンタ方式とデストラクタの組み合わせは非常にうまく機能する
IDisposableのようなものも要らない
コメント1件

416
デフォルトの名無しさん[sage]   投稿日:2016/03/27 00:27:10  ID:vj+h39OC.net(10)
>循環参照以外のGCは重いと言っている

↑間違えた

参照カウンタ方式以外のGCは重いと言っている

417
デフォルトの名無しさん[sage]   投稿日:2016/03/27 00:41:23  ID:15KjVKPo.net(3)
>413
安全が何で保証されてるのかを知るためにアセンブラを勉強しなさい。
その上で「パフォーマンスは何の問題もない」かどうかを語りなさい。

418
デフォルトの名無しさん[sage]   投稿日:2016/03/27 00:59:17  ID:kBj57j3O.net(3)
前にも書いたが、RAIIとGCは直接の関係はないよ。
現にC++/CLIでは、ローカルスコープのオブジェクトがスコープを抜けた時点、あるいは
gcnewで作成されたオブジェクトがdeleteされた時点で即座にデストラクタが実行されて
メモリの回収自体はGCで行われる。

419
デフォルトの名無しさん[sage]   投稿日:2016/03/27 01:02:24  ID:MdJCnp0Y.net(6)
>415
そもそも不可視のコードでリソースを解放するのが愚行そのもの
プログラマとしての良識があるならusingを使いなさい
RAIIなどというくだらないバッドノウハウはC#では必要ない

420
デフォルトの名無しさん[sage]   投稿日:2016/03/27 01:31:49  ID:vj+h39OC.net(10)
>ローカルスコープのオブジェクトがスコープを抜けた時点、あるいは
>gcnewで作成されたオブジェクトがdeleteされた時点で即座にデストラクタが実行されて
>メモリの回収自体はGCで行われる。

それはGC関係ないRAIIの話だろ
C#でもusing使えばRAII出来るが
usingも、ローカル変数も、deleteも、何れもGCじゃない
手動で寿命管理しているに過ぎない

寿命管理を自動化(GC)しつつ、RAIIを実現する話をしているわけだが
どんな場合でも、GCで有ろうが無かろうが、手動でデストラクタなりファイナライザなり呼び出せば
RAII出来るに決まっているだろ、それに何の意味が有るんだよ
自動化の話だよ
コメント1件

421
デフォルトの名無しさん[sage]   投稿日:2016/03/27 01:33:16  ID:vj+h39OC.net(10)
>そもそも不可視のコードでリソースを解放するのが愚行そのもの

その最たるものが、マークスイープ系GCなわけですが
いつ実行されるかすら分からない
まさに不可視

422
デフォルトの名無しさん[sage]   投稿日:2016/03/27 01:51:43  ID:vj+h39OC.net(10)
極端な話
mallocして使い終わったらfreeして
はい、手動でRAII出来ました!って主張
それ何の意味が有る話なの?ってね

423
デフォルトの名無しさん[sage]   投稿日:2016/03/27 07:41:27  ID:kBj57j3O.net(3)
>420
>それはGC関係ないRAIIの話だろ

メモリはGCで回収されると書いたが?あと、そもそもRAII自体がGCと直接関係ないとも書いた。

>usingも、ローカル変数も、deleteも、何れもGCじゃない

いずれもメモリ領域はGCで回収される。

>どんな場合でも、GCで有ろうが無かろうが、手動でデストラクタなりファイナライザなり呼び出せば
>RAII出来るに決まっているだろ、それに何の意味が有るんだよ

ローカルスコープに置いたオブジェクトは手動で呼ぶ必要はない。
gcnewで作成したものにはdeleteを使うってのは普通のC++と同じだ。
ローカルスコープの変数を基点に、スコープを抜けたときに連鎖的にデストラクタが呼ばれて
delete等の後始末がされるってのがRAIIだからな。
普通のC++ではそのdeleteのときにoperator deleteでメモリ領域が解放されるが、C++/CLIでは
GCで回収されるというだけ。

「GCで有ろうが無かろうが」「RAII出来るに決まっている」ということを理解したならまぁそれでいい。
できないってのを否定しただけで、別に意味があるかないかを話していたわけじゃないからな。
要は、GCを使う多くの言語でRAIIができないのはデストラクタの仕組みを持っていないからであって、
それがあるC++/CLIならRAIIも可能ということ。逆にGCを使わない言語でも、デストラクタがなければ
RAIIは不可能。
つまり最初の結論、RAIIとGCの有無に直接の関係はない。
コメント1件

424
デフォルトの名無しさん[sage]   投稿日:2016/03/27 10:01:03  ID:MdJCnp0Y.net(6)
メモリとその他のリソースを混同して考えるからダメ
まずその他のリソースは不可視のコードで解放しちゃダメ
リソースのスコープは明示的でなければならない
これはデストラクタにもGCにも任せられない
逆にメモリは不可視のコードで解放してもよい
まずこの基本原則から話を進めよう
コメント2件

425
デフォルトの名無しさん[sage]   投稿日:2016/03/27 10:12:42  ID:Ap0rkncx.net
schemeにはdynamic-windみたいな他所に継続が飛んでも後処理が保証される仕掛けがあるし
デストラクタがない==RAIIできないにはならないと思うの・・・

426
デフォルトの名無しさん[sage]   投稿日:2016/03/27 11:03:59  ID:+zMq83Ww.net(2)
>424
んな事はない。
あらゆるリソースの寿命はライブラリでデフォルトの管理がされるべきであり、使用者の完全性を前提にすべきではない。
コメント1件

427
デフォルトの名無しさん[sage]   投稿日:2016/03/27 11:16:32  ID:MdJCnp0Y.net(6)
>426
銀の弾丸は無い
あらゆるリソースのあらゆる利用形態に対してデフォルトの動作を定義できるなら話は別だが無理だよね
結局は人が方針を決めて書くしか無い
幸いにしてメインメモリにはRAIIやマークスイープという正解が見つかっているのでそれを使えばいい
だが他のリソースはダメだ

428
デフォルトの名無しさん[sage]   投稿日:2016/03/27 16:21:42  ID:vj+h39OC.net(10)
>423
そんな基本的なことを言って何がしたいの?

RAIIとGCは密接な関係が有るんだよ
君はローカル変数が好きみたいだから、ローカル変数の事例で説明するとする
(嫌ならC#のusingと読み替えてもらっても構わない)
ローカルに確保したオブジェクトが、メンバ変数に他のオブジェクトを持っていたとする
いわゆるコンポジションの状態、よくある話
C++で言えば、class my_class{ object *obj; }; といった感じのクラスになる、分かるよね?
で、ローカル変数はスコープを抜けたら解放される、usingも似たようなもの、これはRAIIの基本、良いね?
このとき、マークスイープ系GCだと、my_classのobjに他からの参照が有るかどうか、即座にわからないので
objを開放してよいのか判断が付かない→my_classは破棄されてもobjはGC発動まで保留される→objは残るのでRAIIの意味がない

もしくは、my_classのobjに他からの参照が全く無いことをプログラマが保証して
my_classの開放部にobjをdeleteなりdisposeなりするコードを記入する
しかしこれは、objの所有権がはっきりしていないことには使えない上に、「手動」である
C++の場合はスマポが有るのでまだましだが、C#のDisposeは完全に手動で呼ばなければならない
自身のメンバにIDisposableなメンバいたら、自身もIDisposableにしなければならず、Disposeメソッドを実装して
自身のメンバのDisposeを芋づる式に呼び出すコードを手動で書かなければならない
mallocしたらfreeしましょうと一緒で、C言語レベルの全くの手動になってしまう

参照カウンタ方式のGCではこれらの問題は発生しない
他からの参照が有るか無いかは即座にわかるし、参照カウンタが0になれば、その場で即座に破棄される
自身のメンバに対して、デストラクタは芋づる式に呼び出されるので、C#のDispose実装のような面倒さは無い

>424
お前言ってること無茶苦茶すぎるだろ

>リソースのスコープは明示的でなければならない、デストラクタにもGCにも任せられない

GCはともかく、デストラクタでもダメって意味不明すぎるんだが
考えの根本がおかしい
コメント1件

429
デフォルトの名無しさん[sage]   投稿日:2016/03/27 16:43:31  ID:vj+h39OC.net(10)
C++で書けば
struct A{ *obj };
void func()
{
  A a;
}
こういったRAIIの場合のobjの開放はどういう扱いにするんだって話

aが完全にobjを所有しているケースなら、Aのデストラクタにdelete obj;とでも書くかscoped_ptrでも使えばよい
しかし、objが彼方此方から参照されている可能性もあるので
そこんとこコンパイラは判断が付かないので、自動化はきない
あくまで、プログラマが保証する形になる
C#のDisposeのような仕組みを言語側で用意したところで、自身のメンバにIDisposableなメンバが有るかどうか
いちいち調べなきゃならなないし、調べ忘れや呼び出し忘れをするという問題が出てくる
しかも、所有権が単一である場合にしか成り立たない

一方でマークスイープ系GCに任せっぱなしにすると、objの開放はGC発動まで遅延してしまうだろう

参照カウンタはこれらの問題をすべて解決する
参照数はどのタイミングでも直ぐに分かるし、0になれば遅延なしで即座に削除される
デストラクタは自身のメンバに対して芋づる式に自動で呼び出されるので
スマポを使っておけば呼び出し忘れるということもないし
Disposeのような冗長なコードを書く必要もない

430
デフォルトの名無しさん[sage]   投稿日:2016/03/27 16:44:43  ID:vj+h39OC.net(10)
訂正

struct A{ *obj };
void func()
{
  A a;
}



struct A{ object *obj };
void func()
{
  A a;
}

431
デフォルトの名無しさん[sage]   投稿日:2016/03/27 17:07:08  ID:vj+h39OC.net(10)
結局、C#のDisposeはどこまで行ってもどんなに進化しても手動で書かなければならない
自身のDisposeが呼ばれたからと言って、自身のメンバ変数のDisposeを芋づる式に勝手に呼び出して良いかは
コンパイラにはまったく判断が付かない
他からも参照されていて今まさに使われている可能性がある以上
コンパイラが勝手に自動でDisposeを呼び出すコードを生成することはできない
GCを発動してみるまでは、どこからも参照されなくなったことが保証できない
しかし、GCの発動まで開放が遅延しても良いのであれば、そもそもDisposeは要らないわけで
Disposeの実行はGC発動より先行していなければならず、GCに頼れないということになる
なので、自身のDisposeが呼ばれたときに、自身のメンバのDisposeをしてよいかは
プログラマが考え、手動で呼び出す必要が有る
所有権が単一であれば、手動でメンバのDisposeを呼び出せばよい
手動で記述しなければならないので面倒くさいし、ミスの元ではあるが、一応できる
所有権が複数であれば参照カウンタを使うしか現実的な方法は無いだろう
マークスイープ系GCなのに参照カウンタで独自に管理するのは馬鹿げているがな

参照カウンタ方式+デストラクタ
であればこれらの問題は一切発生しない
参照カウンタが0になったことは即座にわかるし、デストラクタはメンバ変数に対して芋づる式に呼び出されるので
開放に関しての特別なコードを手動で書く必要は無い
開放処理も一本化される


432
デフォルトの名無しさん[sage]   投稿日:2016/03/27 17:16:20  ID:UGnRhUEw.net
健全でない言葉が含まれているため表示しません 内容を確認する

433
デフォルトの名無しさん[sage]   投稿日:2016/03/27 17:17:01  ID:MdJCnp0Y.net(6)
>428
バカすぎる
細かい事気にせずデストラクタで解放すりゃそれでおkって感じの適当な現場でしか働いた事無いんだろうな

434
デフォルトの名無しさん[sage]   投稿日:2016/03/27 17:22:53  ID:/D0vdPDd.net
ポインタがメンバ変数になってたら公開しちゃいかんでしょ

435
デフォルトの名無しさん[sage]   投稿日:2016/03/27 17:24:21  ID:MdJCnp0Y.net(6)
まずDisposeは生成できる
めんどくさいという奴は知識が無いだけ

リソースを共有する事は少ない
というか設計段階で可能な限り少なくする
そして共有するならするでしっかり管理して自動解放などという手抜きはしない
基本中の基本だ

436
デフォルトの名無しさん[sage]   投稿日:2016/03/27 17:32:09  ID:+zMq83Ww.net(2)
デストラクタで解放してはいけないリソースをデストラクタで解放しなければいいだけで、デストラクタで解放すればいいリソースはデストラクタで自動的に解放すべき。

437
デフォルトの名無しさん[sage]   投稿日:2016/03/27 20:12:26  ID:kBj57j3O.net(3)
>参照カウンタ方式+デストラクタ
>であればこれらの問題は一切発生しない

.NETのマーク&スイープGCの上でRAIIを実現している実例としてC++/CLIを説明したんだが、
「基本的なこと」とか言いながら結局何も理解してないんだな。

そもそもRAIIの話で所有権が共有されたオブジェクトを持ち出すのが意味不明すぎる。

>参照カウンタが0になったことは即座にわかるし、

「いつか」全員が所有権を手放したら「即座に」破棄される
「いつか」全員が所有権を手放したら「いつか」GCで破棄される

どう違うというのか。

438
デフォルトの名無しさん[sage]   投稿日:2016/03/27 20:35:08  ID:Ng/EIIMI.net(2)
RAII信者の痛さは異常
オブジェクトをコピーされたら破綻するのに
コメント1件

439
デフォルトの名無しさん[sage]   投稿日:2016/03/27 21:10:56  ID:N7IGtcj3.net
グローバルインスタンスホルダーは明確にインスタンスの状態を把握したいときに積極的に使うべき

440
デフォルトの名無しさん[sage]   投稿日:2016/03/27 22:32:53  ID:vj+h39OC.net(10)
>「いつか」全員が所有権を手放したら「即座に」破棄される
>「いつか」全員が所有権を手放したら「いつか」GCで破棄される
>どう違うというのか。

少なくとも最善が尽くされるという意味で違うし
同じデータと同じプログラムで有れば、常に同じタイミングで開放処理が走るという再現性が有る

それから、自分しか所有権を持っていない場合、つまり参照数が常に1というシンプルな状況ですら
参照カウンタ方式の方が開放処理が自動化されて楽

参照カウンタ方式で有れば、スマポを使っておけば済む
scoped_ptrでも良い

マークスイープ系GCであれば、自身しか所有権を持たない単純な場合でも
非常に面倒なことになる
自身にDisposeを実装して自身のメンバのDisposeを呼び出すコードを手動で書かなければならない
何故こういったコードをコンパイラが自動生成できず、手動で書かなければならないのかの根底に
まさにマークスイープGCの存在が有る
マークスイープ系GCは何処からも参照されなくなったことがその場ですぐに分からない
GCを発動してみるまで保証することが出来ない

自分のDisposeが呼び出された、まさにその瞬間に、自分のメンバに対してもDisposeしてよいのかどうなのか
参照数がリアルタイムで即座に分からないので判断する材料が何も無く
コンパイラはC++のデストラクタのように自動で芋づる式に開放処理を呼び出すコードを生成することが出来ない

要するにマークスイープ系GCではDisposeのコンパイラによる自動生成が出来ないという大きなマイナスが有る
コメント2件

441
デフォルトの名無しさん[sage]   投稿日:2016/03/27 22:36:05  ID:15KjVKPo.net(3)
>438
しねーよ

442
デフォルトの名無しさん[sage]   投稿日:2016/03/27 22:41:25  ID:VNvh7E4d.net
>440
子要素をDisposeしていいかどうかもわからないってそりゃ設計サボってる以外のなんでもないだろう
ちゃんと設計してればいつ削除してよいかなんてわかるはずだろ
まともに設計もできないレガシーエンジニアは黙っててよ
設計に時間使わないとリソース云々以前に別のバグだらけになるぞ

443
デフォルトの名無しさん[sage]   投稿日:2016/03/27 23:42:37  ID:Ng/EIIMI.net(2)
RAII信者は頭が悪いな
コメント1件

444
デフォルトの名無しさん[sage]   投稿日:2016/03/27 23:59:39  ID:15KjVKPo.net(3)
>443
自分の頭を検証しな

445
デフォルトの名無しさん[sage]   投稿日:2016/03/28 00:10:58  ID:h9yZCrPP.net
メンバにDispose持たせる設計って大抵ダメだよね

446
デフォルトの名無しさん[sage]   投稿日:2016/03/28 00:20:40  ID:j/beyn8U.net
>440
前者(参照カウントGC)はRAIIができるが後者(マーク&スイープGC)ではできないというお前の
主張について言っているんだが?
「最善が尽くされる」からRAIIができて、尽くされないからRAIIができないとでも言うのだろうかw

>要するにマークスイープ系GCではDisposeのコンパイラによる自動生成が出来ないという大きなマイナスが有る

何度も例に挙げているC++/CLIでは、デストラクタを記述するとコンパイラによってDisposeが追加される。
そして、ローカルスコープに置いたオブジェクトに対してはスコープを抜ける際に自動的にdeleteが呼ばれる。
そこからdelete→Dispose→デストラクタと呼び出される。RAIIに必要なものは揃っているし、事実、可能だ。
もちろん、そのメモリ領域は別のタイミングでGCによって回収される。

ここまで説明しても理解できない低脳ならしょうがない。
やはりデストラクタとファイナライザの違いが理解できてないようだからそこから勉強しなおせ。

447
デフォルトの名無しさん[sage]   投稿日:2016/03/28 00:39:52  ID:2h3yopdG.net
{
std::shared_ptr<my_namespace::my_class> p(new my_namespace::my_class(...));
/* unko_code */
}

using(var obj = new MyClass(...)) {
/* GoodCode */
}

美しいという事はいい事だね
C#は書いてある事がシンタックス的にもセマンティック的にも明確だ
リソース管理はこうでなければならない
コメント2件

448
デフォルトの名無しさん[sage]   投稿日:2016/03/28 01:22:52  ID:khgTmo3F.net
>447
C++にもusing使えやw いらない波括弧外せやw

449
デフォルトの名無しさん[sage]   投稿日:2016/03/28 03:34:15  ID:d3YBhLBG.net(2)
>447
usingの方が全然明確だね
objがコピーされてても問題ない
RAII脳ではわからないんだろう

450
デフォルトの名無しさん[sage]   投稿日:2016/03/28 03:36:11  ID:d3YBhLBG.net(2)
schemeに何十年も前から存在するwith-xxxx 系を一般化した構文だね

451
デフォルトの名無しさん[sage]   投稿日:2016/03/29 01:23:53  ID:Qm5oX8hY.net
アレを更にtypedefされたりされると
ワケワカランくなるよな

452
デフォルトの名無しさん[sage]   投稿日:2016/03/29 01:50:13  ID:40IzaG0J.net
c++なら普通こうだな
{
my_class obj(...);
...
}
そういやc#でp.release()相当の事って簡単にできるの?
{
auto p(make_unique<my_class>(...));
...
}
nullって代入可能?

453
デフォルトの名無しさん[sage]   投稿日:2016/04/04 02:47:24  ID:+1V6ohqL.net
GCがあるのになぜJavaはメモリリークしまくるソフトウェアを量産するのか
コメント1件

454
デフォルトの名無しさん[sage]   投稿日:2016/04/04 02:55:18  ID:FhdBY7IF.net
>453
Javaだから

455
デフォルトの名無しさん[sage]   投稿日:2016/04/12 23:15:42  ID:ZWvwh7J9.net
Rust使えばいいのさ
コメント1件

456
デフォルトの名無しさん[sage]   投稿日:2016/04/13 10:33:47  ID:+hJ3fPVS.net
>455
会社にいるよな、そういうやつ

457
デフォルトの名無しさん[sage]   投稿日:2016/04/13 15:29:31  ID:oOcEPJTu.net
GC大好きっ子に聞きたいんだが
完璧な(理想的な)GCを搭載したメジャーな言語処理系って何があるの?
これで開発すればリークも管理も気にしないでOKってやつ
コメント1件

458
デフォルトの名無しさん[sage]   投稿日:2016/04/13 16:22:35  ID:s5MRiDQ8.net(2)
無い

マークスイープ系GC → 循環参照OK、しかし即座に開放されない
参照カウンタGC → 即座に開放される、しかし循環参照NG

ということで、理想のGCは無い
全てのGCは何かを妥協している

それから、たとえGCを使ったとしても
要らなくなったオブジェクトの参照をいつまでも握っている奴が居たら解放されないから
リソースの管理をしなくてよいということは無い

あと、GCは基本的にメインメモリに対してしか有効に機能しないから
例えばファイルオブジェクトなんかは要らなくなったら即座にcloseするなりすべきで
リソース管理フリーというわけにはいかない

459
デフォルトの名無しさん[sage]   投稿日:2016/04/13 16:54:16  ID:s5MRiDQ8.net(2)
つまりは、GCを使っていたとしても
君がオブジェクトを何処かに登録したなら
オブジェクトが要らなくなったら登録解除してあげないと
そのオブジェクトは解放されないのだ
これはちょうどmallocしたらfreeしましょうに似ていて
GCを使ったとしても全てのリソースの管理が自動になるわけではないということだね

究極的にはGCの利点は自分でfree/deleteをしなくても良いところにある
これはつまり、ダングリングポインタが発生しないということだ

460
デフォルトの名無しさん[sage]   投稿日:2016/04/14 20:54:37  ID:f1hhftJp.net

461
デフォルトの名無しさん[]   投稿日:2016/04/17 16:17:55  ID:j/f/oFPY.net(3)
そして無視されてしまうコピーGC君
GCの利点は自分で大量にメモリの確保&解放するプログラムにおいてバグが出にくくスループットも出るってところだと思う
もしheapをそんなに頻繁に確保&解放しないんだったらGCない言語の方がいい
ただ近代的な言語は少数の例外を除いて大抵GC積んでるけど

462
デフォルトの名無しさん[]   投稿日:2016/04/17 16:21:44  ID:j/f/oFPY.net(3)
>リソース管理フリーというわけにはいかない
リソース管理フリーについてはrustみたいなGCない言語のほうが達成できてるよね(あとは関数型言語か)
でもrustでもリソースの解放時にエラーを吐く可能性がある処理なら自分で解放する処理書かなきゃいけないっぽいけど

463
デフォルトの名無しさん[sage]   投稿日:2016/04/17 18:35:17  ID:SAR9JCaP.net
RAIIでも結局どのタイミングで解放されるか意識しなくてもいいってわけじゃないし
リソース解放処理を書かなくていいだけで

464
デフォルトの名無しさん[sage]   投稿日:2016/04/17 18:43:59  ID:cFoKw8Zx.net(2)
メモリ管理系のバグが顕在化しにくいだけで、そこら辺適当なまま中途半端にキャリアを積む開発者を量産するという害悪が大きい。
JNIやらで他のAPI使う必要が出てくると結局いろいろ配慮しなきゃいけなくなるし。

465
デフォルトの名無しさん[sage]   投稿日:2016/04/17 19:43:44  ID:oNE1M7I6.net
>460
コンサバじゃ完璧にほど遠いぞな

466
デフォルトの名無しさん[sage]   投稿日:2016/04/17 19:50:47  ID:1R/4ebGS.net
>メモリ管理系のバグが顕在化しにくいだけ
結局これだよね
本当に丸投げできるなら乗っかるのもいいと思う
性能問題はハードの進化で一部の用途を除けば問題無くなると思うし
でも現実は中途半端だから意識して書いたほうがマシだと

467
デフォルトの名無しさん[]   投稿日:2016/04/17 21:19:09  ID:IB74e9ph.net
ムーブセマンティクスのおかげでずいぶん便利に。

468
デフォルトの名無しさん[sage]   投稿日:2016/04/17 23:09:38  ID:j/f/oFPY.net(3)
あと正確にはGCには含まれないけどメモリコンパクションをやってくれる処理系が多いのも
GCを使う利点になるかも
コメント1件

469
デフォルトの名無しさん[sage]   投稿日:2016/04/17 23:17:23  ID:cFoKw8Zx.net(2)
今どき意図的にやらない限りメモリフラグメンテーションで困るような場面があるか?
アドレス空間も余裕出てきたし、多少おかしな確保パターンで浪費してもGCほど実メモリを食わないし。
今どき主流のサイズ毎に空きを管理するmallocは優秀だしね。
これがダメならlinuxカーネルとか先に落ちちゃうぞ。
コメント1件

470
デフォルトの名無しさん[]   投稿日:2016/04/18 15:56:44  ID:kcE0qDSU.net(2)
>469
昔、C/C++を駆使して日本が誇るスパコン京に投入するタスクセットを書き上げたのだが
実行するとどうも性能が出ない。
色々調べた結果、どうやらメモリーが断片化していることが分かった。
そこで多大な投資を行いJavaで書き直したらなんと100倍も性能が上がったのです!
これが>468さんの経験してきたことなんです。

471
デフォルトの名無しさん[sage]   投稿日:2016/04/18 16:30:17  ID:BDPQ12Es.net
自前のメモリ管理が超下手くそなだけやろ
修業して出直してこいや

472
デフォルトの名無しさん[sage]   投稿日:2016/04/18 16:37:09  ID:OvHIqTOi.net(3)
自慢になってないような

473
デフォルトの名無しさん[sage]   投稿日:2016/04/18 16:44:52  ID:9yQABY6F.net(3)
ゲームだとフラグメント問題になること多いよ
ゲーム専用機なら特に
最近は特にオープンワールドが当たり前になってるけど
あれストリーミングでどんどんメモリ置き換えていくしね

474
デフォルトの名無しさん[sage]   投稿日:2016/04/18 16:47:31  ID:/wa5LIjH.net
jemallocのようなモダンなmalloc実装使えば良かったのでは。

475
デフォルトの名無しさん[sage]   投稿日:2016/04/18 17:47:00  ID:IBBVu28x.net(4)
ゲーム専用機でフラグメンテーションおこすとか開発者としての適性を疑われても不思議ではない。
オブジェクトの寿命管理すらしないのか?
コメント1件

476
デフォルトの名無しさん[sage]   投稿日:2016/04/18 18:51:08  ID:RPQ9NKJO.net(2)
メモリのフラグメンテーションをC/C++でコントロールする方法ってあるの?
mallocの実装頼りじゃなく。

477
デフォルトの名無しさん[sage]   投稿日:2016/04/18 19:05:27  ID:OvHIqTOi.net(3)
mallocの挙動がわかってれば、ある程度は・・・・

478
デフォルトの名無しさん[sage]   投稿日:2016/04/18 19:14:30  ID:OvHIqTOi.net(3)
細かくメモリ要求するから、下回りで時間がかかる
メモリ分断されてもオンメモリでの検索はさほど時間がかからない
(空きができても、そこに入らないときに)

479
デフォルトの名無しさん[sage]   投稿日:2016/04/18 19:15:14  ID:9yQABY6F.net(3)
>475
フラグメンテーションって何かわかってないでしょ?
寿命管理だけでは解決できないよ

480
デフォルトの名無しさん[sage]   投稿日:2016/04/18 19:21:39  ID:IBBVu28x.net(4)
寿命管理で解決できないとか、フラグメンテーションがどういう現象か分かっているの?

汎用の寿命管理APIみたいなのを使うとか言うのと勘違いでもしている?
コメント1件

481
デフォルトの名無しさん[sage]   投稿日:2016/04/18 20:02:22  ID:3yZKjOEp.net(3)
>480
おいおい・・
この場合寿命を管理できないってのはgiven conditionとして考えないと
そりゃ寿命があらかじめわかってるなら苦労しないっての
大規模なプログラムでそんな恵まれた状況は例外的だよ

482
デフォルトの名無しさん[sage]   投稿日:2016/04/18 20:57:42  ID:IBBVu28x.net(4)
専用ゲーム機上のゲームだよ。
リソースが逼迫したら何を優先するかの戦略も含めてほぼ理想的なgiven conditionだろうに。
ユーザーの行動による不確定性も全てコントロール下にあるだろうに。
コメント2件

483
デフォルトの名無しさん[sage]   投稿日:2016/04/18 21:13:59  ID:RPQ9NKJO.net(2)
>482 専用ゲーム機と普通のPCの1アプリケーションとで何が違うのか。mallocも使わないってこと?
NoGC, 各GCでメモリ空間がどう使われるかを視覚化
https://spin.atomicobject.com/2014/09/03/visualizing-garbage-collection-alg...
黒: 未使用
灰: 確保
緑: 読み込み
黄: 書き込み
赤: GC用のアクセス(参照カウンタ、マーク用ビットetc)
緑と黄は時間経過で退色していく

メモリフラグメンテーションという観点から見ると、コピー型GCが綺麗。

484
デフォルトの名無しさん[sage]   投稿日:2016/04/18 21:15:59  ID:3yZKjOEp.net(3)
まぁテトリスとかならその程度の理解でいいんじゃない?w

485
デフォルトの名無しさん[]   投稿日:2016/04/18 21:33:24  ID:kcE0qDSU.net(2)
Javaの寿命管理APIは最強ですな。

486
デフォルトの名無しさん[sage]   投稿日:2016/04/18 21:49:39  ID:9yQABY6F.net(3)
>482
GTAみたいなゲーム考えてみ?
あれ全てオブジェクトの寿命を事前に決められると思う?
原理的には不可能じゃないだろうがそんな職人的な作りしてたら開発に10年かかるわw
コメント1件

487
デフォルトの名無しさん[sage]   投稿日:2016/04/18 21:56:15  ID:IBBVu28x.net(4)
普通のmallocで足りるならそれでもいいけど。
基本メモリ容量ギリギリまで使うから、最初に描画、ゲーム内部状態、音声、ディスクキャッシュなどでどのくらい使うか決めておく。
終始一貫して静的に決めるのが楽だけど、場合によっては場面ごとに配分を切り替えたりする。
で、例えば広いマップ上を自由に動き回るようなゲームだと、マップを複数のパーツに分割して、詳細モデルから簡易モデルまで用意する。

488
デフォルトの名無しさん[sage]   投稿日:2016/04/18 22:12:01  ID:3yZKjOEp.net(3)
ゲームプログラムとかならメモリ確保は直接システムコール呼び出して
ページ単位でアロケートするのが定石
必要ならmspaceとかインスタンスベースのヒープを自分で作る
コメント1件

489
デフォルトの名無しさん[sage]   投稿日:2016/04/19 01:49:46  ID:KVIhh3Hm.net
使用できるメモリのサイズも空きメモリのサイズも最初から分かってて、ユーザーからの入力も限られてて、
そいつら全部自分で管理できる「恵まれた」環境でしか通用しないアプローチだよなそれ。
コメント1件

490
デフォルトの名無しさん[]   投稿日:2016/04/19 01:58:46  ID:fq3yh1do.net
レーシングゲームは出てくる車が決まっていてコースも決まっているから。

491
デフォルトの名無しさん[sage]   投稿日:2016/04/19 08:28:57  ID:YcewE61x.net
昨今はレースゲームでも汎用的なゲームエンジン使うことが多いから
その場合事前に寿命が決まってる前提の作りにはしていないと思うぞ
GDCとかGame Gemとかでも昔からフラグメンテーション対策を含む
メモリ管理の手法はいろいろ議論されているから調べてみるとよろし

492
デフォルトの名無しさん[sage]   投稿日:2016/04/20 12:56:58  ID:r07pzD8i.net
>489
ハードリアルタイムなシステムならごく普通
って言うかそうでないと作れない

493
デフォルトの名無しさん[sage]   投稿日:2016/04/20 13:09:41  ID:DLw9rf+F.net
>486
ああいうFPSのオブジェクトは全部管理されてるし
gcなんか使ってないよ
コメント1件

494
デフォルトの名無しさん[sage]   投稿日:2016/04/20 19:22:46  ID:bj66dBvK.net
>493
フラグメンテーションの話だっての
コメント1件

495
デフォルトの名無しさん[sage]   投稿日:2016/04/20 19:58:58  ID:CuR1I1mj.net
やり手のゲーム系の方たちに、逆らうようなことは・・・・

496
デフォルトの名無しさん[sage]   投稿日:2016/04/21 01:20:25  ID:jf1w54Av.net
>494
そんなのどうにでもなるでしょ
汎用のmallocなんかとは事情が違う
コメント1件

497
デフォルトの名無しさん[sage]   投稿日:2016/04/21 02:16:29  ID:G+xv7xqn.net
>496
どうとでもなるって?
へーじゃあ試させてもらうわ
GDC 2016でもこういう講演があった
http://schedule.gdconf.com/session/building-a-low-fragmentation-memory-s...
64bitならなぜフラグメンテーションが軽減できるか説明してもらおうか?
物理メモリが多いからじゃないからな
あればあるだけメモリ使うのがゲームなのでメモリに余裕があるわけじゃない
コメント3件

498
デフォルトの名無しさん[sage]   投稿日:2016/04/21 11:32:02  ID:EjzxVVPK.net
ゲーム機含む組み込み系は結果が不確定な動的メモリー確保なんかしないのが鉄板(しようとする奴は未熟な馬鹿)だったが
PCと合わせて組み込み機器もスペックが潤沢になって富豪的プログラムが一般的になってきたからね

無知ゆえ聞きたいんだが
最近のゲームソフトやら>497やらってどういうGC使ってるの?

499
デフォルトの名無しさん[sage]   投稿日:2016/04/21 13:09:31  ID:pog3nPgL.net
ゲームだって組込みだって今どき動的メモリー確保しないなんて化石みたいな発想が通るわけないだろ
かといって普通のGCは問題外
賢いメモリアロケーションをするしかないんだよ
>497は「こんなすごい講演するぞ」って言う宣伝だけだけど中身はどこにあるの?

500
デフォルトの名無しさん[sage]   投稿日:2016/04/21 16:14:15  ID:lEi5GQja.net(2)
>497
MMUが付いているから

物理メモリがフラグメンテーションすることは、ある程度これで防げる
しかもハードウェアの機能だから高速だし、勝手にやってくれるから素晴らしい
速度が重要なゲームでは、これは有り難い
ソフト的なアプローチでこれ以上の細工は遅くなるだけで効果が薄い

問題は論理アドレスの方
32bit空間だと例え物理メモリが余っていても
論理アドレスがフラグメンテーションを起こして連続したメモリを確保できなくなる
物理アドレスが枯渇するよりもさきに、そちらの方が問題になることが多い
64bitだと、これが防げる
コメント1件

501
デフォルトの名無しさん[sage]   投稿日:2016/04/21 16:37:13  ID:lEi5GQja.net(2)
各ゲーム機の事情は知らないが
PCで有れば、64bitプロセスは、論理アドレスの空間が256TB(48bit)もある
ゲーム機も似たようなものだろう
256TBもの物理メモリを積んだPCやゲーム機は存在していないし
例え論理アドレスが激しくラグメンテーションを起こしても
256TBもの論理アドレス空間を使い切るという事態は考えなくてよい
つまり、64bitプロセスなら、論理アドレスの心配はしなくてよい

一方で、物理アドレスのフラグメンテーションはMMUに任せておけばよい
これはハードウェアで自動で行われるし、とても高速
その余計にソフトウェア的アプローチで頑張ってみたところで
多少物理メモリのフラグメンテーションは改善されるかもしれないが
徒労というかなんというか、労力に見合わないし
しかも遅くなるのでゲームには向いていないし、やらなくてよい
物理アドレスは自分だけが使っているわけではなく、OSを含めたほかのプロセスも使っているので
自分のプロセスが使っている物理メモリだけフラグメンテーションを解消しようと
コンパクションするのも何か完璧感が無いし
自分のプロセス内だけで考えても、外部ライブラリやXBoxならDirectXが使用している物理メモリの
フラグメンテーションは手が出せないので解消しようがない、やはりやるだけ徒労
自分の管理出来る部分だけ物理メモリのコンパクションをかけても
「これで計算上、必ずあと200MBの物理メモリを使用できる筈」とかといった保証はどこにもない
理由は、外部のライブラリ内での物理メモリの使用状況が分からないし、手が出せないから
とにかく徒労であり、MMUに任せておけばよい

502
デフォルトの名無しさん[sage]   投稿日:2016/04/21 17:22:28  ID:7dcTEyv0.net
ただの物理メモリ不足の話がなんでと思ってしまった
swapはじまったら、fpsなゲームはどうなるんでしょうね

503
デフォルトの名無しさん[sage]   投稿日:2016/04/21 19:18:25  ID:zEEe/DNn.net
論理アドレスが64bitだったらフラグメンテーション対策なんていらんということ?いや自分もそうは思うんだが。
上の方で「専用ゲーム機開発ならフラグメンテーション対策も行うのが常識!」みたいに主張してる人がいて、
それって自作のmalloc相当のアロケータ作るってことだよね?と思ったんだが、
メモリ節約術とごっちゃにしてる人もいてわけが分からなくなってきた。
コメント1件

504
デフォルトの名無しさん[sage]   投稿日:2016/04/21 22:14:27  ID:WHT47icf.net
なんで馬鹿に限って長文書きたがるんだろうか

505
デフォルトの名無しさん[sage]   投稿日:2016/04/22 08:58:47  ID:imh5rD9T.net(2)
>500
すばらしい、正解
まぁ>488で答え言ってたわけだけど
某ゲーム機ならコンパクションも実装できるよ

>503
ページ単位という制限がつくし、速いって言ってもシステムコールなので
ユーザランドで完結するヒープライブラリに比べると遅い
フラグメンテーション対策がいらなくなるわけじゃないよ

506
デフォルトの名無しさん[sage]   投稿日:2016/04/22 11:30:03  ID:+Z1ZyILi.net(2)
わかってなさそうな方がそれっぽいこと・・・・

507
デフォルトの名無しさん[sage]   投稿日:2016/04/22 12:23:02  ID:UzNl+aCx.net
わかってる方は完結に書いてみればいい

508
デフォルトの名無しさん[sage]   投稿日:2016/04/22 15:49:44  ID:+Z1ZyILi.net(2)
学校の先生にそう教わったんですね

509
デフォルトの名無しさん[sage]   投稿日:2016/04/22 19:23:46  ID:cAq2nbH2.net
用途ごとにセグメント分けて使い回すのが無難じゃないの
オブジェクトの数が足りなくなったら透明でいいのよ

510
デフォルトの名無しさん[sage]   投稿日:2016/04/22 20:32:21  ID:1FeuO5Gj.net
結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない

しかし論理アドレスの方は何にもしてくれないのでフラグメンテーション起こして
連続したアドレスが確保出来なくなると、それで終わり、どうしようもない
32bitプロセスだと4GBしか空間がないから、まれに問題になる
64bitプロセスだと無尽蔵に空間があるから問題になることは現状ありえない
コメント1件

511
デフォルトの名無しさん[sage]   投稿日:2016/04/22 23:54:45  ID:imh5rD9T.net(2)
>510
> 結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない

MMUってのはアドレス変換するハードウェア
勝手に物理メモリを仮想メモリにマップしたりはしない
それをやるのはOS

512
デフォルトの名無しさん[sage]   投稿日:2016/04/23 00:19:34  ID:43LRl8T1.net
そもそも、ページサイズより粒度が細かいフラグメンテーションにはMMUはなんの効果もないしな。
コメント1件

513
デフォルトの名無しさん[]   投稿日:2016/04/23 05:06:22  ID:TwuNXQH0.net
autorelease()呼んだらコアダンプ糞osがwww

514
デフォルトの名無しさん[sage]   投稿日:2016/04/23 18:49:46  ID:RPK9BpXO.net
小さな粒度のフラグメンテーションは気にする必要ない
4KBならUTF-16で2000文字ぐらいしかない
32bitビットマップなら32x32ほとのサイズ

515
デフォルトの名無しさん[sage]   投稿日:2016/04/23 20:33:25  ID:PodTlhvX.net
キャッシュヒット率が落ちそう(コナミ)

516
デフォルトの名無しさん[sage]   投稿日:2016/04/24 01:18:30  ID:9YSuZOIq.net
>512
お前のプログラムはメモリを1ページしか使わんのかw?
フラグメンテーションで使用率が低いスカスカのページだらけになるのが問題なんだろうが。
コメント1件

517
デフォルトの名無しさん[sage]   投稿日:2016/04/24 01:38:34  ID:ai61/62A.net(2)
>516
へーお前はヒープを使わないのか
漢だな

518
デフォルトの名無しさん[]   投稿日:2016/04/24 08:38:51  ID:65va2BTL.net(3)
メモリー512バイトでどうやってヒープを使えと。

519
デフォルトの名無しさん[sage]   投稿日:2016/04/24 09:31:32  ID:HSA/nLEW.net(3)
ネイティブコードが必要な場面で中途半端に GC に頼るのが問題なのかもしれないが、もうネイティブコードが必要な戦場は限られた一部だけになってて、主戦場では GC は大前提の技術なんだから必要ないとか言われましてもですわ。

520
デフォルトの名無しさん[sage]   投稿日:2016/04/24 10:14:15  ID:W23a3TIA.net(2)
ページがスカスカになっても大丈夫
1ページ4KBとかだからね、十分小さい
32x32-32bitビットマップより小さい

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

521
デフォルトの名無しさん[sage]   投稿日:2016/04/24 10:14:59  ID:TFb7efu7.net(3)
androidしか知りませんみたいな事言われてもな


522
デフォルトの名無しさん[sage]   投稿日:2016/04/24 10:27:10  ID:W23a3TIA.net(2)
物理アドレスはページサイズで切り売りされるので
元から連続しているアドレスは必要ではなく
フラグメンテーションは問題にならない

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

523
デフォルトの名無しさん[]   投稿日:2016/04/24 10:37:41  ID:65va2BTL.net(3)
実はQtでデーモン作って動かしてるのだが、もう半年以上動き続けてる。
まさかこんなに問題が起きないとは。
案ずるより産むがやすしですぞ皆の衆。

524
デフォルトの名無しさん[]   投稿日:2016/04/24 10:58:37  ID:65va2BTL.net(3)
Qtで作ったのは一日ででっち上げる為だったのだが、意外なことに堅牢に動き続けてる。

525
デフォルトの名無しさん[sage]   投稿日:2016/04/24 12:08:49  ID:HSA/nLEW.net(3)
Qt でデーモン?
GUI が必要なデーモン?
コメント2件

526
デフォルトの名無しさん[]   投稿日:2016/04/24 12:13:06  ID:ynYywbEh.net(8)
>525
デーモンは通常フォアグラウンドじゃないのでUIを持ちませんぜ旦那。
コメント1件

527
デフォルトの名無しさん[sage]   投稿日:2016/04/24 12:25:33  ID:HSA/nLEW.net(3)
ならば何に何故どのように Qt を使うのだ?

528
デフォルトの名無しさん[sage]   投稿日:2016/04/24 12:45:58  ID:TFb7efu7.net(3)
>526
だからQtでデーモン?(クエスチョン)…なんじゃね?
加えてQtってGC関係あるのか?
たしかC++のライブラリーだよね?
コメント1件

529
デフォルトの名無しさん[]   投稿日:2016/04/24 13:02:46  ID:ynYywbEh.net(8)
等と意味不明な供述をしており。

530
デフォルトの名無しさん[sage]   投稿日:2016/04/24 14:52:01  ID:fu8W/E1c.net(2)
>525
Qt 使ってるからと言って QtGui 使ってるとは限らんけどね

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

531
デフォルトの名無しさん[sage]   投稿日:2016/04/24 14:52:56  ID:UKiBgwvV.net
daemonじゃなくてdemonなんじゃない?
デスクトップマスコット的な

532
デフォルトの名無しさん[]   投稿日:2016/04/24 14:59:36  ID:ynYywbEh.net(8)
俺が作ったのはウェブソケットによってサービスを提供するプログラムだ。
エンジンエックスをリバースプロキシとした。
このプログラムは常時数千の接続から大量のリクエストを受け付ける。
接続してくるクライアントは専用に作られQtで書かれている。
大量のリクエストはそれぞれ複数のデータベース検索を引き起こす。

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

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

533
デフォルトの名無しさん[]   投稿日:2016/04/24 15:05:02  ID:ynYywbEh.net(8)
ちなみにQt使ってなかったら一日でサービスを書き上げることは不可能だっただろう。
Qtは、その他のGUIライブラリ同様バグが多いのだが、GUIを抜いてみるとどうだろう、
意外なほどに堅牢なのだ。
何しろもう半年動きっぱなし。

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

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

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

534
デフォルトの名無しさん[sage]   投稿日:2016/04/24 15:05:44  ID:ai61/62A.net(2)
一例をもって一般化はできないだろ

535
デフォルトの名無しさん[sage]   投稿日:2016/04/24 15:05:53  ID:TFb7efu7.net(3)
>530
色々な言語から使えるのか
そういう場合Qtが使うメモリーなんかはどういう扱いなんだろうね
GC適用外な気がするけど知らないからこれでやめとくわ

536
デフォルトの名無しさん[]   投稿日:2016/04/24 15:08:01  ID:ynYywbEh.net(8)
Windowsで書いてLinuxで動かすことに、systemdは大いに貢献した。
従来のデーモンの作り方では、いろいろ煩雑なことがありすぎ、時間の制限から難しかっただろう。

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

537
デフォルトの名無しさん[]   投稿日:2016/04/24 15:11:43  ID:ynYywbEh.net(8)
Qtのバグの多くは、複数の環境に対応するため、その差異によって引き起こされているという結論を得た。

systemd万歳!

538
デフォルトの名無しさん[]   投稿日:2016/04/24 15:16:24  ID:ynYywbEh.net(8)
更にもう一つヒントがある。

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

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

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

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

539
デフォルトの名無しさん[]   投稿日:2016/04/24 15:28:56  ID:u6qUQj/U.net
ねえ訳分かんないんだけど
本人以外で理解してる人要るの?

540
デフォルトの名無しさん[sage]   投稿日:2016/04/24 15:55:24  ID:fu8W/E1c.net(2)
むやみに連投してる奴はたいていスルーでok

541
デフォルトの名無しさん[]   投稿日:2016/04/24 20:02:15  ID:ynYywbEh.net(8)
むしろ、わからないのに何故、一生懸命主張していたのかと。

542
デフォルトの名無しさん[sage]   投稿日:2016/04/24 20:22:44  ID:fcfJojCV.net
誰と戦っているんだろう…

543
デフォルトの名無しさん[sage]   投稿日:2016/04/24 22:39:17  ID:WrdDgWl7.net
マークスイープでメモリリークってどうやって起きるんだ?

初心者だから優しく説明してほしい
コメント1件

544
デフォルトの名無しさん[]   投稿日:2016/04/25 01:16:56  ID:/Pmm49fe.net
狭義の意味では起きない
もし君が気付かない間にオブジェクトへの参照を保持していたらどんなGCだろうが解放されない
それをリークというならリークする

545
デフォルトの名無しさん[sage]   投稿日:2016/04/25 13:44:57  ID:HSarKqaj.net
言い換えればダングリングポインタが発生しない
それだけ

546
デフォルトの名無しさん[sage]   投稿日:2016/04/25 14:51:13  ID:0xpbBk2N.net
マーク&スイープでもポインタの型情報を記録してないとリークしまくる

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

547
デフォルトの名無しさん[sage]   投稿日:2016/04/25 20:35:07  ID:4DDlKiNG.net
>543
どこからマークを始めるかが問題

548
デフォルトの名無しさん[sage]   投稿日:2016/04/29 18:58:56  ID:I1ppYkAy.net
>10
C#はGCの掃除処理を任意で呼び出せるだけだろ

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

549
デフォルトの名無しさん[sage]   投稿日:2016/04/29 22:46:31  ID:wZxrhoKH.net
C++/CLIはデストラクタが呼ばれるだけで、managedメモリの解放がGC任せなのは変わらんよ。

550
デフォルトの名無しさん[]   投稿日:2016/05/01 07:57: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

551
デフォルトの名無しさん[sage]   投稿日:2016/05/01 09:11:45  ID:qHyjCjkk.net
無視リストに追加と

552
デフォルトの名無しさん[]   投稿日:2016/05/02 21:54:41  ID:KYdaomRZ.net
GCCは失敗、Clangを使え。

553
デフォルトの名無しさん[sage]   投稿日:2016/05/02 22:21:36  ID:btgv3pKW.net
うるせーバーカ

554
デフォルトの名無しさん[]   投稿日:2016/05/04 17:42:43  ID:M8+arjAJ.net
gccは失敗。

555
デフォルトの名無しさん[]   投稿日:2016/05/27 12:06:01  ID:FwT+WNvC.net
良スレ発見した。Windowsは32bitで十分だな。32bitでもPAEで4GB超の
メモリ認識するし、仮想メモリは4GBのままだが、AWEを使うことにより
バンク切り替え的にメモリウインドウを切り替えられる
コメント1件

556
デフォルトの名無しさん[sage]   投稿日:2016/05/27 19:30:30  ID:hSijlNU2.net
>555
アプリはよくてもカーネルはつらい

557
デフォルトの名無しさん[]   投稿日:2016/05/28 04:39:26  ID:rTGB9SNh.net
メモリーは俺が確保してやる、任せろ。

558
デフォルトの名無しさん[sage]   投稿日:2016/05/29 07:51:44  ID:Ai+IvVh7.net
おう、この手は絶対、絶対に、死んでも離さねぇ!!
コメント1件

559
デフォルトの名無しさん[sage]   投稿日:2016/05/29 11:50:15  ID:9WWbP5OA.net
OSに載った気持ちでいなさい

560
デフォルトの名無しさん[sage]   投稿日:2016/05/31 22:56:21  ID:mtPUDASJ.net
>1みたいなやつは
研究室にヒキって、社会に出たことないんやろ

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

561
デフォルトの名無しさん[sage]   投稿日:2016/06/07 12:20:18  ID:4vppD7oq.net
>558
死んだら離せw

562
デフォルトの名無しさん[sage]   投稿日:2016/06/12 09:40:01  ID:mfUrI2Z0.net
死後硬直ですね

563
デフォルトの名無しさん[]   投稿日:2016/06/18 23:15:40  ID:03AgrRUX.net
指摘してるレスがなかったので言っとくが
循環参照は参照カウント方式+Cycle Collectorでも回収できるから
GCは必須じゃないぞ
興味があるならBacon Cycle Collectorで調べてみろ
コメント1件

564
デフォルトの名無しさん[]   投稿日:2016/06/18 23:22:46  ID:/B2fY0/K.net
学生の頃は循環参照できないことに困ってたけど、今となっては何時
循環参照が必要になるかさえ思い出せんな。

565
デフォルトの名無しさん[sage]   投稿日:2016/06/19 21:38:00  ID:evh9vaek.net
双方向リスト構造
コメント1件

566
デフォルトの名無しさん[sage]   投稿日:2016/06/19 22:17:16  ID:ao4WLgfX.net
>563
>Cycle Collector
いわゆるmark&sweep式とどう違うの?

567
デフォルトの名無しさん[]   投稿日:2016/06/20 01:16:50  ID:30YoNw6z.net
(コンパクションしてくれるんだろうか)

568
デフォルトの名無しさん[sage]   投稿日:2016/06/22 08:52:46  ID:I9Ep4uZo.net
vmが諸悪の根源な気がしてきた
コメント1件

569
デフォルトの名無しさん[sage]   投稿日:2016/07/06 07:12:12  ID:aYInvTWe.net
>568
まずガベージだらけの頭の中を整理すべき

570
デフォルトの名無しさん[sage]   投稿日:2016/07/16 10:10:08  ID:+8wH/95N.net(3)
>565
別に
単方向リストでもなるだろJK

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

571
デフォルトの名無しさん[sage]   投稿日:2016/07/16 10:13:41  ID:+8wH/95N.net(3)
△: リストの要素
○: リストの要素が保持するデータ

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

572
デフォルトの名無しさん[sage]   投稿日:2016/07/16 10:38:52  ID:6AR6MH2z.net
一般のグラフじゃなくてリスト構造の話だろ?
双方向リストはheadとtailへの参照があるが、単方向リストで循環参照は生じようがないが。
コメント1件

573
デフォルトの名無しさん[sage]   投稿日:2016/07/16 11:51:50  ID:+8wH/95N.net(3)
>572
すまんの>570の単方向リストは正確には循環リストもしくは環状リストと呼んだ方が良いかも試練、

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

574
デフォルトの名無しさん[sage]   投稿日:2016/08/22 17:06:41  ID:oW9zLe2W.net
循環してるかは後付けでオブジェクトをマークすれば判るんだし
扱うデータ構造から可能性の有無は予測できるし循環自体は大した問題じゃないよ
あ、これリークするなと思ったら対策すればいいだけ
問題は他人様のブラックボックスなライブラリを使う場合

575
デフォルトの名無しさん[sage]   投稿日:2016/08/22 19:24:37  ID:csr3LedD.net

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

576
デフォルトの名無しさん[sage]   投稿日:2016/08/22 19:33:58  ID:01M+MFvA.net
いまどきの子はブラウザアプリしか作れないから
ブラウザ再起動とかページ遷移で解決でしょうな

577
デフォルトの名無しさん[sage]   投稿日:2016/08/23 19:56:22  ID:cEt4cHHx.net
現在のGCが不完全なだけであって、
メモリは人が管理すべきでないという考え自体は正しいよ。

578
デフォルトの名無しさん[]   投稿日:2016/08/23 20:17:10  ID:xIKUFX4H.net
潤沢なメモリを用意してGCしない戦略
起動時間に限ってGCしなくても問題ない範囲であればGCしない戦略
結局こういうのが勝つ

579
デフォルトの名無しさん[sage]   投稿日:2016/08/23 20:29:14  ID:uPhg+qti.net
プロセスを細かく分けて寿命を短くすればそんなの考えなくて済む

580
デフォルトの名無しさん[sage]   投稿日:2016/08/24 13:32:09  ID:2RMcAgaj.net(3)
本当の意味での軽量プロセスをOSがサポートしてくれたら良いんだけどね
メモリプールみたいなもんなんだけど、OSのリソースも紐づいてて
メモリプール解放時にOSのリソースもちゃんと解放されるようなもの
マルチプロセスは非常に強力で良いんだけど
メモリ空間が別になるから色々面倒だしパフォーマンスも出にくい

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

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

581
デフォルトの名無しさん[]   投稿日:2016/08/24 16:03:33  ID:Ku8YOB4B.net
erlang最強

582
デフォルトの名無しさん[]   投稿日:2016/08/24 19:53:51  ID:B7v3wZLf.net
軽量プロセスより重量スレッドの方が実現できそう。

583
デフォルトの名無しさん[sage]   投稿日:2016/08/24 20:02:24  ID:971rg3P3.net
いつ無くなってしまうかわからんようなメモリのアクセスが簡単になってもほとんど使いみちないだろ。
安全性重視なら別プロセスにして、必要なデータだけ共有メモリで受け渡してのが妥当なところだろう。

584
デフォルトの名無しさん[sage]   投稿日:2016/08/24 20:18:52  ID:2RMcAgaj.net(3)
結論から言うと、Windowsにforkが無いのが面倒すぎるってことなんだけどね

585
デフォルトの名無しさん[sage]   投稿日:2016/08/24 20:32:21  ID:N/sC1Ga3.net(2)
>580
> 処理を中断する手段が関数側に用意されてなかったりする
具体的には?

586
デフォルトの名無しさん[sage]   投稿日:2016/08/24 22:11:21  ID:2RMcAgaj.net(3)
いやそんなもん、中断する手立てが用意されている方が珍しいだろ
コメント1件

587
デフォルトの名無しさん[sage]   投稿日:2016/08/24 22:31:11  ID:N/sC1Ga3.net(2)
>586
で、具体的には出せないと言うことね

588
デフォルトの名無しさん[sage]   投稿日:2016/08/25 11:39:37  ID:rs2QvvZe.net
元々はスレッドが軽量プロセスって呼ばれていたりしたんだがな(アドレス空間の切り替えが不要だからプロセスより切り替えが軽い)

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

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

589
デフォルトの名無しさん[sage]   投稿日:2016/08/25 11:59:23  ID:8gaIkILP.net
メモリ空間がつながっていること自体はそれほど考慮してないんよ
単にWindowsはマルチプロセスがしにくい
forkあったらちょっとした処理を別プロセスで実行するの、便利じゃん
片づけはプロセスごと殺して終わりだし

590
デフォルトの名無しさん[sage]   投稿日:2016/08/25 15:41:54  ID:8f3yfXIl.net
ほしいのはLinuxでいうclone(2)やね

591
デフォルトの名無しさん[]   投稿日:2016/09/03 00:41:24  ID:XSHFkVCg.net
https://cedil.cesa.or.jp/cedil_sessions/view/1484
リアルタイムGCの実装が凄い

592
デフォルトの名無しさん[sage]   投稿日:2016/10/22 08:52:04  ID:v44cYKg6.net
GCもハードウェアに支援させれば全部解決するよ
リアルタイム処理含めてね

593
デフォルトの名無しさん[sage]   投稿日:2016/10/22 10:51:46  ID:O48rD9qT.net
再起動最強説

594
デフォルトの名無しさん[]   投稿日:2016/11/14 22:33:26  ID:A2iFoZHP.net
固定領域として静的にグローバル変数化、バッファ化すればいいだろ、
それを汚い言うやつがいるが、

潜在BUGだらけでどうにもできないそれのほうが汚いわ。
コメント1件

595
デフォルトの名無しさん[sage]   投稿日:2016/11/14 23:45:18  ID:JD+cxKWX.net
例えばChromeとかFirefoxとかが静的にメモリアロケートしてたらどうなるか
コメント1件

596
デフォルトの名無しさん[sage]   投稿日:2016/11/14 23:59:22  ID:f4osfHdm.net
そういう発想、嫌いじゃないよ
静的にできるものは、なるべく静的にすべし
俺もそう思う
妙なからくりじみたことにはもう興味が湧かなくなった
最初のころはGCのメカニズムが面白いと感じていたが、もうそういうの、無い

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

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

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

599
デフォルトの名無しさん[sage]   投稿日:2016/11/15 00:24:03  ID:PldPJ2O3.net(4)
これがC++が未だにかたくなにマークスイープ系GCを搭載しない理由である
C++を書くプログラマはweak_ptrを適切に使えるものだという前提のもとに
マークスイープ系GCにまつわる数々の問題点を排除したのだ
マークスイープ系GCで有利なのは唯一循環参照だけであり
そこさえ気を付けることができれば
それ以外の部分に関しては参照カウンタのほうが優れている
C++は別に時代遅れなわけじゃなく、そういう選択をしたというだけ
今になって考えるとその選択は正しかったと思う

600
デフォルトの名無しさん[sage]   投稿日:2016/11/15 04:04:15  ID:9A/eUvIY.net(2)
メンバーにdisposeしなければならないような設計が良くない。そんなものはメソッド内のローカル変数に止めるべき。
それすらも理解できず(考え付かず)にただ一律なんにでも同じ考え方を押し込むのはただの愚行。
ありもしない、回避可能な杞憂をただ恐れるのは、勉強不足か進歩が止まっているだけ。
だから皮肉を込めて老害と呼ばれる
コメント1件

601
デフォルトの名無しさん[sage]   投稿日:2016/11/15 04:09:46  ID:9A/eUvIY.net(2)
日本語おかしかった。
メンバーにdisposeしなければならないような物を持たせるのが良くない
でした。

602
デフォルトの名無しさん[sage]   投稿日:2016/11/15 05:19:19  ID:ulUg8AFG.net(2)
>594
参照カウンタよりも固定バッファを動的に確保ですね判ります

603
デフォルトの名無しさん[sage]   投稿日:2016/11/15 05:20:35  ID:ulUg8AFG.net(2)
>595
firefoxは解放が遅いのでそれやってるのと実質同じ
realplayerとかもそうだったな

604
デフォルトの名無しさん[sage]   投稿日:2016/11/15 08:18:37  ID:wcWx6QZb.net
>600-601
よくないって言われてそうせざるを得ない場合はいくらでもあるしなぁ
例えば動的に出力先を切り替えられるログクラスみたいな奴をどう書けと言うんだろ?
コメント2件

605
デフォルトの名無しさん[]   投稿日:2016/11/15 09:05:11  ID:P8K+NdWV.net
>597
スマポとデストラクタの必要性は関係ないだろ…
deleteの必要がない、とか、デストラクトを考えなくて良いってことだと思うけど。

606
デフォルトの名無しさん[sage]   投稿日:2016/11/15 10:48:15  ID:4QSE1fRA.net
スタック変数の 0 クリアすら嫌がる C/C++ が GC 搭載とか夢見すぎ
コメント2件

607
デフォルトの名無しさん[sage]   投稿日:2016/11/15 10:53:43  ID:PldPJ2O3.net(4)
struct test
{
  std::shared_ptr<int> ptr;
  test(){ ptr = new int; }
};

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

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

608
デフォルトの名無しさん[sage]   投稿日:2016/11/15 11:05:47  ID:TNYjuRyh.net
>606
ツボったw
効率至上が利点であり特徴だもんな

609
デフォルトの名無しさん[sage]   投稿日:2016/11/15 12:45:52  ID:LZ5unIkv.net
>607
それptr.reset()使うんじゃないの?

610
デフォルトの名無しさん[sage]   投稿日:2016/11/15 13:34:38  ID:bbRnuBLg.net
グローバルが嫌われたのは
疑似マルチプロセスでメモリを共有していた時代の汚物だろ
今みたいなOSのメモリ管理ならアプリ単位グローバル常套

611
デフォルトの名無しさん[sage]   投稿日:2016/11/15 23:45:20  ID:nDIaGem/.net
C#/C++よりRustだろ
参照カウンタのオーバーヘッドすらない
Firefoxに期待

612
デフォルトの名無しさん[sage]   投稿日:2016/11/16 04:04:29  ID:EhKul/vA.net(2)
>604

http://ideone.com/9L3kQp

これじゃいかんのか?
おかしかったら教えて
コメント1件

613
デフォルトの名無しさん[sage]   投稿日:2016/11/16 12:42:03  ID:KQ3Yixih.net(2)
>612
Write する度に WriteTypeA とかを生成/破棄するってこと?
ログとかならその方が望ましいケースもあるかもしれないけど、例えば性能上の問題でストリームは開きっぱなしにしたいとかもあるでしょ
コメント1件

614
デフォルトの名無しさん[sage]   投稿日:2016/11/16 14:56:37  ID:a2T+Z3SD.net
>613
開きっぱなしにしたいスコープは?
スコープを一つのメソッドにして、同じようにすればいいじゃない

コードが必要なら夜にでも書くよ
コメント1件

615
デフォルトの名無しさん[sage]   投稿日:2016/11/16 19:17:42  ID:KQ3Yixih.net(2)
>614
スコープを動的に変えたい場合を想定してるんだが
実行中にログファイルを変更できるアプリケーションとか見たことないの?
コメント1件

616
デフォルトの名無しさん[sage]   投稿日:2016/11/16 23:34:22  ID:EhKul/vA.net(2)
>615
ログファイルであれば日付で切り替えとかあるね。

そしたらストリーム開きっぱで日付が切り替わったら、閉じて新しいの開き直すとかあるわ。

いつもlog4とか使って主処理と切り離してたから考慮から抜けてたわ。

俺の意見はdb接続とかで一部にしか当てはまらんので、
「基本的には」とか
「リソースを管理する必要があるもの」とか前提がつくね。すまん。

617
デフォルトの名無しさん[sage]   投稿日:2016/11/19 06:41:14  ID:4ie0coBz.net
ログファイルはログが確実に記録されるのが使命であって性能は二の次なのだよ
よって開きっぱなしは論外
性能で問題が出るなら吐く量を調節すればいいだろう
コメント1件

618
デフォルトの名無しさん[sage]   投稿日:2016/11/19 08:38:51  ID:eBLDMII7.net
開きっぱはなんでダメなん?
コメント1件

619
デフォルトの名無しさん[sage]   投稿日:2016/11/19 08:52:00  ID:YtkNE2sc.net(2)
flushすればいいな

620
デフォルトの名無しさん[sage]   投稿日:2016/11/19 10:16:22  ID:HaGDkE41.net(2)
>618
アプリケーションエラーとか異常終了した時にバッファされてる内容が書かれないことがあるから
異常終了した時はまさにそのエラーになる直前のログが欲しいのに〜
ってなる w

ただログってそういうログばかりじゃないし Apache のアクセスログみたいにいちいち閉じてたら全然間に合わないって現実を知らない >617 はもう少し経験積むまで黙ってた方がいいと思う
コメント1件

621
デフォルトの名無しさん[sage]   投稿日:2016/11/19 14:20:53  ID:YtkNE2sc.net(2)
>620
それは開きっぱなしが問題なんじゃなくてflushしてないことが問題なだけで見当違い
コメント1件

622
デフォルトの名無しさん[sage]   投稿日:2016/11/19 14:29:51  ID:HaGDkE41.net(2)
>621
>604 から読み直せよ
見当違いはお前の方だよ...

623
デフォルトの名無しさん[sage]   投稿日:2016/11/19 14:34:26  ID:WWFUnGVk.net
とこのように、相手を互いに見当違いであると罵り合うのであった
しかし、それは正しい
両者とも正しい

624
デフォルトの名無しさん[sage]   投稿日:2016/11/19 15:37:17  ID:O7mQP4/b.net
スコープの話してるのに flush とか頭わいてるだろ

625
デフォルトの名無しさん[sage]   投稿日:2016/11/19 21:51:13  ID:WZ8TOo4I.net
null安全をアピールしてる人間はObjCerから見ると補助輪付き自転車を渡してきてこれ安全だから絶対に乗れよと言ってくる頭おかしいおじさんにしか見えない
Swift移行がこじれるだけだから黙っといて欲しい

626
デフォルトの名無しさん[]   投稿日:2016/11/21 14:59:21  ID:qSFgYSXv.net
浜矩子・著
『アホノミクス完全崩壊に備えよ』
『どアホノミクスへ最後の通告』
『みんなで行こうアホノミクスの向こう側』


抑制のない成長に基づく経済政策は終焉

日本国民はどう対処すればいいのか。
新しい政権は民意を反映し、
食糧、住宅、健康、教育、最後に防衛です。
国民の意志を裏切ることは、
極端な場合、自殺や殺人にまでつながります。
民衆の指導者は
職業的政治家ではない人々から見つかるのです。

世界平和の脅威は、
イスラエル、イラン、アメリカです。
イスラエルの役割は跪いて、
パレスチナに許しを請うことです。
アメリカによる他国の虐待に
反対の声を上げなければなりません。
彼らは今世紀(21世紀)を
この帝国が出来上がるアメリカの世紀と呼ぶ。
しかし、そうはならないでしょう。
彼らが世界中に‘民主的’制度を確立したい
という衝動(世界を支配する)をコントロール
するのは、マイト レーヤの任務です。

非常に間もなく
マイト レーヤをテレビで見るでしょう。
彼は「匿名」で働いております。

627
デフォルトの名無しさん[sage]   投稿日:2016/12/08 09:10:56  ID:FEYStmIt.net
小規模ならGCのメリットは大きいのかもしれないが、大規模または大量にメモリを食うプログラムにはGCは向いてないのではないか。

あんまり例を知らないが、JAVAで動くマインクラフトのデバッグ画面でメモリ使用量みたら、めまぐるしく増加して一気に減ってるのみてびっくりした。
コメント1件

628
デフォルトの名無しさん[]   投稿日:2016/12/13 13:02:48  ID:XUF2n21y.net
GC周りに付いて書かれたネットの記事読んできたけど
オブジェクトが生成されては次々と死んでいき
生きてるオブジェクトより死んだオブジェクトが多い場合の方が速くなるっぽい

>627
そう考えると長命のオブジェクトが大量にある方が(性能的には)問題だが
マインクラフトがそれかは知らない

629
デフォルトの名無しさん[sage]   投稿日:2016/12/15 23:33:53  ID:Z/98FfuD.net
>606
C++はGC支援のメモリモデルが標準に入った
と言ってもコンサバGCライブラリ向けだけどな

630
デフォルトの名無しさん[]   投稿日:2017/01/18 11:38:56  ID:A+XqqRn6.net
漏れたときの調査が大変
安心してると痛い目にあう

631
デフォルトの名無しさん[]   投稿日:2017/01/20 16:23:16  ID:4Q3o1w03.net
参照カウントは循環参照の問題が起こるだけじゃなくて
意外と遅いって聞くけどマジで?

・メモリをOSから直接確保・解放するのは意外と遅い
・マルチスレッドで参照カウントを使うにはアトミックな操作が必要
・カウントを自動化すると不必要な参照カウントが起こる
とかで

対してトレーシングGCの弱点は回収時に止まる時間が長いところか

その対策か、V8やOracle JavaにはGCの時間を制限する機能があるみたいだが
それってどうなんだ?

632
デフォルトの名無しさん[sage]   投稿日:2017/01/20 23:17:39  ID:2XlTkpSB.net
まじ

633
デフォルトの名無しさん[]   投稿日:2017/01/22 15:00:56  ID:lyHWqZIh.net
^ナマポ

634
デフォルトの名無しさん[]   投稿日:2017/01/22 18:20:35  ID:CvVvUjG5.net
ストップ・ザ・ワールドの問題さえなくなればGCが最強ってこと?
コメント1件

635
デフォルトの名無しさん[sage]   投稿日:2017/01/22 18:44:59  ID:2ikRDhsq.net
>634
フルGCの危険があるという点で最強になりえない

636
デフォルトの名無しさん[sage]   投稿日:2017/02/20 19:16:44  ID:NKdiRgAe.net
バイオハザード7は28万行のC#コードでできててビルド10秒らしい。
独自VM、独自GCだとか。
コメント1件

637
デフォルトの名無しさん[sage]   投稿日:2017/03/20 22:46:15  ID:USOySpAW.net
>636
ゲームで28万ステップって長すぎね?

638
デフォルトの名無しさん[sage]   投稿日:2017/04/01 12:49:43  ID:ZgIqHRoc.net
バイオの資料見つけた。
https://www.slideshare.net/mobile/capcom_rd/re-engine-72302524

FrameGCって独自アルゴリズムなのか。
更新情報
・スレッド一覧ページで過去ログのタイトル検索・一覧表示ができるようになりました(2016/1/20)
NGワード登録
登録する
スレッド内検索

プログラム板 タイトル検索

このスレッドが人気です(実況系)
おはよう!時代劇 暴れん坊将軍3 #121(第127話)[字][再] (860)テレ朝実況
映画天国 「ハート・オブ・ウーマン」★2 (678)NTV実況
月曜から夜ふかし★3[無断転載禁止]&#169;3ch.net (887)NTV実況
【陸上】 世界リレー選手権2017 2日目 (804)TBS実況
橋下×羽鳥の番組★3 (724)テレ朝実況
しゃべくり007★3 (902)NTV実況
貴族富豪探偵 第2話 ★4 (898)フジ実況
360°まる見え!VRアイドル水泳大会<Mナイト>★1 (692)フジ実況
このスレッドが人気です(ニュース系)
【北朝鮮】「核攻撃手段、発射待機」=人民武力相が威嚇★7 (598)ニュー速+
【北朝鮮】「核攻撃手段、発射待機」=人民武力相が威嚇★6 (1000)ニュー速+
【北朝鮮】「核攻撃手段、発射待機」=人民武力相が威嚇★5 (1000)ニュー速+
【北朝鮮】「核攻撃手段、発射待機」=人民武力相が威嚇★4 (1000)ニュー速+
【国際】新たな対北朝鮮制裁を準備=北朝鮮は「本物の脅威」と警告―トランプ米大統領 (720)ニュー速+
【芸能】「日本のドラマは見ない方がいい。視聴者無視で芸能プロダクション先行の不適切なキャスティング」 デーブの発言に賛否★4 (517)音楽・芸能ニュース
【北朝鮮】「核攻撃手段、発射待機」=人民武力相が威嚇★3 (1001)ニュー速+
【芸能】「日本のドラマは見ない方がいい。視聴者無視で芸能プロダクション先行の不適切なキャスティング」 デーブの発言に賛否★3 (1001)音楽・芸能ニュース
プログラム板の人気スレ
オブジェクト指向って自然な文法だな 3 (574)
Excel VBA 質問スレ Part47 (688)
【統計分析】機械学習・データマイニング15 (147)
次世代言語議論スレ[Go Rust Kotlin Scala]第4世代 (76)
ねねっちと一緒にプログラムを勉強するスレ第2話 (566)
スレ立てるまでもない質問はここで 147匹目 (388)
C言語なら俺に聞け 139 (795)
C#, C♯, C#相談室 Part92 (1000)
推薦図書/必読書のためのスレッド 81 (903)
C++相談室 part130 (258)
くだすれPython(超初心者用) その33 (305)
ふらっと C#,C♯,C#(初心者用) Part127 (374)
Git 15 (672)
Visual Studio 2017 Part2 (138)
Pythonのお勉強 Part52 (870)
Visual Studio 2015 Part8 (713)
Xamarin Part3 (824)
Swift part10 (410)
Java入門・初心者質問スレ Part.3 (122)
C# vs Java どっちが好き? その3 (186)
Ruby 初心者スレッド Part 59 (990)
クラス名・変数名に迷ったら書き込むスレ。Part27 (943)
プログラミング言語 Rust 2 (811)
HSP総合スレ【part 10】 [無断転載禁止](c)2ch.net (300)
【JavaScript】スクリプト バトルロワイヤル55【php,py,pl,rb】 (643)
【初心者歓迎】C/C++室 Ver.100【環境依存OK】 (629)
【PHP】下らねぇ質問はここに書き込みやがれ 8 (148)
このサイトについて
このサイトは2ちゃんねるからデータを取得し、表示するサービスです。
画像のインライン表示機能について
画像のURLの後ろにある[画像をインライン表示]をクリックすると、URLの下に表示します。
表示される画像は横幅100pxに縮小されていて、クリックすると原寸で表示します。
このサイトの特徴
1)スレッド内検索ができます
2)レス(「>>1」など)のポップアップができます
3)不適切な言葉を含む投稿を表示しません
4)ページ内で画像を直接表示できます
5)2ch他スレッドへのリンクはタイトル・板名つきでリンクします
6)すっきりとしたデザインで表示します
7)最新スレや前スレをチェック・一覧表示します
8)NGワード機能の搭載でイヤな言葉が目に入りません
9)荒らしを自動チェックします
10)スレッド内・同一IDの書き込みだけ表示できます
11)レスの返事をレスされた発言の下に表示する「まとめビュー」が利用できます
12)シリーズ化したスレッドの一覧を表示します
13)最新のスレッドがある場合はお知らせします
削除について
こちらをご覧ください
機能要望について
現在機能要望受付中です。
問い合わせについて
こちらのページからどうぞ
広告


首都圏の方、ソフトバンク光オススメですよ


このサイトは2ch.scからデータを取得・表示しています。削除などについてはこちらをご覧ください。 アクセスモード:差分取得 - 新着書き込みなし(304)