- GCは失敗。メモリは自分で管理せよ！
235 ：デフォルトの名無しさん[sage]：2014/10/19(日) 00:03:35.73 ID:BmB5xxVy - 投げるなよ
内部で投げるのがあるなら
キャッチして処理しろと
|
- GCは失敗。メモリは自分で管理せよ！
239 ：デフォルトの名無しさん[sage]：2014/10/19(日) 01:08:30.38 ID:BmB5xxVy - >>238
unique_ptrのdeleterにlambda渡して
外部スコープの変数にでも
状態を書き込めばいい
まさにraiiの仕組みを使うことになるが
|
- GCは失敗。メモリは自分で管理せよ！
243 ：デフォルトの名無しさん[sage]：2014/10/19(日) 01:28:44.77 ID:BmB5xxVy - つっても結局やることは同じ
後はベリファイすりゃそんな処理は
要らないって話にもできるし
そもそも読み込みの場合は必要ない
|
- GCは失敗。メモリは自分で管理せよ！
247 ：デフォルトの名無しさん[sage]：2014/10/19(日) 02:06:08.59 ID:BmB5xxVy - まあエラー発生が遅延するって
closeの仕様自体が酷いというのが
正直なところ
他にこんな仕様のリソースってあるの？
|
- GCは失敗。メモリは自分で管理せよ！
248 ：デフォルトの名無しさん[sage]：2014/10/19(日) 02:11:32.13 ID:BmB5xxVy - で、こんな仕様が放置されているってのは
みんながエラー対策が万全だからってんじゃなく
あまり対策がされてないのにそれで許されているからというのが実態
まあ本当に大事なデータなら、書き込み正常終了だけでなくベリファイまでするだろうしね。
|
- GCは失敗。メモリは自分で管理せよ！
257 ：デフォルトの名無しさん[sage]：2014/10/19(日) 12:09:02.61 ID:BmB5xxVy - デストラクタで例外出すようなコード書く
のが無茶なだけ
javaその他でもファイナライザで
例外出すのは糞だろうに
死ぬか握り潰すかしかない
|
- GCは失敗。メモリは自分で管理せよ！
260 ：デフォルトの名無しさん[sage]：2014/10/19(日) 12:12:18.58 ID:BmB5xxVy - >>256
そのわりには例外機構的に
もっと都合の悪いファイナライザが
あるのは何故
|
- GCは失敗。メモリは自分で管理せよ！
269 ：デフォルトの名無しさん[sage]：2014/10/19(日) 12:28:33.48 ID:BmB5xxVy - gcでraii出来ているとか
異次元での話かなにか？
|
- GCは失敗。メモリは自分で管理せよ！
274 ：デフォルトの名無しさん[sage]：2014/10/19(日) 12:35:28.62 ID:BmB5xxVy - raiiの仕組みを利用して
デストラクタが例外投げる状況を
回避して安全にエラー処理可能だと
いうことを>>239で書いたんだが。
errnoみたいなのが嫌なら
中で一時オブジェクトに
例外オブジェクト代入して、
外で例外としてthrowしてしまえばいい話
|
- C++相談室 part114
353 ：デフォルトの名無しさん[sage]：2014/10/19(日) 17:03:14.95 ID:BmB5xxVy - べつに中間オブジェクト作って返せば
出来ないことはないが、そこまでする意味があるのか？
素直に()使っておけばいい
|
- C++相談室 part114
361 ：デフォルトの名無しさん[sage]：2014/10/19(日) 19:20:39.01 ID:BmB5xxVy - mapのoperator[]にはconst版は無い。
findかatを使う
|