2ちゃんねる★スマホ版★■掲示板に戻る■全部1-最新50

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

1 :
2015/11/18(水) 23:24:59.79 ID:BUQ68wTG
GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。
以下GCと記す

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

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

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

前スレ
GCは失敗。メモリは自分で管理せよ!
http://peace.2ch.net/test/read.cgi/tech/1412986420/
2 :
2015/11/19(木) 00:01:54.17 ID:6rd98MPK
なるべくスコープを狭くして長時間存在するオブジェクトを無くす
以上
3 :
2015/11/19(木) 00:14:59.30 ID:d0YkbYhs
仮にmalloc/free型を長時間動かしてたらフラグメントが酷いことになるぞ
そういう問題もコピーGCなら一気に解消できるしGCの方が耐久力があるよね
4 :
デフォルトの名無しさん
2015/11/19(木) 01:28:02.40 ID:6x5+bHoL
GCの無い時代のプログラムでフラグメントが問題になった例をあげてみろよゴミッカスw
5 :
2015/11/19(木) 02:10:36.00 ID:C+wDd3AI
>>3
それGCのない言語の問題じゃなくてC/C++の問題だろ
コンパクションとGCはあくまで別だし
6 :
デフォルトの名無しさん
2015/11/19(木) 08:58:13.78 ID:JIJtk7D/
ブラッド・コックスとトム・ラブがObjective-Cを作り「この言語はCのメモリ安全性とSmalltalkの高速性を合わせたものだ」と宣言する。
現代の歴史家は2人が失読症ではないかと疑っている。
https://twitter.com/okdshin/status/666903312151613440
7 :
2015/11/19(木) 23:17:01.16 ID:SYMznuBH
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 :
2015/11/19(木) 23:18:18.19 ID:SYMznuBH
525 :名無し~3.EXE:2015/11/19(木) 22:13:05.49 ID:CEKgHuEl
展開されない時
リロードで展開される場合もあるが
リロードで展開ない場合もある
9 :
2015/11/20(金) 09:27:53.75 ID:em+ldceb
メモリ管理は自分でやった方が漏れが出るでしょ
規模がでかくなればなるほどリスクが大きくなる
10 :
デフォルトの名無しさん
2015/11/20(金) 15:32:07.18 ID:hg0nWx/i
C#の基本は自動だけど部分的に手動にできるハイブリッドがいいと思うよ
確保量の大きい画像なんかを扱っているとどうしても手動で解放したいタイミングもあるし
11 :
2015/11/20(金) 20:28:57.10 ID:QlSu2hgW
まともな言語ならオプションくらいついてる
12 :
2015/11/20(金) 22:40:56.83 ID:h5Le2W6O
>>10
それが理想的だけど、C#ってそんなことできたっけ?
13 :
2015/11/21(土) 09:07:54.65 ID:+qGvO8oq
>>12
出来るよ。
ポインタも使える
14 :
2015/11/21(土) 10:29:39.51 ID:7nxNhgSu
調べてみたけどよくわからんな。
もしかしてアンマネージなメモリを確保してデータ領域に使う話?
15 :
デフォルトの名無しさん
2015/11/21(土) 16:16:49.90 ID:iOucF00Z
アンwwwwマネージwwww
無理に横文字使わなくていいですよwww
16 :
2015/11/21(土) 17:40:45.99 ID:7nxNhgSu
横文字じゃなくてマイクロソフトの用語なんだが?
17 :
2015/11/21(土) 17:47:25.64 ID:/uyrLxeD
c#が残念なんのはC++とデストラクタの呼ぶれるタイミングが違いすぎて移行が大変すぎることだ。
結局、手動でデストラクタを呼ばなきゃならない。GCの利便性がほとんどなし。
18 :
デフォルトの名無しさん
2015/11/21(土) 19:18:42.53 ID:iOucF00Z
>>16
涙ふけよwwww
19 :
デフォルトの名無しさん
2015/11/21(土) 21:36:26.09 ID:tqUpuiXF
>>9
自動ならメモリリーク等々発生するわけがないのに発生している
この原因はプログラマなんだけど、結局メモリ管理から解放されてないなら最初から管理する方針でいいじゃん
20 :
デフォルトの名無しさん
2015/11/22(日) 01:48:28.16 ID:7AflF1fM
メモリ管理を楽にするためにあるわけで人間が全部面倒みんのとは違うだろ
21 :
デフォルトの名無しさん
2015/11/22(日) 04:41:20.06 ID:WFE6EpHf
やっぱりGCのほうがいいかな大規模になってくると
Cでリークはしてないけど本来開放すべきタイミングで開放してないでメモリいっぱいになるのは防ぎやすいと思うし
22 :
デフォルトの名無しさん
2015/11/22(日) 07:04:28.69 ID:MUaNGGyB
>>20
楽になってメモリリークがなくなるならいいけど、メモリリーク発生するわ
プログラマがメモリ管理なんてしなくて大丈夫、とメモリの扱いが雑になって意図しないタイミングで解放されたりされなかったり
最初から管理するという方針で教えないから、こんなことになる
管理漏れをGCがうまいことやってくれる。でもGCにやらせるようだと恥。
というくらいで教育すべき
23 :
デフォルトの名無しさん
2015/11/22(日) 07:12:51.89 ID:MUaNGGyB
メモリ管理すらまともにできないやつが寿命や世代やら管理できるわけがない。
24 :
2015/11/22(日) 10:54:50.51 ID:MJCWCZ10
GCそのものではなく新人教育や解説書が最初のスタンス間違えたんだよ。
GC=メモリ管理適当
という認識作ったから、GCに新しい名称つけて
教育や解説書では、メモリーの確保から解放まできちっと説明し直したほうがいい
25 :
2015/11/22(日) 12:31:51.68 ID:Qlq25ltW
GCって完全なものだと思ってたから、C#案件でメモリリークの調査にえらく手間がかかった
GCはダメな子って認識は必要だな
26 :
2015/11/22(日) 12:38:37.22 ID:mfzN9aoV
C/C++はライブラリレベルでメモリリリークの検査もテストも書けるけど
GC前提言語だとその辺がごっそり抜け落ちて後で問題になる
27 :
2015/11/22(日) 12:42:49.74 ID:zNwKjU3u
メモリ管理できない人がお気楽で作れば、GCあっても・・・・
28 :
2015/11/22(日) 13:08:14.89 ID:KDgQ57Ye
>>25
結局どんなバグだったんだい?
29 :
2015/11/22(日) 16:57:06.63 ID:vggKhYqJ
C++でもスマートポインタ使えば勝手に開放されるよ

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

手続き型言語は処理の順番が重要なのに
いつ実行されるか分からないってのは中々チャレンジャーだし大掛かりな話だね
30 :
2015/11/22(日) 17:32:48.70 ID:vggKhYqJ
前スレでも書いたけど、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++のデストラクタのように芋づる式に勝手に呼ばれない事に有る
だから手動で芋づる式に呼び出すコードを書かなくてはならない
31 :
デフォルトの名無しさん
2015/11/22(日) 18:20:40.59 ID:WFE6EpHf
Formなんかも参照が亡くなったら強制的に殺すべきだったと思うわ
ファイナライザーの処理がひどいことになると思うけど
32 :
2015/11/22(日) 22:36:02.07 ID:iT1tZCI1
またお前か
メンバに持つのが間違い
33 :
2015/11/22(日) 23:18:34.23 ID:7zQV9dKP
無茶いうな
34 :
デフォルトの名無しさん
2015/11/23(月) 08:11:32.17 ID:XNOSKZeE
解放処理をしなくてもGCがやってくれる。
でも、ソースに解放処理が書いてあれば、後から見たらあぁここで用済みになったのかとわかる。

可読性は非常に重要よ。
35 :
2015/11/23(月) 15:41:37.20 ID:qRZYsqEh
解放処理のタイミングが制御できないと、解放して欲しくないタイミングで解放されて
挙動が変わることがある
リアルタイム性が要求されるシステムでこれで困ったことがある(そもそもそんな言語使うなって話だが)
36 :
2015/11/23(月) 17:14:59.57 ID:JWzW06M6
>>35
それはあまりない
挙動が変わるというか停止するというのならあるのかもしれないが
37 :
2015/11/23(月) 17:21:44.69 ID:y4njP/wV
うわっ頭のおかしいQだ
38 :
2015/11/23(月) 17:22:22.95 ID:9XGqpqVu
>解放して欲しくないタイミングで解放

なんでそんなことになったの?
参照切ってなきゃGCの対象にならないはず
39 :
2015/11/23(月) 17:24:18.17 ID:OK+rBFmG
空きメモリによって使用するアルゴリズム変えたりする。
だから実行前にGC手動で走らせて、できるだけ空きメモリ増やしたりとかする。
できるだけ開放したいのに過負荷でまだメモリに余裕あるからGC走らないってのが困る。
40 :
デフォルトの名無しさん
2015/11/23(月) 17:46:43.41 ID:XNOSKZeE
メモリの解放漏れってさ、とどのつまり下手だからするんだよね
下手なやつにはプログラムを組ませないってのが鉄則だと思うの
41 :
2015/11/23(月) 19:25:05.71 ID:6m6E/SfN
c++11のshared_ptrの参照カウンタってそもそも要るんだろうか?
複数のオブジェクトが所有権を持ちあう必要性に迫られる事がないんだけど
weak_ptrの対応だけあれば良くない?
42 :
2015/11/23(月) 19:56:47.15 ID:+Ddm9172
リソースを共有する場合なんかは使うと楽だよ

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

巡回参照のある場合も自動で開放したいという、たったこれだけのために
いつ実行されるか分からない上に重いマークスイープ式GCを導入するのは
業界全体の早とちりだったようだね
43 :
2015/11/23(月) 20:06:26.94 ID:+Ddm9172
最近のC++はdeleteを直接書かないだけでなく、最早newも直接書かない方向
std::make_shared<int>() って書くよね
始めからshread_ptrで受け取るから、循環参照だけ気をつければ
リークする余地がないよね
RAIIも健在で、C#みたいにIDisposableとか要らない
デストラクタも芋づる式に呼び出されるから
>>30で書いたような問題も起きないよ
44 :
2015/11/23(月) 20:09:18.99 ID:OK+rBFmG
C++は益々混沌としているのか。手に負えん。
45 :
2015/11/23(月) 20:35:23.62 ID:PopzBtGV
>>41
糞便利な参照カウンタを使わないなんてC++使う意味なし
46 :
2015/11/23(月) 22:58:10.32 ID:6m6E/SfN
>>42
それはManagerやHolder的なものを書かなくて良いってことを言ってるの?
それって大体一時しのぎで大抵後々リソース管理以外にもそういった管理クラスが必要になるケースがほとんどじゃない?

>>45
ねーよ
47 :
2015/11/24(火) 00:26:10.23 ID:f4S6RtN7
うーん質問がアバウトすぎたな。もう少し具体的に書くわ

例えば2chのある板を管理するプログラムを書くとして
BoardクラスとThreadクラスを想像してみてくれ
BoardはThreadオブジェクトを管理するが、Threadは
産まれたり死んだりと揮発的で寿命が定まらないと。
で各Threadは何らかの共有リソースを持つと。
例えば一度読み込んだ画像を各スレッドで共有したいとかが
考えられるけど、画像オブジェクトをshared_ptrで共有するのは
適切ではない
なぜならある瞬間に産まれたThread群がひとつの画像を共有する
からといってshared_ptrで持たせたとしても、後の更新時に
更にその画像を共有したいThreadが現れたときに、画像が
すでにあることを何らかの形で知れないといけないから。
結局Boardなんかが画像オブジェクトのコンテナを持つ必要が
あってそのコンテナへの追加と削除のために別の共有の
仕組みが必要になるんだよ。例えばThreadがBoardに画像を
リクエストして参照カウンタを持ったアクセサを返すようなもの
だから所有権はBoardひとりが持てばよくてshared_ptrを
使う必要がなくなるという理屈
こういったケースを踏まえてもshared_ptr使うケースって
ほとんどなくね
48 :
デフォルトの名無しさん
2015/11/24(火) 01:21:45.79 ID:0dqdPvnh
IDisposableの問題はDisposeを呼ばなければリークするものとそうでないものの混在だろ
49 :
2015/11/24(火) 03:22:06.30 ID:fjQi4YH+
>>47
マルチスレッドプログラム書いてみろよ
shared_ptrがないと泣くぞ
50 :
2015/11/24(火) 05:26:33.27 ID:f4S6RtN7
>>49
いやいくらでも書いてるけど基本一緒
というか上の例もそのままマルチスレッドに適用できる話でしょ

例えばproducer consumerならproducerが所有権を持つし
thread per messageなら共有データはホストが持って固有データは
個別スレッドで持つだけ
むしろマルチスレッドの場合、所有者をより厳格に決めとかないと
泣く事になるぞ
51 :
2015/11/24(火) 12:31:47.38 ID:HvLaDP3z
所有権って・・・・

unique_ptrを使うと勝手に所有権が移動してしまうし
生のポインタを使うんならわかるけど
52 :
2015/11/24(火) 12:53:55.99 ID:2IyJeQ15
shared_ptrで複数人が所有権を持っても良いんだぞ
上下関係さえしっかりしていれば良い
53 :
2015/11/24(火) 13:15:01.57 ID:HvLaDP3z
そんなの分かってるんだが
>>50の人はどう考えてるのか
54 :
2015/11/24(火) 16:23:15.08 ID:f4S6RtN7
>>51
今のC++からshared_ptrをそのまま無くせって言ってるんじゃないぞ
shared_ptrのコピーを禁止にしてweak_ptrの対応だけあれば良くないかって事
そもそも何でそんなこと言うかっていうと、
GCない言語→循環参照ガー。みたいによく言われるけど使わないで
済むなら静的解析で循環参照の起こり得るケースをエラーにしてしまう
って解決方法もあるかなと思っただけ
あとshared_ptrとweak_ptrはアトミック操作とメモリバリアを必要としうるから
それに頼った設計は疑問を感じる
55 :
2015/11/24(火) 16:37:54.42 ID:f4S6RtN7
一応言っとくと静的解析のくだりは新しい言語を
設計するとした場合の話ね
C++だとほぼ不可能だろうから
56 :
2015/11/24(火) 16:39:45.81 ID:1SleeXaD
せっかくC#は新設計なのにいろいろ失敗が含まれてるよな。

ヘジはなにやってんだか。
57 :
2015/11/24(火) 18:29:34.50 ID:lNjW2jss
大企業は、
中小企業を奴隷にさせる事を第一に考えたツールしかリリースしてないよ
失敗ではなく全部わざと。
58 :
2015/11/25(水) 07:39:30.16 ID:JnM8vxaH
メモリ管理テケトーなやつはその他のリソース管理もテケトー
59 :
2015/11/25(水) 17:12:00.25 ID:Sra0FKsR
そもそも自分のリソース管理がしっかり出来てる人は・・・
60 :
2015/11/27(金) 12:24:34.85 ID:ZRdaHx9T
>>31
Formはnull入れてあげないといけないんだっけ?

なんか、場合場合によってnull入れてあげないといけなかったり入れなくてもよかったり。
ならnull入れるで統一でいいじゃんと思った
61 :
2015/11/27(金) 22:35:05.80 ID:CyIO1ZuX
Rust使えば解決
62 :
デフォルトの名無しさん
2015/11/28(土) 06:44:39.29 ID:CKvy7+My
中の細かい実装まで知らないんだけど、
A = new A()
Loop Begin
  処理
  A = null
  A = new A()
Loop End
とか、nullをセットをGCって見張ってるの?又はGCに伝えているとかあるの?
63 :
2015/11/28(土) 13:02:34.51 ID:Qyl/1Ad+
違うよ
newが動いた時点で中の人がメモリが足りない!って騒いで初めてGCさんお願いします!GC「やれやれ・・・
っていう仕組みなんで
>>62の例のnullの代入は無駄
64 :
2015/11/28(土) 13:08:02.55 ID:Qyl/1Ad+
いや無駄じゃないか
代入演算子の順序の関係でnewの後に代入が起こるから
Aを事前にnullすることでGCさんが回収できるオブジェクトが1個増える
65 :
2015/11/28(土) 13:10:10.16 ID:rTI66XO9
書いたほうが保守性は高く、意味がある。
66 :
デフォルトの名無しさん
2015/11/28(土) 13:34:46.98 ID:CKvy7+My
>>64
つまり、使い終わったら、スグにnullっておいたほうがいいってことか。
・・・とも言い切れないな。

でも、ここで使い終わったってわかるから、書いたほうがいいか。
よし。決めた。全部書こう。
67 :
2015/11/28(土) 13:55:47.33 ID:pohBt4lh
null代入なんていちいち書いていたら
コードが冗長になって保守性が落ちる。

メモリ食いのオブジェクトなど、クリティカルな部分でのみ使うべき
68 :
2015/11/28(土) 14:16:02.55 ID:81goelDj
お前らか。無意味なnull代入書き散らしてるのは
69 :
2015/11/28(土) 14:42:43.95 ID:DqKP/LxN
null代入とか結局やってることc++以下なんだよなぁ
70 :
2015/11/28(土) 14:48:25.74 ID:Fi4wDTmy
ダングリングポインタが出ないって利点は有るにはあるが
スマートポインタ使えば済む話だしなぁ
weak_ptrもあるし
71 :
2015/11/28(土) 15:20:08.61 ID:vL/aYykM
>>68
意味はあるじゃん
72 :
デフォルトの名無しさん
2015/11/28(土) 17:52:47.31 ID:CKvy7+My
>>68
ここでおしまい!って書いてあるだけ。
こんなんで冗長とは評価されない。むしろ読みやすい。と判断した。
73 :
2015/11/28(土) 18:23:41.31 ID:ekTV2Qou
変数がどこで不要になるか明示しなきゃならんほど長い関数ばっかり書いてるのか
それともローカル変数とか無い言語を想定してるのか
74 :
2015/11/28(土) 18:24:46.08 ID:q5KJxTWt
無駄なことするな
どうせ最適化で削除される
75 :
2015/11/28(土) 18:28:07.06 ID:rTI66XO9
保守性より効率重視なんかでコード書くからメモリリークするんだよ。
76 :
2015/11/28(土) 19:04:25.52 ID:ekTV2Qou
どんな意味でnull代入をしてるのか他人に伝わらなきゃ保守性もクソも無いよね
77 :
2015/11/28(土) 19:08:04.34 ID:rTI66XO9
a = null;
で伝わらない人にはどんなコメント書いても伝わらないと思うんだ。
78 :
2015/11/28(土) 19:27:35.81 ID:pohBt4lh
関数内ローカルな変数は
いくら大きくても大概スコープだけで
どうにでもなる。

javascriptみたいなのはlambdaでスコープ切ればいい。
79 :
デフォルトの名無しさん
2015/11/28(土) 19:54:24.96 ID:CKvy7+My
>>75,>>77
同じ結論ですわ。
null代入ってやっぱり特殊だから、コメントよりはるかに目が行く。
ここで使い終わったYO!!(逆に言えば、ここまでは意識してね。使ってるから。)ってわかってもらえれば良い。
80 :
2015/11/28(土) 20:10:37.33 ID:ekTV2Qou
>>77
長い関数中にそれ出てきたら変数を使い回す前に初期化したいのかな?とかも考えるな
短い関数なら変数を使い終わったとか重要な情報じゃないから無駄な行入れて可読性下げてるだけ
81 :
2015/11/28(土) 20:14:43.65 ID:pohBt4lh
永続的な変数でもなきゃ、変数の寿命はコンパイラが把握しているから、null代入がどんな変数にも必要なら勝手に挿入するんじゃね。

そうじゃないとしたら、なんでもかんでもnull代入が必要なんてのは幻想だよ。
82 :
2015/11/28(土) 20:16:46.53 ID:Fi4wDTmy
勝手にnullを代入するとか、そんな変なコンパイラは困る
83 :
2015/11/28(土) 20:47:03.48 ID:03HlMXbm
話は変わるんだがスマートポインタのメリットって何?
コンストラクタで例外投げたとき
そこまでに初期化したメンバ変数のデストラクタを呼ぶため
みたいなのは聞いたことあるけどそれくらいのもん?
84 :
2015/11/28(土) 21:01:25.91 ID:DqKP/LxN
>>83
別にコンストラクタじゃなくて関数内で確保した場合でも、
例外じゃなくreturnで戻った時も勝手に解放してくれたほうが
有り難いし、そもそも解放処理って忘れやすいものだろ
傘を置き忘れたり洗濯物を洗濯機に入れっぱなしにしたことの
ないものだけスマートポインタに石を投げなさい
85 :
2015/11/28(土) 21:20:40.16 ID:ETFlkHGB
null 代入したら行数増えるじゃん…全部のローカル変数にやってんの?
どうしても明示したければスコープで区切った方がまし
それでもインデントが深くなるのであれだけど
86 :
2015/11/28(土) 23:46:43.25 ID:pohBt4lh
>>82
勝手にnull代入すると表現するから気持ち悪く感じるだけで、コンパイラが各変数についてもうアクセスされる可能性の無い基本ブロックに到達したら、その変数をGCのマークの起点として使用しないようにフラグを管理すると言えば当たり前の話じゃね。
フラグの持ち方として変数にnullを代入しているだけで。
87 :
2015/11/29(日) 00:14:42.24 ID:qbMwzV1h
>>84
> そもそも解放処理って忘れやすいものだろ

