"朝日●●(●●市●●経営)"を名乗る人物へ:未成年を売春させることが犯罪です。
◎正当な理由による書き込みの削除について:1レス¥5000円 1スレ¥20000円の技術作業料が発生します。一回分だけの料金で当方管理下の全サイトで作業が実施されます。支払い方法はAmazonギフト券番号。連絡先は当サイトの登録emailへ。

GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚


動画、画像抽出 || この掲示板へ 類似スレ 掲示板一覧 人気スレ 動画人気順

このスレへの固定リンク: http://2chb.net/r/tech/1447856699/
ヒント:2chスレのurlに http://xxxx.2chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

1 :
デフォルトの名無しさん 転載ダメ©2ch.net
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を使う

メモリー不足でのメッセージは良心的
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
問題点として、場合によってはメモリー不足で
メッセージされずに展開されなくなる
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 :
uy ◆Qawu9.2l1E
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 :
◆QZaw55cn4c
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 :
uy ◆Qawu9.2l1E
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 :
Office & Gamers @ 試験運用中(トリなしw
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 :
◆QZaw55cn4c
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信者で)すまんな。
http://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
残念だがスリープだ!  
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚 GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
338 :
デフォルトの名無しさん
2015/12/21(月) 06:40:32.08 ID:ejqZ3DMD
339 :
デフォルトの名無しさん
2015/12/21(月) 06:42:41.39 ID:ejqZ3DMD
LG OLED TV : You Dream We Display
http://aurorawave.atspace.tv/?sop:v/VenG8TF90yA!RDVenG8TF90yA GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚 #AuroraWaveTV
340 :
デフォルトの名無しさん
2015/12/21(月) 06:43:24.61 ID:ejqZ3DMD
LG OLED TV - The Ultimate Display
http://aurorawave.atspace.tv/?sop:v/JubFjalfNIY!RDJubFjalfNIY GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚 #AuroraWaveTV
341 :
デフォルトの名無しさん
2015/12/21(月) 07:08:24.86 ID:ejqZ3DMD
LG 4K OLED: Paris and Chicago
http://aurorawave.atspace.tv/?sop:v/Hi_WWhih4n4!RDHi_WWhih4n4 GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚 #AuroraWaveTV
342 :
デフォルトの名無しさん
2015/12/21(月) 09:26:05.64 ID:ejqZ3DMD
国別ISO登録件数 ⇒ 技術マフィア ⇒ 技術流出状況   
http://www.jicqa.co.jp/09info/07newsletter/2012/no168_news1201.html
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
http://www.google.co.jp/search?q=ISO%E6%9C%AC%E9%83%A8&;num=100&ie=utf-8
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
343 :
デフォルトの名無しさん
2015/12/21(月) 09:41:02.29 ID:ejqZ3DMD
中国、ダークマターの検出に挑む探査衛星「悟空」を打ち上げ
http://news.mynavi.jp/news/2015/12/17/495/
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
344 :
デフォルトの名無しさん
2015/12/21(月) 09:44:40.17 ID:ejqZ3DMD
京がお仕置き候補に???
http://gigazine.net/news/20130618-fastest-supercomputers/

◆1位:Tianhe-2(天河二号)、中国人民解放軍国防科学技術大学
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
IntelのIvy Bridge(12コア・2.2GHz)とXeon Phi(57コア・1.1GHz)を採用し、
コア数は312万、計算速度は33.9ペタフロップス、消費電力は17.8MW

◆2位:Titan、アメリカのオークリッジ国立研究所
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
AMD Opteron 6274(16コア・2.2GHz)とNvidia Kepler(14コア・0.732GHz)を採用し、
コア数は56万640、計算速度は17.6ペタフロップス、消費電力は8.3MW

◆3位:Sequoia、アメリカのローレンス・リバモア国立研究所
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
IBM BlueGene/Qを採用し、中のプロセッサーはPower BQC(16コア・1.60GHz)、
コア数は157万2864、計算速度は17.2ペタフロップス、消費電力は7.9MW

◆4位:スーパーコンピュータ京、独立行政法人理化学研究所 計算科学研究機構(AICS)
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
富士通 SPARC64 VIIIfx(8コア・2.0GHz)を採用し、コア数は70万5204、
計算速度は10.5ペタフロップス、消費電力は12.7MW

