1 名前:デフォルトの名無しさん mailto:sage [2016/01/23(土) 23:06:15.32 ID:HdItgJjm.net] C++に関する質問やら話題やらはこちらへどうぞ。 ただし質問の前にはFAQに一通り目を通してください。 IDE (VC++など)などの使い方の質問はその開発環境のスレに お願いします。 前スレ C++相談室 part121 peace.2ch.net/test/read.cgi/tech/1449240881/ このスレもよろしくね。 【初心者歓迎】C/C++室 Ver.97【環境依存OK】 peace.2ch.net/test/read.cgi/tech/1439849418/ 次期規格C++1zはこちら C++14/C++1z 20 peace.2ch.net/test/read.cgi/tech/1410382924/ ■長いソースを貼るときはここへ。■ codepad.org/ ideone.com/
127 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 10:47:19.58 ID:oAun2w+9.net] >>124 コンストラクタ初期化子
128 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 12:30:07.60 ID:eULyfEEH.net] >>125 >それはそのクラスが内部で処理することであって ずっとその話なのだが
129 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 12:56:11.97 ID:zSFGO6dq.net] 初期化子もそうだけどデフォルトコンストラクトされる変数もそうだな コンストラクタ内でtry-catchできない やっぱりコンストラクトでの例外はまずいんじゃないか?
130 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 13:59:04.99 ID:oAun2w+9.net] C++17ではできるんだっけ?
131 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 17:48:02.83 ID:gidaw1Ah.net] 初期化子リストもメンバ変数も関係なくね? 初期化しきれたクラスはデストラクタが呼ばれ、初期化できなかったクラスは内部でcatchしてエラー処理して再送するだけ。 やっぱ単純だよ。 我らがMeyer先生はなんて言ってるの?
132 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 18:08:44.32 ID:7tk5IOS7.net] >>129 できないと判断した根拠は? ideone.com/WlFMej >>131 メイヤー「ワシ、ちょっとC++引退するわ」
133 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 18:10:24.29 ID:7tk5IOS7.net] 一カ所訂正 誤 try m{}, x{} 正 try : m{}, x{}
134 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 18:15:50.95 ID:7tk5IOS7.net] >>127 荒らしは去れ
135 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 18:45:02.79 ID:oAun2w+9.net] >>131 コンストラクタ初期化子に書くメンバーが初期化はコンストラクタのスコープ内部じゃない。 自作クラスだったら君の言うように内部catchすればいいけど他作クラスで例外をthrowするタイプだtry-catchで囲めない。
136 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 18:49:38.11 ID:oAun2w+9.net] >>134 まさか14以降を前提にしてるなんて言うまい?
137 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 19:31:29.47 ID:3jiwec3B.net] >>136 お前はコンストラクター初期化子や例外という言語機能がC++14以降だとでも言いたそうだな どれだけ勉強不足なんだ
138 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 19:39:57.53 ID:6XO7CsMP.net] お前らに一度確認していい? 初期化リストつったらコンストラクタのパラメータのカッコの横の クラス名(引数) : この部分 {} を言うんだよな? 駆け出しの頃にC++プライマーとかいう分厚い本で学んだときは たしかこうだったはずなんだが std::initializer_listの出現で落ち着かない気持ちになってきてる
139 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 19:53:14.68 ID:3jiwec3B.net] >初期化リストつったら (中略) >を言うんだよな? いやまずそこから違う
140 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 20:04:51.00 ID:1b0Lj9r3.net] クラス名(引数) : この部分は初期化子 {}
141 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 20:41:04.94 ID:aFoLhF8M.net] >>140 とんくす! ↓少し学んだ ISO/IEC 14882:1998 12.6.2 Initializing bases and members ctor-initializer: : mem-initializer-list mem-initializer-list: mem-initializer mem-initializer , mem-initializer-list mem-initializer: mem-initializer-id ( expression-listopt ) mem-initializer-id: ::opt nested-name-specifieropt class-name identifier
142 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 20:44:21.08 ID:gqKHFo+S.net] >>129 だからtry-catchなんかしない。>>94 ,108のとおりRAIIで解決する。 なんというか10年前にタイムスリップした感がある。↓読んでくれ。 https://www.google.co.jp/search?q=C%2B%2B+%E3%82%B3%E3%83%B3%E3%82%B9%E3%83%88%E3%83%A9%E3%82%AF%E3%82%BF+%E4%BE%8B%E5%A4%96
143 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:00:23.97 ID:zSFGO6dq.net] >>132 あなたのおっしゃる通りです。いい加減なこと言ってごめんなさい魔が差しましたw やはり大事なのはRAIIの徹底ですね
144 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:08:05.10 ID:oAun2w+9.net] >>137 えっ? 初期化子までtry説に含めるのはC++11ではできないって言いたいだけなんだけど?
145 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:09:24.27 ID:oAun2w+9.net] ×try説 ○try節
146 名前:デフォルトの名無しさん [2016/01/27(水) 21:10:04.69 ID:0xRCKJUw.net] RAIIって初期化がキモみたいなネーミングだけどデストラクタの解放の方が大事じゃね
147 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:13:01.64 ID:1b0Lj9r3.net] >>141 ああ、構文規則の非終端記号名のmem-initializer-listと混同していたのか。
148 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:16:28.24 ID:3jiwec3B.net] >>144 ISO/IEC 14882:1998 15p1 8行目 ISO/IEC 14882:2003 15p1 8行目 ISO/IEC 14882:2011 15p1 8行目 ISO/IEC 14882:2014 15p1 8行目 これのどこを読んだらいったいそんな嘘が出てくるのか
149 名前:デフォルトの名無しさん [2016/01/27(水) 21:19:58.24 ID:hY0OCllE.net] だからHaskell使えと言っとるだろがボケ。
150 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:23:34.50 ID:zSFGO6dq.net] >>144 俺はあなたに釣られちゃったけどこれが真実です ideone.com/rVg5CP
151 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:26:16.20 ID:Qr5LJlmv.net] このスレって常連の2、3人がID変えながら互いを罵ってんだよな?
152 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:27:35.65 ID:3jiwec3B.net] >>150 C++14の結果のようだが コミュ障は去れ
153 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:28:27.16 ID:oAun2w+9.net] >>148 えっえっ?!?! 今の今まで「14になったら使える機能か楽しみだ」と思ってた...
154 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:30:40.94 ID:hs0c0BKx.net] > C++14の結果のようだが そこは突っ込むのが正解なのかw なんか深遠な理由があるのか 高度な釣りなのかわかりかねたわ(>>144 に対してC++14の結果貼り付け)
155 名前:デフォルトの名無しさん [2016/01/27(水) 21:33:45.85 ID:0q1DRp6s.net] 初期化子って何だ? もしかしてメンバイニシャライザのこと?
156 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:36:46.74 ID:0q1DRp6s.net] >>153 Exceptional C++に出てくるぐらいにはメジャーだったはずだぞ
157 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:40:42.54 ID:3jiwec3B.net] >>155 それはですね 狡猾な>>140 が初期化子リストとメンバー初期化子とコンストラクター初期化子を混同した>>138 を惑わすために出した用語なんです気にしないで ちなみに規格ではnew A(100)とかの『(100)』の部分を指します
158 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:40:46.23 ID:5WlKM79a.net] >>155 > メンバイニシャライザ それちなみにどこで習ったの? どこの流儀?
159 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:42:32.38 ID:zSFGO6dq.net] >>152 はあそんなところに突っ込まれるとはw >>153 あなたはC++14でもだめでC++17になったら出来るかもって思ってたでしょw
160 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:43:28.66 ID:oAun2w+9.net] 申し訳ない。釣りではなく本当にfunction-try-blockはこれから来る規格だと思っていた。 >>156 持ってるけどそんな記述あったかな?
161 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:43:53.84 ID:3jiwec3B.net] >>158 >>141 を100回読み直してこい
162 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:45:04.77 ID:0q1DRp6s.net] >>158 流儀? メンバ変数の初期化を行うのはmember initializerだぞ
163 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:46:53.21 ID:gqKHFo+S.net] >>150 > B() try : _id(GetId()), _a(_id) > { > cout << "B:B" << _id << endl; > } > catch(int ex) > { > cout << "B:B" << _id << " exception " << ex << endl; このcatch内でのメンバ変数 _id の参照は未定義動作になる。 15.3 [except.handle] p10 > Referring to any non-static member or base class of an object in the > handler for a function-try-block of a constructor or destructor for that > object results in undefined behavior.
164 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:47:25.50 ID:0q1DRp6s.net] >>160 お前絶対読んでないだろw
165 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:48:01.49 ID:VHRBi97o.net] >>162 ごめんごめん、純粋に何でその名前を学んだか知りたかっただけ 上でも書いたけど俺はC++プライマーって本を読んで学んだんだけど たしかそれは 初期化リスト って書いてあったはずなんだ(多分) だからみんなソレをどこで学んで何と呼んでるのか気になっただけ
166 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:49:15.00 ID:oAun2w+9.net] 多分、なんか大昔の記事を読んで最新のものと勘違いしたまま来てしまったのだ... 鬱だ
167 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:51:52.82 ID:zSFGO6dq.net] >>163 ごめん その点は危ういと思ったけどGCCだと取り敢えず意図通りになってたから 話の本筋的にはどうでもいいと思っちゃった
168 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:52:17.67 ID:0q1DRp6s.net] すまん見直したらMoreの方だったw
169 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:52:25.06 ID:3jiwec3B.net] >>163 そういやそんな決まりがあったな すっかり忘れてた
170 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:54:30.71 ID:oAun2w+9.net] >>168 安心した。ありがとう。 俺が持ってるのは2000年11月15日発行とある。 みなさん、すいませんでした。
171 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 21:54:40.52 ID:88/bqypu.net] みんな企画とか読んでるのか偉いですね 1ページも読んだことないわ
172 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 22:01:47.89 ID:0q1DRp6s.net] >>170 Moreも2001年なんだから安心するなよw その頃からメジャーどころは載ってたはずだ
173 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 22:10:37.63 ID:0q1DRp6s.net] >>165 あまり意識したことはないので 恐らくコンパイラのメッセージだな 規格も読んだが後付けだと思う
174 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 22:13:35.94 ID:oAun2w+9.net] 鬱だ
175 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 22:15:41.80 ID:jBJgujTM.net] >>173 > 恐らくコンパイラのメッセージだな なるほどなるほど! こういうレスをついにもらえて俺喜んでる
176 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 22:27:11.15 ID:vltUk2i7.net] ここは罵倒したりされたりを楽しむ変態スレ。 記憶でレス→お前バカか→バカはお前→証拠だオラ→悪ぃ悪ぃw これが挨拶みたいなもん。 一度した発言は曲げてはならないという。
177 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 22:35:48.89 ID:zgyqI55G.net] RAIIは論理的には正しいかもしれないが 記述量の割に得られる対価が例外に対する備えだけ、 というのが気に入らない RAIIなプログラムのメモリ消費量はなかなか安定に達しないから(∵確保したり開放したりで断片化が進んだり治まったり、 意図とはうらはらに、実は第三者に対してメモリリークが無いことの証拠提示がヒジョーに厄介なプログラムになってしまったりする
178 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 22:45:20.30 ID:gqKHFo+S.net] >>177 隙だらけすぎるだろ。 > 記述量の割に得られる対価が例外に対する備えだけ、 基本的なところは標準ライブラリでカバーされてるんだけど、記述量ってどんなコード想定してんの? それに、例外以外にreturnやbreakにも利くよ。 > RAIIなプログラムのメモリ消費量はなかなか安定に達しないから(∵確保したり開放したりで断片化が進ん 確保解放のパターンがRAIIで規定されるわけないし、使い方でどうにでもなるでしょ。 > 意図とはうらはらに、実は第三者に対してメモリリークが無いことの証拠提示がヒジョーに厄介なプログラムに RAII使わない、生でdeleteやらなんやら書いてるコードよりはマシでしょ。悪化する例があるなら見たい。
179 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 22:49:16.44 ID:zSFGO6dq.net] >>177 ?それはおかしな見解だな RAIIを徹底するほうが記述量も少なくなる(delete書かなくて済むんだから)し、 メモリリークが無いことも遥かに容易に証明できると思うが? それで納得しない第三者なんて頭が腐ってるんだから相手にするだけ無駄 断片化については直接new、deleteするのと変わらないし
180 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 22:55:49.88 ID:zgyqI55G.net] >>178 いちいちstd::shared_ptr<T>とか打ちたくないし、pSomeSmartPtr.get()ですらちょっと嫌 メモリ直接ならまだ標準ライブラリでカバーされるが、OSがハンドルを返す場合はwrapperを書かねばならない そしてコンストラクタが例外をスローするのに処置しようとしたら、 漏れの無いtry { } catch { }を書くか、メンバ変数を全部wrapperかスマポにせねばならない これは苦行以外の何者でもない そしてクラスの群れを書く面々のうちの誰か一人がしくじれば、やはりリークする returnやbreakについては、例外と違って伝統的な書き方で対処可能 例外はスマポとか、try { } catch { } みたいな仕掛けが要る
181 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 22:56:07.86 ID:3jiwec3B.net] 記述量は局所的な見た目の煩雑さのことを言ってるのだろうに トータルの記述量の話にすり替えとはこれ如何に
182 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 22:59:19.51 ID:zgyqI55G.net] >>179 >そしてクラスの群れを書く面々のうちの誰か一人がしくじれば、やはりリークする この危険性についてコードを見るだけで検証完了という信じる方がよっぽどキチ 同じコードを見る話なら、固定長の配列の方が安心できる
183 名前:デフォルトの名無しさん [2016/01/27(水) 23:00:49.72 ID:0xRCKJUw.net] あらゆる箇所にいちいちdelete Tとか打ちたくないわ
184 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:04:15.53 ID:zgyqI55G.net] >>183 もちろんナマポも極力使わない やっても関数内で確保したやつを関数を抜けるとき全部開放する使い方のみとしたい(この用途にはstd::unique_ptr<T>を使ってやっても良い この構造に統一するなら、メモリの断片化は生じない(まあだれか一人がしくじれば…というのは同じだが
185 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:07:10.32 ID:zSFGO6dq.net] なんだ固定長配列至上主義者か せいぜい頑張って下さい
186 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:08:36.16 ID:3jiwec3B.net] >この危険性についてコードを見るだけで検証完了という信じる方がよっぽどキチ 文脈を考慮して読み解かなくても局所的なコード確認の積み重ねのみで全体に漏れがないことを保証できるのがRAIIだと思っていたのだが…
187 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:13:29.29 ID:zgyqI55G.net] 加えてRAIIにはマルチコア時代にふさわしくない疑いがある RAIIで確保したり開放したるするメモリがスレッド固有という保証が無い限り、 確保や開放の度に排他制御が行われる スタック上にとられた配列がペナルティーゼロであることを鑑みれば、 InterlockedIncrement()ですら塵も積もれば巨大なコスト足りえる
188 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:18:25.90 ID:zSFGO6dq.net] そんなにヘビーなループで確保/解放を繰り返さなきゃいけない場面では俺だってダイナミックアロケーションを避けるけどね
189 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:20:30.30 ID:eULyfEEH.net] >>187 言っていることがよくわからないね shared_ptrのコストが気になるならnewせずに スタック上に確保するなりなんなりすればよいだけだろうに そっちの方が正統派のRAIIだというのに何を言っているのだろうか まったくお門違い むしろスタック上にオブジェクトを確保できる言語の方が珍しくて C++ではそれができるだけでも有り難いというのに
190 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:20:47.91 ID:I7Q8DIXY.net] 普段よりも応用を利かせたコードの書き方の検討をして、まだ知識があいまいなところ をはっきりさせようと、本で調べ物をしてたら、「プログラミング言語 第3版」よりも、 「C++ Primer 改訂3版」のほうが、はっきりと疑問に答えてくれると感じた。応用で検討 していることが可能になるか、それとも無理かをすぐに結論を出してくれるみたいな。 もう一方の本は、ストラウストラップ流のプログラム技術の英知を読者に提供しようとは してるようだけど、仕様で細かいところを素早く確認するのはまだ物足りないかもしれな いな。
191 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:21:41.35 ID:3jiwec3B.net] >スレッド固有という保証が無い限り、 確保や開放の度に排他制御が行われる >スレッド固有という保証が無い限り、 確保や開放の度に排他制御が行われる >スレッド固有という保証が無い限り、 確保や開放の度に排他制御が行われる ひょっとしてRAII=shared_ptrとでも勘違いしたのだろうかこの馬鹿は 👀 Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
192 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:26:34.20 ID:I7Q8DIXY.net] 今は「プログラミング言語 第4版」が新しく出たようだけど、今はC++14らしいが、 この本はC++11のようで、編集が一歩遅れてるという印象は否めない。 読者はC++14準拠の第5版を望んでるかもしれないな。
193 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:27:07.17 ID:0q1DRp6s.net] >>177 >記述量の割に得られる対価が例外に対する備えだけ さすがにこれはないわなあ 今更RAII無しでlockとか絶対使いたくない
194 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:47:08.39 ID:0q1DRp6s.net] ここまで俺の自演
195 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:47:41.22 ID:tYkYQITg.net] 前にEffectiveC++も新版が出たけど、もう絶対的な名著ってわけでもないような
196 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:52:26.77 ID:gqKHFo+S.net] >>180 10年ぐらい前にはこんな爺さんがよく居たもんだが、まだ居るのか・・・。 > いちいちstd::shared_ptr<T>とか打ちたくないし、pSomeSmartPtr.get()ですらちょっと嫌 慣れる。どうしても嫌なら好きに using でもしとけばいい。 get() なんて使わんでいい。 > メモリ直接ならまだ標準ライブラリでカバーされるが、OSがハンドルを返す場合はwrapperを書かねばならない 自分で書くケースがあるのはそうだが、稀だろ。 稀じゃないなら、個別に破棄処理を漏れなく書いて回るよりも一度書けば済むRAIIのほうがマシ。 > メンバ変数を全部wrapperかスマポにせねばならない > これは苦行以外の何者でもない std::shared_ptr<T>が打てない状況ならそうかもしれないな。 でもそれは個人的な事情であってRAIIの問題じゃない。 > そしてクラスの群れを書く面々のうちの誰か一人がしくじれば、やはりリークする RAII関係ない。 > returnやbreakについては、例外と違って伝統的な書き方で対処可能 伝統的で且つ面倒な書き方でな。RAIIのほうが楽。
197 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:54:32.28 ID:0q1DRp6s.net] >>195 古いのは確かだがまだ十分使えると思うね 他に初心者用の良い本があれば別だけど
198 名前:デフォルトの名無しさん mailto:sage [2016/01/27(水) 23:57:30.71 ID:0q1DRp6s.net] スマポはgoogleやmozillaのソース見ればそこらじゅうにあるな それを全部書き下せる自身があるならどうぞ
199 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 00:38:12.26 ID:5VmqP1pO.net] >>132 絶望した! >>135 いやいや、初期化子に並んでるクラスまでtryで囲む必要ないでしょ? 彼らは彼らで後始末するのだから。 自分の後始末せずに例外投げるクラスがいたら、どんな手段を使ったって後始末できないよ。 コンストラクタに限る問題じゃない。
200 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 01:13:22.83 ID:9zxCdjKY.net] >>199 後始末したあと例外を投げて来るやつをcatchするんじゃない?
201 名前:デフォルトの名無しさん [2016/01/28(木) 06:48:43.02 ID:OteWNMPZ.net] RAIIってなんて発音するの? ライー? ラッツー?
202 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 07:29:19.73 ID:y2I8o1dH.net] ラール
203 名前:デフォルトの名無しさん [2016/01/28(木) 07:37:04.01 ID:WeC7vVSZ.net] ライッ!
204 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 07:41:40.98 ID:y2I8o1dH.net] >>199 catch(...)
205 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 08:26:24.97 ID:5VmqP1pO.net] >>204 言葉足らずですまんが、自分が言及した自分自身の後始末っていうのはそのクラス内部の後始末のこと。 ハードを止めるとかメンバのメモリ開放とか。 使う側のクラスは後始末しないクラスの内部のことなんてわからないから、どんな手段を使ったってそのクラスの後始末はできない。 だから、そんなクラスがいることを前提として議論するのはおかしいってこいいたかったわけ。 そのクラスの提供者に直してもらうしかない。
206 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 08:35:58.09 ID:9zxCdjKY.net] >>205 それは正しいが、そこが論点じゃないと思う。 コンストラクタ内でエラーが起きたとき、「後始末はちゃんとやったあと例外をthrowする」クラスに 対処することを想定してる。
207 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 08:51:24.46 ID:5VmqP1pO.net] >>206 対処する必要なんてあるの? 繰り返すけど、 初期化子で構築完了したクラスはデストラクタで後始末されて、例外吐いたクラスも自身のtrycatch再throwで後始末してるんだぜ? 親側自身の雑多な初期化処理は始まってもいない。 …と書いてみたが、自分が間違ってるわ。 これで対応できない例外シチュもあり、そんな場合は個別対応すればよいだろうとは思ってたけど、例外とは呼べないほどそんな場面は多い気がしてきた。
208 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 09:29:37.28 ID:ptM8I7fQ.net] >>207 「これで対応できない例外シチュ」ってどんなの?
209 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 11:10:21.47 ID:5VmqP1pO.net] >>208 dispose()とかclose()みたいな関数を呼んでやらないと終了処理できないやつ。
210 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 11:21:23.95 ID:ptM8I7fQ.net] >>209 fclose や fstream みたいな、能動的操作処理と破棄処理が不可分になってるもののことかな。 そういうクラスをメンバを持つクラスのコンストラクタで例外が出たとした場合に行う「個別対応」って、 たとえばどんなの? デストラクタが最低限の処理をしてくれてれば何もしなくていいケースがほとんどだと思うんだけど。
211 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 13:13:16.79 ID:5VmqP1pO.net] >>210 終了処理がsendfinとかwaittimeoutとかだったりしたら、デストラクタで勝手にやられたら困らね? 非対称的に終了処理関数が用意されてることも少なくないと思う。 バグなら直せと言えるけど、設計いけてないから直せとはなかなか要求しにくい。
212 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 13:56:52.11 ID:tIrgtpz+.net] デストラクタでfcloseとか何ですのん? ファイル操作をオブジェクトの寿命で扱うのって大掴みすぎねぇ? だからコンストラクタやデストラクタでそんなもんの例外までに話が至っちまう 書き込む瞬間、読み無瞬間だけ一瞬だけファイルを開けや そこまではバッファに書きこんどけや糞ども
213 名前:デフォルトの名無しさん [2016/01/28(木) 14:51:57.24 ID:Fy8z7rZ+.net] 一つわかった RAIIと例外を背反と考えてる人がいる
214 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 19:35:11.13 ID:CFwd7jm1.net] >>212 ログライブラリを開発しているのですが 一瞬だけ開くようにすると処理時間が100 倍以上 になって困っています。 どうすればよいですか?
215 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 19:59:05.52 ID:9zxCdjKY.net] >>212 ファイル書き込みオブジェクトをファクトリ関数経由で 一時オブジェクトとしてしか生成できないようにしたことがある。 書き込んだらすぐデストラクタが走るのさ。
216 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 19:59:21.20 ID:D7v4IB1O.net] バッファが無限にあると思ってる人に聞くだけ無駄
217 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 20:01:49.04 ID:VbpHGgsr.net] >>215 kwsk
218 名前:片山博文MZ ◆T6xkBnTXz7B0 mailto:sage [2016/01/28(木) 20:02:05.39 ID:YC3cOEYy.net] >>214 出力が遅いなら、キャッシュとして出力内容をためておけば
219 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 20:11:54.15 ID:D7v4IB1O.net] アプリが落ちて肝心な最後のログレコードが見えないのでしたチャンチャン
220 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 21:05:31.79 ID:DYq8nyhg.net] ログを安易にバッファリングする奴は間違いなく低能
221 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 23:03:17.58 ID:iP985GXo.net] 自作プログラムのログを取る必要が未だ生じたことが無い天才かも知れん
222 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 23:07:22.96 ID:YmAPLaNv.net] んなこたない 糞コテ=馬鹿 で決まり
223 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 23:11:59.87 ID:iP985GXo.net] ログメッセージを複数スレッドから単一のコンソールに出す場合はcerrよりcoutの方がメッセージの1行同士が混ざる危険性が目に見えて減る デバッグレベルならprintf()して何か条件を満たしたらfflush(stdout); throw;、が最強
224 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 23:17:33.09 ID:Fy8z7rZ+.net] >>223 >ログメッセージを複数スレッドから単一のコンソールに出す場合はcerrよりcoutの方がメッセージの1行同士が混ざる危険性が目に見えて減る 気のせいだろ マルチスレッドなら、素直に同期したほうが良いぞ
225 名前:デフォルトの名無しさん mailto:sage [2016/01/28(木) 23:50:40.02 ID:ptM8I7fQ.net] >>211 その困る場合の「対処」の例が聞きたかった。 デストラクタに嫌な終了処理が埋まってて困るという場合は対処のしようも無い =結局何もしなくていいんじゃないの? それで実用上の問題があるなら直せと言えるはず。 コンストラクタで例外が飛んだってことは問題の終了処理を持つオブジェクトを使って やろうとしてた処理全体は失敗したわけで、正常処理の締めに必要な 終了処理( fstream で close() とか)の明示的呼び出しも必要ないことが多いだろうし。
226 名前:デフォルトの名無しさん mailto:sage [2016/01/29(金) 19:24:04.25 ID:dpjhh/AA.net] >>52 > > A *a(int i) {return as.add(new A(i));} > add() の中の push_back() で例外飛んだらリークする。 これはpush_back()出来なかった分をケアしてやればおk? https://ideone.com/s4ibLz ・天然のstd::bad_allocは得られなかったので誤魔化した
227 名前:デフォルトの名無しさん mailto:sage [2016/01/29(金) 21:58:56.14 ID:V57FZVNV.net] 生ポ好きの書きそうな糞みたいなコードだな ↓こんなんでいいだろ v.reserve(v.size() + 1); v.push_back(new Fuck);