それを忘れるなどとんでもない
確保&開放なんてプログラミングの花じゃん
キモじゃん
そこを工夫するのが楽しいんじゃん
設計も楽しいし
チマチマテストすんのも楽しい
温泉行って湯につかり忘れる心配はない
88 :
2015/11/29(日) 00:30:29.12 ID:Co3W2iFa
>>87
まあ勉強目的でやるならいいんじゃね
俺は元々ゲームプログラマだったからもう嫌になるほどやったし
メモリ周り工夫するなら言語設計からしたいわ
89 :
2015/11/29(日) 13:48:13.85 ID:U49gaUJj
信じて送り出した >>87 がわがままな顧客を✕✕して三面記事に載るなんて…
90 :
2015/11/29(日) 14:29:40.51 ID:c+9MHjtm
マークスイープ型のGCが必要かどうかについて、もう少し建設的な会話をしようよ
リソースを自動で開放してくれる機能は、無いよりは有った方が絶対に良い、と言い切ってよいよね
ただ、その方式が話の焦点だと思う

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

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

どちらを選ぶ?
91 :
2015/11/29(日) 14:58:17.95 ID:7vkfzAlt
GCの意見・・・OSではページファイル関連?
http://peace.2ch.net/test/read.cgi/tech/1447856699/l50
92 :
2015/11/29(日) 15:57:55.75 ID:Co3W2iFa
そもそもc++においてメモリリークって対策も発見も
大して難しい部類のバグではないんだよなぁ
GCの優位性をアピールするために過剰に恐怖心を煽ってる気がする
93 :
2015/11/29(日) 16:00:08.95 ID:sCmmZzWu
>>92
その程度の案件しか受けてないからだろう。
94 :
2015/11/29(日) 16:05:07.63 ID:QSPcxrGF
>>90
つ世代別GC

immutableオブジェクトをバンバンnewしまくる関数型プログラミングに慣れてると
やっぱGCないとキツイわ
95 :
2015/11/29(日) 16:15:05.64 ID:Co3W2iFa
>>93
いやいや普通難しいとされるバグってメモリ破壊とか同期周りだから
メモリリークなんてデバッガがチェックして丁寧なダンプ出してくれるし
組み込みとかの貧弱な環境なら専用のメモリ管理を用意して
いくらでも好きなチェックや情報出せるから
96 :
2015/11/29(日) 16:17:37.80 ID:AV0cYAnH
>>92
それな
メモリの確保と開放の対応すら管理できない奴は
なんかもう何をどうしたってダメな気がする
初歩の初歩の初歩の話題を何度も何度も何度も繰り返しすぎ
97 :
デフォルトの名無しさん
2015/11/29(日) 16:20:05.34 ID:3h4H/kBH
忘れるとか忘れないとか池沼レベルの話じゃん。
ゴミクズ。

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

必要な機能の実装を忘れる可能性におびえる池沼プログラマ。
最近流行りのADHD?なんじゃねえの。
98 :
2015/11/29(日) 16:24:33.80 ID:sCmmZzWu
>>95
なるほど。経験の少なさがすぐ分るな。ログ出したらで数十ギガなんてよくあるよ。
ログから問題点をスクリプトで抽出するにも何時間とかかるとかいろいろ。
マルチスレッド絡んで特定のパターンだけだったりして再現性がなかったりする。
他システムの連携だと手が出せない部分の挙動がおかしい可能性もある。結局、oracleのバグだったとかね。
99 :
デフォルトの名無しさん
2015/11/29(日) 16:25:01.11 ID:1uX74bCE
>>97
決済システムとメモリ解放は違うよ。
通販サイトのシステムをC言語で実装してみればわかるかと。
100 :
2015/11/29(日) 16:36:20.27 ID:Co3W2iFa
>>98
はあ?なんでリーク箇所ダンプするだけの話でログ全部吐き出すことになってんの
普通確保する際にヘッダにそのブロックの確保場所埋め込んでるし
アロケータで生存期間のスコープを切り分けといてすぐ分かるようにするけど?
お前の関わったプロジェクトが糞なだけじゃね?
101 :
2015/11/29(日) 16:42:54.34 ID:snjMtaUP
そもそも今時c++でgcならなんとかなる類いのメモリリーク起こすなんて、プログラマが屑なだけ。
リソースリークやその他の問題も確実に起こすこと請け合い。
GC言語でそのレベルのプログラマを使うような案件はGCによるメモリオーバーヘッドが気にならず、リソースリークも問題にならないような非常に緩い案件でしかない。
102 :
2015/11/29(日) 16:46:22.91 ID:sCmmZzWu
>>100
はぁ。話にならんな。扱ってる規模が違いすぎる。
103 :
2015/11/29(日) 16:52:06.50 ID:Co3W2iFa
>>102
おいおい反論できずに捨て台詞かよ
上でも書いたがコンシューマで開発してたから
100人*数年の規模でやってたんだけど
もしかしてC++みたいな危険な言語使ってて
今の今まで解析ツールなり自前のメモリ管理なり知らなかったの?
104 :
2015/11/29(日) 19:41:19.37 ID:GW0SCIDI
お前ら派遣だろw
全体規模とお前らが任されてる範囲を都合よく混ぜるな。
105 :
デフォルトの名無しさん
2015/11/29(日) 22:07:37.11 ID:3h4H/kBH
ほーら、自分の知能が一般人より低いと認めたくないがゆえにレッテル貼りが始まった。
普通の人が当たり前にできることができないってかわいそうだな。
もしADHD?だったら治療法あるらしいから病院行ってみたら?
ここでレッテル貼りやってるよりよっぽど解決する可能性が高いぞ。
106 :
2015/11/29(日) 22:12:02.58 ID:QSPcxrGF
レッテル貼りは2chの華
107 :
2015/11/30(月) 08:34:00.92 ID:qSWjFIuy
>>100
リーク箇所がわかってればログ出力の必要なくね?
ホントに開発したことあるのかな?
108 :
2015/11/30(月) 09:12:24.63 ID:UQyKbzCH
>>107
普通C++のプロジェクトは専用のメモリ管理を用意するから
リークしたメモリはそれを確保したクラスとその行数まで特定できるようにしてるよ
アロケーターも分離しとけばアプリケーション終了させなくても
管理オブジェクトを破棄した時点でリークの判定できるし

リーク箇所特定するのに全ログから解析とか複合的なバグでもない限りしない
そんな状況許してる時点で負け
109 :
2015/11/30(月) 12:11:48.62 ID:fg7tHWVi
100人で数年のシステムなら
10人で一年でやるべきだな。
人を無駄に増やせば、意思疎通や連携に無駄に労力を割く。
開放云々より仕様レベルで齟齬が出やすくなるわ。
110 :
2015/11/30(月) 15:00:18.02 ID:Ee9Jt/HC
>>108
リークしたクラスが分ればリーク原因が分るとかお花畑杉w
111 :
2015/11/30(月) 19:23:16.25 ID:UQyKbzCH
>>110
誰もリークしたクラスの事なんて言ってないんだが…理解できてる?(笑)
解らないなら解るだけの情報埋めたら?
112 :
2015/11/30(月) 19:24:12.90 ID:Ee9Jt/HC
おいおいw
113 :
2015/11/30(月) 19:31:17.77 ID:UQyKbzCH
>>112
そもそもGCがあろうとコンテナに突っ込んで消し忘れれば
オブジェクト破棄するまでメモリ圧迫し続けるって理解できてる?
リーク単体ならC++はそれと同等のレベルまで分かりやすく出来るんだよ
C++が困難なのはそういった管理情報も簡単に破壊出来てしまう点
リーク単体なら怖くはない
114 :
2015/11/30(月) 19:47:37.41 ID:UQyKbzCH
なんかだんだん笑えて来たんだけど、ろくに理由も言わずに
「わかんないんですけど!?わかる奴はお花畑(怒)!!」って
なかなか面白い奴だな
115 :
デフォルトの名無しさん
2015/11/30(月) 19:50:22.70 ID:isQX20zS
メモリの解放すら管理できない奴が、複雑な仕様を管理できるとは到底思えない・・・。
メモリの解放なんてなんの苦にもならんが・・・。
116 :
2015/11/30(月) 20:14:21.83 ID:Ee9Jt/HC
やれやれw

MSやLinuxやFreeBSDまでメモリリークやらかす理由が分らないのか。
117 :
2015/11/30(月) 20:30:16.55 ID:UQyKbzCH
>>116
また反論できずに逃走かよw
そもそも欧米は原因分かっててもバグ無視する連中だろうがw
ライセンスで守られてりゃ平気で放置するぞ
118 :
2015/11/30(月) 20:33:04.33 ID:V9s4KAVu
人生の管理ができない奴が、メモリを管理できるとは到底思えない
119 :
2015/11/30(月) 20:49:26.08 ID:UQyKbzCH
そもそもLinuxカーネルもFreeBSDカーネルもC言語だろ
馬鹿丸出しだなw
120 :
2015/11/30(月) 21:16:22.39 ID:zT+q2mn+
>>115
それな
プログラミングにおいてメモリ周囲はまだ初歩だよな
そしてマルチスレッドはそれよりは大変だがこれも慣れると
結局大事なところをガッチリ排他処理するだけのことだしな

プログラミングって最後はインタフェース設計だけだから
使いやすくてコンパクトなインタフェースを求めていくだけ
これがプログラミング道の後半の道のり
121 :
2015/11/30(月) 21:18:50.76 ID:Ee9Jt/HC
>>120
で例外系の実装がないから破綻するんだよ。実務経験ないとすぐ短絡的になるのが分る。
122 :
2015/11/30(月) 21:25:49.32 ID:zT+q2mn+
意味が不明すぐるw
123 :
2015/11/30(月) 21:28:33.92 ID:Ee9Jt/HC
うむ。まだおまえには早いかもしれない。
124 :
2015/11/30(月) 21:47:43.54 ID:UQyKbzCH
>>122
馬鹿相手にしても時間の無駄だぞ
こいつ具体的なこと何も言わんし
125 :
2015/11/30(月) 22:07:34.86 ID:zT+q2mn+
>>124
そやね
一連のレスの意図すらよーわからんわ
126 :
2015/12/01(火) 00:23:09.00 ID:s1rcgCDh
Guilty Crown?
たしかに失敗作だったなあ…
127 :
2015/12/01(火) 01:24:29.91 ID:mVPa8mQr
GCが云々というより抽象的なプログラミングしたい時は基本的なメモリ管理を言語に任せたいという欲求
128 :
2015/12/01(火) 01:27:09.96 ID:mVPa8mQr
>>113
c++素人なんだけどリーク単体はともかくそれにメモリ破壊が合わさると頭がおかしくなって死ぬ
みたいな感じ?
129 :
2015/12/01(火) 01:30:32.01 ID:s1rcgCDh
GCは関数型プログラミングでのみ正当化される
命令型プログラミングでは全く正当化されない