◆5位:Mira、アメリカのアルゴンヌ国立研究所のエネルギー部門
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
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は中国のためにある
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
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
64の時代だから、そろそろCore64ぐらいでイイのでは?
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚
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

;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 GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚 #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でメモリ空間がどう使われるかを視覚化
http://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は失敗。
218KB

lud20160517101510cこのスレへの固定リンク: http://2chb.net/r/tech/1447856699/
ヒント:2chスレのurlに http://xxxx.2chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

TOPへ TOPへ  

このエントリをはてなブックマークに追加現在登録者数177 ブックマークへ


全掲示板一覧 この掲示板へ 人気スレ | 動画:Youtube fc2 Tube8 xvideo pornhost >50 >100 >200 >300 >500 >1000枚 新着画像

 ↓「GCは失敗。メモリは自分で管理せよ! その2©2ch.netYouTube動画>1本 ->画像>52枚 」を見た人も見ています:
【JS】女子小学生 高学年画像スレPart31【JS】 ©bbspink.com ->動画>8本->画像>625枚
女性の背中から見えるストッキングに萌え〜->動画>2本->画像>166枚
ニートの俺がプログラミング言語を作るんだけど [転載禁止]©2ch.net (40)
集合論に基づいた言語を作りたい (846)
クラスとかインスタンスってなんのためにあんの? [無断転載禁止]&#169;2ch.net (134)
iOS、Android、Linuxサーバーの三点セット開発 [無断転載禁止]&#169;2ch.net (45)
初心者。でもよくわからないけど夢だけはある。 [無断転載禁止]&#169;2ch.net (94)
Visual C++ / C++/cliのHTTPクライアント [無断転載禁止]&#169;2ch.net (28)
【乳首】【膨らみ】胸チラフェチ【乳輪】【谷間】31 [無断転載禁止]©bbspink.com ->動画>27本->画像>820枚
【我慢】おしっこおもらし関連の動画25【失禁】->動画>27本->画像>42枚
パンツ一丁やトップレスになってる女の子の画像 [無断転載禁止]©bbspink.com ->動画>2本->画像>1311枚
今日保存した最高の画像を転載するスレ 703 ->動画>14本->画像>1161枚
【DMM.R18】ReBless リブレスX part137 [無断転載禁止]©bbspink.com ->->画像>27枚
【不正容認詐泣eクロス】神姫PROJECT 1103【80万で出ないピックアップ()】 [無断転載禁止]©bbspink.com ->動画>1本->画像>41枚
# 愛媛の JC JK JD スレ パート4 #->動画>9本->画像>144枚
【中国】大阪府立登美丘高校ダンス部のキレッキレ「バブリーダンス」、中国ネットも大絶賛 ->動画>53本->画像>31枚
【非18禁】一般誌のエロ漫画スレ20 [無断転載禁止]©bbspink.com ->->画像>226枚
【吉原】ローテンブルク Part.3【セレブ妻専門】 ©bbspink.com ->->画像>39枚
【シャドウ】桂正和 総合スレッドPart8【レディ】 [無断転載禁止]©2ch.net->->画像>188枚
【動画専用】これ誰と聞けば教えてくれるスレ 154 ©bbspink.com ->動画>373本->画像>42枚
山文京伝についてPart51 [無断転載禁止]©bbspink.com ->->画像>1枚
山文京伝について Part50 [無断転載禁止]&#169;bbspink.com [無断転載禁止]©bbspink.com
アニメ「つうかあ」 1話はクモセが2話はそこそこ良かった。尻と百合のアニメとしてワンチャンある [275723402]->動画>2本->画像>17枚
ゆっくりフェラ、手コキetc.している動画 part4->動画>143本->画像>68枚
今日保存した最高の画像を転載するスレ 704 [無断転載禁止]©bbspink.com ->動画>6本->画像>641枚
【吉原】ローテンブルク Part.2【セレブ妻専門】 ©bbspink.com ->->画像>5枚
七草ちとせ->->画像>181枚
あうろりくださいんごぉ [無断転載禁止]©2ch.net->->画像>11枚
パンモロのほうがいい人
【Sleeping Beauty】昏睡レイプ動画を集めるスレ->動画>144本->画像>55枚
小学生のエロリ画像を集めるスレ167 [無断転載禁止]©bbspink.com ->->画像>835枚
安倍「日本を守り抜く!」←5年間お前から自分や家族の身を守るのに必死なんだが ->->画像>10枚
島田陽子->->画像>21枚
神ロリ画像サイト、発見される->->画像>22枚
■ エロ画像やエロ動画の質問スレ 3 ■©bbspink.com ->動画>23本->画像>409枚
女の子の書く字フェチpornhost>10本 ->->動画>10本->画像>207枚
Futures Entertainment 4©bbspink.com ->動画>3本->画像>11枚
キズナアイ ちゃんのエロ画像ください!!!! ->->画像>10枚
OLのスーツ・制服に萌えるスレ【チョン禁止】Part23 ©bbspink.com ->動画>29本->画像>1323枚
OLのスーツ・制服に萌えるスレPart22 ©bbspink.com ->動画>23本->画像>994枚
OLのスーツ・制服に萌えるスレPart21->動画>16本->画像>1163枚
【Empress】キングダム その34【Princess】 [無断転載禁止]©bbspink.com ->動画>2本->画像>72枚
フルバックのショーツ、パンティ、パンツのお尻画像 ©bbspink.com ->->画像>1351枚
栃木県の製造業界は?->->画像>2枚
【大阪】梅田立ちんぼ事件簿その21【環境浄化】 [無断転載禁止]©bbspink.com ->->画像>4枚
【喪無・有】熟女動画をうpするスレ21【BT不可】 [無断転載禁止]©bbspink.com
【本店】やんちゃな子猫日本橋店【プレミア嬢】->->画像>6枚
無修正は禁止なの?108スレ [無断転載禁止]©bbspink.com
【倒産】 全国の高齢者から1700億円を集めた会社 年末押し迫った本日破綻 社員の給与も支払われず [219241683]->動画>2本->画像>28枚
無修正は禁止なの?105スレ [無断転載禁止]©bbspink.com
無修正は禁止なの?105スレ [無断転載禁止]©bbspink.com
無修正は禁止なの?104スレ [無断転載禁止]©bbspink.com
バカ(デカい)女王 [無断転載禁止]©bbspink.com ->->画像>1枚
【川崎南町】クラブ京都・クリスタル京都Part175【京都G】 [無断転載禁止]©bbspink.com ->->画像>5枚
パンティラインってたまらん(^ω^ )!!その47 [無断転載禁止]©bbspink.com ->動画>16本->画像>452枚
【相撲】相撲協会臨時理事会終了 午後1時半から会見 ->->画像>22枚
今日保存した最高の画像を転載するスレ 441 ©bbspink.com ->動画>30本->画像>1026枚
ザ・ノンフィクション 「追い込まれた男」 ★3 ->動画>2本->画像>8枚
近々死んで欲しい人間の名前を書きなぐるスレ150->動画>4本->画像>16枚
ストライクウィッチーズの宮藤芳佳ちゃんは不死鳥かわいい [無断転載禁止]©2ch.net ->動画>8本->画像>6枚
来期アニメにガチの児童ポルノ。主人公は7歳で非処女になり8歳でレイプ中に抵抗した結果殺人犯になり、汚いおっさんの女にされる [711847287]->動画>6本->画像>29枚
仕事中ロリサイトを見ていたおっさん(34)、会社の児童ポルノ探知システムにより単純所持で書類送検へ [無断転載禁止]©2ch.net [113554418]->動画>2本->画像>12枚
▽電車での対面パンチラ▼29両目 [無断転載禁止]©bbspink.com ->動画>6本->画像>329枚
ハイモェないと生きて行けない! [無断転載禁止]©bbspink.com ->->画像>1枚
風俗嬢って歳を取ったら人生どうすんの?結婚できないしカタギの仕事も無理だろ? [無断転載禁止]©2ch.net [352914648]->動画>4本->画像>31枚
【難波】大阪ミナミ立ちんぼスレッド14【日本橋】 [無断転載禁止]©bbspink.com

人気検索: 二次 スカートめくり 女子小学生マンコ 小学生のマンコ画像 かわいい 巨乳小学生 アウ洋ロリ画像 洋ロリ パンチラ u15女子中学中学生 思わずムラッとしたU-15 ランパン 遞イ逕ー譛狗セ 小中学生写真袋
18:55:06 up 52 days, 19:26, 1 user, load average: 2.27, 2.55, 2.61

in 0.026739835739136 sec @[email protected] on 022608