15/11/19 00:01:54.17 6rd98MPK.net
なるべくスコープを狭くして長時間存在するオブジェクトを無くす
以上
3:デフォルトの名無しさん
15/11/19 00:14:59.30 d0YkbYhs.net
仮にmalloc/free型を長時間動かしてたらフラグメントが酷いことになるぞ
そういう問題もコピーGCなら一気に解消できるしGCの方が耐久力があるよね
4:デフォルトの名無しさん
15/11/19 01:28:02.40 6x5+bHoL.net
GCの無い時代のプログラムでフラグメントが問題になった例をあげてみろよゴミッカスｗ
5:デフォルトの名無しさん
15/11/19 02:10:36.00 C+wDd3AI.net
>>3
それGCのない言語の問題じゃなくてC/C++の問題だろ
コンパクションとGCはあくまで別だし
6:デフォルトの名無しさん
15/11/19 08:58:13.78 JIJtk7D/.net
ブラッド・コックスとトム・ラブがObjective-Cを作り「この言語はCのメモリ安全性とSmalltalkの高速性を合わせたものだ」と宣言する。
現代の歴史家は2人が失読症ではないかと疑っている。
URLﾘﾝｸ(twitter.com)
7:デフォルトの名無しさん
15/11/19 23:17:01.16 SYMznuBH.net
519 ：名無し~3.EXE：2015/11/19(木) 21:49:08.84 ID:CEKgHuEl
他のアプリを使用しながらSleipnirを使う
メモリー不足でのメッセージは良心的
URLﾘﾝｸ(i.gyazo.com)
問題点として、場合によってはメモリー不足で
メッセージされずに展開されなくなる
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:デフォルトの名無しさん
15/11/19 23:18:18.19 SYMznuBH.net
525 ：名無し~3.EXE：2015/11/19(木) 22:13:05.49 ID:CEKgHuEl
展開されない時
リロードで展開される場合もあるが
リロードで展開ない場合もある
9:デフォルトの名無しさん
15/11/20 09:27:53.75 em+ldceb.net
メモリ管理は自分でやった方が漏れが出るでしょ
規模がでかくなればなるほどリスクが大きくなる
10:デフォルトの名無しさん
15/11/20 15:32:07.18 hg0nWx/i.net
C#の基本は自動だけど部分的に手動にできるハイブリッドがいいと思うよ
確保量の大きい画像なんかを扱っているとどうしても手動で解放したいタイミングもあるし
11:uy ◆Qawu9.2l1E
15/11/20 20:28:57.10 QlSu2hgW.net
まともな言語ならオプションくらいついてる
12:デフォルトの名無しさん
15/11/20 22:40:56.83 h5Le2W6O.net
>>10
それが理想的だけど、C#ってそんなことできたっけ？
13:デフォルトの名無しさん
15/11/21 09:07:54.65 +qGvO8oq.net
>>12
出来るよ。
ポインタも使える
14:デフォルトの名無しさん
15/11/21 10:29:39.51 7nxNhgSu.net
調べてみたけどよくわからんな。
もしかしてアンマネージなメモリを確保してデータ領域に使う話？
15:デフォルトの名無しさん
15/11/21 16:16:49.90 iOucF00Z.net
アンｗｗｗｗマネージｗｗｗｗ
無理に横文字使わなくていいですよｗｗｗ
16:デフォルトの名無しさん
15/11/21 17:40:45.99 7nxNhgSu.net
横文字じゃなくてマイクロソフトの用語なんだが？
17:デフォルトの名無しさん
15/11/21 17:47:25.64 /uyrLxeD.net
c#が残念なんのはC++とデストラクタの呼�
18:ﾔれるタイミングが違いすぎて移行が大変すぎることだ。 結局、手動でデストラクタを呼ばなきゃならない。GCの利便性がほとんどなし。
19:デフォルトの名無しさん
15/11/21 19:18:42.53 iOucF00Z.net
>>16
涙ふけよｗｗｗｗ
20:デフォルトの名無しさん
15/11/21 21:36:26.09 tqUpuiXF.net
>>9
自動ならメモリリーク等々発生するわけがないのに発生している
この原因はプログラマなんだけど、結局メモリ管理から解放されてないなら最初から管理する方針でいいじゃん
21:デフォルトの名無しさん
15/11/22 01:48:28.16 7AflF1fM.net
メモリ管理を楽にするためにあるわけで人間が全部面倒みんのとは違うだろ
22:デフォルトの名無しさん
15/11/22 04:41:20.06 WFE6EpHf.net
やっぱりGCのほうがいいかな大規模になってくると
Cでリークはしてないけど本来開放すべきタイミングで開放してないでメモリいっぱいになるのは防ぎやすいと思うし
23:デフォルトの名無しさん
15/11/22 07:04:28.69 MUaNGGyB.net
>>20
楽になってメモリリークがなくなるならいいけど、メモリリーク発生するわ
プログラマがメモリ管理なんてしなくて大丈夫、とメモリの扱いが雑になって意図しないタイミングで解放されたりされなかったり
最初から管理するという方針で教えないから、こんなことになる
管理漏れをGCがうまいことやってくれる。でもGCにやらせるようだと恥。
というくらいで教育すべき
24:デフォルトの名無しさん
15/11/22 07:12:51.89 MUaNGGyB.net
メモリ管理すらまともにできないやつが寿命や世代やら管理できるわけがない。
25:デフォルトの名無しさん
15/11/22 10:54:50.51 MJCWCZ10.net
GCそのものではなく新人教育や解説書が最初のスタンス間違えたんだよ。
GC=メモリ管理適当
という認識作ったから、GCに新しい名称つけて
教育や解説書では、メモリーの確保から解放まできちっと説明し直したほうがいい
26:デフォルトの名無しさん
15/11/22 12:31:51.68 Qlq25ltW.net
GCって完全なものだと思ってたから、C#案件でメモリリークの調査にえらく手間がかかった
GCはダメな子って認識は必要だな
27:デフォルトの名無しさん
15/11/22 12:38:37.22 mfzN9aoV.net
C/C++はライブラリレベルでメモリリリークの検査もテストも書けるけど
GC前提言語だとその辺がごっそり抜け落ちて後で問題になる
28:デフォルトの名無しさん
15/11/22 12:42:49.74 zNwKjU3u.net
メモリ管理できない人がお気楽で作れば、GCあっても・・・・
29:デフォルトの名無しさん
15/11/22 13:08:14.89 KDgQ57Ye.net
>>25
結局どんなバグだったんだい？
30:デフォルトの名無しさん
15/11/22 16:57:06.63 vggKhYqJ.net
C++でもスマートポインタ使えば勝手に開放されるよ
所謂GC任せだと、いつ開放処理が走るか分らなくなるから
その事に対する新たな対策が必要になるよ
URLﾘﾝｸ(ufcpp.net)
手続き型言語は処理の順番が重要なのに
いつ実行されるか分からないってのは中々チャレンジャーだし大掛かりな話だね
31:デフォルトの名無しさん
15/11/22 17:32:48.70 vggKhYqJ.net
前スレでも書いたけど、C#のDisposeの問題を紹介しよう
IDisposableなオブジェクトをコンポジションしてメンバに持つと自身もIDisposableにしなければならない
だから自分がコンポジションしているオブジェクトがIDisposableかどうか一々調べなければならないし
IDisposableなオブジェクトがメンバにあれば、自身もIDisposableにしなければならない
さらに、その作ったクラスをコンポジションして使うクラスもIDisposableにする必要があり・・・
という風にIDisposableはクラスで閉じずコンポジションで伝染する
というか、むしろ手動で伝染させなければならないという
しかもIDisposableの一連のイディオムはとても長くて煩雑
URLﾘﾝｸ(ufcpp.net)
こういうものを書いて、マネッジドリソースとアンマネッジドリソースで場合わけをしつつ
IDisposableなオブジェクトに関しては
手動で自分のメンバのDisposeを漏れなく呼び出すコードを書かなければならない
当たり前だが、どのメンバがIDisposableか完全に把握しておく必要が有る
手動で自分のメンバのDisposeを呼び出す作業は、まるでCのmallocを思い起こさせる
問題点は明確で、DisposeがC++のデストラクタのように芋づる式に勝手に呼ばれない事に有る
だから手動で芋づる式に呼び出すコードを書かなくてはならない
32:デフォルトの名無しさん
15/11/22 18:20:40.59 WFE6EpHf.net
Formなんかも参照が亡くなったら強制的に殺すべきだったと思うわ
ファイナライザーの処理がひどいことになると思うけど
33:デフォルトの名無しさん
15/11/22 22:36:02.07 iT1tZCI1.net
またお前か
メンバに持つのが間違い
34:デフォルトの名無しさん
15/11/22 23:18:34.23 7zQV9dKP.net
無茶いうな
35:デフォルトの名無しさん
15/11/23 08:11:32.17 XNOSKZeE.net
解放処理をしなくてもGCがやってくれる。
でも、ソースに解放処理が書いてあれば、後から見たらあぁここで用済みになったのかとわかる。
可読性は非常に重要よ。
36:デフォルトの名無しさん
15/11/23 15:41:37.20 qRZYsqEh.net
解放処理のタイミングが制御できないと、解放して欲しくないタイミングで解放されて
挙動が変わることがある
リアルタイム性が要求されるシステムでこれで困ったことがある（そもそもそんな言語使うなって話だが）
37: ◆QZaw55cn4c
15/11/23 17:14:59.57 JWzW06M6.net
>>35
それはあまりない
挙動が変わるというか停止するというのならあるのかもしれないが
38:デフォルトの名無しさん
15/11/23 17:21:44.69 y4njP/wV.net
うわっ頭のおかしいQだ
39:デフォルトの名無しさん
15/11/23 17:22:22.95 9XGqpqVu.net
＞解放して欲しくないタイミングで解放
なんでそんなことになったの？
参照切ってなきゃGCの対象にならないはず
40:デフォルトの名無しさん
15/11/23 17:24:18.17 OK+rBFmG.net
空きメモリによって使用するアルゴリズム変えたりする。
だから実行前にGC手動で走らせて、できるだけ空きメモリ増やしたりとかする。
できるだけ開放したいのに過負荷でまだメモリに余裕あるからGC走らないってのが困る。
41:デフォルトの名無しさん
15/11/23 17:46:43.41 XNOSKZeE.net
メモリの解放漏れってさ、とどのつまり下手だからするんだよね
下手なやつにはプログラムを組ませないってのが鉄則だと思うの
42:デフォルトの名無しさん
15/11/23 19:25:05.71 6m6E/SfN.net
c++11のshared_ptrの参照カウンタってそもそも要るんだろうか？
複数のオブジェクトが所有権を持ちあう必要性に迫られる事がないんだけど
weak_ptrの対応だけあれば良くない？
43:デフォルトの名無しさん
15/11/23 19:56:47.15 +Ddm9172.net
リソースを共有する場合なんかは使うと楽だよ
まーshared_ptrが有れば、いつ実行されるか分からないような、手の込んだGCは要らないよな
巡回参照が有る場合はどちらかをweak_ptrにする、これだけを守ってれば問題は起きない
大体の場合は所有権というか上下関係がはっきりしているからな
巡回参照のある場合も自動で開放したいという、たったこれだけのために
いつ実行されるか分からない上に重いマークスイープ式GCを導入するのは
業界全体の早とちりだったようだね
44:デフォルトの名無しさん
15/11/23 20:06:26.94 +Ddm9172.net
最近のC++はdeleteを直接書かないだけでなく、最早newも直接書かない方向
std::make_shared<int>() って書くよね
始めからshread_ptrで受け取るから、循環参照だけ気をつければ
リークする余地がないよね
RAIIも健在で、C#みたいにIDisposableとか要らない
デストラクタも芋づる式に呼び出されるから
>>30で書いたような問題も起きないよ
45:デフォルトの名無しさん
15/11/23 20:09:18.99 OK+rBFmG.net
C++は益々混沌としているのか。手に負えん。
46:デフォルトの名無しさん
15/11/23 20:35:23.62 PopzBtGV.net
>>41
糞便利な参照カウンタを使わないなんてＣ＋＋使う意味なし
47:デフォルトの名無しさん
15/11/23 22:58:10.32 6m6E/SfN.net
>>42
それはManagerやHolder的なものを書かなくて良いってことを言ってるの？
それって大体一時しのぎで大抵後々リソース管理以外にもそういった管理クラスが必要になるケースがほとんどじゃない？
>>45
ねーよ
48:デフォルトの名無しさん
15/11/24 00:26:10.23 f4S6RtN7.net
うーん質問がアバウトすぎたな。もう少し具体的に書くわ
例えば2chのある板を管理するプログラムを書くとして
BoardクラスとThreadクラスを想像してみてくれ
BoardはThreadオブジェクトを管理するが、Threadは
産まれたり死んだりと揮発的で寿命が定まらないと。
で各Threadは何らかの共有リソースを持つと。
例えば一度読み込んだ画像を各スレッドで共有したいとかが
考えられるけど、画像オブジェクトをshared_ptrで共有するのは
適切ではない
なぜならある瞬間に産まれたThread群がひとつの画像を共有する
からといってshared_ptrで持たせたとしても、後の更新時に
更にその画像を共有したいThreadが現れたときに、画像が
すでにあることを何らかの形で知れないといけないから。
結局Boardなんかが画像オブジェクトのコンテナを持つ必要が
あってそのコンテナへの追加と削除のために別の共有の
仕組みが必要になるんだよ。例えばThreadがBoardに画像を
リクエストして参照カウンタを持ったアクセサを返すようなもの
だから所有権はBoardひとりが持てばよくてshared_ptrを
使う必要がなくなるという理屈
こういったケースを踏まえてもshared_ptr使うケースって
ほとんどなくね
49:デフォルトの名無しさん
15/11/24 01:21:45.79 0dqdPvnh.net
IDisposableの問題はDisposeを呼ばなければリークするものとそうでないものの混在だろ
50:デフォルトの名無しさん
15/11/24 03:22:06.30 fjQi4YH+.net
>>47
マルチスレッドプログラム書いてみろよ
shared_ptrがないと泣くぞ
51:デフォルトの名無しさん
15/11/24 05:26:33.27 f4S6RtN7.net
>>49
いやいくらでも書いてるけど基本一緒
というか上の例もそのままマルチスレッドに適用できる話でしょ
例えばproducer consumerならproducerが所有権を持つし
thread per messageなら共有データはホストが持って固有データは
個別スレッドで持つだけ
むしろマルチスレッドの場合、所有者をより厳格に決めとかないと
泣く事になるぞ
52:デフォルトの名無しさん
15/11/24 12:31:47.38 HvLaDP3z.net
所有権って・・・・
unique_ptrを使うと勝手に所有権が移動してしまうし
生のポインタを使うんならわかるけど
53:デフォルトの名無しさん
15/11/24 12:53:55.99 2IyJeQ15.net
shared_ptrで複数人が所有権を持っても良いんだぞ
上下関係さえしっかりしていれば良い
54:デフォルトの名無しさん
15/11/24 13:15:01.57 HvLaDP3z.net
そんなの分かってるんだが
>>50の人はどう考えてるのか
55:デフォルトの名無しさん
15/11/24 16:23:15.08 f4S6RtN7.net
>>51
今のC++からshared_ptrをそのまま無くせって言ってるんじゃないぞ
shared_ptrのコピーを禁止にしてweak_ptrの対応だけあれば良くないかって事
そもそも何でそんなこと言うかっていうと、
GCない言語→循環参照ガー。みたいによく言われるけど使わないで
済むなら静的解析で循環参照の起こり得るケースをエラーにしてしまう
って解決方法もあるかなと思っただけ
あとshared_ptrとweak_ptrはアトミック操作とメモリバリアを必要としうるから
それに頼った設計は疑問を感じる
56:デフォルトの名無しさん
15/11/24 16:37:54.42 f4S6RtN7.net
一応言っとくと静的解析のくだりは新しい言語を
設計するとした場合の話ね
C++だとほぼ不可能だろうから
57:デフォルトの名無しさん
15/11/24 16:39:45.81 1SleeXaD.net
せっかくC#は新設計なのにいろいろ失敗が含まれてるよな。
ヘジはなにやってんだか。
58:uy ◆Qawu9.2l1E
15/11/24 18:29:34.50 lNjW2jss.net
大企業は、
中小企業を奴隷にさせる事を第一に考えたツールしかリリースしてないよ
失敗ではなく全部わざと。
59:デフォルトの名無しさん
15/11/25 07:39:30.16 JnM8vxaH.net
メモリ管理テケトーなやつはその他のリソース管理もテケトー
60:デフォルトの名無しさん
15/11/25 17:12:00.25 Sra0FKsR.net
そもそも自分のリソース管理がしっかり出来てる人は・・・
61:デフォルトの名無しさん
15/11/27 12:24:34.85 ZRdaHx9T.net
>>31
Formはnull入れてあげないといけないんだっけ？
なんか、場合場合によってnull入れてあげないといけなかったり入れなくてもよかったり。
ならnull入れるで統一でいいじゃんと思った
62:デフォルトの名無しさん
15/11/27 22:35:05.80 CyIO1ZuX.net
Rust使えば解決
63:デフォルトの名無しさん
15/11/28 06:44:39.29 CKvy7+My.net
中の細かい実装まで知らないんだけど、
A = new A()
Loop Begin
処理
A = null
A = new A()
Loop End
とか、nullをセットをGCって見張ってるの？又はGCに伝えているとかあるの？
64:デフォルトの名無しさん
15/11/28 13:02:34.51 Qyl/1Ad+.net
違うよ
newが動いた時点で中の人がメモリが足りない！って騒いで初めてGCさんお願いします！GC「やれやれ・・・
っていう仕組みなんで
>>62の例のnullの代入は無駄
65:デフォルトの名無しさん
15/11/28 13:08:02.55 Qyl/1Ad+.net
いや無駄じゃないか
代入演算子の順序の関係でnewの後に代入が起こるから
Aを事前にnullすることでGCさんが回収できるオブジェクトが1個増える
66:デフォルトの名無しさん
15/11/28 13:10:10.16 rTI66XO9.net
書いたほうが保守性は高く、意味がある。
67:デフォルトの名無しさん
15/11/28 13:34:46.98 CKvy7+My.net
>>64
つまり、使い終わったら、スグにnullっておいたほうがいいってことか。
・・・とも言い切れないな。
でも、ここで使い終わったってわかるから、書いたほうがいいか。
よし。決めた。全部書こう。
68:デフォルトの名無しさん
15/11/28 13:55:47.33 pohBt4lh.net
null代入なんていちいち書いていたら
コードが冗長になって保守性が落ちる。
メモリ食いのオブジェクトなど、クリティカルな部分でのみ使うべき
69:デフォルトの名無しさん
15/11/28 14:16:02.55 81goelDj.net
お前らか。無意味なnull代入書き散らしてるのは
70:デフォルトの名無しさん
15/11/28 14:42:43.95 DqKP/LxN.net
null代入とか結局やってることc++以下なんだよなぁ
71:デフォルトの名無しさん
15/11/28 14:48:25.74 Fi4wDTmy.net
ダングリングポインタが出ないって利点は有るにはあるが
スマートポインタ使えば済む話だしなぁ
weak_ptrもあるし
72:デフォルトの名無しさん
15/11/28 15:20:08.61 vL/aYykM.net
>>68
意味はあるじゃん
73:デフォルトの名無しさん
15/11/28 17:52:47.31 CKvy7+My.net
>>68
ここでおしまい！って書いてあるだけ。
こんなんで冗長とは評価されない。むしろ読みやすい。と判断した。
74:デフォルトの名無しさん
15/11/28 18:23:41.31 ekTV2Qou.net
変数がどこで不要になるか明示しなきゃならんほど長い関数ばっかり書いてるのか
それともローカル変数とか無い言語を想定してるのか
75:デフォルトの名無しさん
15/11/28 18:24:46.08 q5KJxTWt.net
無駄なことするな
どうせ最適化で削除される
76:デフォルトの名無しさん
15/11/28 18:28:07.06 rTI66XO9.net
保守性より効率重視なんかでコード書くからメモリリークするんだよ。
77:デフォルトの名無しさん
15/11/28 19:04:25.52 ekTV2Qou.net
どんな意味でnull代入をしてるのか他人に伝わらなきゃ保守性もクソも無いよね
78:デフォルトの名無しさん
15/11/28 19:08:04.34 rTI66XO9.net
a = null;
で伝わらない人にはどんなコメント書いても伝わらないと思うんだ。
79:デフォルトの名無しさん
15/11/28 19:27:35.81 pohBt4lh.net
関数内ローカルな変数は
いくら大きくても大概スコープだけで
どうにでもなる。
javascriptみたいなのはlambdaでスコープ切ればいい。
80:デフォルトの名無しさん
15/11/28 19:54:24.96 CKvy7+My.net
>>75,>>77
同じ結論ですわ。
null代入ってやっぱり特殊だから、コメントよりはるかに目が行く。
ここで使い終わったYO!！（逆に言えば、ここまでは意識してね。使ってるから。）ってわかってもらえれば良い。
81:デフォルトの名無しさん
15/11/28 20:10:37.33 ekTV2Qou.net
>>77
長い関数中にそれ出てきたら変数を使い回す前に初期化したいのかな？とかも考えるな
短い関数なら変数を使い終わったとか重要な情報じゃないから無駄な行入れて可読性下げてるだけ
82:デフォルトの名無しさん
15/11/28 20:14:43.65 pohBt4lh.net
永続的な変数でもなきゃ、変数の寿命はコンパイラが把握しているから、null代入がどんな変数にも必要なら勝手に挿入するんじゃね。
そうじゃないとしたら、なんでもかんでもnull代入が必要なんてのは幻想だよ。
83:デフォルトの名無しさん
15/11/28 20:16:46.53 Fi4wDTmy.net
勝手にnullを代入するとか、そんな変なコンパイラは困る
84:デフォルトの名無しさん
15/11/28 20:47:03.48 03HlMXbm.net
話は変わるんだがスマートポインタのメリットって何？
コンストラクタで例外投げたとき
そこまでに初期化したメンバ変数のデストラクタを呼ぶため
みたいなのは聞いたことあるけどそれくらいのもん？
85:デフォルトの名無しさん
15/11/28 21:01:25.91 DqKP/LxN.net
>>83
別にコンストラクタじゃなくて関数内で確保した場合でも、
例外じゃなくreturnで戻った時も勝手に解放してくれたほうが
有り難いし、そもそも解放処理って忘れやすいものだろ
傘を置き忘れたり洗濯物を洗濯機に入れっぱなしにしたことの
ないものだけスマートポインタに石を投げなさい
86:デフォルトの名無しさん
15/11/28 21:20:40.16 ETFlkHGB.net
null 代入したら行数増えるじゃん…全部のローカル変数にやってんの？
どうしても明示したければスコープで区切った方がまし
それでもインデントが深くなるのであれだけど
87:デフォルトの名無しさん
15/11/28 23:46:43.25 pohBt4lh.net
>>82
勝手にnull代入すると表現するから気持ち悪く感じるだけで、コンパイラが各変数についてもうアクセスされる可能性の無い基本ブロックに到達したら、その変数をGCのマークの起点として使用しないようにフラグを管理すると言えば当たり前の話じゃね。
フラグの持ち方として変数にnullを代入しているだけで。
88:デフォルトの名無しさん
15/11/29 00:14:42.24 qbMwzV1h.net
>>84
> そもそも解放処理って忘れやすいものだろ
それを忘れるなどとんでもない
確保＆開放なんてプログラミングの花じゃん
キモじゃん
そこを工夫するのが楽しいんじゃん
設計も楽しいし
チマチマテストすんのも楽しい
温泉行って湯につかり忘れる心配はない
89:デフォルトの名無しさん
15/11/29 00:30:29.12 Co3W2iFa.net
>>87
まあ勉強目的でやるならいいんじゃね
俺は元々ゲームプログラマだったからもう嫌になるほどやったし
メモリ周り工夫するなら言語設計からしたいわ
90:デフォルトの名無しさん
15/11/29 13:48:13.85 U49gaUJj.net
信じて送り出した >>87 がわがままな顧客を✕✕して三面記事に載るなんて…
91:デフォルトの名無しさん
15/11/29 14:29:40.51 c+9MHjtm.net
マークスイープ型のGCが必要かどうかについて、もう少し建設的な会話をしようよ
リソースを自動で開放してくれる機能は、無いよりは有った方が絶対に良い、と言い切ってよいよね
ただ、その方式が話の焦点だと思う
C++のスマポの参照カウンタ方式はデストラクタとの相性が良いし、RAIIもよく機能するし
開放されるタイミングもはっきりしているのて、手続き型言語と相性が良いし、軽い
ただし、循環参照があるとリークする
解決策として、片方をweak_ptrにするという方法が用意されている
weak_ptrは対象オブジェクトが開放されると勝手にヌルポみたいになるのでいろいろと悪用ができる
一方でマークスイープ系のGCは、循環参照があってもリークしない
しかし参照カウンタ方式に比べてマークスイープ系のGCが優れている点は、それだけ
重いし、いつ開放処理が実行されるか分からないので
リソース開放のタイミングを明確に行いたい場合のための別の仕組みが必要になった
どちらを選ぶ？
92:デフォルトの名無しさん
15/11/29 14:58:17.95 7vkfzAlt.net
GCの意見・・・OSではページファイル関連？
ｽﾚﾘﾝｸ(tech板)l50
93:デフォルトの名無しさん
15/11/29 15:57:55.75 Co3W2iFa.net
そもそもc++においてメモリリークって対策も発見も
大して難しい部類のバグではないんだよなぁ
GCの優位性をアピールするために過剰に恐怖心を煽ってる気がする
94:デフォルトの名無しさん
15/11/29 16:00:08.95 sCmmZzWu.net
>>92
その程度の案件しか受けてないからだろう。
95:デフォルトの名無しさん
15/11/29 16:05:07.63 QSPcxrGF.net
>>90
つ世代別GC
immutableオブジェクトをバンバンnewしまくる関数型プログラミングに慣れてると
やっぱGCないとキツイわ
96:デフォルトの名無しさん
15/11/29 16:15:05.64 Co3W2iFa.net
>>93
いやいや普通難しいとされるバグってメモリ破壊とか同期周りだから
メモリリークなんてデバッガがチェックして丁寧なダンプ出してくれるし
組み込みとかの貧弱な環境なら専用のメモリ管理を用意して
いくらでも好きなチェックや情報出せるから
97:デフォルトの名無しさん
15/11/29 16:17:37.80 AV0cYAnH.net
>>92
それな
メモリの確保と開放の対応すら管理できない奴は
なんかもう何をどうしたってダメな気がする
初歩の初歩の初歩の話題を何度も何度も何度も繰り返しすぎ
98:デフォルトの名無しさん
15/11/29 16:20:05.34 3h4H/kBH.net
忘れるとか忘れないとか池沼レベルの話じゃん。
ゴミクズ。
メモリの解放が必要ならそれは必要な機能の実装ってことになる。
それを忘れるってことはプログラムを組んでいて必要な機能の実装を忘れるってことだ。
必要な機能の実装を忘れるということは、例えば通販サイトのシステム開発請け負っておきながら、決済システムを実装し忘れるのと同等。
ありえない。
プログラム云々以前に頭の問題だろう。
必要な機能の実装を忘れる可能性におびえる池沼プログラマ。
最近流行りのADHD？なんじゃねえの。
99:デフォルトの名無しさん
15/11/29 16:24:33.80 sCmmZzWu.net
>>95
なるほど。経験の少なさがすぐ分るな。ログ出したらで数十ギガなんてよくあるよ。
ログから問題点をスクリプトで抽出するにも何時間とかかるとかいろいろ。
マルチスレッド絡んで特定のパターンだけだったりして再現性がなかったりする。
他システムの連携だと手が出せない部分の挙動がおかしい可能性もある。結局、oracleのバグだったとかね。
100:デフォルトの名無しさん
15/11/29 16:25:01.11 1uX74bCE.net
>>97
決済システムとメモリ解放は違うよ。
通販サイトのシステムをC言語で実装してみればわかるかと。
101:デフォルトの名無しさん
15/11/29 16:36:20.27 Co3W2iFa.net
>>98
はあ？なんでリーク箇所ダンプするだけの話でログ全部吐き出すことになってんの
普通確保する際にヘッダにそのブロックの確保場所埋め込んでるし
アロケータで生存期間のスコープを切り分けといてすぐ分かるようにするけど？
お前の関わったプロジェクトが糞なだけじゃね？
102:デフォルトの名無しさん
15/11/29 16:42:54.34 snjMtaUP.net
そもそも今時c++でgcならなんとかなる類いのメモリリーク起こすなんて、プログラマが屑なだけ。
リソースリークやその他の問題も確実に起こすこと請け合い。
GC言語でそのレベルのプログラマを使うような案件はGCによるメモリオーバーヘッドが気にならず、リソースリークも問題にならないような非常に緩い案件でしかない。
103:デフォルトの名無しさん
15/11/29 16:46:22.91 sCmmZzWu.net
>>100
はぁ。話にならんな。扱ってる規模が違いすぎる。
104:デフォルトの名無しさん
15/11/29 16:52:06.50 Co3W2iFa.net
>>102
おいおい反論できずに捨て台詞かよ
上でも書いたがコンシューマで開発してたから
100人*数年の規模でやってたんだけど
もしかしてC++みたいな危険な言語使ってて
今の今まで解析ツールなり自前のメモリ管理なり知らなかったの？
105:デフォルトの名無しさん
15/11/29 19:41:19.37 GW0SCIDI.net
お前ら派遣だろw
全体規模とお前らが任されてる範囲を都合よく混ぜるな。
106:デフォルトの名無しさん
15/11/29 22:07:37.11 3h4H/kBH.net
ほーら、自分の知能が一般人より低いと認めたくないがゆえにレッテル貼りが始まった。
普通の人が当たり前にできることができないってかわいそうだな。
もしADHD？だったら治療法あるらしいから病院行ってみたら？
ここでレッテル貼りやってるよりよっぽど解決する可能性が高いぞ。
107:デフォルトの名無しさん
15/11/29 22:12:02.58 QSPcxrGF.net
レッテル貼りは2chの華
108:デフォルトの名無しさん
15/11/30 08:34:00.92 qSWjFIuy.net
>>100
リーク箇所がわかってればログ出力の必要なくね？
ホントに開発したことあるのかな？
109:デフォルトの名無しさん
15/11/30 09:12:24.63 UQyKbzCH.net
>>107
普通C++のプロジェクトは専用のメモリ管理を用意するから
リークしたメモリはそれを確保したクラスとその行数まで特定できるようにしてるよ
アロケーターも分離しとけばアプリケーション終了させなくても
管理オブジェクトを破棄した時点でリークの判定できるし
リーク箇所特定するのに全ログから解析とか複合的なバグでもない限りしない
そんな状況許してる時点で負け
110:デフォルトの名無しさん
15/11/30 12:11:48.62 fg7tHWVi.net
100人で数年のシステムなら
10人で一年でやるべきだな。
人を無駄に増やせば、意思疎通や連携に無駄に労力を割く。
開放云々より仕様レベルで齟齬が出やすくなるわ。
111:デフォルトの名無しさん
15/11/30 15:00:18.02 Ee9Jt/HC.net
>>108
リークしたクラスが分ればリーク原因が分るとかお花畑杉w
112:デフォルトの名無しさん
15/11/30 19:23:16.25 UQyKbzCH.net
>>110
誰もリークしたクラスの事なんて言ってないんだが…理解できてる？(笑)
解らないなら解るだけの情報埋めたら？
113:デフォルトの名無しさん
15/11/30 19:24:12.90 Ee9Jt/HC.net
おいおいw
114:デフォルトの名無しさん
15/11/30 19:31:17.77 UQyKbzCH.net
>>112
そもそもGCがあろうとコンテナに突っ込んで消し忘れれば
オブジェクト破棄するまでメモリ圧迫し続けるって理解できてる？
リーク単体ならC++はそれと同等のレベルまで分かりやすく出来るんだよ
C++が困難なのはそういった管理情報も簡単に破壊出来てしまう点
リーク単体なら怖くはない
115:デフォルトの名無しさん
15/11/30 19:47:37.41 UQyKbzCH.net
なんかだんだん笑えて来たんだけど、ろくに理由も言わずに
「わかんないんですけど！？わかる奴はお花畑(怒)！！」って
なかなか面白い奴だな
116:デフォルトの名無しさん
15/11/30 19:50:22.70 isQX20zS.net
メモリの解放すら管理できない奴が、複雑な仕様を管理できるとは到底思えない・・・。
メモリの解放なんてなんの苦にもならんが・・・。
117:デフォルトの名無しさん
15/11/30 20:14:21.83 Ee9Jt/HC.net
やれやれw
MSやLinuxやFreeBSDまでメモリリークやらかす理由が分らないのか。
118:デフォルトの名無しさん
15/11/30 20:30:16.55 UQyKbzCH.net
>>116
また反論できずに逃走かよw
そもそも欧米は原因分かっててもバグ無視する連中だろうがw
ライセンスで守られてりゃ平気で放置するぞ
119:デフォルトの名無しさん
15/11/30 20:33:04.33 V9s4KAVu.net
人生の管理ができない奴が、メモリを管理できるとは到底思えない
120:デフォルトの名無しさん
15/11/30 20:49:26.08 UQyKbzCH.net
そもそもLinuxカーネルもFreeBSDカーネルもC言語だろ
馬鹿丸出しだなw
121:デフォルトの名無しさん
15/11/30 21:16:22.39 zT+q2mn+.net
>>115
それな
プログラミングにおいてメモリ周囲はまだ初歩だよな
そしてマルチスレッドはそれよりは大変だがこれも慣れると
結局大事なところをガッチリ排他処理するだけのことだしな
プログラミングって最後はインタフェース設計だけだから
使いやすくてコンパクトなインタフェースを求めていくだけ
これがプログラミング道の後半の道のり
122:デフォルトの名無しさん
15/11/30 21:18:50.76 Ee9Jt/HC.net
>>120
で例外系の実装がないから破綻するんだよ。実務経験ないとすぐ短絡的になるのが分る。
123:デフォルトの名無しさん
15/11/30 21:25:49.32 zT+q2mn+.net
意味が不明すぐるｗ
124:デフォルトの名無しさん
15/11/30 21:28:33.92 Ee9Jt/HC.net
うむ。まだおまえには早いかもしれない。
125:デフォルトの名無しさん
15/11/30 21:47:43.54 UQyKbzCH.net
>>122
馬鹿相手にしても時間の無駄だぞ
こいつ具体的なこと何も言わんし
126:デフォルトの名無しさん
15/11/30 22:07:34.86 zT+q2mn+.net
>>124
そやね
一連のレスの意図すらよーわからんわ
127:デフォルトの名無しさん
15/12/01 00:23:09.00 s1rcgCDh.net
Guilty Crown?
たしかに失敗作だったなあ…
128:デフォルトの名無しさん
15/12/01 01:24:29.91 mVPa8mQr.net
GCが云々というより抽象的なプログラミングしたい時は基本的なメモリ管理を言語に任せたいという欲求
129:デフォルトの名無しさん
15/12/01 01:27:09.96 mVPa8mQr.net
>>113
c++素人なんだけどリーク単体はともかくそれにメモリ破壊が合わさると頭がおかしくなって死ぬ
みたいな感じ？
130:デフォルトの名無しさん
15/12/01 01:30:32.01 s1rcgCDh.net
GCは関数型プログラミングでのみ正当化される
命令型プログラミングでは全く正当化されない
命令型プログラミング（＝チューリングマシンに基づく計算モデル）は読み書きの「順序」こそがネ申なので
命令コードの「順序」を横断して存続するブツは善と悪の最終戦争で滅ぼされるであろう
つまり確保し、使ったら後開放する、これを明示的に書き下す姿勢こそが正しい
131:デフォルトの名無しさん
15/12/01 01:31:50.27 s1rcgCDh.net
>GCは関数型プログラミングでのみ正当化される
ちな、これは処理系の裏方としての存在が許される、の意味
132:デフォルトの名無しさん
15/12/01 01:36:31.76 mVPa8mQr.net
関数型プログラミング好きだけど
代数型データ型と型クラスでモナドとかアプリカティブとかtraverse、free monadとかやってる時に
メモリ管理だの言われたら余裕で死ねるな
本物のhaskellプログラマはhaskellで低レイヤを書くらしいけど
133:運用中（トリなしｗ
15/12/01 04:32:07.54 79aHC4wo.net
口 先 人 間 展 覧 会 。（ｱﾊ
134:デフォルトの名無しさん
15/12/01 12:55:11.72 S8usJREu.net
>>128
> メモリ破壊が合わさると
これが合わさるとなんでもありありなので何が起きても不思議はない
なので、ダングリングポインタの管理と配列のレンジチェックはちゃんとやるべし
135:デフォルトの名無しさん
15/12/03 12:20:09.85 AuS7g0FI.net
ここでメモリ確保
ここでメモリ解放
たったこれだけが書けない管理できないとかw
136:デフォルトの名無しさん
15/12/03 12:23:19.04 n26CULk9.net
知らないでやるって幸せなことなんですね
137:デフォルトの名無しさん
15/12/03 13:19:32.39 N5r0JkUz.net
>>134
下には下がいるんだよ
138:デフォルトの名無しさん
15/12/03 13:29:54.15 JbiOZ/E3.net
メモリリークは開放忘れでなると思ってる低レベルがいるのか。
139:デフォルトの名無しさん
15/12/03 14:07:05.91 n26CULk9.net
低レベルなことを舐めるなよ
140:デフォルトの名無しさん
15/12/03 16:32:54.69 JraK7tKY.net
>>134
mallocでOSから確保したメモリはfreeで解放されないんだが、
「ここで解放」はどうやって書くんでしょう?
141:デフォルトの名無しさん
15/12/03 19:43:25.89 R/g8PPkY.net
>>137や>>139みたいのが知識や技術に溺れて本質を見失い、
人と会話ができなくなった人の見本なんだろうか
142:デフォルトの名無しさん
15/12/03 19:47:17.15 JraK7tKY.net
>>140
今まで正しいと信じきってた鰯の頭が迷信だと指摘され発狂中
143:デフォルトの名無しさん
15/12/03 19:53:39.75 R/g8PPkY.net
>>141おｗ おまえ会社で孤立してるだろ派遣ｗ
144:デフォルトの名無しさん
15/12/03 20:32:35.32 R04IP6VM.net
確保したやつが解放するんだぞ。大丈夫か？
145:デフォルトの名無しさん
15/12/03 20:33:46.24 cWTIfUD3.net
想像を絶するアホは居るもんだよ
if (cond) exp; の場合も中カッコを必ず付ける流派ってのがあって
理由を聞くと
if (cond) {exp1; exp2;}とするはずが
if (cond) exp1; exp2;としてしまうのを防ぐための常に中カッコらしい
中カッコを書き忘れるくらいの意識レベルで書かれたコードって
他のとこももう全部ダメだろそれは
146:デフォルトの名無しさん
15/12/03 20:52:03.75 s/TINiTx.net
>>144
お前がアホなｗｗｗ
147:デフォルトの名無しさん
15/12/03 21:25:03.70 n26CULk9.net
カッコ先につけといたほうが 後々、都合がいいことも
148:デフォルトの名無しさん
15/12/03 21:30:08.65 WeEbsZB7.net
アホな書き方といえば
if ( 1 == a ) {
って比較元と先を逆にしてる奴
149:デフォルトの名無しさん
15/12/03 21:41:57.39 4rUKwdGH.net
別におかしくない
基準値が先にあって、それと比べてaがどうなのか、と考えるか
aが先にあって、基準値と比べてどうなのか、と考えるかの違いでしか無いから
どっちでも良い
150:デフォルトの名無しさん
15/12/03 21:59:47.07 /xqyH1ID.net
>>147
知ってて言ってると思うが、定数を==の左辺にするのは
if (a=1) { ...
と書き間違うのを恐れているらしい
>>139
free()から設計し直す、
まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ
>>135
スレッド安全に書かない奴が悪いていうかそれは別の話
シングルスレッド状況（またはそれと等価な状況）では>>134の言っていることは全く正しい
151:デフォルトの名無しさん
15/12/03 22:27:47.14 zepIVOGi.net
ここ数日一気にレベルが下がったなw
ＧＣの話しろよw
152:デフォルトの名無しさん
15/12/03 22:46:13.76 srgQPG9D.net
つーか前スレと同じこと書いてる人多数
頼むから前スレ読んできて
153:デフォルトの名無しさん
15/12/04 04:37:18.54 HtuddwW0.net
【 オンラインTCGエディター 】 >>1
デュエル・マスターズ的な非電源TCGの 《 オンライン化ツクール系ソフト 》 制作の企画。
例えば、ガチンコ・ジャッジを直ぐにでも導入できる機能を持っておりながら、
当面それを扱わず単純化させておいて、事後的に導入拡張する際に当該システムを
ブロック構造の組み合わせで後付け挿入できるように予めシステム化してあるソフト（エディター）。
既存の非電源TCGを劣らずに再現できるならば大概のニーズに応えられる筈。
バトスピ、ヴァンガ、ウィクロス、ポケカ、デジモン、ゼクス、モンコレ、ガンダム・ウォー、ライブオン、ディメンション・ゼロ、カードヒーロー、シャーマン・キングなど
のシステムを完全再現できるように設計するけど、他に此のTCGの此のシステムは再現希望とか有ったら書いて。
マジック：ザ・ギャザリングの全システムを完全に再現するのは無理だから、此れだけは必用だ！って部分のみリクエストして。
WEB通信での対戦は、個vs個、多数乱戦、チームvsチーム、個vsチームを可能な仕様とする方針。
設計思想は 《 RPGツクール 》 が良いかな？ 他に、優れたエディター有ったら挙げてみて。
個人や企業などのベンダーが提示する開発費（見積もり）で折り合えば、発注する。
↓
エディター群から基本コンセプトを絞り込む（もちろんオリジナルで優れた新ネタが有れば導入する）。
↓
遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。
なるべく前述３つで可能な再現は全て実装させる方向を目指す。 まぁ努力する・・・
バトスピ、ヴァンガ、バディ、デュエマなど発売済みゲームソフトが存在してるケースはベンダーに研究させる。
↓
各社TCGを再現するテストプレイ ⇒ 更に改良や修正。
↓
機能制限した下位版を５万円以上で発売 ＋ デュエリ－グ用に改造した上位版でサーバー稼動＝営業開始。
↑
下位版の改造および商用利用には、別途で当社との契約が必要。
さ～て、製作ベンダー見つけよっと！ｗｗ（ｸｽ
ｽﾚﾘﾝｸ(entrance2板:-18番)
154:デフォルトの名無しさん
15/12/04 12:21:13.29 GzeAUkqU.net
>>149
>free()から設計し直す、
>まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ
じゃ>>134は設計し直してから言うんだな。坊や。
って、事でオッケーね。
155:デフォルトの名無しさん
15/12/04 20:05:33.81 SAJ9n/s7.net
>>137これって何が言いたいの？OSやライブラリ自体にミスがあるって言いたいの？
wikiより
>メモリリーク (Memory leak) とは、プログラミングにおけるバグの一種。
>プログラムが確保したメモリの一部、または全部を解放するのを忘れ、確保したままになってしまうことを言う。
>プログラマによる単純なミスやプログラムの論理的欠陥によって発生することが多い。
>>137みたいなこと言う奴って、電磁波からデータが盗まれる！対応しないと！とか言い出すタイプ？
156:デフォルトの名無しさん
15/12/04 21:16:45.71 7W1HEY29.net
>>
157:151 そもそも１５年ぐらい前から延々繰り返されてるんだが…
158:デフォルトの名無しさん
15/12/04 23:45:19.53 j6MEWqDN.net
>>154
開放コードを忘れずに書いたのに開放されないという怪奇現象がマルチスレッド状況ではしばしばあるんじゃー！
マルチコア時代になってこれはますます危険になった
見ただけで正しさがわかる系のスレッド安全策はクロックサイクルを糞のごとく消費するし…
こういうのは専門家が徹底的にデバッグしたGCで面倒を見て欲しいと思う反面、
やっぱプロセス全体のごみ処理を選任モジュールにやらせるのはクロックサイクルをドブに捨てるがごとき
センス無い設計なｷﾓｽ、、
159:デフォルトの名無しさん
15/12/05 00:08:28.41 +HxrBEdK.net
それ単にメモリバリアの問題じゃ…
160:デフォルトの名無しさん
15/12/05 04:01:37.91 2vAbbe+i.net
>>154
入門書に書いてるコードしか見たことないんだね。
スレッドプールみたいなテクニックは高速化のためにみな普通に使うんだよ。
OSやライブラリにもメモリリークなんてよくあることだし、それらのバグも開放忘れて起きてるイージーなバグじゃないよ。
他のバグやトラブルがメモリリークという形で表面化してるにすぎない。
161:デフォルトの名無しさん
15/12/05 08:28:25.61 Pfi54LUx.net
>>158
具体的にいつのどのバージョンのライブラリで起きてるの？
使い終わったらメモリを開放しろ。使い終わってないなら開放する必要はない。これとスレッドプールとどこに関連性があるの？
162:デフォルトの名無しさん
15/12/05 09:45:44.55 P9ivIQ+p.net
>>159詰めても無意味。
こういう連中は、まず自分の考えややり方が絶対正しく絶対に曲げない。曲げないために無理やり理由を当てはめようとしている。
で、さもそれを自分はやってるように言っているが、実際は単に本に載ってることを言ってるだけ。
実装もできない。面前で詰めてやれば発狂して勝敗がハッキリつくけどネット上では無理だね。
163:デフォルトの名無しさん
15/12/05 09:48:00.71 BOwcKS4A.net
メモリの話とスレッドの話を混ぜ込んでしまうタイプは
問題の切り分けがそもそも出来ないタイプ
だからメモリリーク（）に悩まされる
スレッド間の協調と、メモリのケアは直交する別の話題
164:デフォルトの名無しさん
15/12/05 10:18:00.14 NRX1k+Is.net
>>158
ちょっ漏れが作ったわけでも漏れの使い方に問題があるわけでもない階層で起きるメモリリークの責任を漏れに負わされても困る…
それに他人が作ったモジュール内でのメモリリークも結局は開放が書かれていなかったか、書かれていても正しくなかったからリークしているはず…
>>161
全面同意だが同意したからと言ってメモリリークがゼロになるかっていうと以下略
単純にクリティカルセクションとかキューによるシリアライズ（Active Objectパターン）で排他して
マルチコアを活かさずパフォーマンスをドブに捨てて良ければ平和なんだが…
165:デフォルトの名無しさん
15/12/05 12:34:30.29 eGerJrSR.net
だからメモリを自動開放してほしいときはスマートポインタを使えばよいだろ
循環参照が無い限りshared_ptrで問題ないだろ
循環参照がある場合はどちらかをweak_ptrにすれば済む話だろ
現実にshared_ptrの様な物が存在して無いなら、そういう議論も意味があるが
実際にはshared_ptrは現実に有るのだから、自動管理したい場合は使えばよいだけの話でしかない
166:デフォルトの名無しさん
15/12/05 12:38:09.16 eGerJrSR.net
むしろ議論すべきはshared_ptrのような参照カウンタ方式のスマポと
言語ビルドインのマークスイープ系のGCとで
どちらが良いか、だろう
参照カウンタ方式は循環参照で問題を起こすし
マークスイープ系のGCはいつ実行されるか分からない
167:デフォルトの名無しさん
15/12/05 13:11:12.91 eGerJrSR.net
つまり、完璧なGCは無いということだ
完璧なGCが無い以上、使う側が状況に合わせて選べた方が良いわけだが
そうなるとC++/CLIのような変体言語しかないのが残念だ
168:デフォルトの名無しさん
15/12/05 13:42:35.29 FurPG6R/.net
普通に言語を選べば良いだけの話では
169:デフォルトの名無しさん
15/12/05 13:49:45.99 Pfi54LUx.net
このスレ論点が一致してないよね。
freeやdeleteを記述すべきという論点で話をしている人
freeやdeleteしたところでメモリが解放されてるわけではないですがという論点の人
freeやdeleteは当然、さらにnull等を記述すべきという論点で話をしている人
GCの実装そのものを論点にしている人
論点がばらっばらだから咬み合わない
170:デフォルトの名無しさん
15/12/05 13:58:32.14 wharPYQR.net
>>158
> OSやライブラリにもメモリリークなんてよくあることだし
よくあると言うなら１０個ぐらいすぐにあげられるよな
もちろん最新版でリークする奴ね
171:デフォルトの名無しさん
15/12/05 14:16:25.84 2vAbbe+i.net
MSのサイトにfix分と調査中のものが全部公開されてる。他のOSもlog、mlみれば腐るほど出てくる。
10個上げろとか、ほんと幼稚園児かよ、おまえらは。頭悪すぎw
172:デフォルトの名無しさん
15/12/05 14:33:31.47 9PUwCRa0.net
C++でRAIIを徹底しておくのが一番いいよ
解放タイミングのコントロールが必要になったら後からでも柔軟に対応できるし
GCは解放に係る少し変わった条件が発生した時に滅茶汚いことをしなきゃならなくなる
173:デフォルトの名無しさん
15/12/05 14:36:53.80 NRX1k+Is.net
shareed_ptrはC++で比較的効率よくやれることと、GCしたい人が真にやりたいことの妥協の産物であって
どんなシチュでもベストにフィットするような一押しの決定版ってほどでも無い…
参照カウンタの排他が不要で循環参照が無いことも保証できるまで設計が詰められているなら
スレッドごとに、メモリを確保して使って返す処理を直に書くのが一番良い
174:デフォルトの名無しさん
15/12/05 14:43:55.34 9PUwCRa0.net
確保／解放を直に書くのはスピード的には一番速いだろうけど解放漏れバグの温床過ぎてネ
特に例外が絡むとやってられない状況になる
175:デフォルトの名無しさん
15/12/05 14:45:23.69 +HxrBEdK.net
>>167
null云々は別言語だ馬鹿
176:デフォルトの名無しさん
15/12/05 14:47:17.08 wharPYQR.net
>>169
> もちろん最新版でリークする奴ね
早くあげてよね w
177:デフォルトの名無しさん
15/12/05 14:52:20.59 NRX1k+Is.net
>>172
>特に例外が絡むとやってられない状況になる
そこだけはstd::unique_ptr<T>の一押し
これで例外状況でのRAIIが完成するので真にGCが要らんところまで逝く
ていうか大概のアプリなら、例外を生じたらFatal errorなことをユーザーに知らせて終了、でいいんじゃ…
178:デフォルトの名無しさん
15/12/05 14:59:01.89 9PUwCRa0.net
>>175
いやーリソース獲得した状態でファイルI/Oとかネットワークとかが絡む場合は終了じゃすまん場合が多いでしょ
179:デフォルトの名無しさん
15/12/05 15:06:58.28 MOG2PmhH.net
昔C言語で数珠繋ぎの独自スコープとしてblock_enter/block_leaveというのを作って
{
block_handle h = block_enter(b)
object = block_create_object(h)
block_leave(h)
}
180:デフォルトの名無しさん
15/12/05 15:10:52.59 MOG2PmhH.net
書き損じた
昔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)で全開放とかそんなの
181:デフォルトの名無しさん
15/12/05 15:15:45.24 MOG2PmhH.net
デメリットはblock_create～で作成するものは全部ヒープに確保されること
結局C言語でここまで必要な案件てのが回ってこなくてあんま使ってないけどリーク予防法の参考程度に
182:デフォルトの名無しさん
15/12/05 15:24:40.86 4CEShJeO.net
例外にも対応って？
183:デフォルトの名無しさん
15/12/05 15:29:31.41 K
184:dBqlpoa.net
185:デフォルトの名無しさん
15/12/05 15:30:53.84 MOG2PmhH.net
>>180
例外つってるのは具体的にはSEHの話
どっかで止めた時点のblock_leave(b, h)でそれまでの開放が保証されるってこと
186:デフォルトの名無しさん
15/12/05 15:39:23.63 eGerJrSR.net
C++にfinallyが無いのが気に食わない
今はラムダが有るのでマクロでそれっぽいものを自作したが
標準で用意しておいてほしい
C++はリソースを自分で管理する傾向のある言語なのに
finallyが無いのは本来おかしいよな
ラッパー作ってRAIIを徹底しろってことなんだろうけど
すべてのリソースに対してラッパーを用意するのは面倒だよ
fainallyが有ったって邪魔になるわけでもないのに
最終的に使うかどうかは利用者が選べばよいことだし
C++ってそういう言語だろ
187:デフォルトの名無しさん
15/12/05 15:50:01.56 9PUwCRa0.net
>>183
C++にはテンプレートがあるからリソースの型をテンプレート引数とするラッパーを作るのは
そんなに面倒なことじゃないと思う
あとC++でRAIIを徹底してればfainallyの必要性を感じたことはない
fainallyを書かなければいけない時点で危なっかしいコードだと思う
188:デフォルトの名無しさん
15/12/05 16:34:34.82 +HxrBEdK.net
むしろfinallyってデストラクタがない言語だから
必要なものなんじゃ…
どうしても必要ならデストラクタで任意のラムダ呼ぶ
ユーティリティクラス作れば同じこと出来るし
189:デフォルトの名無しさん
15/12/05 16:50:13.74 +HxrBEdK.net
98以前でもローカルクラス定義できるんだからすこし冗長なだけで同じだし
190:デフォルトの名無しさん
15/12/05 16:59:06.52 NRX1k+Is.net
例外発生はバグ、というプログラミングしかしたことないからよくは知らんが、
try {
try {
/*...*/
} catch (std::badalloc()) {
/*...*/
} catch (UserException e) {
/*...*/
}
} catch (...) { // fainally節の代わり
/*...*/
}
じゃあいかんの？実行時コストは知らん
191:デフォルトの名無しさん
15/12/05 17:00:08.66 NRX1k+Is.net
ｽﾏﾝ
誤： } catch (std::badalloc()) {
正： } catch (std::badalloc e) {
192:デフォルトの名無しさん
15/12/05 17:32:52.06 +HxrBEdK.net
違う。そんぐらいググれ
193:デフォルトの名無しさん
15/12/05 17:37:26.87 KdBqlpoa.net
デストラクタの問題点は不可視なところだな
usingやfinallyは目に見えるから安心する
194:デフォルトの名無しさん
15/12/05 18:00:14.20 NRX1k+Is.net
>>189
内側のtry～catchから再throwするのを忘れたorz
内側のtry～catchから再throwして外側ので再捕捉したらいいんじゃ…
195:デフォルトの名無しさん
15/12/05 18:22:16.37 0v99S3Ys.net
例外をロジックとして使うなってばっちゃんが言ってた
196:デフォルトの名無しさん
15/12/05 19:38:41.80 eGerJrSR.net
>>191
throwせずにreturnするパスが有ったらどうするんだよ
そういうのを防ぐためのfinallyやRAIIなのに
まったくちんぷんかんぷん
結局returnする前に手動で忘れないようにthrowすることを強制するんなら
goto文とか開放用ラムダ呼び出すのとかと替わらないだろ
197:デフォルトの名無しさん
15/12/05 20:44:27.97 ZNw2R9x1.net
だから忘れる忘れないレベルをぶち込んでくるのは止めようやｗ
これをぶち込むから全ての議論が池沼レベルになってる
198:デフォルトの名無しさん
15/12/06 06:02:02.37 JYyEEHci.net
異常系で例外返す仕様のライブラリが失敗。
199:デフォルトの名無しさん
15/12/06 08:06:42.75 XhferEg+.net
>>194
GCなんて池沼のために生まれたようなものだし・・・
NULLったりfreeったりすることすらまともに把握、指示しきれない
200:デフォルトの名無しさん
15/12/06 11:36:02.06 G3VNQyn5.net
c++のデストラクタって後処理に失敗しても
例外投げられないからウンコ
結果的にエラーを握り潰すゴミコードを量産する原因になってる
201:デフォルトの名無しさん
15/12/06 11:40:47.08 zGnP2wpv.net
そのクラスが管理してる範囲で後処理の失敗って何が起こるの？
202:デフォルトの名無しさん
15/12/06 12:05:41.69 kVHO13oj.net
どうしてもやりたいなら対処法はあるしなぁ。
203:デフォルトの名無しさん
15/12/06 12:23:19.67 MkaxAbH2.net
現実的な確率で発生して無視出来ないリスクが有る解放処理はデストラクタでやるべきじゃない
そういうリソースに対してデストラクタがやる事はプログラマに対しいて未解放のリソースを通知する事だけでよい
204:デフォルトの名無しさん
15/12/06 12:30:12.96 XhferEg+.net
具体的に何があるん？？？
クラス内で使っているリソースで解放に失敗（失敗し続ける）するって。
205:デフォルトの名無しさん
15/12/06 13:14:17.95 lk97yytv.net
どっか他のオブジェクトと共有してるものを解放しようとして失敗するとか？
それはそもそもの設計に問題ありすぎだが。。
206:デフォルトの名無しさん
15/12/06 15:01:28.77 XhferEg+.net
>>202
だよね。
否定しようとして無理やり現象を創りだそうとしているとしか・・・。
でもその無理やりつくった現象は、そもそも論理設計のミスが大前提だったりする。
論理設計のミスまで言われたらなんにも組めないわ。
207:デフォルトの名無しさん
15/12/06 15:42:32.97 wxELMJDc.net
>>200
デストラクタの中で起きた例外については
try { } catch (...) { }で囲った上で、リカバリ処理（何とかしてリソース解法漏れをなくす）を行えばいいじゃない？
もし例外発生後に行うべき適切なリカバリ処理が書けない（存在しない）んだとすると、
もはやデストラクタ内に限った話ではなくなって、例外を発生させた時点で設計か実装にバグが居たとしか…
208:デフォルトの名無しさん
15/12/06 16:03:58.23 5cQQ9Lrm.net
バグ（リソースへのポインタやハンドルを壊しちゃったとか）以外で
リソース解放に失敗するケースなんて１つも思いつかない
209: ◆QZaw55cn4c
15/12/06 16:19:39.63 4bjdt2kC.net
fclose() にも失敗があるじゃないか？
210:デフォルトの名無しさん
15/12/06 16:54:30.29 djRjUyAt.net
fflush() しとけばＯＫ
211:デフォルトの名無しさん
15/12/06 16:59:21.77 5cQQ9Lrm.net
>>206
fcloseの失敗はハンドルが正しい限りflush時のI/Oエラーの通知であって、その場合でもリソースは解放されるよ
212:デフォルトの名無しさん
15/12/06 17:35:51.31 G3VNQyn5.net
c++信者ってアホだなー
みんなこんなんなの？
URLﾘﾝｸ(cpplover.blogspot.jp)
213:デフォルトの名無しさん
15/12/06 17:44:16.50 G3VNQyn5.net
fcloseに失敗してファイルに正常に書き込みされなくてもシカトしてるんだよね？
それともerrnoとかチェックしちゃってるの？
214:デフォルトの名無しさん
15/12/06 19:05:12.47 RyqEmv/A.net
まあC++の例外を援護するつもりはないがそういう場合は
普通にフラッシュしろよ
そもそもC++が二重例外時にstd::terminate呼ぶのはGCのあるなしに
関係ないからスレ違いだお前ら。よそでやれ
215:デフォルトの名無しさん
15/12/06 19:24:21.60 XJADMoL5.net
GCというよりライブラリとの関係だな
.net framework libraryのいくつかのクラスは中で自分自身をロックするから
プログラマ側で参照が切れてもGCされない
216:デフォルトの名無しさん
15/12/06 19:25:02.74 XJADMoL5.net
今日一日なんでFormがGCされないのか調べてて大変な思いしたわ
217:デフォルトの名無しさん
15/12/06 19:31:56.53 bkfT5adp.net
>>213
よくそこまで調べたな。( ・∀・)つ旦 お茶ﾄﾞｿﾞｰ
218:デフォルトの名無しさん
15/12/06 19:37:02.30 Gxx7TgqC.net
いまだにプログラマはアセンブリ言語を使えるべきだ派？
219:デフォルトの名無しさん
15/12/06 19:40:49.58 JYyEEHci.net
アセンブラ知ってると知らないとじゃスキルレベル全然違うからな。話にならないぐらいのレベル差
220:。
221:デフォルトの名無しさん
15/12/06 20:22:00.43 RyqEmv/A.net
まあ実際Java屋とかってコンパイラやメモリ意識できない奴多いよね
以前2chで↓みたいなコードが勝手に最適化されると思って
StringBuilder使う奴は馬鹿！とか言い出す奴いて目眩したわ
String s;
for(int i = 0; i < strarray.length; ++i){ s += strarray[i]; }
222:デフォルトの名無しさん
15/12/06 20:58:14.61 wxELMJDc.net
>>217
それはStringの+=の実装次第ではあんまり差が付かないケースなんじゃ…
（左辺と右辺が別の実体である（アドレスが違う）ケースでは多分右辺を左辺の末尾に1回コピーするだけという実装が有り得る
真に糞なのは
StringBuilder sb;
String s = "Hello";
sb.Append("[" + s + "]");
が遅いからStringBuilderは糞、と結論付けるニンゲンであってコードではない、
みたいな？
223:デフォルトの名無しさん
15/12/06 21:26:17.35 IAFYzi6n.net
>>217みたいにループ中で一個づつくっつける場合は別にして
s = a + b + c + d; // このように、高々数個をくっつけてる場合は
Javaだと無駄にStringBufferが作られてダメと言うのが定説だったが
C#の場合は内部的にString#Concatに置き換えられて
それによって
StringBuilder b = 略
s = a.Append(b)中略.Append(d).ToString()
するより早い、という話題があってそれと勘違いしたのかもね
224:デフォルトの名無しさん
15/12/06 21:28:20.04 IAFYzi6n.net
いちおう訂正しとこｗ
StringBuilder sb = 略
s = sb.Append(a)中略.Append(d).ToString()
225:デフォルトの名無しさん
15/12/06 21:50:20.98 MkaxAbH2.net
そもそもその最適化は仕様なのか
226:デフォルトの名無しさん
15/12/06 22:27:08.91 RyqEmv/A.net
>>218
？？、これJavaだぞ。演算子オーバーロードなんて出来ないから
>>219
違う違う。+の連結がStringじゃなくてStringBufferに
最適化されるらしいって話だけで、StringBulderって
必要ないでしょ？レガプロ？(笑)、って認識レベル
しかもそいつ一人ならまだしもスレに同じレベルの
認識の奴結構多かったよ。レベルの低さ舐めたらあかんで
227:デフォルトの名無しさん
15/12/07 01:50:02.58 3Z+aJEnB.net
>>222
実装云々でなんで演算子オーバーロードがでてくるんだ？
228:デフォルトの名無しさん
15/12/07 05:22:13.32 QznWTKRS.net
逆だろ？
C#との勘違いでないなら、その最適化されるJVM実装とやらを示さないと
229:デフォルトの名無しさん
15/12/07 07:11:57.22 X5Y+ON7N.net
>>219
全く逆の認識してないか？
classファイル解析したら分かるけど、ループ中の+=の方が問題で毎回newされるから遅い
s = a + b + c + d の方は一つしかStringBuilderのインスタンスは作られない
230:デフォルトの名無しさん
15/12/07 08:02:18.14 nEG5/lEo.net
こうやって、比較的プログラミングという行為を好きでいる・好きでやっている・興味を持っているという人ですらまともに言語仕様を理解出来ていない。
malloc、freeで管理、GCで管理だと、機構の複雑さは後者。
結局GCもその機構を正しく理解しないと参照が切れてない、参照が切れていても別のリソースが・・・と。
機構を正しく理解していることが前提なら、機構はシンプルなほうがいい。
その点を誤ったから
>プログラマをメモリ管理から開放する！
>といいつつ、メモリリーク問題の文献が大量にある。
>これすなわち、メモリリーク問題が全然解決していないということ。
>さらに、メモリ解放のタイミングの文献まで大量に生み出した。
>これすなわち、新たなるメモリ管理に関する問題を生み出したということ。
なんてことになったんだろうね
231:デフォルトの名無しさん
15/12/07 08:12:44.70 EA
232:/TwAsy.net
233:デフォルトの名無しさん
15/12/07 09:22:45.43 q5G1dKJA.net
やっぱりARC最強だな
234:デフォルトの名無しさん
15/12/07 15:38:30.00 6rSJBSiX.net
結局いつ開放されるか分からないってのが曲者で
使い終わったら確実にリソースを開放してほしいときは
別の仕組みが必要になってしまったってのが問題だろう
その別の仕組も、C++のデストラクタのようにクラスのメンバに関して
芋づる式に呼び出す仕組みがないから
C++のデストラクタがやっていることを手動で再現しなければならない始末
一方でC++のスマポなどの参照カウンタ方式は循環参照だけが問題だが
それ以外の問題が一切発生しない、デメリットは循環参照だけ
しかも循環参照が発生する場合は片方をweak_ptrにすれば良い
ということが分かりきっているし、循環参照が発生する箇所も
設計段階でわかる
循環参照に気を配れる知能が有るのであれば、参照カウンタ方式のほうがスマート
235:デフォルトの名無しさん
15/12/07 17:29:26.60 nEG5/lEo.net
>>229
処理速度やタイミングがシビアな組み込みや科学技術計算系とかならいざしらず、
ソレ以外は、実際の解放のタイミング自体は問題にならんでしょ。(膨大なメモリの使用も別だけど)
問題は、使い終わったよーって明示しないで良い。という運用が結局、悪い結果をもたらしているという点。
メモリの管理をしっかり最後までやるクセのないプログラマは、
平然と参照が途切れている可能性のあるポイントで参照しに行こうとする。
結局は、そいつがバカだからに集約されてしまうんだけど、使い終わりの明示をしない文化がバカを生む土壌となっている
236:デフォルトの名無しさん
15/12/07 18:21:02.44 q5G1dKJA.net
そういう事になる原因ってさ、構造がぐちゃぐちゃでオブジェクト間も依存しまくって、
いつ解放していいのかわかんねえーというヘボいプログラミングなんだろうなと思う。
237:デフォルトの名無しさん
15/12/07 18:23:12.12 tBfENkIS.net
と馬鹿なSEやPGはそう思うだろうなとも思う。
238:デフォルトの名無しさん
15/12/07 19:54:31.23 GogXEvJk.net
ある意味メモリなんて一番扱いやすいリソースだからな。
メモリの管理すら適当なプログラマが、他のリソースを適切に扱える訳がないのに、GC前提の言語ではそちらのケアが言語側でやりづらくなってしまっている。
239:デフォルトの名無しさん
15/12/07 20:05:22.53 W4QZalq7.net
メモリ意識した時点で雑魚プログラマ決定だろ。
JavaScriptもPascalも使えないんじゃ話にならないよ。
おちんぽ見られることを意識しすぎて温泉に入れないようなもの。
癒やしのない人生に刺激なんてない。←これ名言
240:デフォルトの名無しさん
15/12/07 20:07:43.02 nEG5/lEo.net
>>231
そう。そういう状態にしちゃう原因が、いい加減なメモリの管理で教育された結果にあるのではないか？ということで。
241:デフォルトの名無しさん
15/12/07 20:09:47.14 nEG5/lEo.net
>>234
だれの名言かしらんが、
刺激のない人生に癒やしはない。
ならなんかしっくりくる。まぁ逆とっても同じ意味だからいいんだけど・・・。
242:デフォルトの名無しさん
15/12/07 20:16:31.05 ZNsl6+sP.net
メモリ意識しないプログラマとかカスだろ。
243:デフォルトの名無しさん
15/12/07 20:42:25.43 wP/KA6jo.net
JavaやC#ではリソースをプログラマが管理してはいけない
せっかくメモリ管理を透過的にしたのにリソース管理でコードをより複雑化させては意味がない
真っ当な教育を受けた少数のプログラマがSafeHandleを作成する
末端のプログラマはSafeHandleのファイナライザに全てを任せてメモリと同様にリソースを完全に透過的に扱うべきだ
244:デフォルトの名無しさん
15/12/07 23:25:36.31 QznWTKRS.net
>>230
JavaのGCでサーバー応答が止まるなんてザラにある話だよ
それを聞いたことがないなら文系SEと同レベルだね
>>238
管理放棄して開くだけ開いて計算資源を食い潰す玄人気取りプログラマ
245:デフォルトの名無しさん
15/12/08 00:48:22.00 pyjW8EMu.net
full GCが頻繁に生じちゃうのは明らかに設計ミスやな
immutableな短命objectを使いまくるのだ。。
つかimmutableなオブジェクト使いまくるとGCないときつくね？
246:デフォルトの名無しさん
15/12/08 02:05:45.39 H3TgUaFB.net
RAIIで事足りる
immutableかどうかとＧＣは無関係
247:デフォルトの名無しさん
15/12/08 02:21:53.95 RVFMry3L.net
むしろ短命なオブジェクトなんてスタックで十分だし
管理するならshared_ptrのが優れてる
248:デフォルトの名無しさん
15/12/08 03:41:28.67 pU1qoPPC.net
ライブラリ、アプリ、ユーザの三者で考えないと
一部リソースはユーザがを閉じることができる。
そのときアプリの参照を消す仕組みがどのライブラリにもない
249:デフォルトの名無しさん
15/12/08 08:07:46.77 rWJ9nJMw.net
>>243
よくわからんが、それは階層的におかしいのでは？
ユーザーがアプリを通さずにリソースを閉じる事ができるって事？
250:デフォルトの名無しさん
15/12/08 12:16:07.11 VV6tYNBF.net
Manager.Execute((res) => ...);
これが終着点
短命なリソースは全てこの形式で事足りし長命なリソースはファイナライザにでも任せればよい
ユーザーが管理しちゃ絶対にダメ
251:デフォルトの名無しさん
15/12/08 15:11:36.25 DYNM3xm/.net
このスレでGCいらんて言ってる人たちは環境に恵まれてるんだなぁって思う
252:デフォルトの名無しさん
15/12/08 15:20:06.88 Bkt0caBE.net
GC
タモリが昔宣伝してやつ？
253:デフォルトの名無しさん
15/12/08 15:28:54.90 NMHe7TFl.net
むしろGCなんて環境良くないと使えないだろ
254:デフォルトの名無しさん
15/12/08 16:16:30.38 zjJIjn6V.net
参照がなくなったタイミングで必ず開放してくれて
かつ
循環参照でも問題ない
パーフェクトなGCが有れば最高なわけだが
実際にはそんなGCは無い
となれば、通常であれば言語側は性質の異なる複数のGCを用意しておいて
使う側はシチュエーションに合わせて選べるようにしておくのが自然な発想
しかしそういう言語は殆ど無い、これが問題
といってもマークスイープ系GCが前提のC#やJavaのような言語に
RAIIの発想を持ち込もうとしても
C++のデストラクタのように自身のメンバのデストラクタを自動で芋づる式に呼び出す仕組みが
元々無いので、手動で芋づる式に解放関数を呼び出すコードを書かなければならなく
うまく行っていない
255:デフォルトの名無しさん
15/12/08 16:25:08.60 RVFMry3L.net
>>246
JavaでPhantomReferenceも使ったこと無い人って恵まれてるんだなあって思う
>>249
無いのでってもろにAutoCloseableとかあるやん
256:デフォルトの名無しさん
15/12/08 16:37:24.80 zjJIjn6V.net
>>250
自分のクラスがファイルなんかのcloseを持つリソースをメンバに持っていたとする
そうすると、それらのメンバのリソースを明示的にcloseできるようにするために
自身もcloseを実装することになるだろう
それで、自身のcloseが呼ばれた時、勝手にメンバのcloseが呼ばれるか？
結局手動でメンバのcloseを呼び出しまわるコードを書かなければならない
C++のデストラクタならメンバのデストラクタが芋づる式に勝手に呼び出されるから
気にしなくて良い
257:デフォルトの名無しさん
15/12/08 17:08:50.17 NMHe7TFl.net
強参照、ソフト参照、弱参照、ファントム参照
この字面だけで糞言語って察せられるから凄い
258:デフォルトの名無しさん
15/12/08 19:22:21.31 RKxPG6yJ.net
Rustはどう？
明文化されたmoveセマンティクスと、オブジェクトの寿命と参照のチェッカを型システムに組み込んでるおかげで、
リソース管理の実行時コストをゼロにしつつ、メモリリークが発生しないプログラムが書ける。
shared_ptrに相当するRcもあるから、所有者を複数にしたい場合のコストもそれなりに抑えられる。
259:デフォルトの名無しさん
15/12/08 19:35:14.32 Hrv9Cion.net
>>253
すげえ難しいらしいじゃん
260:デフォルトの名無しさん
15/12/08 19:52:40.51 NMHe7TFl.net
rustの清貧さは好みだけどまだ触った事ないな
同期処理を省略するためかshared_ptr相当がタスク間跨げないらしいけど
そこら辺の使い勝手ってどうなんだろう
261:デフォルトの名無しさん
15/12/08 21:00:06.21 RKxPG6yJ.net
>>254 難しいのは難しいが、低レベルの世界に相応な難易度であって、理不尽さはあまり無いと思う。
自分が遭遇した理不尽というか不便は、トレイト(型クラスみたいなの)を戻り値にした、ジェネリックな関数の型注釈の煩雑さで、
そのworkaroundが、その関数の返り値専用の型を定義する、ってのがカルチャーショックだった。
URLﾘﾝｸ(doc.rust-lang.org)
↑はIteratorトレイト(Listインターフェイスみたいなもの)のドキュメントだけど、mapとかfoldとかよくある高階関数の戻り値が、それ専用の型(MapとかFold)になってる。
だから、よくある関数型言語のイメージで、何か高階関数を利用したアダプタ関数を試しに定義してみよう！ってやると、
型注釈のエラー、ライフタイムのエラー等が一辺に出てきてわけが分からなくなる。
その関数の戻り値専用の型、なんて贅沢に見えるけど、返り値のサイズを見る限り、余計なデータで膨れているわけでもなかった。
Cでstruct wrap_int { int c; };とやったときにsizeof(wrap_int)がsizeof(int)と等しいけど、それと同じことをやっていた。
型情報なんてコンパイル時に全部消えちゃうから、実行コストも無いんじゃないかと今では思う。
メモリ/リソースの所有権を意識してコードを書くこと、が身について面白いよ。
ヒープを贅沢に使ってコピーしまくりなコードを書くと汚いし遅いしなんで、ちょっとダイエットする気分も出てくる。
262:デフォルトの名無しさん
15/12/08 22:39:35.60 RVFMry3L.net
>>251
C++もヒープ相手は自分で呼ぶので、実装は必要だよ
Javaでもメンバの特定メソッド呼び出しはやろうと思えばできる
現実に横断的な呼び出しをやる場合はある
結局要求される物と実装の問題
263:デフォルトの名無しさん
15/12/08 22:59:22.32 RKxPG6yJ.net
>>255 shared_ptrと恒等なものは無いけど、ポインタ的に使える型がBox, Rc, Cell(あるいはRefCell)とあって、
Boxはヒープ領域であること、Rcは複数の所有者がいる(つまり所有者全員が死ぬまでは生きている)こと、Cellは複数の書き込みが作れること、
とか機能とコストが別れているから、これらを組み合わせて使う。
で、Thread Safetyを実現させる機構は上記には無いので、Atomicityを導入させるRcの類似形であるArcと、
書き込みもしたいならMutexっていう型も合わせて使う。
すると、例えば整数のベクトルをスレッド間で共有したい、とかになるとArc<Mutex<Vec<i32>>>という目が滑るような型表記をすることになる。
あんま詳しくないので、ケース毎にもっと簡単なやり方があるとは思うんだけどね。
264:デフォルトの名無しさん
15/12/08 23:55:28.64 NMHe7TFl.net
>>258
ああ、Arcってのが別にいるのね。納得
個人的にもう一点気になる所があるから聞いてしまう
BoxやDropを使ってるとコピー禁止になるらしいけど
これ面倒な場合ない？
最初はコピー可能な型としてガンガンコピーしてたけど
途中から終了処理を書きたくなったらコピーしてる箇所
全部直すって事？
ちなみにググってたらRWArcっての見つけたんだけど
これ読み書き可能なArcなんじゃね
265:デフォルトの名無しさん
15/12/09 00:46:02.26 WVnNYSfg.net
>>249
javaは世代別管理でGCの種類は色々選べるはずでは
266:デフォルトの名無しさん
15/12/09 01:14:15.85 wAGGTtTq.net
>>260
起動時に切り替えられるだけであって
オブジェクトごとには切り替えられないのでは
267:デフォルトの名無しさん
15/12/09 01:50:08.36 x/ryIvcR.net
>>259 コピーしまくっているような変数の型をTからBox<T>に変えた場合、確かに面倒なことになる。
けど、基本的に単純な代入(let x = y)はコピーじゃなくてmoveになるし、
Box<T>の値をコピーしてBox<T>の値を生成するっていうのは、同じヒープ領域を指すポインタを作るんじゃなく、
新しいヒープ領域を確保して中身をコピーし、そのポインタを返すという意味なんで、
変数の型を後でTをBox<T>に変える、という場面はあまり無い(少なくとも自分は学んでいる最中にそういうことをしたくなったことがない)
値をコピーする場面では、元の変数の型がBox<T>であってもTであっても、参照型&Tを受け取ってTを生成、ということをするのが定石。
&Tはほぼ無制限に安全に作ることができるし、安全じゃない可能性があったらコンパイルが通らない。
で、コピーした型Tの値は呼び出し元がBoxに包んでヒープ領域に置いたりするのが定石
Dropも別にコピーを禁止することは無いよ。後からつけたらエラーまみれ、ということにはならない。
あと、自作じゃない型に自作じゃないトレイト(インターフェイスみたいなもの)をつけることができないので、
例えば標準ライブラリのFileやTcpStreamはCopyできるようには決してできない。メモリ以外の資源管理も安全だよ。
268:デフォルトの名無しさん
15/12/12 10:36:13.53 mXWFWn5f.net
freeし忘れるとか、そんな超ウルトラ素人ミスを大前提に議論するのは間違いだよなｗ
freeしきれないとかｗｗｗｗ
269:デフォルトの名無しさん
15/12/12 11:52:29.69 v/VbuB+R.net
>>263
規模が大きくなれば管理が難しくなるのは普通のことだよ。
ライフサイクルはオブジェクトごとに異なるものだし、
人間に頼らずにGCにメモリ管理を任せるっていうのは良いやり方だよ。
270:デフォルトの名無しさん
15/12/12 12:05:07.06 yfUf7LLZ.net
shared_ptrって参照カウント式のGCじゃないの？
271:デフォルトの名無しさん
15/12/12 12:44:09.71 7G0ybzbE.net
循環を綺麗に扱えるなら参照カウントの方が良いと思うけど
VB6は循環参照の扱いどうやってるんだろう
272:デフォルトの名無しさん
15/12/12 14:25:51.97 npRd3MLZ.net
>>265
RAIIじゃろ
273:デフォルトの名無しさん
15/12/12 15:20:38.55 tVgJgcBS.net
>>265
GCの一種だけど、文脈的にはプログラマが
管理が非局所的で明確な型宣言もなしに使えるのをGCと言ってるわけで
議論で揚げ足にしかならない野暮な突っ込みはやめようぜ
274:名無しさん＠そうだ選挙に行こう
15/12/14 08:16:09.53 hn3965Zz.net
>>264
いや、下手って一言で片付けられるよ。
よっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっぽど、出ない限り
275:名無しさん＠そうだ選挙に行こう
15/12/14 08:38:44.84 sXTPVO5Q.net
片付ける奴が馬鹿なのだ。素人ほど簡単だと言いたがり、上級者ほど簡単ではないとはっきり言うものだ。
どの分野でもな。
276:名無しさん＠そうだ選挙に行こう
15/12/14 09:09:02.89 lNUL9lX8.net
freeとか言ってる奴はC++使えよ。いつまでＣ使ってんだ。
277:名無しさん＠そうだ選挙に行こう
15/12/14 09:20:53.11 MauTQhQ/.net
>>270
東大生が人に教えるとき、何がわからないのかわからないというのがわからない。
上級者になればなるほど自分がやってることなんて簡単に見えてくる
278:名無しさん＠そうだ選挙に行こう
15/12/14 09:35:23.70 sXTPVO5Q.net
>>272
何が分らないか分らない、つまり東大生も生徒がどういう思考をしてるか分析できず分らないと言ってるのだ。
低学歴ほど、分らないのはおまえが馬鹿だからと簡単に片付けるものだ。
279:名無しさん＠そうだ選挙に行こう
15/12/14 09:37:05.77 eBJzgHzn.net
それ中級者
あと、東大生は教えるの上手いのもいるから想像で話すな馬鹿
280:名無しさん＠そうだ選挙に行こう
15/12/14 09:41:37.74 sXTPVO5Q.net
このようにおまえのようなコンテキストすらまともに読めないPGは五万といる。
スレッドがデッドロックしてメモリを開放できないなんてよくあることだ。
281:名無しさん＠そうだ選挙に行こう
15/12/14 10:59:16.82 hn3965Zz.net
>>275
。。。。。完全な設計ミスじゃん
282:名無しさん＠そうだ選挙に行こう
15/12/14 11:15:19.23 eBJzgHzn.net
>>275
俺は272に向けてたんだが
そりゃコンテキスト読めてないように見えるよなw
283:名無しさん＠そうだ選挙に行こう
15/12/14 11:40:27.14 ETDpPCfc.net
スレッドがデッドロックしたらメモリリークどころじゃないじゃないかwww
284:名無しさん＠そうだ選挙に行こう
15/12/14 14:48:51.74 MOnxQz3f.net
スレッドがデッドロックしちゃってメモリ解放できない（泣）
っていうPGが五万といるのかよｗ
285:名無しさん＠そうだ選挙に行こう
15/12/14 15:51:19.55 hn3965Zz.net
まぁfreeやdeleteやnullやらすらできないPGに、「僕はそんなこと管理しきれる脳みそ持ってない！」って言われたらソレは真実なんだろうけど・・・。
そんな脳みそPGに「もっと複雑な業務使用」を理解できるとは思えないんだ。
そんなPGにプログラミングの場を与えるのが間違い。
286:名無しさん＠そうだ選挙に行こう
15/12/14 15:58:21.86 2JSVZtRY.net
そもそも実務でスレッド使うＰＧなんてゴマンもいない
287:名無しさん＠そうだ選挙に行こう
15/12/14 17:06:58.52 eBJzgHzn.net
Javaのプロジェクトだとほぼ使ってるけどな隠蔽してるだけで
そのせいで共有リソース壊したり、逆に個人情報の領域が共有されたりして、とんでもないインシデントが発生する
そんな奴等にメモリ管理なんて任せられんし、共有リソースも触らせたくないから
更に隠蔽したフレームワークもどきが出来上がる
288:名無しさん＠そうだ選挙に行こう
15/12/14 17:59:33.07 hn3965Zz.net
>>282
勝手に使うな。勝手にトリッキーコードにすんな。
素直に、設計書通りに作れ。
勝手なことやって勝手に自爆してるだけじゃねーか。
289:名無しさん＠そうだ選挙に行こう
15/12/14 18:15:27.90 Z4FycFda.net
javaってc++のconst参照に対応するものが無いのに、素人みたいなプログラマを大量にかき集めているのが怖すぎる。
290:名無しさん＠そうだ選挙に行こう
15/12/14 18:28:13.63 eBJzgHzn.net
>>283
理解してないのに無理してレスしなくていいから
291:名無しさん＠そうだ選挙に行こう
15/12/14 18:42:08.38 CJqGCki1.net
C#はマルチスレッド使いまくりだけど事故の話はあまり聞かないな
マイクロソフトが優秀なのか低品質プログラマがいないのか
292:名無しさん＠そうだ選挙に行こう
15/12/14 19:01:59.11 2+GDL4RD.net
JAVA自体がDQN
293:uy ◆Qawu9.2l1E
15/12/14 20:57:26.55 J5PYIleC.net
Freeし忘れ
↑これ。
ソースコード書いてる人間の注意力次第でバグが入るなら
言語も設計も間違ってるよ
294:デフォルトの名無しさん
15/12/14 21:54:10.80 ETDpPCfc.net
動的型言語
↑
これ
コード書いている人間の注意力次第でtypoするだけで
実行するまでわからないバグが入るなら
言語も設計も間違ってるよ
295:デフォルトの名無しさん
15/12/14 22:23:00.81 lNUL9lX8.net
C#でcatchやfinally書くの嫌すぎる
C++に戻りたい
296:デフォルトの名無しさん
15/12/14 22:43:08.79 bhzmg0NL.net
>>290
おかえり
297:デフォルトの名無しさん
15/12/15 06:39:51.52 gQhFMQgY.net
(ヽ´ω`)眠い
298:デフォルトの名無しさん
15/12/16 08:46:15.45 fgV80IeN.net
>>290
C++/CLR「こっちこいよ」
299:デフォルトの名無しさん
15/12/17 17:18:40.36 Szn4FINI.net
COMのVariantとかJSとかリークしまくりだし
300:デフォルトの名無しさん
15/12/17 23:16:36.40 kltDf5Nv.net
そういやVBScriptって参照カウンタ以外のGC積んでんのあれ
必要には見えないんだけど
301:デフォルトの名無しさん
15/12/18 23:17:49.50 b1Otx84Y.net
プログラマはMacを使ってるってマジ？
ｽﾚﾘﾝｸ(news板)
302:デフォルトの名無しさん
15/12/19 07:07:37.11 qL4RiVer.net
マカーってどんだけアホなの？
303:デフォルトの名無しさん
15/12/19 12:49:09.79 EW8XrhCB.net
解放処理
すら、まともにお前ら管理できねーのかよ・・・・・・・・・・・・・・・・。そらオレが完璧な仕様書渡してもバグってるわけだ
304:デフォルトの名無しさん
15/12/19 13:38:07.82 i3zp3GbO.net
開放処理を手動でやれって書いてある仕様書かw
御免こうむるwwwww
305:デフォルトの名無しさん
15/12/19 14:42:49.35 iG82T79N.net
ガベコレのあるPyObjectをラップするクラスをガベコレのあるDで書いたら
wxPythonで書いたクラスをDから使ったとき意味不明なタイミングで落ちるようになった
二重に管理するとだめなんかな
306:デフォルトの名無しさん
15/12/19 15:57:38.71 qL4RiVer.net
>>298
ﾌﾟﾌﾟﾌﾟ 馬鹿だこいつw
307:デフォルトの名無しさん
15/12/20 08:46:23.14 gr0U1KS4.net
ガベージコレクションはたしかに便利だ
だからといって「本来はてめぇのケツはてめぇで拭け＝自分で解放すること」を忘れてはならない
そんだけ
308:デフォルトの名無しさん
15/12/20 11:55:11.08 HXRBhwTH.net
C#ではSafeHandleだけ作って後は放置
usingも使わないってのがトレンドだけどね
自分で解放とかバカバカしい
面倒はランタイムに見させて開発者はドメイン設計に集中するって目的を見失うな
309:デフォルトの名無しさん
15/12/20 12:13:23.36 ofrSOHxv.net
>>303
オブジェクトの開放を他と独立にやれるケースばかりならそう言えるかもしれんが
オブジェクトAとBがリソースCに依存しているケースでA、Bの開放の少なくとも片方をGCに任せる場合、
リソースCの参照カウンタなりをつかった防護策をプログラマーが書かねばならない
しかしそんな嫌ったらしい雑用を増やすぐらいなら
Cオープン
A生成
B生成
A, B使用
B開放
A開放
Cクローズ
でええやん？
さらにダンプファイルとかからの障害解析において、オブジェクトが生きているべきなのか死んでいるべきなのか決まっていないとか、
アドレスがはっきりしないとか言う状況は地獄
310:デフォルトの名無しさん
15/12/20 12:21:54.48 ofrSOHxv.net
つかこの世はうつろうもののであって、物理的ハードウェアでプログラムを実行する限り、
計算モデルは明らかに状態遷移ベース（チューリングマシン）の方に分がある
GCとかチューリングマシンで無理矢理関数型プログラミングを行うためのつなぎの技術、
いわば邪道
どんだけ蛇が出てくるか、GCの方がかえってわからん
311:デフォルトの名無しさん
15/12/20 13:48:14.94 HXRBhwTH.net
>>304
設計が悪い
使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
知らなきゃ困るような設計にしたのが間違いだね
312:デフォルトの名無しさん
15/12/20 13:52:55.68 8RLYRFXT.net
メモリ空間は無限であるべき
使い終わったメモリの断片化なにそれ？
仮想メモリを管理するのはCPUの責任だろ
313:デフォルトの名無しさん
15/12/20 14:03:49.29 ofrSOHxv.net
>>306
>>304の例で、さらにCを上書き更新したいオブジェクトDがいたらどうすんの？
GCがA、B両方開放してくれるまでDは期限不定で待たされるけどそれが>>306的に良い設計なの？
つまり、ハードウェアリソースの有限性を考慮する限り
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
が常に成立はしないという話
314:デフォルトの名無しさん
15/12/20 14:28:20.48 i39XsMQ2.net
>>308
そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？
意見を否定するためだけの極端な反例(この場合は例にすらなっていないが)を引き合いに出すのは不毛だよ
315:デフォルトの名無しさん
15/12/20 14:35:53.96 xl2QwS3M.net
>>303
いい加減だなぁw
316:デフォルトの名無しさん
15/12/20 14:36:58.02 ofrSOHxv.net
>>309
>そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？
極論なもんｶﾖ；
例： 表示デバイスの数＞表示したいスレッドの数
というのはざらにある
で、>>308のオブジェクトDのケースはどう解決すんのさ…
GCが「いつ開放してくれるかわからない」ブツである以上解消しない問題だとおもうんだけど
（A、BにCのための明示的closeメソッドを付けるぐらいならGCに頼らずに順序管理するわ；
317:デフォルトの名無しさん
15/12/20 14:42:20.07 ofrSOHxv.net
解決策の一つはActive ObjectパターンでリソースCの管理を1スレッドXにやらせて
Cに対する要求を全部Xのキューにシリアル化して入れさせるというのがあるが、それはそれで
リソースCを使う全てのオブジェクトがスレッドXに依存するから、Xの開放コードが面倒なことになりかねない
かつ、シリアル化はマルチコア時代のせっかくの並列実行性能を殺してしまう
GCに合わせて生きることは、神仙にでもならねば到底かなわぬ…
318:デフォルトの名無しさん
15/12/20 14:44:35.05 ZDEpjFBd.net
つくづく、ARC最強だな。
319:デフォルトの名無しさん
15/12/20 14:46:27.58 i39XsMQ2.net
>>311
その例じゃ308の状況にならないよ
どんなコード書いてんだよw
320:デフォルトの名無しさん
15/12/20 14:48:11.36 ofrSOHxv.net
>>314
>その例じゃ308の状況にならないよ
なんで？ビデオメモリに2スレッドから同時に書いて無事に済むと思ってるの…；
321:デフォルトの名無しさん
15/12/20 14:51:52.93 i39XsMQ2.net
だから同時に書く設計が悪いんだって
気合入れて設計を見直してみろ
そんな必要はないってわかるから
322:デフォルトの名無しさん
15/12/20 14:55:30.48 ofrSOHxv.net
ていうか>>316の言っていることはますます矛盾で、
>同時に書く設計が悪い
>そんな必要はないってわかる
というのは明白に「書き込みの順序を設計できる」ということを言っていて、
それはその通り（チューリングマシンの計算モデルに合致する）ので別段漏れの立場と対立するものではなく、
かつ気合を入れて設計すれば順序で全て解決する（GCは不要である）という言明でもある
323:デフォルトの名無しさん
15/12/20 15:17:45.93 14eB8c4R.net
>>315
もはやGCがどう関係するのかわからない
324:デフォルトの名無しさん
15/12/20 15:20:28.11 i39XsMQ2.net
>>318
彼は敵対意見に反論する材料が欲しいというだけで変な例をでっち上げて出してしまったんだ
本人も今頃困ってるんじゃないかな
325:デフォルトの名無しさん
15/12/20 17:05:42.48 6vo8OCaj.net
>>319
>>308を変な例変な例というばかりでGCを用いた正しい解決方法が一向に示されない件について：
繰り返しになるが、>>308のオブジェクトDのケースはどう解決すんのさ…
たとえ変でも反例は反例だし
>>308のリソースCがファイルなのだとしたら、病的な反例というほど例外的想定でもない
読み書き順序の設計の必要性（破壊的代入前提のプログラミング）を口にしつつ
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない （>306）
と言い切ることはできないとかそういう話
で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306)
>>318
ウィンドウシステムでの描画は一般に裏VRAMに描いてハードウェアでBitBlt転送するが
裏VRAMに書く際のデバイスコンテキストが複数使えるが数に限りがある場合…
とか細かい話をしても通じないようならリソースCをファイルと考えてくんな
326:デフォルトの名無しさん
15/12/20 17:12:24.84 6vo8OCaj.net
ﾌﾟﾁ訂正
誤: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306)
正: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>308)
327:デフォルトの名無しさん
15/12/20 17:19:25.13 HXRBhwTH.net
読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
書き込みたいから読み込み終わるの待ってますってリソースの無駄だろ
328:デフォルトの名無しさん
15/12/20 17:21:31.86 ZDEpjFBd.net
なんか参照カウントの話とマルチスレッドの話がごっちゃになってね？
329:デフォルトの名無しさん
15/12/20 17:33:49.10 6vo8OCaj.net
>>322
>読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
破壊的代入の世界ではそいつは常に可能とは限らない
>308の例で、リソースCがファイルXなのだとしたら、オブジェクトDが上書きすべきもあくまでファイルXでないといけない。
つまりリソース分離の余地など無い
（正確には、無理矢理ファイルA、BはファイルX、DはファイルYに分ける設計もありえるが、XとYに対する変更をいつどのように統合するかという超難題が生じる
この手の混乱は、A、BがアクセスするリソースCの開放タイミングの決定をGCに任せてサボったがために生じるのである
330:デフォルトの名無しさん
15/12/20 18:10:09.92 ZDEpjFBd.net
おいおい、バージョン管理のマージの話にまで拡張したら収集つかなくなるぞw
331:デフォルトの名無しさん
15/12/20 19:32:49.85 i39XsMQ2.net
>>324
ファイルの分割は必ずしも必要ではないし更新モデルから読み取りモデルへの同期も必要ないよ
332:デフォルトの名無しさん
15/12/20 19:44:06.53 9YX+2XWA.net
>>323 (Rust信者で)すまんな。
URLﾘﾝｸ(smallcultfollowing.com)
マルチスレッドで起きるデータ競合といった問題も、シングルスレッドで起きうるdangling pointerなどの問題も、
どっちも所有権を持つオブジェクトが無闇にいたり、変な参照関係があるから起きるんじゃないか？って言う人がおる。
根っこが同じ、あるいは近しい問題なんで、横滑りに見えても堪忍な。
333:デフォルトの名無しさん
15/12/20 19:49:46.85 kaqci566.net
メモリ管理もできないんだから
データの依存関係とか関係ねえ～～～～～～～～～～～～
でおわりでは
334:デフォルトの名無しさん
15/12/21 05:26:25.94 ejqZ3DMD.net
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
335:デフォルトの名無しさん
15/12/21 05:32:28.99 ejqZ3DMD.net
その理由・・・GCは失敗。メモリは自分で管理せよ！
ｽﾚﾘﾝｸ(tech板)l50
336:デフォルトの名無しさん
15/12/21 05:35:31.18 ejqZ3DMD.net
メインメモリに対するGC・・・MGC
HDDならストレージGC・・・SGC
337:デフォルトの名無しさん
15/12/21 05:38:11.78 ejqZ3DMD.net
GoogleChromeかsvchost.exeを使わなくなった理由・・・ページメモリGC制御が遅過ぎでお粗末だからか？
338:デフォルトの名無しさん
2
339:015/12/21(月) 05:42:27.02 ID:ejqZ3DMD.net
340:デフォルトの名無しさん
15/12/21 05:45:15.43 ejqZ3DMD.net
「Svchost Process Analyzer」
svchost.exeのプロセスの中身が何かを調べて表示するフリーソフト
URLﾘﾝｸ(gigazine.net)
341:デフォルトの名無しさん
15/12/21 05:51:39.30 ejqZ3DMD.net
そろそろsvchost.exeを使うソフトは使用禁止なのかも？
342:デフォルトの名無しさん
15/12/21 06:11:17.64 ejqZ3DMD.net
svchost.exeを使わないことでGoogleChromeは確実に応答性能が速くなって�
343:｢る ・・・動画マルチ再生でクラッシュしたFirefoxは見習うべき
344:デフォルトの名無しさん
15/12/21 06:17:26.48 ejqZ3DMD.net
残念だがスリープだ！
URLﾘﾝｸ(pds.exblog.jp) URLﾘﾝｸ(i.imgur.com)
345:デフォルトの名無しさん
15/12/21 06:40:32.08 ejqZ3DMD.net
Wave
URLﾘﾝｸ(aurorawave.atspace.tv) URLﾘﾝｸ(i1.ytimg.com) #AuroraWaveTV
346:デフォルトの名無しさん
15/12/21 06:42:41.39 ejqZ3DMD.net
LG OLED TV : You Dream We Display
URLﾘﾝｸ(aurorawave.atspace.tv) URLﾘﾝｸ(i1.ytimg.com) #AuroraWaveTV
347:デフォルトの名無しさん
15/12/21 06:43:24.61 ejqZ3DMD.net
LG OLED TV - The Ultimate Display
URLﾘﾝｸ(aurorawave.atspace.tv) URLﾘﾝｸ(i1.ytimg.com) #AuroraWaveTV
348:デフォルトの名無しさん
15/12/21 07:08:24.86 ejqZ3DMD.net
LG 4K OLED: Paris and Chicago
URLﾘﾝｸ(aurorawave.atspace.tv) URLﾘﾝｸ(i1.ytimg.com) #AuroraWaveTV
349:デフォルトの名無しさん
15/12/21 09:26:05.64 ejqZ3DMD.net
国別ISO登録件数 ⇒ 技術マフィア ⇒ 技術流出状況
URLﾘﾝｸ(www.jicqa.co.jp)
URLﾘﾝｸ(www.jicqa.co.jp)
URLﾘﾝｸ(www.jicqa.co.jp)
URLﾘﾝｸ(www.jicqa.co.jp)
URLﾘﾝｸ(www.google.co.jp)
URLﾘﾝｸ(pds.exblog.jp)
350:デフォルトの名無しさん
15/12/21 09:41:02.29 ejqZ3DMD.net
中国、ダークマターの検出に挑む探査衛星「悟空」を打ち上げ
URLﾘﾝｸ(news.mynavi.jp)
URLﾘﾝｸ(n.mynv.jp)
URLﾘﾝｸ(n.mynv.jp)
URLﾘﾝｸ(n.mynv.jp)
351:デフォルトの名無しさん
15/12/21 09:44:40.17 ejqZ3DMD.net
京がお仕置き候補に???
URLﾘﾝｸ(gigazine.net)
◆1位：Tianhe-2(天河二号)、中国人民解放軍国防科学技術大学
URLﾘﾝｸ(i.gzn.jp)
IntelのIvy Bridge(12コア・2.2GHz)とXeon Phi(57コア・1.1GHz)を採用し、
コア数は312万、計算速度は33.9ペタフロップス、消費電力は17.8MW
◆2位：Titan、アメリカのオークリッジ国立研究所
URLﾘﾝｸ(i.gzn.jp)
AMD Opteron 6274(16コア・2.2GHz)とNvidia Kepler(14コア・0.732GHz)を採用し、
コア数は56万640、計算速度は17.6ペタフロップス、消費電力は8.3MW
◆3位：Sequoia、アメリカのローレンス・リバモア国立研究所
URLﾘﾝｸ(i.gzn.jp)
IBM BlueGene/Qを採用し、中のプロセッサーはPower BQC(16コア・1.60GHz)、
コア数は157万2864、計算速度は17.2ペタフロップス、消費電力は7.9MW
◆4位：スーパーコンピュータ京、独立行政法人理化学研究所 計算科学研究機構(AICS)
URLﾘﾝｸ(i.gzn.jp)
富士通 SPARC64 VIIIfx(8コア・2.0GHz)を採用し、コア数は70万5204、
計算速度は10.5ペタフロップス、消費電力は12.7MW
◆5位：Mira、アメリカのアルゴンヌ国立研究所のエネルギー部門
URLﾘﾝｸ(i.gzn.jp)
BM BlueGene/Qを採用し、中のプロセッサーはPower BQC(16コア・1.60GHz)、
コア数は78万6432、計算速度は8.6ペタフロップス、消費電力は3.95MW
352:デフォルトの名無しさん
15/12/21 09:50:17.19 ejqZ3DMD.net
気づかないかISOは中国のためにある
URLﾘﾝｸ(www.jicqa.co.jp)
353:デフォルトの名無しさん
15/12/21 10:45:57.17 1HvlxK+M.net
>>344
蓮舫さんに次の選挙は次点で良いですよねって言ってきて
354:デフォルトの名無しさん
15/12/21 11:12:03.51 1HvlxK+M.net
>>336
ほんそれ
355:デフォルトの名無しさん
15/12/21 12:31:40.33 ejqZ3DMD.net
URLﾘﾝｸ(ja.wikipedia.org)
356:デフォルトの名無しさん
15/12/21 12:34:04.50 ejqZ3DMD.net
URLﾘﾝｸ(www.google.co.jp)
357:デフォルトの名無しさん
15/12/21 12:36:38.19 x6st9rMu.net
ただしChromeはプロセスが一杯できるから
タスクマネージャ覗いた時に気持ち悪い
358:デフォルトの名無しさん
15/12/21 16:06:45.56 ejqZ3DMD.net
64の時代だから、そろそろCore64ぐらいでイイのでは？
URLﾘﾝｸ(blogs.msdn.com)
URLﾘﾝｸ(download.intel.com)
359:デフォルトの名無しさん
15/12/21 16:21:26.45 ejqZ3DMD.net
ラーメン
URLﾘﾝｸ(www.chikuwachan.com)
URLﾘﾝｸ(www.chikuwachan.com)
360:デフォルトの名無しさん
15/12/21 16:33:49.61 ejqZ3DMD.net
URLﾘﾝｸ(www.dospara.co.jp)
URLﾘﾝｸ(www.dospara.co.jp)