トップページ > プログラム > 2016年01月27日 > zgyqI55G

書き込み順位&時間帯一覧

5 位/200 ID中時間01234567891011121314151617181920212223Total
書き込み数3100000000000000000000329



使用した名前一覧書き込んだスレッド一覧
デフォルトの名無しさん
C++相談室 part122 [無断転載禁止]©2ch.net

書き込みレス一覧

C++相談室 part122 [無断転載禁止]©2ch.net
113 :デフォルトの名無しさん[sage]:2016/01/27(水) 00:02:05.29 ID:zgyqI55G
>>112
コンストラクタ内で例外が発生してもコンストラクタ内でキャッチしてしまえば走らない
コンストラクタ内で例外が発生してもコンストラクタ内でキャッチしてしまえば走らない
C++相談室 part122 [無断転載禁止]©2ch.net
114 :デフォルトの名無しさん[sage]:2016/01/27(水) 00:02:50.96 ID:zgyqI55G
ごめwwwwwwww
走るの間違いwwwwwwwwww
C++相談室 part122 [無断転載禁止]©2ch.net
116 :デフォルトの名無しさん[sage]:2016/01/27(水) 00:13:07.10 ID:zgyqI55G
普通に使ってリソースリークの危険があり、
かつユーザーの立場からリークを阻止する手段が無いというのは
ライブラリのバグと言って過言ではない
C++相談室 part122 [無断転載禁止]©2ch.net
120 :デフォルトの名無しさん[sage]:2016/01/27(水) 01:45:10.90 ID:zgyqI55G
>>100
longjump()か例外をthrowするかして大域脱出すると良い
ID:I8Y70xN6が。
C++相談室 part122 [無断転載禁止]©2ch.net
177 :デフォルトの名無しさん[sage]:2016/01/27(水) 22:35:48.89 ID:zgyqI55G
RAIIは論理的には正しいかもしれないが
記述量の割に得られる対価が例外に対する備えだけ、
というのが気に入らない

RAIIなプログラムのメモリ消費量はなかなか安定に達しないから(∵確保したり開放したりで断片化が進んだり治まったり、
意図とはうらはらに、実は第三者に対してメモリリークが無いことの証拠提示がヒジョーに厄介なプログラムになってしまったりする
C++相談室 part122 [無断転載禁止]©2ch.net
180 :デフォルトの名無しさん[sage]:2016/01/27(水) 22:55:49.88 ID:zgyqI55G
>>178
いちいちstd::shared_ptr<T>とか打ちたくないし、pSomeSmartPtr.get()ですらちょっと嫌
メモリ直接ならまだ標準ライブラリでカバーされるが、OSがハンドルを返す場合はwrapperを書かねばならない
そしてコンストラクタが例外をスローするのに処置しようとしたら、
漏れの無いtry { } catch { }を書くか、メンバ変数を全部wrapperかスマポにせねばならない
これは苦行以外の何者でもない
そしてクラスの群れを書く面々のうちの誰か一人がしくじれば、やはりリークする

returnやbreakについては、例外と違って伝統的な書き方で対処可能
例外はスマポとか、try { } catch { } みたいな仕掛けが要る
C++相談室 part122 [無断転載禁止]©2ch.net
182 :デフォルトの名無しさん[sage]:2016/01/27(水) 22:59:19.51 ID:zgyqI55G
>>179
>そしてクラスの群れを書く面々のうちの誰か一人がしくじれば、やはりリークする
この危険性についてコードを見るだけで検証完了という信じる方がよっぽどキチ

同じコードを見る話なら、固定長の配列の方が安心できる
C++相談室 part122 [無断転載禁止]©2ch.net
184 :デフォルトの名無しさん[sage]:2016/01/27(水) 23:04:15.53 ID:zgyqI55G
>>183
もちろんナマポも極力使わない
やっても関数内で確保したやつを関数を抜けるとき全部開放する使い方のみとしたい(この用途にはstd::unique_ptr<T>を使ってやっても良い
この構造に統一するなら、メモリの断片化は生じない(まあだれか一人がしくじれば…というのは同じだが
C++相談室 part122 [無断転載禁止]©2ch.net
187 :デフォルトの名無しさん[sage]:2016/01/27(水) 23:13:29.29 ID:zgyqI55G
加えてRAIIにはマルチコア時代にふさわしくない疑いがある
RAIIで確保したり開放したるするメモリがスレッド固有という保証が無い限り、
確保や開放の度に排他制御が行われる
スタック上にとられた配列がペナルティーゼロであることを鑑みれば、
InterlockedIncrement()ですら塵も積もれば巨大なコスト足りえる


※このページは、『2ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の2ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。