[過去ﾛｸﾞ] GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
37: デフォルトの名無しさん [sage] 2015/11/23(月) 17:21:44.69 ID:y4njP/wV(1) AAS
うわっ頭のおかしいQだ
38: デフォルトの名無しさん [sage] 2015/11/23(月) 17:22:22.95 ID:9XGqpqVu(1) AAS
＞解放して欲しくないタイミングで解放
なんでそんなことになったの？
参照切ってなきゃGCの対象にならないはず
39: デフォルトの名無しさん [sage] 2015/11/23(月) 17:24:18.17 ID:OK+rBFmG(1/2) AAS
空きメモリによって使用するアルゴリズム変えたりする。
だから実行前にGC手動で走らせて、できるだけ空きメモリ増やしたりとかする。
できるだけ開放したいのに過負荷でまだメモリに余裕あるからGC走らないってのが困る。
40: デフォルトの名無しさん [] 2015/11/23(月) 17:46:43.41 ID:XNOSKZeE(2/2) AAS
メモリの解放漏れってさ、とどのつまり下手だからするんだよね
下手なやつにはプログラムを組ませないってのが鉄則だと思うの
41(1): デフォルトの名無しさん [sage] 2015/11/23(月) 19:25:05.71 ID:6m6E/SfN(1/2) AAS
c++11のshared_ptrの参照カウンタってそもそも要るんだろうか？
複数のオブジェクトが所有権を持ちあう必要性に迫られる事がないんだけど
weak_ptrの対応だけあれば良くない？
42(1): デフォルトの名無しさん [sage] 2015/11/23(月) 19:56:47.15 ID:+Ddm9172(1/2) AAS
リソースを共有する場合なんかは使うと楽だよ
まーshared_ptrが有れば、いつ実行されるか分からないような、手の込んだGCは要らないよな
巡回参照が有る場合はどちらかをweak_ptrにする、これだけを守ってれば問題は起きない
大体の場合は所有権というか上下関係がはっきりしているからな
巡回参照のある場合も自動で開放したいという、たったこれだけのために
いつ実行されるか分からない上に重いマークスイープ式GCを導入するのは
業界全体の早とちりだったようだね
43: デフォルトの名無しさん [sage] 2015/11/23(月) 20:06:26.94 ID:+Ddm9172(2/2) AAS
最近のC++はdeleteを直接書かないだけでなく、最早newも直接書かない方向
std::make_shared<int>() って書くよね
始めからshread_ptrで受け取るから、循環参照だけ気をつければ
リークする余地がないよね
RAIIも健在で、C#みたいにIDisposableとか要らない
デストラクタも芋づる式に呼び出されるから
>>3030(1): デフォルトの名無しさん [sage] 2015/11/22(日) 17:32:48.70 ID:vggKhYqJ(2/2) AAS
前スレでも書いたけど、C#のDisposeの問題を紹介しよう
IDisposableなオブジェクトをコンポジションしてメンバに持つと自身もIDisposableにしなければならない
だから自分がコンポジションしているオブジェクトがIDisposableかどうか一々調べなければならないし
IDisposableなオブジェクトがメンバにあれば、自身もIDisposableにしなければならない
さらに、その作ったクラスをコンポジションして使うクラスもIDisposableにする必要があり・・・
という風にIDisposableはクラスで閉じずコンポジションで伝染する
というか、むしろ手動で伝染させなければならないという
しかもIDisposableの一連のイディオムはとても長くて煩雑
外部ﾘﾝｸ[html]:ufcpp.net
こういうものを書いて、マネッジドリソースとアンマネッジドリソースで場合わけをしつつ
IDisposableなオブジェクトに関しては
手動で自分のメンバのDisposeを漏れなく呼び出すコードを書かなければならない
当たり前だが、どのメンバがIDisposableか完全に把握しておく必要が有る
手動で自分のメンバのDisposeを呼び出す作業は、まるでCのmallocを思い起こさせる
問題点は明確で、DisposeがC++のデストラクタのように芋づる式に勝手に呼ばれない事に有る
だから手動で芋づる式に呼び出すコードを書かなくてはならない
で書いたような問題も起きないよ
44: デフォルトの名無しさん [sage] 2015/11/23(月) 20:09:18.99 ID:OK+rBFmG(2/2) AAS
C++は益々混沌としているのか。手に負えん。
45(1): デフォルトの名無しさん [sage] 2015/11/23(月) 20:35:23.62 ID:PopzBtGV(1) AAS
>>41
糞便利な参照カウンタを使わないなんてＣ＋＋使う意味なし
46: デフォルトの名無しさん [sage] 2015/11/23(月) 22:58:10.32 ID:6m6E/SfN(2/2) AAS
>>42
それはManagerやHolder的なものを書かなくて良いってことを言ってるの？
それって大体一時しのぎで大抵後々リソース管理以外にもそういった管理クラスが必要になるケースがほとんどじゃない？
>>45
ねーよ
47(1): デフォルトの名無しさん [sage] 2015/11/24(火) 00:26:10.23 ID:f4S6RtN7(1/4) AAS
うーん質問がアバウトすぎたな。もう少し具体的に書くわ
例えば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(1) AAS
IDisposableの問題はDisposeを呼ばなければリークするものとそうでないものの混在だろ
49(1): デフォルトの名無しさん [sage] 2015/11/24(火) 03:22:06.30 ID:fjQi4YH+(1) AAS
>>47
マルチスレッドプログラム書いてみろよ
shared_ptrがないと泣くぞ
50(1): デフォルトの名無しさん [sage] 2015/11/24(火) 05:26:33.27 ID:f4S6RtN7(2/4) AAS
>>49
いやいくらでも書いてるけど基本一緒
というか上の例もそのままマルチスレッドに適用できる話でしょ
例えばproducer consumerならproducerが所有権を持つし
thread per messageなら共有データはホストが持って固有データは
個別スレッドで持つだけ
むしろマルチスレッドの場合、所有者をより厳格に決めとかないと
泣く事になるぞ
51(1): デフォルトの名無しさん [sage] 2015/11/24(火) 12:31:47.38 ID:HvLaDP3z(1/2) AAS
所有権って・・・・
unique_ptrを使うと勝手に所有権が移動してしまうし
生のポインタを使うんならわかるけど
52: デフォルトの名無しさん [sage] 2015/11/24(火) 12:53:55.99 ID:2IyJeQ15(1) AAS
shared_ptrで複数人が所有権を持っても良いんだぞ
上下関係さえしっかりしていれば良い
53: デフォルトの名無しさん [sage] 2015/11/24(火) 13:15:01.57 ID:HvLaDP3z(2/2) AAS
そんなの分かってるんだが
>>50の人はどう考えてるのか
54: デフォルトの名無しさん [sage] 2015/11/24(火) 16:23:15.08 ID:f4S6RtN7(3/4) AAS
>>51
今のC++からshared_ptrをそのまま無くせって言ってるんじゃないぞ
shared_ptrのコピーを禁止にしてweak_ptrの対応だけあれば良くないかって事
そもそも何でそんなこと言うかっていうと、
GCない言語→循環参照ガー。みたいによく言われるけど使わないで
済むなら静的解析で循環参照の起こり得るケースをエラーにしてしまう
って解決方法もあるかなと思っただけ
あとshared_ptrとweak_ptrはアトミック操作とメモリバリアを必要としうるから
それに頼った設計は疑問を感じる
55: デフォルトの名無しさん [sage] 2015/11/24(火) 16:37:54.42 ID:f4S6RtN7(4/4) AAS
一応言っとくと静的解析のくだりは新しい言語を
設計するとした場合の話ね
C++だとほぼ不可能だろうから
56: デフォルトの名無しさん [sage] 2015/11/24(火) 16:39:45.81 ID:1SleeXaD(1) AAS
せっかくC#は新設計なのにいろいろ失敗が含まれてるよな。
ヘジはなにやってんだか。
57: uy ◆Qawu9.2l1E [sage] 2015/11/24(火) 18:29:34.50 ID:lNjW2jss(1) AAS
大企業は、
中小企業を奴隷にさせる事を第一に考えたツールしかリリースしてないよ
失敗ではなく全部わざと。
58: デフォルトの名無しさん [sage] 2015/11/25(水) 07:39:30.16 ID:JnM8vxaH(1) AAS
メモリ管理テケトーなやつはその他のリソース管理もテケトー
59: デフォルトの名無しさん [sage] 2015/11/25(水) 17:12:00.25 ID:Sra0FKsR(1) AAS
そもそも自分のリソース管理がしっかり出来てる人は・・・
60: デフォルトの名無しさん [sage] 2015/11/27(金) 12:24:34.85 ID:ZRdaHx9T(1) AAS
>>3131(1): デフォルトの名無しさん [] 2015/11/22(日) 18:20:40.59 ID:WFE6EpHf(2/2) AAS
Formなんかも参照が亡くなったら強制的に殺すべきだったと思うわ
ファイナライザーの処理がひどいことになると思うけど
Formはnull入れてあげないといけないんだっけ？
なんか、場合場合によってnull入れてあげないといけなかったり入れなくてもよかったり。
ならnull入れるで統一でいいじゃんと思った
61: デフォルトの名無しさん [sage] 2015/11/27(金) 22:35:05.80 ID:CyIO1ZuX(1) AAS
Rust使えば解決
上下前次1-新書関写板覧索設栞歴
あと 659 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.013s