命令型プログラミング(=チューリングマシンに基づく計算モデル)は読み書きの「順序」こそがネ申なので
命令コードの「順序」を横断して存続するブツは善と悪の最終戦争で滅ぼされるであろう
つまり確保し、使ったら後開放する、これを明示的に書き下す姿勢こそが正しい
130 :
2015/12/01(火) 01:31:50.27 ID:s1rcgCDh
>GCは関数型プログラミングでのみ正当化される
ちな、これは処理系の裏方としての存在が許される、の意味
131 :
2015/12/01(火) 01:36:31.76 ID:mVPa8mQr
関数型プログラミング好きだけど
代数型データ型と型クラスでモナドとかアプリカティブとかtraverse、free monadとかやってる時に
メモリ管理だの言われたら余裕で死ねるな
本物のhaskellプログラマはhaskellで低レイヤを書くらしいけど
132 :
2015/12/01(火) 04:32:07.54 ID:79aHC4wo
口 先 人 間 展 覧 会 。(アハ
133 :
2015/12/01(火) 12:55:11.72 ID:S8usJREu
>>128
> メモリ破壊が合わさると

これが合わさるとなんでもありありなので何が起きても不思議はない
なので、ダングリングポインタの管理と配列のレンジチェックはちゃんとやるべし
134 :
2015/12/03(木) 12:20:09.85 ID:AuS7g0FI
ここでメモリ確保
ここでメモリ解放

たったこれだけが書けない管理できないとかw
135 :
2015/12/03(木) 12:23:19.04 ID:n26CULk9
知らないでやるって幸せなことなんですね
136 :
2015/12/03(木) 13:19:32.39 ID:N5r0JkUz
>>134
下には下がいるんだよ
137 :
2015/12/03(木) 13:29:54.15 ID:JbiOZ/E3
メモリリークは開放忘れでなると思ってる低レベルがいるのか。
138 :
2015/12/03(木) 14:07:05.91 ID:n26CULk9
低レベルなことを舐めるなよ
139 :
デフォルトの名無しさん
2015/12/03(木) 16:32:54.69 ID:JraK7tKY
>>134
mallocでOSから確保したメモリはfreeで解放されないんだが、

「ここで解放」はどうやって書くんでしょう?
140 :
デフォルトの名無しさん
2015/12/03(木) 19:43:25.89 ID:R/g8PPkY
>>137>>139みたいのが知識や技術に溺れて本質を見失い、
人と会話ができなくなった人の見本なんだろうか
141 :
デフォルトの名無しさん
2015/12/03(木) 19:47:17.15 ID:JraK7tKY
>>140
今まで正しいと信じきってた鰯の頭が迷信だと指摘され発狂中
142 :
デフォルトの名無しさん
2015/12/03(木) 19:53:39.75 ID:R/g8PPkY
>>141おw おまえ会社で孤立してるだろ派遣w
143 :
デフォルトの名無しさん
2015/12/03(木) 20:32:35.32 ID:R04IP6VM
確保したやつが解放するんだぞ。大丈夫か?
144 :
2015/12/03(木) 20:33:46.24 ID:cWTIfUD3
想像を絶するアホは居るもんだよ
if (cond) exp; の場合も中カッコを必ず付ける流派ってのがあって
理由を聞くと
if (cond) {exp1; exp2;}とするはずが
if (cond) exp1; exp2;としてしまうのを防ぐための常に中カッコらしい

中カッコを書き忘れるくらいの意識レベルで書かれたコードって
他のとこももう全部ダメだろそれは
145 :
2015/12/03(木) 20:52:03.75 ID:s/TINiTx
>>144
お前がアホなwww
146 :
2015/12/03(木) 21:25:03.70 ID:n26CULk9
カッコ先につけといたほうが 後々、都合がいいことも
147 :
2015/12/03(木) 21:30:08.65 ID:WeEbsZB7
アホな書き方といえば
 if ( 1 == a ) {
って比較元と先を逆にしてる奴
148 :
2015/12/03(木) 21:41:57.39 ID:4rUKwdGH
別におかしくない
基準値が先にあって、それと比べてaがどうなのか、と考えるか
aが先にあって、基準値と比べてどうなのか、と考えるかの違いでしか無いから
どっちでも良い
149 :
2015/12/03(木) 21:59:47.07 ID:/xqyH1ID
>>147
知ってて言ってると思うが、定数を==の左辺にするのは
if (a=1) { ...
と書き間違うのを恐れているらしい

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

>>135
スレッド安全に書かない奴が悪いていうかそれは別の話
シングルスレッド状況(またはそれと等価な状況)では>>134の言っていることは全く正しい
150 :
2015/12/03(木) 22:27:47.14 ID:zepIVOGi
ここ数日一気にレベルが下がったなw
GCの話しろよw
151 :
2015/12/03(木) 22:46:13.76 ID:srgQPG9D
つーか前スレと同じこと書いてる人多数
頼むから前スレ読んできて
152 :
デフォルトの名無しさん
2015/12/04(金) 04:37:18.54 ID:HtuddwW0
【 オンラインTCGエディター 】 >>1

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

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

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

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

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

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

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

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

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

さ〜て、製作ベンダー見つけよっと!ww(クス
http://wc2014.2ch.net/test/read.cgi/entrance2/1449039272/-18
153 :
2015/12/04(金) 12:21:13.29 ID:GzeAUkqU
>>149
>free()から設計し直す、
>まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ

じゃ>>134は設計し直してから言うんだな。坊や。
って、事でオッケーね。
154 :
デフォルトの名無しさん
2015/12/04(金) 20:05:33.81 ID:SAJ9n/s7
>>137これって何が言いたいの?OSやライブラリ自体にミスがあるって言いたいの?
wikiより
>メモリリーク (Memory leak) とは、プログラミングにおけるバグの一種。
>プログラムが確保したメモリの一部、または全部を解放するのを忘れ、確保したままになってしまうことを言う。
>プログラマによる単純なミスやプログラムの論理的欠陥によって発生することが多い。

>>137みたいなこと言う奴って、電磁波からデータが盗まれる!対応しないと!とか言い出すタイプ?
155 :
2015/12/04(金) 21:16:45.71 ID:7W1HEY29
>>151
そもそも15年ぐらい前から延々繰り返されてるんだが…
156 :
2015/12/04(金) 23:45:19.53 ID:j6MEWqDN
>>154
開放コードを忘れずに書いたのに開放されないという怪奇現象がマルチスレッド状況ではしばしばあるんじゃー!
マルチコア時代になってこれはますます危険になった
見ただけで正しさがわかる系のスレッド安全策はクロックサイクルを糞のごとく消費するし…

こういうのは専門家が徹底的にデバッグしたGCで面倒を見て欲しいと思う反面、
やっぱプロセス全体のごみ処理を選任モジュールにやらせるのはクロックサイクルをドブに捨てるがごとき
センス無い設計なキモス、、
157 :
2015/12/05(土) 00:08:28.41 ID:+HxrBEdK
それ単にメモリバリアの問題じゃ…
158 :
2015/12/05(土) 04:01:37.91 ID:2vAbbe+i
>>154
入門書に書いてるコードしか見たことないんだね。
スレッドプールみたいなテクニックは高速化のためにみな普通に使うんだよ。
OSやライブラリにもメモリリークなんてよくあることだし、それらのバグも開放忘れて起きてるイージーなバグじゃないよ。
他のバグやトラブルがメモリリークという形で表面化してるにすぎない。
159 :
デフォルトの名無しさん
2015/12/05(土) 08:28:25.61 ID:Pfi54LUx
>>158
具体的にいつのどのバージョンのライブラリで起きてるの?
使い終わったらメモリを開放しろ。使い終わってないなら開放する必要はない。これとスレッドプールとどこに関連性があるの?
160 :
2015/12/05(土) 09:45:44.55 ID:P9ivIQ+p
>>159詰めても無意味。
こういう連中は、まず自分の考えややり方が絶対正しく絶対に曲げない。曲げないために無理やり理由を当てはめようとしている。
で、さもそれを自分はやってるように言っているが、実際は単に本に載ってることを言ってるだけ。
実装もできない。面前で詰めてやれば発狂して勝敗がハッキリつくけどネット上では無理だね。
161 :
2015/12/05(土) 09:48:00.71 ID:BOwcKS4A
メモリの話とスレッドの話を混ぜ込んでしまうタイプは
問題の切り分けがそもそも出来ないタイプ
だからメモリリーク()に悩まされる

スレッド間の協調と、メモリのケアは直交する別の話題
162 :
2015/12/05(土) 10:18:00.14 ID:NRX1k+Is
>>158
ちょっ漏れが作ったわけでも漏れの使い方に問題があるわけでもない階層で起きるメモリリークの責任を漏れに負わされても困る…
それに他人が作ったモジュール内でのメモリリークも結局は開放が書かれていなかったか、書かれていても正しくなかったからリークしているはず…

>>161
全面同意だが同意したからと言ってメモリリークがゼロになるかっていうと以下略
単純にクリティカルセクションとかキューによるシリアライズ(Active Objectパターン)で排他して
マルチコアを活かさずパフォーマンスをドブに捨てて良ければ平和なんだが…
163 :
2015/12/05(土) 12:34:30.29 ID:eGerJrSR
だからメモリを自動開放してほしいときはスマートポインタを使えばよいだろ
循環参照が無い限りshared_ptrで問題ないだろ
循環参照がある場合はどちらかをweak_ptrにすれば済む話だろ

現実にshared_ptrの様な物が存在して無いなら、そういう議論も意味があるが
実際にはshared_ptrは現実に有るのだから、自動管理したい場合は使えばよいだけの話でしかない
164 :
2015/12/05(土) 12:38:09.16 ID:eGerJrSR
むしろ議論すべきはshared_ptrのような参照カウンタ方式のスマポと
言語ビルドインのマークスイープ系のGCとで
どちらが良いか、だろう

参照カウンタ方式は循環参照で問題を起こすし
マークスイープ系のGCはいつ実行されるか分からない
165 :
2015/12/05(土) 13:11:12.91 ID:eGerJrSR
つまり、完璧なGCは無いということだ

完璧なGCが無い以上、使う側が状況に合わせて選べた方が良いわけだが
そうなるとC++/CLIのような変体言語しかないのが残念だ
166 :
2015/12/05(土) 13:42:35.29 ID:FurPG6R/
普通に言語を選べば良いだけの話では
167 :
デフォルトの名無しさん
2015/12/05(土) 13:49:45.99 ID:Pfi54LUx
このスレ論点が一致してないよね。
 freeやdeleteを記述すべきという論点で話をしている人
 freeやdeleteしたところでメモリが解放されてるわけではないですがという論点の人
 freeやdeleteは当然、さらにnull等を記述すべきという論点で話をしている人
 GCの実装そのものを論点にしている人
論点がばらっばらだから咬み合わない
168 :
2015/12/05(土) 13:58:32.14 ID:wharPYQR
>>158
> OSやライブラリにもメモリリークなんてよくあることだし

よくあると言うなら10個ぐらいすぐにあげられるよな
もちろん最新版でリークする奴ね
169 :
2015/12/05(土) 14:16:25.84 ID:2vAbbe+i
MSのサイトにfix分と調査中のものが全部公開されてる。他のOSもlog、mlみれば腐るほど出てくる。

10個上げろとか、ほんと幼稚園児かよ、おまえらは。頭悪すぎw
170 :
2015/12/05(土) 14:33:31.47 ID:9PUwCRa0
C++でRAIIを徹底しておくのが一番いいよ
解放タイミングのコントロールが必要になったら後からでも柔軟に対応できるし
GCは解放に係る少し変わった条件が発生した時に滅茶汚いことをしなきゃならなくなる
171 :
2015/12/05(土) 14:36:53.80 ID:NRX1k+Is
shareed_ptrはC++で比較的効率よくやれることと、GCしたい人が真にやりたいことの妥協の産物であって
どんなシチュでもベストにフィットするような一押しの決定版ってほどでも無い…

参照カウンタの排他が不要で循環参照が無いことも保証できるまで設計が詰められているなら
スレッドごとに、メモリを確保して使って返す処理を直に書くのが一番良い
172 :
2015/12/05(土) 14:43:55.34 ID:9PUwCRa0
確保/解放を直に書くのはスピード的には一番速いだろうけど解放漏れバグの温床過ぎてネ
特に例外が絡むとやってられない状況になる
173 :
2015/12/05(土) 14:45:23.69 ID:+HxrBEdK
>>167
null云々は別言語だ馬鹿
174 :
2015/12/05(土) 14:47:17.08 ID:wharPYQR
>>169
> もちろん最新版でリークする奴ね

早くあげてよね w
175 :
2015/12/05(土) 14:52:20.59 ID:NRX1k+Is
>>172
>特に例外が絡むとやってられない状況になる
そこだけはstd::unique_ptr<T>の一押し
これで例外状況でのRAIIが完成するので真にGCが要らんところまで逝く

ていうか大概のアプリなら、例外を生じたらFatal errorなことをユーザーに知らせて終了、でいいんじゃ…
176 :
2015/12/05(土) 14:59:01.89 ID:9PUwCRa0
>>175
いやーリソース獲得した状態でファイルI/Oとかネットワークとかが絡む場合は終了じゃすまん場合が多いでしょ
177 :
2015/12/05(土) 15:06:58.28 ID:MOG2PmhH
昔C言語で数珠繋ぎの独自スコープとしてblock_enter/block_leaveというのを作って

{
block_handle h = block_enter(b)

object = block_create_object(h)

block_leave(h)
}
178 :
2015/12/05(土) 15:10:52.59 ID:MOG2PmhH
書き損じた
昔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 :
2015/12/05(土) 15:15:45.24 ID:MOG2PmhH
デメリットはblock_create〜で作成するものは全部ヒープに確保されること
結局C言語でここまで必要な案件てのが回ってこなくてあんま使ってないけどリーク予防法の参考程度に
180 :
2015/12/05(土) 15:24:40.86 ID:4CEShJeO
例外にも対応って?
181 :
2015/12/05(土) 15:29:31.41 ID:KdBqlpoa
C#でアンマネージドなメモリを扱えるのはわかった
確保したメモリ領域にオブジェクトを配置する事は出来ない?
C++で言うところの配置newを再現したいんだ
メモリの確保解放はプログラマが特別に管理してその間は普通のオブジェクトと同じように透過的に扱いたい
182 :
2015/12/05(土) 15:30:53.84 ID:MOG2PmhH
>>180
例外つってるのは具体的にはSEHの話
どっかで止めた時点のblock_leave(b, h)でそれまでの開放が保証されるってこと
183 :
2015/12/05(土) 15:39:23.63 ID:eGerJrSR
C++にfinallyが無いのが気に食わない
今はラムダが有るのでマクロでそれっぽいものを自作したが
標準で用意しておいてほしい
C++はリソースを自分で管理する傾向のある言語なのに
finallyが無いのは本来おかしいよな
ラッパー作ってRAIIを徹底しろってことなんだろうけど
すべてのリソースに対してラッパーを用意するのは面倒だよ
fainallyが有ったって邪魔になるわけでもないのに
最終的に使うかどうかは利用者が選べばよいことだし
C++ってそういう言語だろ
184 :
2015/12/05(土) 15:50:01.56 ID:9PUwCRa0
>>183
C++にはテンプレートがあるからリソースの型をテンプレート引数とするラッパーを作るのは
そんなに面倒なことじゃないと思う
あとC++でRAIIを徹底してればfainallyの必要性を感じたことはない
fainallyを書かなければいけない時点で危なっかしいコードだと思う
185 :
2015/12/05(土) 16:34:34.82 ID:+HxrBEdK
むしろfinallyってデストラクタがない言語だから
必要なものなんじゃ…
どうしても必要ならデストラクタで任意のラムダ呼ぶ
ユーティリティクラス作れば同じこと出来るし
186 :
2015/12/05(土) 16:50:13.74 ID:+HxrBEdK
98以前でもローカルクラス定義できるんだからすこし冗長なだけで同じだし
187 :
2015/12/05(土) 16:59:06.52 ID:NRX1k+Is
例外発生はバグ、というプログラミングしかしたことないからよくは知らんが、
try {
 try {
  /*...*/
 } catch (std::badalloc()) {
  /*...*/
} catch (UserException e) {
  /*...*/
}
} catch (...) { // fainally節の代わり
 /*...*/
}
じゃあいかんの?実行時コストは知らん
188 :
2015/12/05(土) 17:00:08.66 ID:NRX1k+Is
スマン
誤: } catch (std::badalloc()) {
正: } catch (std::badalloc e) {
189 :
2015/12/05(土) 17:32:52.06 ID:+HxrBEdK
違う。そんぐらいググれ
190 :
2015/12/05(土) 17:37:26.87 ID:KdBqlpoa
デストラクタの問題点は不可視なところだな
usingやfinallyは目に見えるから安心する
191 :
2015/12/05(土) 18:00:14.20 ID:NRX1k+Is
>>189
内側のtry〜catchから再throwするのを忘れたorz
内側のtry〜catchから再throwして外側ので再捕捉したらいいんじゃ…
192 :
2015/12/05(土) 18:22:16.37 ID:0v99S3Ys
例外をロジックとして使うなってばっちゃんが言ってた
193 :
2015/12/05(土) 19:38:41.80 ID:eGerJrSR
>>191
throwせずにreturnするパスが有ったらどうするんだよ
そういうのを防ぐためのfinallyやRAIIなのに
まったくちんぷんかんぷん
結局returnする前に手動で忘れないようにthrowすることを強制するんなら
goto文とか開放用ラムダ呼び出すのとかと替わらないだろ
194 :
2015/12/05(土) 20:44:27.97 ID:ZNw2R9x1
だから忘れる忘れないレベルをぶち込んでくるのは止めようやw
これをぶち込むから全ての議論が池沼レベルになってる
195 :
2015/12/06(日) 06:02:02.37 ID:JYyEEHci
異常系で例外返す仕様のライブラリが失敗。
196 :
デフォルトの名無しさん
2015/12/06(日) 08:06:42.75 ID:XhferEg+
>>194
GCなんて池沼のために生まれたようなものだし・・・
NULLったりfreeったりすることすらまともに把握、指示しきれない
197 :
2015/12/06(日) 11:36:02.06 ID:G3VNQyn5
c++のデストラクタって後処理に失敗しても
例外投げられないからウンコ
結果的にエラーを握り潰すゴミコードを量産する原因になってる
198 :
2015/12/06(日) 11:40:47.08 ID:zGnP2wpv
そのクラスが管理してる範囲で後処理の失敗って何が起こるの?
199 :
2015/12/06(日) 12:05:41.69 ID:kVHO13oj
どうしてもやりたいなら対処法はあるしなぁ。
200 :
2015/12/06(日) 12:23:19.67 ID:MkaxAbH2
現実的な確率で発生して無視出来ないリスクが有る解放処理はデストラクタでやるべきじゃない
そういうリソースに対してデストラクタがやる事はプログラマに対しいて未解放のリソースを通知する事だけでよい
201 :
デフォルトの名無しさん
2015/12/06(日) 12:30:12.96 ID:XhferEg+
具体的に何があるん???
クラス内で使っているリソースで解放に失敗(失敗し続ける)するって。
202 :
2015/12/06(日) 13:14:17.95 ID:lk97yytv
どっか他のオブジェクトと共有してるものを解放しようとして失敗するとか?
それはそもそもの設計に問題ありすぎだが。。
203 :
デフォルトの名無しさん
2015/12/06(日) 15:01:28.77 ID:XhferEg+
>>202
だよね。
否定しようとして無理やり現象を創りだそうとしているとしか・・・。
でもその無理やりつくった現象は、そもそも論理設計のミスが大前提だったりする。
論理設計のミスまで言われたらなんにも組めないわ。
204 :
2015/12/06(日) 15:42:32.97 ID:wxELMJDc
>>200
デストラクタの中で起きた例外については
try { } catch (...) { }で囲った上で、リカバリ処理(何とかしてリソース解法漏れをなくす)を行えばいいじゃない?

もし例外発生後に行うべき適切なリカバリ処理が書けない(存在しない)んだとすると、
もはやデストラクタ内に限った話ではなくなって、例外を発生させた時点で設計か実装にバグが居たとしか…
205 :
2015/12/06(日) 16:03:58.23 ID:5cQQ9Lrm
バグ(リソースへのポインタやハンドルを壊しちゃったとか)以外で
リソース解放に失敗するケースなんて1つも思いつかない
206 :
2015/12/06(日) 16:19:39.63 ID:4bjdt2kC
fclose() にも失敗があるじゃないか?
207 :
2015/12/06(日) 16:54:30.29 ID:djRjUyAt
fflush() しとけばOK
208 :
2015/12/06(日) 16:59:21.77 ID:5cQQ9Lrm
>>206
fcloseの失敗はハンドルが正しい限りflush時のI/Oエラーの通知であって、その場合でもリソースは解放されるよ
209 :
2015/12/06(日) 17:35:51.31 ID:G3VNQyn5
c++信者ってアホだなー
みんなこんなんなの?

http://cpplover.blogspot.jp/2011/01/fclose.html?m=1
210 :
2015/12/06(日) 17:44:16.50 ID:G3VNQyn5
fcloseに失敗してファイルに正常に書き込みされなくてもシカトしてるんだよね?
それともerrnoとかチェックしちゃってるの?
211 :
2015/12/06(日) 19:05:12.47 ID:RyqEmv/A
まあC++の例外を援護するつもりはないがそういう場合は
普通にフラッシュしろよ
そもそもC++が二重例外時にstd::terminate呼ぶのはGCのあるなしに
関係ないからスレ違いだお前ら。よそでやれ
212 :
デフォルトの名無しさん
2015/12/06(日) 19:24:21.60 ID:XJADMoL5
GCというよりライブラリとの関係だな
.net framework libraryのいくつかのクラスは中で自分自身をロックするから
プログラマ側で参照が切れてもGCされない
213 :
デフォルトの名無しさん
2015/12/06(日) 19:25:02.74 ID:XJADMoL5
今日一日なんでFormがGCされないのか調べてて大変な思いしたわ
214 :
デフォルトの名無しさん
2015/12/06(日) 19:31:56.53 ID:bkfT5adp
>>213
よくそこまで調べたな。( ・∀・)つ旦 お茶ドゾー
215 :
2015/12/06(日) 19:37:02.30 ID:Gxx7TgqC
いまだにプログラマはアセンブリ言語を使えるべきだ派?
216 :
2015/12/06(日) 19:40:49.58 ID:JYyEEHci
アセンブラ知ってると知らないとじゃスキルレベル全然違うからな。話にならないぐらいのレベル差。
217 :
2015/12/06(日) 20:22:00.43 ID:RyqEmv/A
まあ実際Java屋とかってコンパイラやメモリ意識できない奴多いよね
以前2chで↓みたいなコードが勝手に最適化されると思って
StringBuilder使う奴は馬鹿!とか言い出す奴いて目眩したわ
String s;
for(int i = 0; i < strarray.length; ++i){ s += strarray[i]; }
218 :
2015/12/06(日) 20:58:14.61 ID:wxELMJDc
>>217
それはStringの+=の実装次第ではあんまり差が付かないケースなんじゃ…
(左辺と右辺が別の実体である(アドレスが違う)ケースでは多分右辺を左辺の末尾に1回コピーするだけという実装が有り得る
真に糞なのは
StringBuilder sb;
String s = "Hello";
sb.Append("[" + s + "]");
が遅いからStringBuilderは糞、と結論付けるニンゲンであってコードではない、
みたいな?
219 :
2015/12/06(日) 21:26:17.35 ID:IAFYzi6n
>>217みたいにループ中で一個づつくっつける場合は別にして
s = a + b + c + d; // このように、高々数個をくっつけてる場合は
Javaだと無駄にStringBufferが作られてダメと言うのが定説だったが
C#の場合は内部的にString#Concatに置き換えられて
それによって
StringBuilder b = 略
s = a.Append(b)中略.Append(d).ToString()
するより早い、という話題があってそれと勘違いしたのかもね
220 :
2015/12/06(日) 21:28:20.04 ID:IAFYzi6n
いちおう訂正しとこw

StringBuilder sb = 略
s = sb.Append(a)中略.Append(d).ToString()
221 :
2015/12/06(日) 21:50:20.98 ID:MkaxAbH2
そもそもその最適化は仕様なのか
222 :
2015/12/06(日) 22:27:08.91 ID:RyqEmv/A
>>218
??、これJavaだぞ。演算子オーバーロードなんて出来ないから
>>219
違う違う。+の連結がStringじゃなくてStringBufferに
最適化されるらしいって話だけで、StringBulderって
必要ないでしょ?レガプロ?(笑)、って認識レベル

しかもそいつ一人ならまだしもスレに同じレベルの
認識の奴結構多かったよ。レベルの低さ舐めたらあかんで
223 :
デフォルトの名無しさん
2015/12/07(月) 01:50:02.58 ID:3Z+aJEnB
>>222
実装云々でなんで演算子オーバーロードがでてくるんだ?
224 :
2015/12/07(月) 05:22:13.32 ID:QznWTKRS
逆だろ?
C#との勘違いでないなら、その最適化されるJVM実装とやらを示さないと
225 :
2015/12/07(月) 07:11:57.22 ID:X5Y+ON7N
>>219
全く逆の認識してないか?
classファイル解析したら分かるけど、ループ中の+=の方が問題で毎回newされるから遅い

s = a + b + c + d の方は一つしかStringBuilderのインスタンスは作られない
226 :
デフォルトの名無しさん
2015/12/07(月) 08:02:18.14 ID:nEG5/lEo
こうやって、比較的プログラミングという行為を好きでいる・好きでやっている・興味を持っているという人ですらまともに言語仕様を理解出来ていない。
malloc、freeで管理、GCで管理だと、機構の複雑さは後者。
結局GCもその機構を正しく理解しないと参照が切れてない、参照が切れていても別のリソースが・・・と。
機構を正しく理解していることが前提なら、機構はシンプルなほうがいい。
その点を誤ったから
>プログラマをメモリ管理から開放する!
>といいつつ、メモリリーク問題の文献が大量にある。
>これすなわち、メモリリーク問題が全然解決していないということ。
>さらに、メモリ解放のタイミングの文献まで大量に生み出した。
>これすなわち、新たなるメモリ管理に関する問題を生み出したということ。
なんてことになったんだろうね
227 :
2015/12/07(月) 08:12:44.70 ID:EA/TwAsy
そもそもプログラマの大半にマネージリソース、アンマネージリソースとはなに?
って質問してまともに回答できる割合がどんなもんになるのか
始めたら終わらせる
これワンセットね
にしたほうがミスはなくなるかと
ファイル開いたら閉じる
メモリ確保したら解放する
通信接続したら切断する
228 :
デフォルトの名無しさん
2015/12/07(月) 09:22:45.43 ID:q5G1dKJA
やっぱりARC最強だな
229 :
2015/12/07(月) 15:38:30.00 ID:6rSJBSiX
結局いつ開放されるか分からないってのが曲者で
使い終わったら確実にリソースを開放してほしいときは
別の仕組みが必要になってしまったってのが問題だろう
その別の仕組も、C++のデストラクタのようにクラスのメンバに関して
芋づる式に呼び出す仕組みがないから
C++のデストラクタがやっていることを手動で再現しなければならない始末

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

循環参照に気を配れる知能が有るのであれば、参照カウンタ方式のほうがスマート
230 :
デフォルトの名無しさん
2015/12/07(月) 17:29:26.60 ID:nEG5/lEo
>>229
処理速度やタイミングがシビアな組み込みや科学技術計算系とかならいざしらず、
ソレ以外は、実際の解放のタイミング自体は問題にならんでしょ。(膨大なメモリの使用も別だけど)
問題は、使い終わったよーって明示しないで良い。という運用が結局、悪い結果をもたらしているという点。
メモリの管理をしっかり最後までやるクセのないプログラマは、
平然と参照が途切れている可能性のあるポイントで参照しに行こうとする。
結局は、そいつがバカだからに集約されてしまうんだけど、使い終わりの明示をしない文化がバカを生む土壌となっている
231 :
デフォルトの名無しさん
2015/12/07(月) 18:21:02.44 ID:q5G1dKJA
そういう事になる原因ってさ、構造がぐちゃぐちゃでオブジェクト間も依存しまくって、
いつ解放していいのかわかんねえーというヘボいプログラミングなんだろうなと思う。
232 :
2015/12/07(月) 18:23:12.12 ID:tBfENkIS
と馬鹿なSEやPGはそう思うだろうなとも思う。
233 :
2015/12/07(月) 19:54:31.23 ID:GogXEvJk
ある意味メモリなんて一番扱いやすいリソースだからな。
メモリの管理すら適当なプログラマが、他のリソースを適切に扱える訳がないのに、GC前提の言語ではそちらのケアが言語側でやりづらくなってしまっている。
234 :
デフォルトの名無しさん
2015/12/07(月) 20:05:22.53 ID:W4QZalq7
メモリ意識した時点で雑魚プログラマ決定だろ。
JavaScriptもPascalも使えないんじゃ話にならないよ。
おちんぽ見られることを意識しすぎて温泉に入れないようなもの。
癒やしのない人生に刺激なんてない。←これ名言
235 :
デフォルトの名無しさん
2015/12/07(月) 20:07:43.02 ID:nEG5/lEo
>>231
そう。そういう状態にしちゃう原因が、いい加減なメモリの管理で教育された結果にあるのではないか?ということで。
236 :
デフォルトの名無しさん
2015/12/07(月) 20:09:47.14 ID:nEG5/lEo
>>234
だれの名言かしらんが、

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

ならなんかしっくりくる。まぁ逆とっても同じ意味だからいいんだけど・・・。
237 :
2015/12/07(月) 20:16:31.05 ID:ZNsl6+sP
メモリ意識しないプログラマとかカスだろ。
238 :
2015/12/07(月) 20:42:25.43 ID:wP/KA6jo
JavaやC#ではリソースをプログラマが管理してはいけない
せっかくメモリ管理を透過的にしたのにリソース管理でコードをより複雑化させては意味がない
真っ当な教育を受けた少数のプログラマがSafeHandleを作成する
末端のプログラマはSafeHandleのファイナライザに全てを任せてメモリと同様にリソースを完全に透過的に扱うべきだ
239 :
2015/12/07(月) 23:25:36.31 ID:QznWTKRS
>>230
JavaのGCでサーバー応答が止まるなんてザラにある話だよ
それを聞いたことがないなら文系SEと同レベルだね

>>238
管理放棄して開くだけ開いて計算資源を食い潰す玄人気取りプログラマ
240 :
2015/12/08(火) 00:48:22.00 ID:pyjW8EMu
full GCが頻繁に生じちゃうのは明らかに設計ミスやな
immutableな短命objectを使いまくるのだ。。
つかimmutableなオブジェクト使いまくるとGCないときつくね?
241 :
2015/12/08(火) 02:05:45.39 ID:H3TgUaFB
RAIIで事足りる
immutableかどうかとGCは無関係
242 :
2015/12/08(火) 02:21:53.95 ID:RVFMry3L
むしろ短命なオブジェクトなんてスタックで十分だし
管理するならshared_ptrのが優れてる
243 :
デフォルトの名無しさん
2015/12/08(火) 03:41:28.67 ID:pU1qoPPC
ライブラリ、アプリ、ユーザの三者で考えないと
一部リソースはユーザがを閉じることができる。
そのときアプリの参照を消す仕組みがどのライブラリにもない
244 :
デフォルトの名無しさん
2015/12/08(火) 08:07:46.77 ID:rWJ9nJMw
>>243
よくわからんが、それは階層的におかしいのでは?
ユーザーがアプリを通さずにリソースを閉じる事ができるって事?
245 :
2015/12/08(火) 12:16:07.11 ID:VV6tYNBF
Manager.Execute((res) => ...);

これが終着点
短命なリソースは全てこの形式で事足りし長命なリソースはファイナライザにでも任せればよい
ユーザーが管理しちゃ絶対にダメ
246 :
2015/12/08(火) 15:11:36.25 ID:DYNM3xm/
このスレでGCいらんて言ってる人たちは環境に恵まれてるんだなぁって思う
247 :
2015/12/08(火) 15:20:06.88 ID:Bkt0caBE
GC
タモリが昔宣伝してやつ?
248 :
2015/12/08(火) 15:28:54.90 ID:NMHe7TFl
むしろGCなんて環境良くないと使えないだろ
249 :
2015/12/08(火) 16:16:30.38 ID:zjJIjn6V
参照がなくなったタイミングで必ず開放してくれて
かつ
循環参照でも問題ない
パーフェクトなGCが有れば最高なわけだが
実際にはそんなGCは無い

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

といってもマークスイープ系GCが前提のC#やJavaのような言語に
RAIIの発想を持ち込もうとしても
C++のデストラクタのように自身のメンバのデストラクタを自動で芋づる式に呼び出す仕組みが
元々無いので、手動で芋づる式に解放関数を呼び出すコードを書かなければならなく
うまく行っていない
250 :
2015/12/08(火) 16:25:08.60 ID:RVFMry3L
>>246
JavaでPhantomReferenceも使ったこと無い人って恵まれてるんだなあって思う

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

C++のデストラクタならメンバのデストラクタが芋づる式に勝手に呼び出されるから
気にしなくて良い
252 :
2015/12/08(火) 17:08:50.17 ID:NMHe7TFl
強参照、ソフト参照、弱参照、ファントム参照
この字面だけで糞言語って察せられるから凄い
253 :
2015/12/08(火) 19:22:21.31 ID:RKxPG6yJ
Rustはどう?
明文化されたmoveセマンティクスと、オブジェクトの寿命と参照のチェッカを型システムに組み込んでるおかげで、
リソース管理の実行時コストをゼロにしつつ、メモリリークが発生しないプログラムが書ける。
shared_ptrに相当するRcもあるから、所有者を複数にしたい場合のコストもそれなりに抑えられる。
254 :
デフォルトの名無しさん
2015/12/08(火) 19:35:14.32 ID:Hrv9Cion
>>253
すげえ難しいらしいじゃん
255 :
2015/12/08(火) 19:52:40.51 ID:NMHe7TFl
rustの清貧さは好みだけどまだ触った事ないな
同期処理を省略するためかshared_ptr相当がタスク間跨げないらしいけど
そこら辺の使い勝手ってどうなんだろう
256 :
2015/12/08(火) 21:00:06.21 ID:RKxPG6yJ
>>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 :
2015/12/08(火) 22:39:35.60 ID:RVFMry3L
>>251
C++もヒープ相手は自分で呼ぶので、実装は必要だよ
Javaでもメンバの特定メソッド呼び出しはやろうと思えばできる
現実に横断的な呼び出しをやる場合はある

結局要求される物と実装の問題
258 :
2015/12/08(火) 22:59:22.32 ID:RKxPG6yJ
>>255 shared_ptrと恒等なものは無いけど、ポインタ的に使える型がBox, Rc, Cell(あるいはRefCell)とあって、
Boxはヒープ領域であること、Rcは複数の所有者がいる(つまり所有者全員が死ぬまでは生きている)こと、Cellは複数の書き込みが作れること、
とか機能とコストが別れているから、これらを組み合わせて使う。

で、Thread Safetyを実現させる機構は上記には無いので、Atomicityを導入させるRcの類似形であるArcと、
書き込みもしたいならMutexっていう型も合わせて使う。
すると、例えば整数のベクトルをスレッド間で共有したい、とかになるとArc<Mutex<Vec<i32>>>という目が滑るような型表記をすることになる。
あんま詳しくないので、ケース毎にもっと簡単なやり方があるとは思うんだけどね。
259 :
2015/12/08(火) 23:55:28.64 ID:NMHe7TFl
>>258
ああ、Arcってのが別にいるのね。納得
個人的にもう一点気になる所があるから聞いてしまう
BoxやDropを使ってるとコピー禁止になるらしいけど
これ面倒な場合ない?
最初はコピー可能な型としてガンガンコピーしてたけど
途中から終了処理を書きたくなったらコピーしてる箇所
全部直すって事?

ちなみにググってたらRWArcっての見つけたんだけど
これ読み書き可能なArcなんじゃね
260 :
2015/12/09(水) 00:46:02.26 ID:WVnNYSfg
>>249
javaは世代別管理でGCの種類は色々選べるはずでは
261 :
デフォルトの名無しさん
2015/12/09(水) 01:14:15.85 ID:wAGGTtTq
>>260
起動時に切り替えられるだけであって
オブジェクトごとには切り替えられないのでは
262 :
2015/12/09(水) 01:50:08.36 ID:x/ryIvcR
>>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.53 ID:mXWFWn5f
freeし忘れるとか、そんな超ウルトラ素人ミスを大前提に議論するのは間違いだよなw
freeしきれないとかwwww
264 :
デフォルトの名無しさん
2015/12/12(土) 11:52:29.69 ID:v/VbuB+R
>>263
規模が大きくなれば管理が難しくなるのは普通のことだよ。
ライフサイクルはオブジェクトごとに異なるものだし、
人間に頼らずにGCにメモリ管理を任せるっていうのは良いやり方だよ。
265 :
2015/12/12(土) 12:05:07.06 ID:yfUf7LLZ
shared_ptrって参照カウント式のGCじゃないの?
266 :
2015/12/12(土) 12:44:09.71 ID:7G0ybzbE
循環を綺麗に扱えるなら参照カウントの方が良いと思うけど
VB6は循環参照の扱いどうやってるんだろう
267 :
2015/12/12(土) 14:25:51.97 ID:npRd3MLZ
>>265
RAIIじゃろ
268 :
2015/12/12(土) 15:20:38.55 ID:tVgJgcBS
>>265
GCの一種だけど、文脈的にはプログラマが
管理が非局所的で明確な型宣言もなしに使えるのをGCと言ってるわけで
議論で揚げ足にしかならない野暮な突っ込みはやめようぜ
269 :
名無しさん@そうだ選挙に行こう
2015/12/14(月) 08:16:09.53 ID:hn3965Zz
>>264
いや、下手って一言で片付けられるよ。
よっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっぽど、出ない限り
270 :
2015/12/14(月) 08:38:44.84 ID:sXTPVO5Q
片付ける奴が馬鹿なのだ。素人ほど簡単だと言いたがり、上級者ほど簡単ではないとはっきり言うものだ。
どの分野でもな。
271 :
2015/12/14(月) 09:09:02.89 ID:lNUL9lX8
freeとか言ってる奴はC++使えよ。いつまでC使ってんだ。
272 :
2015/12/14(月) 09:20:53.11 ID:MauTQhQ/
>>270
東大生が人に教えるとき、何がわからないのかわからないというのがわからない。
上級者になればなるほど自分がやってることなんて簡単に見えてくる
273 :
2015/12/14(月) 09:35:23.70 ID:sXTPVO5Q
>>272
何が分らないか分らない、つまり東大生も生徒がどういう思考をしてるか分析できず分らないと言ってるのだ。
低学歴ほど、分らないのはおまえが馬鹿だからと簡単に片付けるものだ。
274 :
2015/12/14(月) 09:37:05.77 ID:eBJzgHzn
それ中級者
あと、東大生は教えるの上手いのもいるから想像で話すな馬鹿
275 :
2015/12/14(月) 09:41:37.74 ID:sXTPVO5Q
このようにおまえのようなコンテキストすらまともに読めないPGは五万といる。
スレッドがデッドロックしてメモリを開放できないなんてよくあることだ。
276 :
名無しさん@そうだ選挙に行こう
2015/12/14(月) 10:59:16.82 ID:hn3965Zz
>>275
。。。。。完全な設計ミスじゃん
277 :
2015/12/14(月) 11:15:19.23 ID:eBJzgHzn
>>275
俺は272に向けてたんだが
そりゃコンテキスト読めてないように見えるよなw
278 :
2015/12/14(月) 11:40:27.14 ID:ETDpPCfc
スレッドがデッドロックしたらメモリリークどころじゃないじゃないかwww
279 :
2015/12/14(月) 14:48:51.74 ID:MOnxQz3f
スレッドがデッドロックしちゃってメモリ解放できない(泣)
っていうPGが五万といるのかよw
280 :
名無しさん@そうだ選挙に行こう
2015/12/14(月) 15:51:19.55 ID:hn3965Zz
まぁfreeやdeleteやnullやらすらできないPGに、「僕はそんなこと管理しきれる脳みそ持ってない!」って言われたらソレは真実なんだろうけど・・・。
そんな脳みそPGに「もっと複雑な業務使用」を理解できるとは思えないんだ。

そんなPGにプログラミングの場を与えるのが間違い。
281 :
2015/12/14(月) 15:58:21.86 ID:2JSVZtRY
そもそも実務でスレッド使うPGなんてゴマンもいない
282 :
2015/12/14(月) 17:06:58.52 ID:eBJzgHzn
Javaのプロジェクトだとほぼ使ってるけどな隠蔽してるだけで
そのせいで共有リソース壊したり、逆に個人情報の領域が共有されたりして、とんでもないインシデントが発生する
そんな奴等にメモリ管理なんて任せられんし、共有リソースも触らせたくないから
更に隠蔽したフレームワークもどきが出来上がる
283 :
名無しさん@そうだ選挙に行こう
2015/12/14(月) 17:59:33.07 ID:hn3965Zz
>>282
勝手に使うな。勝手にトリッキーコードにすんな。
素直に、設計書通りに作れ。
勝手なことやって勝手に自爆してるだけじゃねーか。
284 :
2015/12/14(月) 18:15:27.90 ID:Z4FycFda
javaってc++のconst参照に対応するものが無いのに、素人みたいなプログラマを大量にかき集めているのが怖すぎる。
285 :
2015/12/14(月) 18:28:13.63 ID:eBJzgHzn
>>283
理解してないのに無理してレスしなくていいから
286 :
2015/12/14(月) 18:42:08.38 ID:CJqGCki1
C#はマルチスレッド使いまくりだけど事故の話はあまり聞かないな
マイクロソフトが優秀なのか低品質プログラマがいないのか
287 :
2015/12/14(月) 19:01:59.11 ID:2+GDL4RD
JAVA自体がDQN
288 :
uy ◆Qawu9.2l1E
2015/12/14(月) 20:57:26.55 ID:J5PYIleC
Freeし忘れ

↑これ。


ソースコード書いてる人間の注意力次第でバグが入るなら
言語も設計も間違ってるよ
289 :
2015/12/14(月) 21:54:10.80 ID:ETDpPCfc
動的型言語

これ

コード書いている人間の注意力次第でtypoするだけで
実行するまでわからないバグが入るなら
言語も設計も間違ってるよ
290 :
2015/12/14(月) 22:23:00.81 ID:lNUL9lX8
C#でcatchやfinally書くの嫌すぎる
C++に戻りたい
291 :
2015/12/14(月) 22:43:08.79 ID:bhzmg0NL
>>290
おかえり
292 :
2015/12/15(火) 06:39:51.52 ID:gQhFMQgY
(ヽ´ω`)眠い
293 :
2015/12/16(水) 08:46:15.45 ID:fgV80IeN
>>290
C++/CLR「こっちこいよ」
294 :
デフォルトの名無しさん
2015/12/17(木) 17:18:40.36 ID:Szn4FINI
COMのVariantとかJSとかリークしまくりだし
295 :
2015/12/17(木) 23:16:36.40 ID:kltDf5Nv
そういやVBScriptって参照カウンタ以外のGC積んでんのあれ
必要には見えないんだけど
296 :
デフォルトの名無しさん
2015/12/18(金) 23:17:49.50 ID:b1Otx84Y
プログラマはMacを使ってるってマジ?
http://hayabusa3.2ch.net/test/read.cgi/news/1450395043/
297 :
2015/12/19(土) 07:07:37.11 ID:qL4RiVer
マカーってどんだけアホなの?
298 :
デフォルトの名無しさん
2015/12/19(土) 12:49:09.79 ID:EW8XrhCB
解放処理
すら、まともにお前ら管理できねーのかよ・・・・・・・・・・・・・・・・。そらオレが完璧な仕様書渡してもバグってるわけだ
299 :
2015/12/19(土) 13:38:07.82 ID:i3zp3GbO
開放処理を手動でやれって書いてある仕様書かw
御免こうむるwwwww
300 :
デフォルトの名無しさん
2015/12/19(土) 14:42:49.35 ID:iG82T79N
ガベコレのあるPyObjectをラップするクラスをガベコレのあるDで書いたら
wxPythonで書いたクラスをDから使ったとき意味不明なタイミングで落ちるようになった
二重に管理するとだめなんかな
301 :
デフォルトの名無しさん
2015/12/19(土) 15:57:38.71 ID:qL4RiVer
>>298
プププ 馬鹿だこいつw
302 :
2015/12/20(日) 08:46:23.14 ID:gr0U1KS4
ガベージコレクションはたしかに便利だ
だからといって「本来はてめぇのケツはてめぇで拭け=自分で解放すること」を忘れてはならない

そんだけ
303 :
2015/12/20(日) 11:55:11.08 ID:HXRBhwTH
C#ではSafeHandleだけ作って後は放置
usingも使わないってのがトレンドだけどね
自分で解放とかバカバカしい
面倒はランタイムに見させて開発者はドメイン設計に集中するって目的を見失うな
304 :
2015/12/20(日) 12:13:23.36 ID:ofrSOHxv
>>303
オブジェクトの開放を他と独立にやれるケースばかりならそう言えるかもしれんが
オブジェクトAとBがリソースCに依存しているケースでA、Bの開放の少なくとも片方をGCに任せる場合、
リソースCの参照カウンタなりをつかった防護策をプログラマーが書かねばならない
しかしそんな嫌ったらしい雑用を増やすぐらいなら
 Cオープン
 A生成
 B生成
 A, B使用
 B開放
 A開放
 Cクローズ
でええやん?

さらにダンプファイルとかからの障害解析において、オブジェクトが生きているべきなのか死んでいるべきなのか決まっていないとか、
アドレスがはっきりしないとか言う状況は地獄
305 :
2015/12/20(日) 12:21:54.48 ID:ofrSOHxv
つかこの世はうつろうもののであって、物理的ハードウェアでプログラムを実行する限り、
計算モデルは明らかに状態遷移ベース(チューリングマシン)の方に分がある
GCとかチューリングマシンで無理矢理関数型プログラミングを行うためのつなぎの技術、
いわば邪道
どんだけ蛇が出てくるか、GCの方がかえってわからん
306 :
2015/12/20(日) 13:48:14.94 ID:HXRBhwTH
>>304
設計が悪い
使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
知らなきゃ困るような設計にしたのが間違いだね
307 :
2015/12/20(日) 13:52:55.68 ID:8RLYRFXT
メモリ空間は無限であるべき
使い終わったメモリの断片化なにそれ?
仮想メモリを管理するのはCPUの責任だろ
308 :
2015/12/20(日) 14:03:49.29 ID:ofrSOHxv
>>306
>>304の例で、さらにCを上書き更新したいオブジェクトDがいたらどうすんの?
GCがA、B両方開放してくれるまでDは期限不定で待たされるけどそれが>>306的に良い設計なの?

つまり、ハードウェアリソースの有限性を考慮する限り
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
が常に成立はしないという話
309 :
2015/12/20(日) 14:28:20.48 ID:i39XsMQ2
>>308
そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ?
意見を否定するためだけの極端な反例(この場合は例にすらなっていないが)を引き合いに出すのは不毛だよ
310 :
2015/12/20(日) 14:35:53.96 ID:xl2QwS3M
>>303
いい加減だなぁw
311 :
2015/12/20(日) 14:36:58.02 ID:ofrSOHxv
>>309
>そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ?
極論なもんカヨ;
例: 表示デバイスの数>表示したいスレッドの数
というのはざらにある

で、>>308のオブジェクトDのケースはどう解決すんのさ…
GCが「いつ開放してくれるかわからない」ブツである以上解消しない問題だとおもうんだけど
(A、BにCのための明示的closeメソッドを付けるぐらいならGCに頼らずに順序管理するわ;
312 :
2015/12/20(日) 14:42:20.07 ID:ofrSOHxv
解決策の一つはActive ObjectパターンでリソースCの管理を1スレッドXにやらせて
Cに対する要求を全部Xのキューにシリアル化して入れさせるというのがあるが、それはそれで
リソースCを使う全てのオブジェクトがスレッドXに依存するから、Xの開放コードが面倒なことになりかねない
かつ、シリアル化はマルチコア時代のせっかくの並列実行性能を殺してしまう

GCに合わせて生きることは、神仙にでもならねば到底かなわぬ…
313 :
2015/12/20(日) 14:44:35.05 ID:ZDEpjFBd
つくづく、ARC最強だな。
314 :
2015/12/20(日) 14:46:27.58 ID:i39XsMQ2
>>311
その例じゃ308の状況にならないよ
どんなコード書いてんだよw
315 :
2015/12/20(日) 14:48:11.36 ID:ofrSOHxv
>>314
>その例じゃ308の状況にならないよ
なんで?ビデオメモリに2スレッドから同時に書いて無事に済むと思ってるの…;
316 :
2015/12/20(日) 14:51:52.93 ID:i39XsMQ2
だから同時に書く設計が悪いんだって
気合入れて設計を見直してみろ
そんな必要はないってわかるから
317 :
2015/12/20(日) 14:55:30.48 ID:ofrSOHxv
ていうか>>316の言っていることはますます矛盾で、
>同時に書く設計が悪い
>そんな必要はないってわかる
というのは明白に「書き込みの順序を設計できる」ということを言っていて、
それはその通り(チューリングマシンの計算モデルに合致する)ので別段漏れの立場と対立するものではなく、
かつ気合を入れて設計すれば順序で全て解決する(GCは不要である)という言明でもある
318 :
2015/12/20(日) 15:17:45.93 ID:14eB8c4R
>>315
もはやGCがどう関係するのかわからない
319 :
2015/12/20(日) 15:20:28.11 ID:i39XsMQ2
>>318
彼は敵対意見に反論する材料が欲しいというだけで変な例をでっち上げて出してしまったんだ
本人も今頃困ってるんじゃないかな
320 :
2015/12/20(日) 17:05:42.48 ID:6vo8OCaj
>>319
>>308を変な例変な例というばかりでGCを用いた正しい解決方法が一向に示されない件について:
繰り返しになるが、>>308のオブジェクトDのケースはどう解決すんのさ…
たとえ変でも反例は反例だし
>>308のリソースCがファイルなのだとしたら、病的な反例というほど例外的想定でもない

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

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

>>318
ウィンドウシステムでの描画は一般に裏VRAMに描いてハードウェアでBitBlt転送するが
裏VRAMに書く際のデバイスコンテキストが複数使えるが数に限りがある場合…
とか細かい話をしても通じないようならリソースCをファイルと考えてくんな
321 :
2015/12/20(日) 17:12:24.84 ID:6vo8OCaj
プチ訂正
誤: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、(>306)
正: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、(>308)
322 :
2015/12/20(日) 17:19:25.13 ID:HXRBhwTH
読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
書き込みたいから読み込み終わるの待ってますってリソースの無駄だろ
323 :
2015/12/20(日) 17:21:31.86 ID:ZDEpjFBd
なんか参照カウントの話とマルチスレッドの話がごっちゃになってね?
324 :
2015/12/20(日) 17:33:49.10 ID:6vo8OCaj
>>322
>読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
破壊的代入の世界ではそいつは常に可能とは限らない

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

この手の混乱は、A、BがアクセスするリソースCの開放タイミングの決定をGCに任せてサボったがために生じるのである
325 :
2015/12/20(日) 18:10:09.92 ID:ZDEpjFBd
おいおい、バージョン管理のマージの話にまで拡張したら収集つかなくなるぞw
326 :
2015/12/20(日) 19:32:49.85 ID:i39XsMQ2
>>324
ファイルの分割は必ずしも必要ではないし更新モデルから読み取りモデルへの同期も必要ないよ
327 :
2015/12/20(日) 19:44:06.53 ID:9YX+2XWA
>>323 (Rust信者で)すまんな。
ttp://smallcultfollowing.com/babysteps/blog/2015/12/18/rayon-data-parallelism-in-rust/#data-race-freedom
マルチスレッドで起きるデータ競合といった問題も、シングルスレッドで起きうるdangling pointerなどの問題も、
どっちも所有権を持つオブジェクトが無闇にいたり、変な参照関係があるから起きるんじゃないか?って言う人がおる。
根っこが同じ、あるいは近しい問題なんで、横滑りに見えても堪忍な。
328 :
2015/12/20(日) 19:49:46.85 ID:kaqci566
メモリ管理もできないんだから
データの依存関係とか関係ねえ〜〜〜〜〜〜〜〜〜〜〜〜
でおわりでは
329 :
2015/12/21(月) 05:26:25.94 ID:ejqZ3DMD
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 :
2015/12/21(月) 05:32:28.99 ID:ejqZ3DMD
その理由・・・GCは失敗。メモリは自分で管理せよ!
http://peace.2ch.net/test/read.cgi/tech/1447856699/l50
331 :
2015/12/21(月) 05:35:31.18 ID:ejqZ3DMD
メインメモリに対するGC・・・MGC
HDDならストレージGC・・・SGC
332 :
2015/12/21(月) 05:38:11.78 ID:ejqZ3DMD
GoogleChromeかsvchost.exeを使わなくなった理由・・・ページメモリGC制御が遅過ぎでお粗末だからか?
333 :
2015/12/21(月) 05:42:27.02 ID:ejqZ3DMD
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 :
2015/12/21(月) 05:45:15.43 ID:ejqZ3DMD
「Svchost Process Analyzer」
svchost.exeのプロセスの中身が何かを調べて表示するフリーソフト
http://gigazine.net/news/20131114-svchost-process-analyzer/
335 :
2015/12/21(月) 05:51:39.30 ID:ejqZ3DMD
そろそろsvchost.exeを使うソフトは使用禁止なのかも?
336 :
2015/12/21(月) 06:11:17.64 ID:ejqZ3DMD
svchost.exeを使わないことでGoogleChromeは確実に応答性能が速くなっている
・・・動画マルチ再生でクラッシュしたFirefoxは見習うべき
337 :
2015/12/21(月) 06:17:26.48 ID:ejqZ3DMD
338 :
2015/12/21(月) 06:40:32.08 ID:ejqZ3DMD
339 :
2015/12/21(月) 06:42:41.39 ID:ejqZ3DMD
340 :
2015/12/21(月) 06:43:24.61 ID:ejqZ3DMD
341 :
2015/12/21(月) 07:08:24.86 ID:ejqZ3DMD
342 :
2015/12/21(月) 09:26:05.64 ID:ejqZ3DMD
343 :
2015/12/21(月) 09:41:02.29 ID:ejqZ3DMD
344 :
2015/12/21(月) 09:44:40.17 ID:ejqZ3DMD
京がお仕置き候補に???
http://gigazine.net/news/20130618-fastest-supercomputers/

◆1位:Tianhe-2(天河二号)、中国人民解放軍国防科学技術大学
http://i.gzn.jp/img/2013/06/18/fastest-supercomputers/01_m.jpg
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_titan2_m.jpg
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_8716842181_3f50ae207a_o_m.jpg
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.jpg
富士通 SPARC64 VIIIfx(8コア・2.0GHz)を採用し、コア数は70万5204、
計算速度は10.5ペタフロップス、消費電力は12.7MW

◆5位:Mira、アメリカのアルゴンヌ国立研究所のエネルギー部門
http://i.gzn.jp/img/2013/06/18/fastest-supercomputers/05_30292D004-72dpi_m.jpg
BM BlueGene/Qを採用し、中のプロセッサーはPower BQC(16コア・1.60GHz)、
コア数は78万6432、計算速度は8.6ペタフロップス、消費電力は3.95MW
345 :
2015/12/21(月) 09:50:17.19 ID:ejqZ3DMD
気づかないかISOは中国のためにある
http://www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1742-a.JPG
346 :
2015/12/21(月) 10:45:57.17 ID:1HvlxK+M
>>344
蓮舫さんに次の選挙は次点で良いですよねって言ってきて
347 :
2015/12/21(月) 11:12:03.51 ID:1HvlxK+M
>>336
ほんそれ
348 :
2015/12/21(月) 12:31:40.33 ID:ejqZ3DMD
349 :
2015/12/21(月) 12:34:04.50 ID:ejqZ3DMD
350 :
2015/12/21(月) 12:36:38.19 ID:x6st9rMu
ただしChromeはプロセスが一杯できるから
タスクマネージャ覗いた時に気持ち悪い
351 :
2015/12/21(月) 16:06:45.56 ID:ejqZ3DMD
352 :
2015/12/21(月) 16:21:26.45 ID:ejqZ3DMD
353 :
2015/12/21(月) 16:33:49.61 ID:ejqZ3DMD
354 :
2015/12/21(月) 16:35:11.77 ID:ejqZ3DMD
diginnos stickpc_02
http://www.youtube.com/watch?v=OPt0OGNQhnU&list=RDOPt0OGNQhnU
355 :
2015/12/21(月) 18:37:51.00 ID:ejqZ3DMD
356 :
2015/12/21(月) 18:38:29.84 ID:ejqZ3DMD
357 :
2015/12/21(月) 18:43:07.58 ID:ejqZ3DMD
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.41 ID:LOFSek54
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.36 ID:LOFSek54
Vivaldiの起動が遅いのは
タブのサムネイルに関係しているかもしれない
Blinkは負荷分散のため?かHDDアクセスも遅いらしい
ローカルストレージ関係がとても遅いからだ
タブサムネイルを
ローカルストレージで保存するのは止めたほうがいい
タブサムネイルは直接アクセスする事
fopen();ランダム書込:fclose();ランダム読込:fopen();
読取だけならオーバーヘッドを避けるためfopen();しない
命題・・・Vivaldiは遅い起動を早期解消せよ!
ランダム書込用HDDスペースを作る 個数*固定サイズ 
1トランザクション 個数1024個、固定サイズ256kバイト 
そしたら、ランダム読み書きでfopen()すればいい
オーバーヘッドを避けるためfopen();は終了のときだけ
オーバーヘッド無いだけで1000倍ほど速くなるケースも
オーバーヘッドはドコにあるのか?
それはWindowsOSのフォルダ構造検索にある
フォルダ構造検索回数を省けば速くなるのだ
360 :
デフォルトの名無しさん
2016/01/10(日) 12:52:32.51 ID:LOFSek54
fopen();のときフォルダ構造検索するようだ
361 :
デフォルトの名無しさん
2016/01/26(火) 06:48:44.23 ID:v48l+1vS
やっとこの気色の悪い仕組みにトドメが刺されたか
javaとかGCが基本だけどflash();とかできるの?
362 :
2016/01/26(火) 07:35:03.77 ID:RBo8KHcc
ゴミ言語は所詮ゴミ
363 :
2016/01/27(水) 17:10:09.80 ID:eULyfEEH
GCのすべてを否定するつもりはないけど・・・
GCはメモリ管理を自動化する技術だけど、今のコンピュータはメインメモリを何十ギガ積んでたりするのも普通で
メインメモリが足りなくなることはほぼ無くて、しかも仮想メモリもあるから、なおさらメモリは潤沢で・・・
むしろメインメモリ以外のリソースの方が余程貴重で、もし仮にメインメモリが足りなくなるまで
GCを発動しないアホなGCが有ったとしたらメインメモリより先に他のリソースが枯渇する状況

だからメインメモリは無駄遣いしてもよいけど、他のリソースは使い終わったら
こまめに開放しないとダメだから、いつ実行されるか分からないマークスイープ系GCの余計にRAIIな仕組みも必要なわけ

しかしこのRAIIが付け焼刃でなまっちょろい出来だったりする
C#で言えばDisposeが有るけど、C++のデストラクタのように特別扱いされておらず
ただの普通の関数でしかないので、C++のデストラクタみたいに自身のメンバ変数について
自動で芋づる式に呼び出してくれない
だから手動でメンバのDisposeを芋づる式に呼び出すコードを記述しなければならない

いちいち自身のメンバ変数にIDisposableなものが有るか無いか調べるのもひと手間かかるし
もしそうだったら自身もIDisposableにする必要があり、例の一連のイディオムを書かなければならない
当たり前にDisposeの呼び出し忘れが有ってもいけない
まるで、mallocしたらfreeするのと似ている
しかもIDisposableはコンポジションで増殖する
IDisposableなオブジェクトをコンポジションしたら、自身もIDisposableといった具合

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

結局C++の方式が一番優れている
循環参照が発生する場合はweak_ptrを使う事だけ注意を払えば
GCにまつわる他の問題が一切発生しない
365 :
2016/01/27(水) 17:46:52.79 ID:eULyfEEH
もっと言えばC#でDisposeを実装する場合でも↑は問題になる
自身のメンバのDisposeを呼んでよいのかどうなのか

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

GC任せにするか、自分で参照カウンタを実装するか
どちらにせよ、RAIIと相性が悪い
366 :
2016/01/27(水) 17:58:09.12 ID:aloDWtjb
前から何度も言ってるがDisposeの実装はしていいが呼び出しは禁止
これがC#では基本だからね
リソースの使用効率が悪いとか軟弱な反論をするバカがたまにいるが
実行効率気にするならそもそも別の言語使えって話になるからな
C++CLIを使えってこった
本質を見誤るなよ
367 :
2016/01/27(水) 18:38:52.76 ID:XmqLFQFE
c#の欠点はデストラクタが呼び出されるタイミングが分からないこと。
不便で仕方ないや。
368 :
2016/01/27(水) 18:56:08.53 ID:VDkVQpP+
最近VB.NETを使い始めたんだけど
new したオブジェクトが不要になった時にDispose()よんだり参照にNothing代入する必要ってない(やってもいいが無意味・無駄)なのかな?
369 :
2016/01/28(木) 08:05:17.75 ID:oip5UtLa
c++のデストラクタは例外投げられないウンコ仕様
だから皆デストラクタ内で発生したエラーは握り潰してる

他の言語はあんなバカなの真似する必要ない
370 :
2016/01/28(木) 17:53:06.50 ID:M0BYpVOa
デストラクタで投げるなよ。迷惑な奴だな。
371 :
2016/01/28(木) 18:02:00.92 ID:xwQj4KRs
javaはファイナライザで発生した例外は握りつぶすことが仕様で決まっているな。
c++の場合は、デストラクタでどうしても例外を外に伝えたかったらやりようはある。
372 :
2016/01/30(土) 01:11:50.31 ID:QZN0GaAw
そら伝えたかったらやりようはいくらでもあるでしょう?C++に限らず
373 :
デフォルトの名無しさん
2016/02/10(水) 11:29:59.19 ID:lL2Wg2mH
Javaは強制的に解放させることもできるようにすべきだったな。
374 :
2016/02/10(水) 11:41:46.63 ID:83b7Yxnh
Java(VM)は(すべてのプラットフォームで)強制的に解放させることもできるようにすべきだったな。
375 :
2016/02/10(水) 12:19:44.29 ID:k9iR7lzz
都度メモリ管理するよか、GCに任せた方がスループット的に有利な場合も多いでしょ。
376 :
2016/02/10(水) 14:29:59.29 ID:CcpqYYAq
GCはメモリ管理に関しては成功してる、
でも、メモリブロックをオブジェクトに昇格させたにも関わらず、相変わらず「メモリ管理」だから失敗。
377 :
2016/02/10(水) 17:29:46.71 ID:+sMp0qjD
そうそう、メインメモリの管理に関しては100%成功している
しかし、今やメインメモリはそれほど貴重なものではないわけだがな
コンシューマでも数十GB積んでたりは珍しくない
メインメモリがなくなるより他のリソースが枯渇する方が現実的
だからメインメモリ以外のリソースに関しては使い終わったら即座に開放してほしいから
GCとは別にRAIIを行う仕組みを導入するわけだが
真剣に考えていくと、RAIIはGCと相性が悪い
そもそも使い終わったら自動で即座に開放(RAII)できるなら全てのGCはそう実装すべきで
それが出来ないからわざわざコストのかかるマークスイープを遅延して実行しているわけだからな
C++みたいにGCを参照カウンタ方式にして、プログラマが人力で循環参照が無いことを保証する以外に
あちこちから参照されるオブジェクトのRAIIを自動化する方法は無い
378 :
2016/02/10(水) 20:59:51.38 ID:rEABlirv
JAVAはクソ
379 :
2016/02/10(水) 21:00:45.91 ID:ZQ/yQmxu
簡単だよ
スレッド立ててGCをフルサイクル実行し続けるだけ
380 :
2016/02/11(木) 16:22:39.56 ID:vxbPXQEr
javaもsandy-bridge以降でSSDとかならそれほど重いってわけじゃないけど
相変わらずatomでeMMCだったりする環境も並行して存在してて
そこで動かすと改めて糞だと思うわけよ
GCが悪いんじゃなくてjavaランタイムが悪いんだろうけどね
381 :
2016/02/11(木) 19:04:56.18 ID:EuRhj+pR
フラッシュとJAVAは、システムに見つかり次第、速攻アンインストールしている
382 :
2016/02/12(金) 08:32:20.35 ID:Uwfak+5B
>>377
Pythonみたいに参照カウント+GC(循環参照を解放するため)が最強ってこと?
383 :
2016/02/13(土) 15:34:22.04 ID:OKKAbu21
最近のPC環境でも贅沢が過ぎるプログラムは動かん。
最近の奴だと、Node.jsのパッケージマネージャnpmが`npm search`と初回に打つとパッケージ検索用のインデックスを作ろうとするんだけど、
1つのjsonオブジェクトにまとめようとするからかOOMエラーを吐いて失敗するっていう不具合。
npmに登録されてるパッケージ数が膨大になったせいもあるが、設計を間違えると遅いどころか動かなくなる。
384 :
2016/02/13(土) 22:32:48.48 ID:6Xm9VASh
GCがある言語でRAIIみたいな事したいのなら
loan patten使えばいいだけでは
385 :
2016/02/13(土) 23:42:47.95 ID:VLo29AwR
リソースを共有した上で最後の参照が切れた時点で回収してほしい
しかし誰が共有するかもその寿命も実行時までわからない
そういう前時代的なダサい設計をした時の話しなんだろ
Loan Patternはこの状況では役に立たない
386 :
2016/02/14(日) 00:56:38.97 ID:mwiD0ozs
しかし、言語側は、そういうダサい設計も許さないといけないので
マークスイープ系GC搭載で、循環参照が有っても良いことが前提になっている言語で
「使い終わったら自動で即座に開放」を実現するのは困難
そんなことが可能なら、マークスイープは要らないからな
387 :
2016/02/14(日) 19:42:04.72 ID:I7Qc+kxz
循環参照なんて放置すればいいの
どうせプロセスが終了すればOSが開放してくれるの
388 :
デフォルトの名無しさん
2016/02/14(日) 20:10:25.23 ID:EqhxGdNa
>>387
Windowsのように定期的に再起動しなければいけないソフトウェアができあがっちゃいそう
389 :
2016/02/15(月) 18:16:17.47 ID:TvNTryet
ErlangでOS作るか
390 :
デフォルトの名無しさん
2016/02/15(月) 19:50:44.55 ID:L+A+Kd2h
そこはRustで
391 :
2016/03/01(火) 15:00:17.89 ID:QERDe7Jh
5分でわかるガベージコレクションの仕組み
https://geechs-magazine.com/tag/tech/20160229
392 :
デフォルトの名無しさん
2016/03/23(水) 02:31:06.32 ID:MFzvJNSi
常識的に考えてカーネルの実装にはGCなんて使えないし
業務アプリケーションではパフォーマンスより開発速度がはるかに重要になる
結局適材適所だ
GCを強制されるのは苦痛だが使えないのも苦痛だ
好きな時に使える言語がいいよね!
393 :
2016/03/23(水) 03:41:39.64 ID:SoMbpeP6
パフォーマンスが問題にならないGCが一つだけあって、それが参照カウンタ方式のGC
パフォーマンスが問題にならない→即座に逐一削除できる→RAIIが出来る
非常に強力だがプログラマが循環参照が無いことを保証しなければならない
しかし、循環参照が発生する場合は設計段階で分かるのでそれほど深刻では無いのだ!
394 :
2016/03/23(水) 03:47:03.14 ID:VzK80P8k
androidでもう何も判らん状態でプログラミングして
それなりに動くのができたからおれは許したよ
でもサービスまで勝手に回収されちゃうとは思わなかったわ
アホだろグーグル
395 :
2016/03/23(水) 07:53:14.58 ID:JT2FURwc
RAIIに必要なのはデストラクタが呼ばれることであって実際にメモリが解放されることじゃないから
GC言語でもRAIIができないわけじゃない。
396 :
2016/03/23(水) 10:07:19.06 ID:SB04Y3rp
RAIIに必要なのは適切なタイミングで確実に解放処理が呼ばれることであって
いつ呼ばれるかわからないデストラクタではだめ
397 :
2016/03/23(水) 18:24:05.29 ID:jWiL+V+6
かつてStandard MLの実装で、GCじゃないメモリ管理方法をやってみたのがあったな。
コンパイラが全部自動でやるからコードの見た目はSMLなんだけど、いざ動かすとGCより遅かった。

ある程度プログラマがリソース管理のためのヒントを与えないと、GCを捨てられない。
398 :
2016/03/23(水) 20:05:29.02 ID:JT2FURwc
>>396
おまえが言っているのはファイナライザ。
それと、デストラクタはメモリの解放なんかしないよ。デストラクトするだけ。
399 :
2016/03/23(水) 21:43:30.89 ID:SoMbpeP6
この際、呼び名はどうでも良い
参照カウンタ方式以外のGCでは、どこからも参照されなくなったことが、即座にはわからない
だから、自動で即座に開放関数を呼び出すことが出来ない→RAIIが出来ない

C#で言うところのusingみたいに、プログラマが手動で情報を与えるなら出来る
だが、usingはGCでは無い
400 :
2016/03/24(木) 00:53:54.57 ID:smGLwjga
いまさら、ゲームキューブ叩いてどうするんだ?
401 :
デフォルトの名無しさん
2016/03/26(土) 05:40:22.28 ID:vD3g1idC
>>393
間違い
マークスイープのように負荷が集中しないだけでありパフォーマンスへの影響はある
特にツリー状のデータついてルートが削除された時子要素もデクリメントする必要があるため負荷が大きい
カウンタはオブジェクト毎に持つためコピーオンライトとの相性が悪い
また言語の機能として実装されなければ明示的に行う必要がある(例えばCとか)
そのためgcない言語ではマークスイープと比べ非常に面倒なことになる
402 :
2016/03/26(土) 10:35:48.15 ID:GKwGPSgf
androidで原因不明のフリーズが発生、プロジェクトはデスマーチに突入した
これだからGCは
403 :
2016/03/26(土) 11:39:27.66 ID:drxQ1xsy
これだからGCに頼りきった未熟者は
404 :
2016/03/26(土) 11:39:40.83 ID:MgEq8J/o
>>401
そりゃどんなものだって多少の負荷は有るよ
しかし参照カウンタの上げ下げの負荷なんか
マークスイープに比べれば無いも同然
405 :
2016/03/26(土) 18:02:09.56 ID:2IjmMYr5
マルチスレッド環境だと参照カウンタとかいうクソアルゴリズムは使い物にならない
406 :
2016/03/26(土) 18:52:26.07 ID:QL60ocAy
参照カウンタがオーバーフローしたらどうなんの?
407 :
2016/03/26(土) 19:10:36.57 ID:nXtJgRqN
>>405
SSOのが遅いだろ
>>406
size_t にしとけばオーバーフローしない
408 :
2016/03/26(土) 19:44:45.11 ID:R9brpoqy
>>406
殿堂入りさせて、回収しない
409 :
2016/03/26(土) 20:22:44.37 ID:QL60ocAy
>>407
確かに現実的にオーバーフローしないと言えると思うけど
STLとかもそういう実装になってる?
410 :
2016/03/26(土) 20:52:01.21 ID:rTAUpSul
使う側は少なくとも1つのポインタを持たなくちゃいけないんだからオーバーフローし得ないだろ
411 :
2016/03/26(土) 22:10:23.58 ID:6zuFQelp
マルチスレッドでGCスレッド立ち上げて、再配置起こる可能性のある普通のGCだと、オブジェクト毎にLock,Unlockできる何らかの機構が必要だし、参照カウンタ増減するより高頻度でその機構使うよね。
412 :
2016/03/26(土) 22:34:25.82 ID:2IjmMYr5
そうでもない
413 :
2016/03/26(土) 23:56:59.65 ID:MgEq8J/o
例えばWindowsだとInterlocked系のAPIを使えば
マルチスレッドでも安全に参照カウンタを増減できるから
パフォーマンスは何の問題もない
414 :
2016/03/27(日) 00:13:33.76 ID:MdJCnp0Y
C#なら参照のコピーはただのワード代入で済む
メモリ確保もポインタへの加算だけで済むから圧倒的に速い
回収もマルチスレッドで処理されるから圧縮フェーズ以外はUIへの影響もなくユーザ目線では実質コストゼロ
良いコードを書いてるなら圧縮もたまにしか起こらないし起こっても大した事ない
415 :
2016/03/27(日) 00:26:17.07 ID:vj+h39OC
>>399からの流れを見ればわかるがそういう話ではない
参照カウンタ方式以外のGCは、オブジェクトがどこからも参照されなくなったことが「即座」にわからない
だからRAIIが出来ない、そういう話

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

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

参照カウンタ方式で問題になるのは循環参照が起こった場合だが
循環参照が発生する箇所は設計段階で分かるので、実際には大した問題ではない
C++であれば、片方をweak_ptrにすればよいというだけの話
そこさえ気を付ければ、参照カウンタ方式とデストラクタの組み合わせは非常にうまく機能する
IDisposableのようなものも要らない
416 :
2016/03/27(日) 00:27:10.73 ID:vj+h39OC
>循環参照以外のGCは重いと言っている

↑間違えた

参照カウンタ方式以外のGCは重いと言っている
417 :
2016/03/27(日) 00:41:23.52 ID:15KjVKPo
>>413
安全が何で保証されてるのかを知るためにアセンブラを勉強しなさい。
その上で「パフォーマンスは何の問題もない」かどうかを語りなさい。
418 :
2016/03/27(日) 00:59:17.81 ID:kBj57j3O
前にも書いたが、RAIIとGCは直接の関係はないよ。
現にC++/CLIでは、ローカルスコープのオブジェクトがスコープを抜けた時点、あるいは
gcnewで作成されたオブジェクトがdeleteされた時点で即座にデストラクタが実行されて
メモリの回収自体はGCで行われる。
419 :
2016/03/27(日) 01:02:24.98 ID:MdJCnp0Y
>>415
そもそも不可視のコードでリソースを解放するのが愚行そのもの
プログラマとしての良識があるならusingを使いなさい
RAIIなどというくだらないバッドノウハウはC#では必要ない
420 :
2016/03/27(日) 01:31:49.74 ID:vj+h39OC
>ローカルスコープのオブジェクトがスコープを抜けた時点、あるいは
>gcnewで作成されたオブジェクトがdeleteされた時点で即座にデストラクタが実行されて
>メモリの回収自体はGCで行われる。

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

寿命管理を自動化(GC)しつつ、RAIIを実現する話をしているわけだが
どんな場合でも、GCで有ろうが無かろうが、手動でデストラクタなりファイナライザなり呼び出せば
RAII出来るに決まっているだろ、それに何の意味が有るんだよ
自動化の話だよ
421 :
2016/03/27(日) 01:33:16.88 ID:vj+h39OC
>そもそも不可視のコードでリソースを解放するのが愚行そのもの

その最たるものが、マークスイープ系GCなわけですが
いつ実行されるかすら分からない
まさに不可視
422 :
2016/03/27(日) 01:51:43.15 ID:vj+h39OC
極端な話
mallocして使い終わったらfreeして
はい、手動でRAII出来ました!って主張
それ何の意味が有る話なの?ってね
423 :
2016/03/27(日) 07:41:27.84 ID:kBj57j3O
>>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の有無に直接の関係はない。
424 :
2016/03/27(日) 10:01:03.80 ID:MdJCnp0Y
メモリとその他のリソースを混同して考えるからダメ
まずその他のリソースは不可視のコードで解放しちゃダメ
リソースのスコープは明示的でなければならない
これはデストラクタにもGCにも任せられない
逆にメモリは不可視のコードで解放してもよい
まずこの基本原則から話を進めよう
425 :
2016/03/27(日) 10:12:42.93 ID:Ap0rkncx
schemeにはdynamic-windみたいな他所に継続が飛んでも後処理が保証される仕掛けがあるし
デストラクタがない==RAIIできないにはならないと思うの・・・
426 :
2016/03/27(日) 11:03:59.82 ID:+zMq83Ww
>>424
んな事はない。
あらゆるリソースの寿命はライブラリでデフォルトの管理がされるべきであり、使用者の完全性を前提にすべきではない。
427 :
2016/03/27(日) 11:16:32.31 ID:MdJCnp0Y
>>426
銀の弾丸は無い
あらゆるリソースのあらゆる利用形態に対してデフォルトの動作を定義できるなら話は別だが無理だよね
結局は人が方針を決めて書くしか無い
幸いにしてメインメモリにはRAIIやマークスイープという正解が見つかっているのでそれを使えばいい
だが他のリソースはダメだ
428 :
2016/03/27(日) 16:21:42.54 ID:vj+h39OC
>>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はともかく、デストラクタでもダメって意味不明すぎるんだが
考えの根本がおかしい
429 :
2016/03/27(日) 16:43:31.54 ID:vj+h39OC
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 :
2016/03/27(日) 16:44:43.86 ID:vj+h39OC
訂正

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



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

参照カウンタ方式+デストラクタ
であればこれらの問題は一切発生しない
参照カウンタが0になったことは即座にわかるし、デストラクタはメンバ変数に対して芋づる式に呼び出されるので
開放に関しての特別なコードを手動で書く必要は無い
開放処理も一本化される
432 :
2016/03/27(日) 17:16:20.56 ID:UGnRhUEw
長文は漏れなく基地外
433 :
2016/03/27(日) 17:17:01.33 ID:MdJCnp0Y
>>428
バカすぎる
細かい事気にせずデストラクタで解放すりゃそれでおkって感じの適当な現場でしか働いた事無いんだろうな
434 :
2016/03/27(日) 17:22:53.59 ID:/D0vdPDd
ポインタがメンバ変数になってたら公開しちゃいかんでしょ
435 :
2016/03/27(日) 17:24:21.54 ID:MdJCnp0Y
まずDisposeは生成できる
めんどくさいという奴は知識が無いだけ

リソースを共有する事は少ない
というか設計段階で可能な限り少なくする
そして共有するならするでしっかり管理して自動解放などという手抜きはしない
基本中の基本だ
436 :
2016/03/27(日) 17:32:09.52 ID:+zMq83Ww
デストラクタで解放してはいけないリソースをデストラクタで解放しなければいいだけで、デストラクタで解放すればいいリソースはデストラクタで自動的に解放すべき。
437 :
2016/03/27(日) 20:12:26.78 ID:kBj57j3O
>参照カウンタ方式+デストラクタ
>であればこれらの問題は一切発生しない

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

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

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

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

どう違うというのか。
438 :
2016/03/27(日) 20:35:08.73 ID:Ng/EIIMI
RAII信者の痛さは異常
オブジェクトをコピーされたら破綻するのに
439 :
2016/03/27(日) 21:10:56.38 ID:N7IGtcj3
グローバルインスタンスホルダーは明確にインスタンスの状態を把握したいときに積極的に使うべき
440 :
2016/03/27(日) 22:32:53.86 ID:vj+h39OC
>「いつか」全員が所有権を手放したら「即座に」破棄される
>「いつか」全員が所有権を手放したら「いつか」GCで破棄される
>どう違うというのか。

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

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

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

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

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

要するにマークスイープ系GCではDisposeのコンパイラによる自動生成が出来ないという大きなマイナスが有る
441 :
2016/03/27(日) 22:36:05.37 ID:15KjVKPo
>>438
しねーよ
442 :
2016/03/27(日) 22:41:25.16 ID:VNvh7E4d
>>440
子要素をDisposeしていいかどうかもわからないってそりゃ設計サボってる以外のなんでもないだろう
ちゃんと設計してればいつ削除してよいかなんてわかるはずだろ
まともに設計もできないレガシーエンジニアは黙っててよ
設計に時間使わないとリソース云々以前に別のバグだらけになるぞ
443 :
2016/03/27(日) 23:42:37.04 ID:Ng/EIIMI
RAII信者は頭が悪いな
444 :
2016/03/27(日) 23:59:39.99 ID:15KjVKPo
>>443
自分の頭を検証しな
445 :
2016/03/28(月) 00:10:58.97 ID:h9yZCrPP
メンバにDispose持たせる設計って大抵ダメだよね
446 :
2016/03/28(月) 00:20:40.85 ID:j/beyn8U
>>440
前者(参照カウントGC)はRAIIができるが後者(マーク&スイープGC)ではできないというお前の
主張について言っているんだが?
「最善が尽くされる」からRAIIができて、尽くされないからRAIIができないとでも言うのだろうかw

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

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

ここまで説明しても理解できない低脳ならしょうがない。
やはりデストラクタとファイナライザの違いが理解できてないようだからそこから勉強しなおせ。
447 :
2016/03/28(月) 00:39:52.48 ID:2h3yopdG
{
std::shared_ptr<my_namespace::my_class> p(new my_namespace::my_class(...));
/* unko_code */
}

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

美しいという事はいい事だね
C#は書いてある事がシンタックス的にもセマンティック的にも明確だ
リソース管理はこうでなければならない
448 :
2016/03/28(月) 01:22:52.25 ID:khgTmo3F
>>447
C++にもusing使えやw いらない波括弧外せやw
449 :
2016/03/28(月) 03:34:15.37 ID:d3YBhLBG
>>447
usingの方が全然明確だね
objがコピーされてても問題ない
RAII脳ではわからないんだろう
450 :
2016/03/28(月) 03:36:11.96 ID:d3YBhLBG
schemeに何十年も前から存在するwith-xxxx 系を一般化した構文だね
451 :
2016/03/29(火) 01:23:53.57 ID:Qm5oX8hY
アレを更にtypedefされたりされると
ワケワカランくなるよな
452 :
2016/03/29(火) 01:50:13.51 ID:40IzaG0J
c++なら普通こうだな
{
my_class obj(...);
...
}
そういやc#でp.release()相当の事って簡単にできるの?
{
auto p(make_unique<my_class>(...));
...
}
nullって代入可能?
453 :
2016/04/04(月) 02:47:24.69 ID:+1V6ohqL
GCがあるのになぜJavaはメモリリークしまくるソフトウェアを量産するのか
454 :
2016/04/04(月) 02:55:18.29 ID:FhdBY7IF
>>453
Javaだから
455 :
2016/04/12(火) 23:15:42.48 ID:ZWvwh7J9
Rust使えばいいのさ
456 :
2016/04/13(水) 10:33:47.16 ID:+hJ3fPVS
>>455
会社にいるよな、そういうやつ
457 :
2016/04/13(水) 15:29:31.16 ID:oOcEPJTu
GC大好きっ子に聞きたいんだが
完璧な(理想的な)GCを搭載したメジャーな言語処理系って何があるの?
これで開発すればリークも管理も気にしないでOKってやつ
458 :
2016/04/13(水) 16:22:35.14 ID:s5MRiDQ8
無い

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

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

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

あと、GCは基本的にメインメモリに対してしか有効に機能しないから
例えばファイルオブジェクトなんかは要らなくなったら即座にcloseするなりすべきで
リソース管理フリーというわけにはいかない
459 :
2016/04/13(水) 16:54:16.68 ID:s5MRiDQ8
つまりは、GCを使っていたとしても
君がオブジェクトを何処かに登録したなら
オブジェクトが要らなくなったら登録解除してあげないと
そのオブジェクトは解放されないのだ
これはちょうどmallocしたらfreeしましょうに似ていて
GCを使ったとしても全てのリソースの管理が自動になるわけではないということだね

究極的にはGCの利点は自分でfree/deleteをしなくても良いところにある
これはつまり、ダングリングポインタが発生しないということだ
460 :
2016/04/14(木) 20:54:37.84 ID:f1hhftJp
>>457
C+BoehmGC
461 :
デフォルトの名無しさん
2016/04/17(日) 16:17:55.58 ID:j/f/oFPY
そして無視されてしまうコピーGC君
GCの利点は自分で大量にメモリの確保&解放するプログラムにおいてバグが出にくくスループットも出るってところだと思う
もしheapをそんなに頻繁に確保&解放しないんだったらGCない言語の方がいい
ただ近代的な言語は少数の例外を除いて大抵GC積んでるけど
462 :
デフォルトの名無しさん
2016/04/17(日) 16:21:44.96 ID:j/f/oFPY
>リソース管理フリーというわけにはいかない
リソース管理フリーについてはrustみたいなGCない言語のほうが達成できてるよね(あとは関数型言語か)
でもrustでもリソースの解放時にエラーを吐く可能性がある処理なら自分で解放する処理書かなきゃいけないっぽいけど
463 :
2016/04/17(日) 18:35:17.89 ID:SAR9JCaP
RAIIでも結局どのタイミングで解放されるか意識しなくてもいいってわけじゃないし
リソース解放処理を書かなくていいだけで
464 :
2016/04/17(日) 18:43:59.82 ID:cFoKw8Zx
メモリ管理系のバグが顕在化しにくいだけで、そこら辺適当なまま中途半端にキャリアを積む開発者を量産するという害悪が大きい。
JNIやらで他のAPI使う必要が出てくると結局いろいろ配慮しなきゃいけなくなるし。
465 :
2016/04/17(日) 19:43:44.44 ID:oNE1M7I6
>>460
コンサバじゃ完璧にほど遠いぞな
466 :
2016/04/17(日) 19:50:47.36 ID:1R/4ebGS
>メモリ管理系のバグが顕在化しにくいだけ
結局これだよね
本当に丸投げできるなら乗っかるのもいいと思う
性能問題はハードの進化で一部の用途を除けば問題無くなると思うし
でも現実は中途半端だから意識して書いたほうがマシだと
467 :
デフォルトの名無しさん
2016/04/17(日) 21:19:09.59 ID:IB74e9ph
ムーブセマンティクスのおかげでずいぶん便利に。
468 :
2016/04/17(日) 23:09:38.99 ID:j/f/oFPY
あと正確にはGCには含まれないけどメモリコンパクションをやってくれる処理系が多いのも
GCを使う利点になるかも
469 :
2016/04/17(日) 23:17:23.70 ID:cFoKw8Zx
今どき意図的にやらない限りメモリフラグメンテーションで困るような場面があるか?
アドレス空間も余裕出てきたし、多少おかしな確保パターンで浪費してもGCほど実メモリを食わないし。
今どき主流のサイズ毎に空きを管理するmallocは優秀だしね。
これがダメならlinuxカーネルとか先に落ちちゃうぞ。
470 :
デフォルトの名無しさん
2016/04/18(月) 15:56:44.18 ID:kcE0qDSU
>>469
昔、C/C++を駆使して日本が誇るスパコン京に投入するタスクセットを書き上げたのだが
実行するとどうも性能が出ない。
色々調べた結果、どうやらメモリーが断片化していることが分かった。
そこで多大な投資を行いJavaで書き直したらなんと100倍も性能が上がったのです!
これが>>468さんの経験してきたことなんです。
471 :
2016/04/18(月) 16:30:17.23 ID:BDPQ12Es
自前のメモリ管理が超下手くそなだけやろ
修業して出直してこいや
472 :
2016/04/18(月) 16:37:09.21 ID:OvHIqTOi
自慢になってないような
473 :
2016/04/18(月) 16:44:52.62 ID:9yQABY6F
ゲームだとフラグメント問題になること多いよ
ゲーム専用機なら特に
最近は特にオープンワールドが当たり前になってるけど
あれストリーミングでどんどんメモリ置き換えていくしね
474 :
2016/04/18(月) 16:47:31.98 ID:/wa5LIjH
jemallocのようなモダンなmalloc実装使えば良かったのでは。
475 :
2016/04/18(月) 17:47:00.91 ID:IBBVu28x
ゲーム専用機でフラグメンテーションおこすとか開発者としての適性を疑われても不思議ではない。
オブジェクトの寿命管理すらしないのか?
476 :
2016/04/18(月) 18:51:08.61 ID:RPQ9NKJO
メモリのフラグメンテーションをC/C++でコントロールする方法ってあるの?
mallocの実装頼りじゃなく。
477 :
2016/04/18(月) 19:05:27.63 ID:OvHIqTOi
mallocの挙動がわかってれば、ある程度は・・・・
478 :
2016/04/18(月) 19:14:30.71 ID:OvHIqTOi
細かくメモリ要求するから、下回りで時間がかかる
メモリ分断されてもオンメモリでの検索はさほど時間がかからない
(空きができても、そこに入らないときに)
479 :
2016/04/18(月) 19:15:14.97 ID:9yQABY6F
>>475
フラグメンテーションって何かわかってないでしょ?
寿命管理だけでは解決できないよ
480 :
2016/04/18(月) 19:21:39.69 ID:IBBVu28x
寿命管理で解決できないとか、フラグメンテーションがどういう現象か分かっているの?

汎用の寿命管理APIみたいなのを使うとか言うのと勘違いでもしている?
481 :
2016/04/18(月) 20:02:22.75 ID:3yZKjOEp
>>480
おいおい・・
この場合寿命を管理できないってのはgiven conditionとして考えないと
そりゃ寿命があらかじめわかってるなら苦労しないっての
大規模なプログラムでそんな恵まれた状況は例外的だよ
482 :
2016/04/18(月) 20:57:42.92 ID:IBBVu28x
専用ゲーム機上のゲームだよ。
リソースが逼迫したら何を優先するかの戦略も含めてほぼ理想的なgiven conditionだろうに。
ユーザーの行動による不確定性も全てコントロール下にあるだろうに。
483 :
2016/04/18(月) 21:13:59.16 ID:RPQ9NKJO
>>482 専用ゲーム機と普通のPCの1アプリケーションとで何が違うのか。mallocも使わないってこと?
NoGC, 各GCでメモリ空間がどう使われるかを視覚化
ttps://spin.atomicobject.com/2014/09/03/visualizing-garbage-collection-algorithms/
黒: 未使用
灰: 確保
緑: 読み込み
黄: 書き込み
赤: GC用のアクセス(参照カウンタ、マーク用ビットetc)
緑と黄は時間経過で退色していく

メモリフラグメンテーションという観点から見ると、コピー型GCが綺麗。
484 :
2016/04/18(月) 21:15:59.31 ID:3yZKjOEp
まぁテトリスとかならその程度の理解でいいんじゃない?w
485 :
デフォルトの名無しさん
2016/04/18(月) 21:33:24.92 ID:kcE0qDSU
Javaの寿命管理APIは最強ですな。
486 :
2016/04/18(月) 21:49:39.41 ID:9yQABY6F
>>482
GTAみたいなゲーム考えてみ?
あれ全てオブジェクトの寿命を事前に決められると思う?
原理的には不可能じゃないだろうがそんな職人的な作りしてたら開発に10年かかるわw
487 :
2016/04/18(月) 21:56:15.95 ID:IBBVu28x
普通のmallocで足りるならそれでもいいけど。
基本メモリ容量ギリギリまで使うから、最初に描画、ゲーム内部状態、音声、ディスクキャッシュなどでどのくらい使うか決めておく。
終始一貫して静的に決めるのが楽だけど、場合によっては場面ごとに配分を切り替えたりする。
で、例えば広いマップ上を自由に動き回るようなゲームだと、マップを複数のパーツに分割して、詳細モデルから簡易モデルまで用意する。
488 :
2016/04/18(月) 22:12:01.61 ID:3yZKjOEp
ゲームプログラムとかならメモリ確保は直接システムコール呼び出して
ページ単位でアロケートするのが定石
必要ならmspaceとかインスタンスベースのヒープを自分で作る
489 :
2016/04/19(火) 01:49:46.30 ID:KVIhh3Hm
使用できるメモリのサイズも空きメモリのサイズも最初から分かってて、ユーザーからの入力も限られてて、
そいつら全部自分で管理できる「恵まれた」環境でしか通用しないアプローチだよなそれ。
490 :
デフォルトの名無しさん
2016/04/19(火) 01:58:46.65 ID:fq3yh1do
レーシングゲームは出てくる車が決まっていてコースも決まっているから。
491 :
2016/04/19(火) 08:28:57.71 ID:YcewE61x
昨今はレースゲームでも汎用的なゲームエンジン使うことが多いから
その場合事前に寿命が決まってる前提の作りにはしていないと思うぞ
GDCとかGame Gemとかでも昔からフラグメンテーション対策を含む
メモリ管理の手法はいろいろ議論されているから調べてみるとよろし
492 :
2016/04/20(水) 12:56:58.01 ID:r07pzD8i
>>489
ハードリアルタイムなシステムならごく普通
って言うかそうでないと作れない
493 :
2016/04/20(水) 13:09:41.53 ID:DLw9rf+F
>>486
ああいうFPSのオブジェクトは全部管理されてるし
gcなんか使ってないよ
494 :
2016/04/20(水) 19:22:46.02 ID:bj66dBvK
>>493
フラグメンテーションの話だっての
495 :
2016/04/20(水) 19:58:58.01 ID:CuR1I1mj
やり手のゲーム系の方たちに、逆らうようなことは・・・・
496 :
2016/04/21(木) 01:20:25.83 ID:jf1w54Av
>>494
そんなのどうにでもなるでしょ
汎用のmallocなんかとは事情が違う
497 :
2016/04/21(木) 02:16:29.96 ID:G+xv7xqn
>>496
どうとでもなるって?
へーじゃあ試させてもらうわ
GDC 2016でもこういう講演があった
http://schedule.gdconf.com/session/building-a-low-fragmentation-memory-system-for-64-bit-games
64bitならなぜフラグメンテーションが軽減できるか説明してもらおうか?
物理メモリが多いからじゃないからな
あればあるだけメモリ使うのがゲームなのでメモリに余裕があるわけじゃない
498 :
2016/04/21(木) 11:32:02.27 ID:EjzxVVPK
ゲーム機含む組み込み系は結果が不確定な動的メモリー確保なんかしないのが鉄板(しようとする奴は未熟な馬鹿)だったが
PCと合わせて組み込み機器もスペックが潤沢になって富豪的プログラムが一般的になってきたからね

無知ゆえ聞きたいんだが
最近のゲームソフトやら>>497やらってどういうGC使ってるの?
499 :
2016/04/21(木) 13:09:31.92 ID:pog3nPgL
ゲームだって組込みだって今どき動的メモリー確保しないなんて化石みたいな発想が通るわけないだろ
かといって普通のGCは問題外
賢いメモリアロケーションをするしかないんだよ
>>497は「こんなすごい講演するぞ」って言う宣伝だけだけど中身はどこにあるの?
500 :
2016/04/21(木) 16:14:15.43 ID:lEi5GQja
>>497
MMUが付いているから

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

問題は論理アドレスの方
32bit空間だと例え物理メモリが余っていても
論理アドレスがフラグメンテーションを起こして連続したメモリを確保できなくなる
物理アドレスが枯渇するよりもさきに、そちらの方が問題になることが多い
64bitだと、これが防げる
501 :
2016/04/21(木) 16:37:13.61 ID:lEi5GQja
各ゲーム機の事情は知らないが
PCで有れば、64bitプロセスは、論理アドレスの空間が256TB(48bit)もある
ゲーム機も似たようなものだろう
256TBもの物理メモリを積んだPCやゲーム機は存在していないし
例え論理アドレスが激しくラグメンテーションを起こしても
256TBもの論理アドレス空間を使い切るという事態は考えなくてよい
つまり、64bitプロセスなら、論理アドレスの心配はしなくてよい

一方で、物理アドレスのフラグメンテーションはMMUに任せておけばよい
これはハードウェアで自動で行われるし、とても高速
その余計にソフトウェア的アプローチで頑張ってみたところで
多少物理メモリのフラグメンテーションは改善されるかもしれないが
徒労というかなんというか、労力に見合わないし
しかも遅くなるのでゲームには向いていないし、やらなくてよい
物理アドレスは自分だけが使っているわけではなく、OSを含めたほかのプロセスも使っているので
自分のプロセスが使っている物理メモリだけフラグメンテーションを解消しようと
コンパクションするのも何か完璧感が無いし
自分のプロセス内だけで考えても、外部ライブラリやXBoxならDirectXが使用している物理メモリの
フラグメンテーションは手が出せないので解消しようがない、やはりやるだけ徒労
自分の管理出来る部分だけ物理メモリのコンパクションをかけても
「これで計算上、必ずあと200MBの物理メモリを使用できる筈」とかといった保証はどこにもない
理由は、外部のライブラリ内での物理メモリの使用状況が分からないし、手が出せないから
とにかく徒労であり、MMUに任せておけばよい
502 :
2016/04/21(木) 17:22:28.74 ID:7dcTEyv0
ただの物理メモリ不足の話がなんでと思ってしまった
swapはじまったら、fpsなゲームはどうなるんでしょうね
503 :
2016/04/21(木) 19:18:25.46 ID:zEEe/DNn
論理アドレスが64bitだったらフラグメンテーション対策なんていらんということ?いや自分もそうは思うんだが。
上の方で「専用ゲーム機開発ならフラグメンテーション対策も行うのが常識!」みたいに主張してる人がいて、
それって自作のmalloc相当のアロケータ作るってことだよね?と思ったんだが、
メモリ節約術とごっちゃにしてる人もいてわけが分からなくなってきた。
504 :
2016/04/21(木) 22:14:27.41 ID:WHT47icf
なんで馬鹿に限って長文書きたがるんだろうか
505 :
2016/04/22(金) 08:58:47.78 ID:imh5rD9T
>>500
すばらしい、正解
まぁ>>488で答え言ってたわけだけど
某ゲーム機ならコンパクションも実装できるよ

>>503
ページ単位という制限がつくし、速いって言ってもシステムコールなので
ユーザランドで完結するヒープライブラリに比べると遅い
フラグメンテーション対策がいらなくなるわけじゃないよ
506 :
2016/04/22(金) 11:30:03.69 ID:+Z1ZyILi
わかってなさそうな方がそれっぽいこと・・・・
507 :
2016/04/22(金) 12:23:02.13 ID:UzNl+aCx
わかってる方は完結に書いてみればいい
508 :
2016/04/22(金) 15:49:44.48 ID:+Z1ZyILi
学校の先生にそう教わったんですね
509 :
2016/04/22(金) 19:23:46.16 ID:cAq2nbH2
用途ごとにセグメント分けて使い回すのが無難じゃないの
オブジェクトの数が足りなくなったら透明でいいのよ
510 :
2016/04/22(金) 20:32:21.23 ID:1FeuO5Gj
結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない

しかし論理アドレスの方は何にもしてくれないのでフラグメンテーション起こして
連続したアドレスが確保出来なくなると、それで終わり、どうしようもない
32bitプロセスだと4GBしか空間がないから、まれに問題になる
64bitプロセスだと無尽蔵に空間があるから問題になることは現状ありえない
511 :
2016/04/22(金) 23:54:45.31 ID:imh5rD9T
>>510
> 結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない

MMUってのはアドレス変換するハードウェア
勝手に物理メモリを仮想メモリにマップしたりはしない
それをやるのはOS
512 :
2016/04/23(土) 00:19:34.35 ID:43LRl8T1
そもそも、ページサイズより粒度が細かいフラグメンテーションにはMMUはなんの効果もないしな。
513 :
デフォルトの名無しさん
2016/04/23(土) 05:06:22.41 ID:TwuNXQH0
autorelease()呼んだらコアダンプ糞osがwww
514 :
2016/04/23(土) 18:49:46.90 ID:RPK9BpXO
小さな粒度のフラグメンテーションは気にする必要ない
4KBならUTF-16で2000文字ぐらいしかない
32bitビットマップなら32x32ほとのサイズ
515 :
2016/04/23(土) 20:33:25.39 ID:PodTlhvX
キャッシュヒット率が落ちそう(コナミ)
516 :
2016/04/24(日) 01:18:30.93 ID:9YSuZOIq
>>512
お前のプログラムはメモリを1ページしか使わんのかw?
フラグメンテーションで使用率が低いスカスカのページだらけになるのが問題なんだろうが。
517 :
2016/04/24(日) 01:38:34.87 ID:ai61/62A
>>516
へーお前はヒープを使わないのか
漢だな
518 :
デフォルトの名無しさん
2016/04/24(日) 08:38:51.73 ID:65va2BTL
メモリー512バイトでどうやってヒープを使えと。
519 :
2016/04/24(日) 09:31:32.99 ID:HSA/nLEW
ネイティブコードが必要な場面で中途半端に GC に頼るのが問題なのかもしれないが、もうネイティブコードが必要な戦場は限られた一部だけになってて、主戦場では GC は大前提の技術なんだから必要ないとか言われましてもですわ。
520 :
2016/04/24(日) 10:14:15.47 ID:W23a3TIA
ページがスカスカになっても大丈夫
1ページ4KBとかだからね、十分小さい
32x32-32bitビットマップより小さい

最近のゲームで使われるような大きなサイズのテクスチャなど
でかいサイズを確保する場合はどうせ新しいページが割り当てられるし
小さなサイズを確保する場合は、スカスカになったページから空いているところを探して割り当てられるので
問題ない
521 :
2016/04/24(日) 10:14:59.78 ID:TFb7efu7
androidしか知りませんみたいな事言われてもな
522 :
2016/04/24(日) 10:27:10.54 ID:W23a3TIA
物理アドレスはページサイズで切り売りされるので
元から連続しているアドレスは必要ではなく
フラグメンテーションは問題にならない

連続したアドレスが必要になるのは論理アドレスのほうであり
32bitプロセスでは4GBしか空間がないから問題になることがある
64bitプロセスであれば現状問題にならない
523 :
デフォルトの名無しさん
2016/04/24(日) 10:37:41.02 ID:65va2BTL
実はQtでデーモン作って動かしてるのだが、もう半年以上動き続けてる。
まさかこんなに問題が起きないとは。
案ずるより産むがやすしですぞ皆の衆。
524 :
デフォルトの名無しさん
2016/04/24(日) 10:58:37.83 ID:65va2BTL
Qtで作ったのは一日ででっち上げる為だったのだが、意外なことに堅牢に動き続けてる。
525 :
2016/04/24(日) 12:08:49.17 ID:HSA/nLEW
Qt でデーモン?
GUI が必要なデーモン?
526 :
デフォルトの名無しさん
2016/04/24(日) 12:13:06.27 ID:ynYywbEh
>>525
デーモンは通常フォアグラウンドじゃないのでUIを持ちませんぜ旦那。
527 :
2016/04/24(日) 12:25:33.24 ID:HSA/nLEW
ならば何に何故どのように Qt を使うのだ?
528 :
2016/04/24(日) 12:45:58.38 ID:TFb7efu7
>>526
だからQtでデーモン?(クエスチョン)…なんじゃね?
加えてQtってGC関係あるのか?
たしかC++のライブラリーだよね?
529 :
デフォルトの名無しさん
2016/04/24(日) 13:02:46.55 ID:ynYywbEh
等と意味不明な供述をしており。
530 :
2016/04/24(日) 14:52:01.10 ID:fu8W/E1c
>>525
Qt 使ってるからと言って QtGui 使ってるとは限らんけどね

>>528
Qt 本体は C++ で書かれてるけ
ど Java, Ruby, Python, Perl, C# 等からも利用できるよ
531 :
2016/04/24(日) 14:52:56.88 ID:UKiBgwvV
daemonじゃなくてdemonなんじゃない?
デスクトップマスコット的な
532 :
デフォルトの名無しさん
2016/04/24(日) 14:59:36.53 ID:ynYywbEh
俺が作ったのはウェブソケットによってサービスを提供するプログラムだ。
エンジンエックスをリバースプロキシとした。
このプログラムは常時数千の接続から大量のリクエストを受け付ける。
接続してくるクライアントは専用に作られQtで書かれている。
大量のリクエストはそれぞれ複数のデータベース検索を引き起こす。

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

Qtは出自からしてGUIのためのライブラリではあるのだが、GUIが無いと使えないというわけでもない。
むしろボリュームからすれば、GUI以外の方がより大きい。
そして、半年動きっぱなしで大丈夫ことからして、実は断片化は気にしなくても
良さそうだ。
533 :
デフォルトの名無しさん
2016/04/24(日) 15:05:02.69 ID:ynYywbEh
ちなみにQt使ってなかったら一日でサービスを書き上げることは不可能だっただろう。
Qtは、その他のGUIライブラリ同様バグが多いのだが、GUIを抜いてみるとどうだろう、
意外なほどに堅牢なのだ。
何しろもう半年動きっぱなし。

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

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

ちなみにWindowsで書いてLinuxで動かしてます。
534 :
2016/04/24(日) 15:05:44.58 ID:ai61/62A
一例をもって一般化はできないだろ
535 :
2016/04/24(日) 15:05:53.54 ID:TFb7efu7
>>530
色々な言語から使えるのか
そういう場合Qtが使うメモリーなんかはどういう扱いなんだろうね
GC適用外な気がするけど知らないからこれでやめとくわ
536 :
デフォルトの名無しさん
2016/04/24(日) 15:08:01.90 ID:ynYywbEh
Windowsで書いてLinuxで動かすことに、systemdは大いに貢献した。
従来のデーモンの作り方では、いろいろ煩雑なことがありすぎ、時間の制限から難しかっただろう。

Qt+systemd、この直観的な選択は大成功であった。
537 :
デフォルトの名無しさん
2016/04/24(日) 15:11:43.89 ID:ynYywbEh
Qtのバグの多くは、複数の環境に対応するため、その差異によって引き起こされているという結論を得た。

systemd万歳!
538 :
デフォルトの名無しさん
2016/04/24(日) 15:16:24.95 ID:ynYywbEh
更にもう一つヒントがある。

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

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

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

若者よ、案ずるより産むが易しですぞ。
539 :
デフォルトの名無しさん
2016/04/24(日) 15:28:56.74 ID:u6qUQj/U
ねえ訳分かんないんだけど
本人以外で理解してる人要るの?
540 :
2016/04/24(日) 15:55:24.75 ID:fu8W/E1c
むやみに連投してる奴はたいていスルーでok
541 :
デフォルトの名無しさん
2016/04/24(日) 20:02:15.39 ID:ynYywbEh
むしろ、わからないのに何故、一生懸命主張していたのかと。
542 :
2016/04/24(日) 20:22:44.80 ID:fcfJojCV
誰と戦っているんだろう…
543 :
2016/04/24(日) 22:39:17.85 ID:WrdDgWl7
マークスイープでメモリリークってどうやって起きるんだ?

初心者だから優しく説明してほしい
544 :
デフォルトの名無しさん
2016/04/25(月) 01:16:56.77 ID:/Pmm49fe
狭義の意味では起きない
もし君が気付かない間にオブジェクトへの参照を保持していたらどんなGCだろうが解放されない
それをリークというならリークする
545 :
2016/04/25(月) 13:44:57.25 ID:HSarKqaj
言い換えればダングリングポインタが発生しない
それだけ
546 :
2016/04/25(月) 14:51:13.10 ID:0xpbBk2N
マーク&スイープでもポインタの型情報を記録してないとリークしまくる

無関係な数値をアドレス参照と勘違いしてマーク→未開放
某言語ではこのために巨大なメモリブロックが開放されない
547 :
2016/04/25(月) 20:35:07.72 ID:4DDlKiNG
>>543
どこからマークを始めるかが問題
548 :
2016/04/29(金) 18:58:56.34 ID:I1ppYkAy
>>10
C#はGCの掃除処理を任意で呼び出せるだけだろ

C++/CLIなら自分でdelete呼べば即座に消え去るが
もちろんC++と同じくデストラクタも確実に起動する。
549 :
2016/04/29(金) 22:46:31.85 ID:wZxrhoKH
C++/CLIはデストラクタが呼ばれるだけで、managedメモリの解放がGC任せなのは変わらんよ。
550 :
デフォルトの名無しさん
2016/05/01(日) 07:57:30.30 ID:tKi6j9CT
匿名通信(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 :
2016/05/01(日) 09:11:45.10 ID:qHyjCjkk
無視リストに追加と
552 :
デフォルトの名無しさん
2016/05/02(月) 21:54:41.51 ID:KYdaomRZ
GCCは失敗、Clangを使え。
553 :
2016/05/02(月) 22:21:36.97 ID:btgv3pKW
うるせーバーカ
554 :
デフォルトの名無しさん
2016/05/04(水) 17:42:43.75 ID:M8+arjAJ
gccは失敗。
555 :
デフォルトの名無しさん
2016/05/27(金) 12:06:01.84 ID:FwT+WNvC
良スレ発見した。Windowsは32bitで十分だな。32bitでもPAEで4GB超の
メモリ認識するし、仮想メモリは4GBのままだが、AWEを使うことにより
バンク切り替え的にメモリウインドウを切り替えられる
556 :
2016/05/27(金) 19:30:30.19 ID:hSijlNU2
>>555
アプリはよくてもカーネルはつらい
557 :
デフォルトの名無しさん
2016/05/28(土) 04:39:26.17 ID:rTGB9SNh
メモリーは俺が確保してやる、任せろ。
558 :
2016/05/29(日) 07:51:44.19 ID:Ai+IvVh7
おう、この手は絶対、絶対に、死んでも離さねぇ!!
559 :
2016/05/29(日) 11:50:15.87 ID:9WWbP5OA
OSに載った気持ちでいなさい
560 :
2016/05/31(火) 22:56:21.68 ID:mtPUDASJ
>>1みたいなやつは
研究室にヒキって、社会に出たことないんやろ

おまえ、本気の糞コードで書かれたペチプ〜とか見たらチビるで
あんなんに加えてメモリ管理なんてやらせたら
それこそHELLO END OF THE WORLD
この世の終わりですわ
561 :
2016/06/07(火) 12:20:18.65 ID:4vppD7oq
>>558
死んだら離せw
562 :
2016/06/12(日) 09:40:01.67 ID:mfUrI2Z0
死後硬直ですね
563 :
デフォルトの名無しさん
2016/06/18(土) 23:15:40.44 ID:03AgrRUX
指摘してるレスがなかったので言っとくが
循環参照は参照カウント方式+Cycle Collectorでも回収できるから
GCは必須じゃないぞ
興味があるならBacon Cycle Collectorで調べてみろ
564 :
デフォルトの名無しさん
2016/06/18(土) 23:22:46.70 ID:/B2fY0/K
学生の頃は循環参照できないことに困ってたけど、今となっては何時
循環参照が必要になるかさえ思い出せんな。
565 :
2016/06/19(日) 21:38:00.28 ID:evh9vaek
双方向リスト構造
566 :
2016/06/19(日) 22:17:16.01 ID:ao4WLgfX
>>563
>Cycle Collector
いわゆるmark&sweep式とどう違うの?
567 :
デフォルトの名無しさん
2016/06/20(月) 01:16:50.71 ID:30YoNw6z
(コンパクションしてくれるんだろうか)
568 :
2016/06/22(水) 08:52:46.04 ID:I9Ep4uZo
vmが諸悪の根源な気がしてきた
569 :
2016/07/06(水) 07:12:12.60 ID:aYInvTWe
>>568
まずガベージだらけの頭の中を整理すべき
570 :
2016/07/16(土) 10:10:08.78 ID:+8wH/95N
>>565
別に
単方向リストでもなるだろJK

ていうかリストの要素をshared_ptrにするのは現代でも有効
リストのリンクヘッダ自体の寿命は要素が明示的にdeleteされるかリスト全体が廃棄されるまでなので
リンクヘッダも管理したければリスト固有のストレージ丸ごとな単位でshared_ptrにしたら良い、
希ガス
571 :
2016/07/16(土) 10:13:41.67 ID:+8wH/95N
△: リストの要素
○: リストの要素が保持するデータ

つか開放タイミングをshared_ptrに任せておk、などという発想のは管理しているうちに含めれないがな…
572 :
2016/07/16(土) 10:38:52.53 ID:6AR6MH2z
一般のグラフじゃなくてリスト構造の話だろ?
双方向リストはheadとtailへの参照があるが、単方向リストで循環参照は生じようがないが。
573 :
2016/07/16(土) 11:51:50.13 ID:+8wH/95N
>>572
すまんの>>570の単方向リストは正確には循環リストもしくは環状リストと呼んだ方が良いかも試練、

だが、循環リストもしくは環状リストも単方向リストの実装方式の一つではある(初期の『プログラミング言語C++』か何かのslist等
のじゃ…!
574 :
2016/08/22(月) 17:06:41.08 ID:oW9zLe2W
循環してるかは後付けでオブジェクトをマークすれば判るんだし
扱うデータ構造から可能性の有無は予測できるし循環自体は大した問題じゃないよ
あ、これリークするなと思ったら対策すればいいだけ
問題は他人様のブラックボックスなライブラリを使う場合
575 :
2016/08/22(月) 19:24:37.36 ID:csr3LedD

今の議論はプログラマーが何も考えないアホでもGC(言語)使ってれば問題無いのか
そうでなければ結局なんらかの管理が必要でちゃんとする事しないとリークするから本質的には管理から開放されないよねって話だと思うが
576 :
2016/08/22(月) 19:33:58.37 ID:01M+MFvA
いまどきの子はブラウザアプリしか作れないから
ブラウザ再起動とかページ遷移で解決でしょうな
577 :
2016/08/23(火) 19:56:22.47 ID:cEt4cHHx
現在のGCが不完全なだけであって、
メモリは人が管理すべきでないという考え自体は正しいよ。
578 :
デフォルトの名無しさん
2016/08/23(火) 20:17:10.56 ID:xIKUFX4H
潤沢なメモリを用意してGCしない戦略
起動時間に限ってGCしなくても問題ない範囲であればGCしない戦略
結局こういうのが勝つ
579 :
2016/08/23(火) 20:29:14.30 ID:uPhg+qti
プロセスを細かく分けて寿命を短くすればそんなの考えなくて済む
580 :
2016/08/24(水) 13:32:09.69 ID:2RMcAgaj
本当の意味での軽量プロセスをOSがサポートしてくれたら良いんだけどね
メモリプールみたいなもんなんだけど、OSのリソースも紐づいてて
メモリプール解放時にOSのリソースもちゃんと解放されるようなもの
マルチプロセスは非常に強力で良いんだけど
メモリ空間が別になるから色々面倒だしパフォーマンスも出にくい

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

だから別プロセスで実行して、キャンセルされたときはプロセスごと殺すしか方法が無い
しかし別プロセスにするとメモリ空間が繋がってないので面倒
だからその中間がほしい
581 :
デフォルトの名無しさん
2016/08/24(水) 16:03:33.76 ID:Ku8YOB4B
erlang最強
582 :
デフォルトの名無しさん
2016/08/24(水) 19:53:51.27 ID:B7v3wZLf
軽量プロセスより重量スレッドの方が実現できそう。
583 :
2016/08/24(水) 20:02:24.36 ID:971rg3P3
いつ無くなってしまうかわからんようなメモリのアクセスが簡単になってもほとんど使いみちないだろ。
安全性重視なら別プロセスにして、必要なデータだけ共有メモリで受け渡してのが妥当なところだろう。
584 :
2016/08/24(水) 20:18:52.71 ID:2RMcAgaj
結論から言うと、Windowsにforkが無いのが面倒すぎるってことなんだけどね
585 :
2016/08/24(水) 20:32:21.12 ID:N/sC1Ga3
>>580
> 処理を中断する手段が関数側に用意されてなかったりする
具体的には?
586 :
2016/08/24(水) 22:11:21.77 ID:2RMcAgaj
いやそんなもん、中断する手立てが用意されている方が珍しいだろ
587 :
2016/08/24(水) 22:31:11.60 ID:N/sC1Ga3
>>586
で、具体的には出せないと言うことね
588 :
2016/08/25(木) 11:39:37.19 ID:rs2QvvZe
元々はスレッドが軽量プロセスって呼ばれていたりしたんだがな(アドレス空間の切り替えが不要だからプロセスより切り替えが軽い)

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

まあどちらにしろGCじゃメモリーをはじめとする資源管理からは完全には解放されないって事だ
589 :
2016/08/25(木) 11:59:23.81 ID:8gaIkILP
メモリ空間がつながっていること自体はそれほど考慮してないんよ
単にWindowsはマルチプロセスがしにくい
forkあったらちょっとした処理を別プロセスで実行するの、便利じゃん
片づけはプロセスごと殺して終わりだし
590 :
2016/08/25(木) 15:41:54.51 ID:8f3yfXIl
ほしいのはLinuxでいうclone(2)やね
591 :
デフォルトの名無しさん
2016/09/03(土) 00:41:24.79 ID:XSHFkVCg
https://cedil.cesa.or.jp/cedil_sessions/view/1484
リアルタイムGCの実装が凄い
592 :
2016/10/22(土) 08:52:04.68 ID:v44cYKg6
GCもハードウェアに支援させれば全部解決するよ
リアルタイム処理含めてね
593 :
2016/10/22(土) 10:51:46.42 ID:O48rD9qT
再起動最強説
594 :
デフォルトの名無しさん
2016/11/14(月) 22:33:26.01 ID:A2iFoZHP
固定領域として静的にグローバル変数化、バッファ化すればいいだろ、
それを汚い言うやつがいるが、

潜在BUGだらけでどうにもできないそれのほうが汚いわ。
595 :
2016/11/14(月) 23:45:18.91 ID:JD+cxKWX
例えばChromeとかFirefoxとかが静的にメモリアロケートしてたらどうなるか
596 :
2016/11/14(月) 23:59:22.37 ID:f4osfHdm
そういう発想、嫌いじゃないよ
静的にできるものは、なるべく静的にすべし
俺もそう思う
妙なからくりじみたことにはもう興味が湧かなくなった
最初のころはGCのメカニズムが面白いと感じていたが、もうそういうの、無い

いかに静的にシンプルに書くか、こっちのがパズルみたいで面白い
すべての事は明確であるべきで、コードはそのようになっているべきだ、と
俺が特に嫌いなのは、何がどの順番に実行されるか、コードを見ただけで
よくわからない類のプログラムだ
コールバックも基本的に嫌いだ
なのでいつ実行されるか分からないマークスイープGCは好きではない
参照カウンタ方式のほうが根本的に安全であり、シンプルであると思う
というのも参照カウンタ方式のGCはバグの再現性があるから
唯一の問題は循環参照だが、これも弱い参照を使えば解決する
たったそれだけの工夫でマークスイープGCの複雑な仕組みがいらなくなるなら
おれはそちらのほうが良いと考える
開放するというただそれだけのことに、あれだけ巨大な仕組みが必要になるのはおかしい
597 :
2016/11/15(火) 00:00:47.13 ID:PldPJ2O3
マークスイープ系GCはメモリ管理に関しては完璧かもしれないが
それ以外のリソースの面倒は一切見てくれない
そういったものはファイナライザで開放すればよいわけだが
要らなくなったらすぐさま開放してほしい時に困るので、例えばC#ではDisposeを用意している
しかしながら根本的に本当にDisposeを呼んで良いのかは誰にもわからない部分がある
もしかしたら他の誰かが使用中かもしれない、という場面もありうる
だから誰も使ってないことをプログラマが保証する格好になる
その意味ではfree()と大差ないわけで
usingという構文が用意されていて、ある程度自動で呼ばれるというだけである
本当に誰も使ってないことを保証するにはマークスイープを走らせなければわからない
しかしマークスイープはコストがかかるので、そんな都度都度気軽に走らせられない
その点、参照カウンタ方式は参照カウンタを見るだけで使われているかどうかわかるので
都度都度チェックできるし、要らなくなったらその場で即開放できるので
Disposeのような仕組みもいらず、解放処理をデストラクタに一本化できるし
スマポを使えばデストラクタ自体、書く必要すらないかもしれない
そして有り難いことに、デストラクタはメンバ変数やベースクラスに対しても
芋づる式に自動で呼ばれる
これはDisposeには無い機能だ
何故無いのか?答えは、勝手にDisposeして良いのかどうか、コンパイラは判断がつかないからだ
誰か他の人が使っているかもしれないわけで、勝手にDispose出来ない
Disposeして良いかどうかはプログラマが保証しなければならないので自動化できないのだ
598 :
2016/11/15(火) 00:02:48.22 ID:PldPJ2O3
本当にC#で解放処理をまともに書こうと思うと
自身のクラスのメンバ変数にIDisposableを実装しているものがあるかどうかを調べ
もし、実装しているものがあれば、自身もIDisposableにし
Disposeメソッドを作り、その中で、先ほど調べたメンバのDisposeを呼び出さなければならない
これを手作業でやる
C#をやったことのある人なら知っている通り、マイクロソフトの示すIDisposableの実装例自体が
非常に煩雑であるわけだが、ともかく、もれがないように、手作業で頑張る
まず、IDisposableかどうか調べ忘れるだろうし、Disposeの呼び出し忘れもありうる
mallocしたらfreeしましょうと同レベルのことを強いられる
このように面倒なIDisposableであるが
IDisposableなオブジェクトをメンバに持つと、自身もIDisposableになるということは
IDisposableはどんどん伝染していくわけで、手動でDisposeしまくるコードを書き続ける羽目になる
このように、まじめに考えると、破たんした方法であることが分かる
根本の問題はDisposeが自動で呼ばれるコードをコンパイラが生成してくれないこであるが
確実にDisposeして良いかどうかを判断するためにはマークスイープを走らせる必要があるので
どうやっても自動化は困難であり、プログラマが開放してよいことを保証するという
ある種手作業なusingがせいぜいである
参照カウンタ方式であれば、ほぼノーコストで開放して良いかどうか分かるので
これらの問題は一切発生しない
解放処理はデストラクタ一本であるし、芋づる式に自動的に呼ばれるので
手動でコードを書かなければならないということもない
ランタイムもシンプルであり、バグった時も再現性が期待できる
599 :
2016/11/15(火) 00:24:03.03 ID:PldPJ2O3
これがC++が未だにかたくなにマークスイープ系GCを搭載しない理由である
C++を書くプログラマはweak_ptrを適切に使えるものだという前提のもとに
マークスイープ系GCにまつわる数々の問題点を排除したのだ
マークスイープ系GCで有利なのは唯一循環参照だけであり
そこさえ気を付けることができれば
それ以外の部分に関しては参照カウンタのほうが優れている
C++は別に時代遅れなわけじゃなく、そういう選択をしたというだけ
今になって考えるとその選択は正しかったと思う
600 :
2016/11/15(火) 04:04:15.16 ID:9A/eUvIY
メンバーにdisposeしなければならないような設計が良くない。そんなものはメソッド内のローカル変数に止めるべき。
それすらも理解できず(考え付かず)にただ一律なんにでも同じ考え方を押し込むのはただの愚行。
ありもしない、回避可能な杞憂をただ恐れるのは、勉強不足か進歩が止まっているだけ。
だから皮肉を込めて老害と呼ばれる
601 :
2016/11/15(火) 04:09:46.64 ID:9A/eUvIY
日本語おかしかった。
メンバーにdisposeしなければならないような物を持たせるのが良くない
でした。
602 :
2016/11/15(火) 05:19:19.06 ID:ulUg8AFG
>>594
参照カウンタよりも固定バッファを動的に確保ですね判ります
603 :
2016/11/15(火) 05:20:35.14 ID:ulUg8AFG
>>595
firefoxは解放が遅いのでそれやってるのと実質同じ
realplayerとかもそうだったな
604 :
2016/11/15(火) 08:18:37.29 ID:wcWx6QZb
>>600-601
よくないって言われてそうせざるを得ない場合はいくらでもあるしなぁ
例えば動的に出力先を切り替えられるログクラスみたいな奴をどう書けと言うんだろ?
605 :
デフォルトの名無しさん
2016/11/15(火) 09:05:11.25 ID:P8K+NdWV
>>597
スマポとデストラクタの必要性は関係ないだろ…
deleteの必要がない、とか、デストラクトを考えなくて良いってことだと思うけど。
606 :
2016/11/15(火) 10:48:15.69 ID:4QSE1fRA
スタック変数の 0 クリアすら嫌がる C/C++ が GC 搭載とか夢見すぎ
607 :
2016/11/15(火) 10:53:43.30 ID:PldPJ2O3
struct test
{
  std::shared_ptr<int> ptr;
  test(){ ptr = new int; }
};

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

ちなみにC#のDisposeはただのメソッドであるので
このような芋づる式にメンバ変数のDisposeを呼び出してくれる機能はないし
マークスイープなので原理上不可能である
他で使用中でないことをプログラマが保証しないとにはDisposeは呼べないので
自動化できない
608 :
2016/11/15(火) 11:05:47.46 ID:TNYjuRyh
>>606
ツボったw
効率至上が利点であり特徴だもんな
609 :
2016/11/15(火) 12:45:52.53 ID:LZ5unIkv
>>607
それptr.reset()使うんじゃないの?
610 :
2016/11/15(火) 13:34:38.18 ID:bbRnuBLg
グローバルが嫌われたのは
疑似マルチプロセスでメモリを共有していた時代の汚物だろ
今みたいなOSのメモリ管理ならアプリ単位グローバル常套
611 :
2016/11/15(火) 23:45:20.82 ID:nDIaGem/
C#/C++よりRustだろ
参照カウンタのオーバーヘッドすらない
Firefoxに期待
612 :
2016/11/16(水) 04:04:29.47 ID:EhKul/vA
>>604

http://ideone.com/9L3kQp

これじゃいかんのか?
おかしかったら教えて
613 :
2016/11/16(水) 12:42:03.97 ID:KQ3Yixih
>>612
Write する度に WriteTypeA とかを生成/破棄するってこと?
ログとかならその方が望ましいケースもあるかもしれないけど、例えば性能上の問題でストリームは開きっぱなしにしたいとかもあるでしょ
614 :
2016/11/16(水) 14:56:37.10 ID:a2T+Z3SD
>>613
開きっぱなしにしたいスコープは?
スコープを一つのメソッドにして、同じようにすればいいじゃない

コードが必要なら夜にでも書くよ
615 :
2016/11/16(水) 19:17:42.21 ID:KQ3Yixih
>>614
スコープを動的に変えたい場合を想定してるんだが
実行中にログファイルを変更できるアプリケーションとか見たことないの?
616 :
2016/11/16(水) 23:34:22.54 ID:EhKul/vA
>>615
ログファイルであれば日付で切り替えとかあるね。

そしたらストリーム開きっぱで日付が切り替わったら、閉じて新しいの開き直すとかあるわ。

いつもlog4とか使って主処理と切り離してたから考慮から抜けてたわ。

俺の意見はdb接続とかで一部にしか当てはまらんので、
「基本的には」とか
「リソースを管理する必要があるもの」とか前提がつくね。すまん。
617 :
2016/11/19(土) 06:41:14.49 ID:4ie0coBz
ログファイルはログが確実に記録されるのが使命であって性能は二の次なのだよ
よって開きっぱなしは論外
性能で問題が出るなら吐く量を調節すればいいだろう
618 :
2016/11/19(土) 08:38:51.71 ID:eBLDMII7
開きっぱはなんでダメなん?
619 :
2016/11/19(土) 08:52:00.55 ID:YtkNE2sc
flushすればいいな
620 :
2016/11/19(土) 10:16:22.36 ID:HaGDkE41
>>618
アプリケーションエラーとか異常終了した時にバッファされてる内容が書かれないことがあるから
異常終了した時はまさにそのエラーになる直前のログが欲しいのに〜
ってなる w

ただログってそういうログばかりじゃないし Apache のアクセスログみたいにいちいち閉じてたら全然間に合わないって現実を知らない >>617 はもう少し経験積むまで黙ってた方がいいと思う
621 :
2016/11/19(土) 14:20:53.96 ID:YtkNE2sc
>>620
それは開きっぱなしが問題なんじゃなくてflushしてないことが問題なだけで見当違い
622 :
2016/11/19(土) 14:29:51.71 ID:HaGDkE41
>>621
>>604 から読み直せよ
見当違いはお前の方だよ...
623 :
2016/11/19(土) 14:34:26.96 ID:WWFUnGVk
とこのように、相手を互いに見当違いであると罵り合うのであった
しかし、それは正しい
両者とも正しい
624 :
2016/11/19(土) 15:37:17.31 ID:O7mQP4/b
スコープの話してるのに flush とか頭わいてるだろ
625 :
2016/11/19(土) 21:51:13.35 ID:WZ8TOo4I
null安全をアピールしてる人間はObjCerから見ると補助輪付き自転車を渡してきてこれ安全だから絶対に乗れよと言ってくる頭おかしいおじさんにしか見えない
Swift移行がこじれるだけだから黙っといて欲しい
626 :
デフォルトの名無しさん
2016/11/21(月) 14:59:21.88 ID:qSFgYSXv
浜矩子・著
『アホノミクス完全崩壊に備えよ』
『どアホノミクスへ最後の通告』
『みんなで行こうアホノミクスの向こう側』


抑制のない成長に基づく経済政策は終焉

日本国民はどう対処すればいいのか。
新しい政権は民意を反映し、
食糧、住宅、健康、教育、最後に防衛です。
国民の意志を裏切ることは、
極端な場合、自殺や殺人にまでつながります。
民衆の指導者は
職業的政治家ではない人々から見つかるのです。

世界平和の脅威は、
イスラエル、イラン、アメリカです。
イスラエルの役割は跪いて、
パレスチナに許しを請うことです。
アメリカによる他国の虐待に
反対の声を上げなければなりません。
彼らは今世紀(21世紀)を
この帝国が出来上がるアメリカの世紀と呼ぶ。
しかし、そうはならないでしょう。
彼らが世界中に‘民主的’制度を確立したい
という衝動(世界を支配する)をコントロール
するのは、マイト レーヤの任務です。

非常に間もなく
マイト レーヤをテレビで見るでしょう。
彼は「匿名」で働いております。
627 :
2016/12/08(木) 09:10:56.35 ID:FEYStmIt
小規模ならGCのメリットは大きいのかもしれないが、大規模または大量にメモリを食うプログラムにはGCは向いてないのではないか。

あんまり例を知らないが、JAVAで動くマインクラフトのデバッグ画面でメモリ使用量みたら、めまぐるしく増加して一気に減ってるのみてびっくりした。
628 :
デフォルトの名無しさん
2016/12/13(火) 13:02:48.84 ID:XUF2n21y
GC周りに付いて書かれたネットの記事読んできたけど
オブジェクトが生成されては次々と死んでいき
生きてるオブジェクトより死んだオブジェクトが多い場合の方が速くなるっぽい

>>627
そう考えると長命のオブジェクトが大量にある方が(性能的には)問題だが
マインクラフトがそれかは知らない
629 :
2016/12/15(木) 23:33:53.51 ID:Z/98FfuD
>>606
C++はGC支援のメモリモデルが標準に入った
と言ってもコンサバGCライブラリ向けだけどな
630 :
デフォルトの名無しさん
2017/01/18(水) 11:38:56.79 ID:A+XqqRn6
漏れたときの調査が大変
安心してると痛い目にあう
631 :
デフォルトの名無しさん
2017/01/20(金) 16:23:16.03 ID:4Q3o1w03
参照カウントは循環参照の問題が起こるだけじゃなくて
意外と遅いって聞くけどマジで?

・メモリをOSから直接確保・解放するのは意外と遅い
・マルチスレッドで参照カウントを使うにはアトミックな操作が必要
・カウントを自動化すると不必要な参照カウントが起こる
とかで

対してトレーシングGCの弱点は回収時に止まる時間が長いところか

その対策か、V8やOracle JavaにはGCの時間を制限する機能があるみたいだが
それってどうなんだ?
632 :
2017/01/20(金) 23:17:39.79 ID:2XlTkpSB
まじ
633 :
デフォルトの名無しさん
2017/01/22(日) 15:00:56.26 ID:lyHWqZIh
^ナマポ
634 :
デフォルトの名無しさん
2017/01/22(日) 18:20:35.13 ID:CvVvUjG5
ストップ・ザ・ワールドの問題さえなくなればGCが最強ってこと?
635 :
2017/01/22(日) 18:44:59.67 ID:2ikRDhsq
>>634
フルGCの危険があるという点で最強になりえない
636 :
2017/02/20(月) 19:16:44.90 ID:NKdiRgAe
バイオハザード7は28万行のC#コードでできててビルド10秒らしい。
独自VM、独自GCだとか。
637 :
2017/03/20(月) 22:46:15.84 ID:USOySpAW
>>636
ゲームで28万ステップって長すぎね?
250KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: