C++相談室 part122 [無断転載禁止]©5ch.io
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2016/01/23(土) 23:06:15.32ID:HdItgJjmただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレに
お願いします。
前スレ
C++相談室 part121
http://peace.2ch.net/test/read.cgi/tech/1449240881/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.97【環境依存OK】
http://peace.2ch.net/test/read.cgi/tech/1439849418/
次期規格C++1zはこちら
C++14/C++1z 20
http://peace.2ch.net/test/read.cgi/tech/1410382924/
■長いソースを貼るときはここへ。■
http://codepad.org/
http://ideone.com/
0153デフォルトの名無しさん
2016/01/27(水) 21:28:27.16ID:oAun2w+9えっえっ？！？！
今の今まで「14になったら使える機能か楽しみだ」と思ってた...
0154デフォルトの名無しさん
2016/01/27(水) 21:30:40.94ID:hs0c0BKxそこは突っ込むのが正解なのかｗ
なんか深遠な理由があるのか
高度な釣りなのかわかりかねたわ（>>144に対してC++14の結果貼り付け）
0155デフォルトの名無しさん
2016/01/27(水) 21:33:45.85ID:0q1DRp6sもしかしてメンバイニシャライザのこと？
0156デフォルトの名無しさん
2016/01/27(水) 21:36:46.74ID:0q1DRp6sExceptional C++に出てくるぐらいにはメジャーだったはずだぞ
0157デフォルトの名無しさん
2016/01/27(水) 21:40:42.54ID:3jiwec3Bそれはですね
狡猾な>>140が初期化子リストとメンバー初期化子とコンストラクター初期化子を混同した>>138を惑わすために出した用語なんです気にしないで
ちなみに規格ではnew A(100)とかの『(100)』の部分を指します
0158デフォルトの名無しさん
2016/01/27(水) 21:40:46.23ID:5WlKM79a> メンバイニシャライザ
それちなみにどこで習ったの？
どこの流儀？
0159デフォルトの名無しさん
2016/01/27(水) 21:42:32.38ID:zSFGO6dqはあそんなところに突っ込まれるとはｗ
>>153
あなたはC++14でもだめでC++17になったら出来るかもって思ってたでしょｗ
0160デフォルトの名無しさん
2016/01/27(水) 21:43:28.66ID:oAun2w+9>>156
持ってるけどそんな記述あったかな？
0161デフォルトの名無しさん
2016/01/27(水) 21:43:53.84ID:3jiwec3B>>141を100回読み直してこい
0162デフォルトの名無しさん
2016/01/27(水) 21:45:04.77ID:0q1DRp6s流儀？
メンバ変数の初期化を行うのはmember initializerだぞ
0163デフォルトの名無しさん
2016/01/27(水) 21:46:53.21ID:gqKHFo+S> 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.
0164デフォルトの名無しさん
2016/01/27(水) 21:47:25.50ID:0q1DRp6sお前絶対読んでないだろｗ
0165デフォルトの名無しさん
2016/01/27(水) 21:48:01.49ID:VHRBi97oごめんごめん、純粋に何でその名前を学んだか知りたかっただけ
上でも書いたけど俺はC++プライマーって本を読んで学んだんだけど
たしかそれは 初期化リスト って書いてあったはずなんだ（多分）
だからみんなソレをどこで学んで何と呼んでるのか気になっただけ
0166デフォルトの名無しさん
2016/01/27(水) 21:49:15.00ID:oAun2w+9鬱だ
0167デフォルトの名無しさん
2016/01/27(水) 21:51:52.82ID:zSFGO6dqごめん
その点は危ういと思ったけどGCCだと取り敢えず意図通りになってたから
話の本筋的にはどうでもいいと思っちゃった
0168デフォルトの名無しさん
2016/01/27(水) 21:52:17.67ID:0q1DRp6s0169デフォルトの名無しさん
2016/01/27(水) 21:52:25.06ID:3jiwec3Bそういやそんな決まりがあったな
すっかり忘れてた
0170デフォルトの名無しさん
2016/01/27(水) 21:54:30.71ID:oAun2w+9安心した。ありがとう。
俺が持ってるのは2000年11月15日発行とある。
みなさん、すいませんでした。
0171デフォルトの名無しさん
2016/01/27(水) 21:54:40.52ID:88/bqypu1ページも読んだことないわ
0172デフォルトの名無しさん
2016/01/27(水) 22:01:47.89ID:0q1DRp6sMoreも2001年なんだから安心するなよｗ
その頃からメジャーどころは載ってたはずだ
0173デフォルトの名無しさん
2016/01/27(水) 22:10:37.63ID:0q1DRp6sあまり意識したことはないので
恐らくコンパイラのメッセージだな
規格も読んだが後付けだと思う
0174デフォルトの名無しさん
2016/01/27(水) 22:13:35.94ID:oAun2w+90175デフォルトの名無しさん
2016/01/27(水) 22:15:41.80ID:jBJgujTM> 恐らくコンパイラのメッセージだな
なるほどなるほど！
こういうレスをついにもらえて俺喜んでる
0176デフォルトの名無しさん
2016/01/27(水) 22:27:11.15ID:vltUk2i7記憶でレス→お前バカか→バカはお前→証拠だオラ→悪ぃ悪ぃw
これが挨拶みたいなもん。
一度した発言は曲げてはならないという。
0177デフォルトの名無しさん
2016/01/27(水) 22:35:48.89ID:zgyqI55G記述量の割に得られる対価が例外に対する備えだけ、
というのが気に入らない
RAIIなプログラムのメモリ消費量はなかなか安定に達しないから（∵確保したり開放したりで断片化が進んだり治まったり、
意図とはうらはらに、実は第三者に対してメモリリークが無いことの証拠提示がﾋｼﾞｮｰに厄介なプログラムになってしまったりする
0178デフォルトの名無しさん
2016/01/27(水) 22:45:20.30ID:gqKHFo+S隙だらけすぎるだろ。
> 記述量の割に得られる対価が例外に対する備えだけ、
基本的なところは標準ライブラリでカバーされてるんだけど、記述量ってどんなコード想定してんの？
それに、例外以外にreturnやbreakにも利くよ。
> RAIIなプログラムのメモリ消費量はなかなか安定に達しないから（∵確保したり開放したりで断片化が進ん
確保解放のパターンがRAIIで規定されるわけないし、使い方でどうにでもなるでしょ。
> 意図とはうらはらに、実は第三者に対してメモリリークが無いことの証拠提示がﾋｼﾞｮｰに厄介なプログラムに
RAII使わない、生でdeleteやらなんやら書いてるコードよりはマシでしょ。悪化する例があるなら見たい。
0179デフォルトの名無しさん
2016/01/27(水) 22:49:16.44ID:zSFGO6dq？それはおかしな見解だな
RAIIを徹底するほうが記述量も少なくなる（delete書かなくて済むんだから）し、
メモリリークが無いことも遥かに容易に証明できると思うが？
それで納得しない第三者なんて頭が腐ってるんだから相手にするだけ無駄
断片化については直接new、deleteするのと変わらないし
0180デフォルトの名無しさん
2016/01/27(水) 22:55:49.88ID:zgyqI55Gいちいちstd::shared_ptr<T>とか打ちたくないし、pSomeSmartPtr.get()ですらちょっと嫌
メモリ直接ならまだ標準ライブラリでカバーされるが、OSがハンドルを返す場合はwrapperを書かねばならない
そしてコンストラクタが例外をスローするのに処置しようとしたら、
漏れの無いtry { } catch { }を書くか、メンバ変数を全部wrapperかスマポにせねばならない
これは苦行以外の何者でもない
そしてクラスの群れを書く面々のうちの誰か一人がしくじれば、やはりリークする
returnやbreakについては、例外と違って伝統的な書き方で対処可能
例外はスマポとか、try { } catch { } みたいな仕掛けが要る
0181デフォルトの名無しさん
2016/01/27(水) 22:56:07.86ID:3jiwec3Bトータルの記述量の話にすり替えとはこれ如何に
0182デフォルトの名無しさん
2016/01/27(水) 22:59:19.51ID:zgyqI55G>そしてクラスの群れを書く面々のうちの誰か一人がしくじれば、やはりリークする
この危険性についてコードを見るだけで検証完了という信じる方がよっぽどｷﾁ
同じコードを見る話なら、固定長の配列の方が安心できる
0183デフォルトの名無しさん
2016/01/27(水) 23:00:49.72ID:0xRCKJUw0184デフォルトの名無しさん
2016/01/27(水) 23:04:15.53ID:zgyqI55Gもちろんﾅﾏﾎﾟも極力使わない
やっても関数内で確保したやつを関数を抜けるとき全部開放する使い方のみとしたい（この用途にはstd::unique_ptr<T>を使ってやっても良い
この構造に統一するなら、メモリの断片化は生じない（まあだれか一人がしくじれば…というのは同じだが
0185デフォルトの名無しさん
2016/01/27(水) 23:07:10.32ID:zSFGO6dqせいぜい頑張って下さい
0186デフォルトの名無しさん
2016/01/27(水) 23:08:36.16ID:3jiwec3B文脈を考慮して読み解かなくても局所的なコード確認の積み重ねのみで全体に漏れがないことを保証できるのがRAIIだと思っていたのだが…
0187デフォルトの名無しさん
2016/01/27(水) 23:13:29.29ID:zgyqI55GRAIIで確保したり開放したるするメモリがスレッド固有という保証が無い限り、
確保や開放の度に排他制御が行われる
スタック上にとられた配列がペナルティーゼロであることを鑑みれば、
InterlockedIncrement()ですら塵も積もれば巨大なコスト足りえる
0188デフォルトの名無しさん
2016/01/27(水) 23:18:25.90ID:zSFGO6dq0189デフォルトの名無しさん
2016/01/27(水) 23:20:30.30ID:eULyfEEH言っていることがよくわからないね
shared_ptrのコストが気になるならnewせずに
スタック上に確保するなりなんなりすればよいだけだろうに
そっちの方が正統派のRAIIだというのに何を言っているのだろうか
まったくお門違い
むしろスタック上にオブジェクトを確保できる言語の方が珍しくて
C++ではそれができるだけでも有り難いというのに
0190デフォルトの名無しさん
2016/01/27(水) 23:20:47.91ID:I7Q8DIXYをはっきりさせようと、本で調べ物をしてたら、「プログラミング言語 第3版」よりも、
「C++ Primer 改訂3版」のほうが、はっきりと疑問に答えてくれると感じた。応用で検討
していることが可能になるか、それとも無理かをすぐに結論を出してくれるみたいな。
もう一方の本は、ストラウストラップ流のプログラム技術の英知を読者に提供しようとは
してるようだけど、仕様で細かいところを素早く確認するのはまだ物足りないかもしれな
いな。
0191デフォルトの名無しさん
2016/01/27(水) 23:21:41.35ID:3jiwec3B確保や開放の度に排他制御が行われる
>スレッド固有という保証が無い限り、
確保や開放の度に排他制御が行われる
>スレッド固有という保証が無い限り、
確保や開放の度に排他制御が行われる
ひょっとしてRAII＝shared_ptrとでも勘違いしたのだろうかこの馬鹿は 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
0192デフォルトの名無しさん
2016/01/27(水) 23:26:34.20ID:I7Q8DIXYこの本はC++11のようで、編集が一歩遅れてるという印象は否めない。
読者はC++14準拠の第5版を望んでるかもしれないな。
0193デフォルトの名無しさん
2016/01/27(水) 23:27:07.17ID:0q1DRp6s>記述量の割に得られる対価が例外に対する備えだけ
さすがにこれはないわなあ
今更RAII無しでlockとか絶対使いたくない
0194デフォルトの名無しさん
2016/01/27(水) 23:47:08.39ID:0q1DRp6s0195デフォルトの名無しさん
2016/01/27(水) 23:47:41.22ID:tYkYQITg0196デフォルトの名無しさん
2016/01/27(水) 23:52:26.77ID:gqKHFo+S１０年ぐらい前にはこんな爺さんがよく居たもんだが、まだ居るのか・・・。
> いちいちstd::shared_ptr<T>とか打ちたくないし、pSomeSmartPtr.get()ですらちょっと嫌
慣れる。どうしても嫌なら好きに using でもしとけばいい。 get() なんて使わんでいい。
> メモリ直接ならまだ標準ライブラリでカバーされるが、OSがハンドルを返す場合はwrapperを書かねばならない
自分で書くケースがあるのはそうだが、稀だろ。
稀じゃないなら、個別に破棄処理を漏れなく書いて回るよりも一度書けば済むRAIIのほうがマシ。
> メンバ変数を全部wrapperかスマポにせねばならない
> これは苦行以外の何者でもない
std::shared_ptr<T>が打てない状況ならそうかもしれないな。
でもそれは個人的な事情であってRAIIの問題じゃない。
> そしてクラスの群れを書く面々のうちの誰か一人がしくじれば、やはりリークする
RAII関係ない。
> returnやbreakについては、例外と違って伝統的な書き方で対処可能
伝統的で且つ面倒な書き方でな。RAIIのほうが楽。
0197デフォルトの名無しさん
2016/01/27(水) 23:54:32.28ID:0q1DRp6s古いのは確かだがまだ十分使えると思うね
他に初心者用の良い本があれば別だけど
0198デフォルトの名無しさん
2016/01/27(水) 23:57:30.71ID:0q1DRp6sそれを全部書き下せる自身があるならどうぞ
0199デフォルトの名無しさん
2016/01/28(木) 00:38:12.26ID:5VmqP1pO絶望した！
>>135
いやいや、初期化子に並んでるクラスまでtryで囲む必要ないでしょ？
彼らは彼らで後始末するのだから。
自分の後始末せずに例外投げるクラスがいたら、どんな手段を使ったって後始末できないよ。
コンストラクタに限る問題じゃない。
0200デフォルトの名無しさん
2016/01/28(木) 01:13:22.83ID:9zxCdjKY後始末したあと例外を投げて来るやつをcatchするんじゃない？
0201デフォルトの名無しさん
2016/01/28(木) 06:48:43.02ID:OteWNMPZライー？ ラッツー？
0202デフォルトの名無しさん
2016/01/28(木) 07:29:19.73ID:y2I8o1dH0203デフォルトの名無しさん
2016/01/28(木) 07:37:04.01ID:WeC7vVSZ0204デフォルトの名無しさん
2016/01/28(木) 07:41:40.98ID:y2I8o1dHcatch(...)
0205デフォルトの名無しさん
2016/01/28(木) 08:26:24.97ID:5VmqP1pO言葉足らずですまんが、自分が言及した自分自身の後始末っていうのはそのクラス内部の後始末のこと。
ハードを止めるとかメンバのメモリ開放とか。
使う側のクラスは後始末しないクラスの内部のことなんてわからないから、どんな手段を使ったってそのクラスの後始末はできない。
だから、そんなクラスがいることを前提として議論するのはおかしいってこいいたかったわけ。
そのクラスの提供者に直してもらうしかない。
0206デフォルトの名無しさん
2016/01/28(木) 08:35:58.09ID:9zxCdjKYそれは正しいが、そこが論点じゃないと思う。
コンストラクタ内でエラーが起きたとき、「後始末はちゃんとやったあと例外をthrowする」クラスに
対処することを想定してる。
0207デフォルトの名無しさん
2016/01/28(木) 08:51:24.46ID:5VmqP1pO対処する必要なんてあるの？
繰り返すけど、
初期化子で構築完了したクラスはデストラクタで後始末されて、例外吐いたクラスも自身のtrycatch再throwで後始末してるんだぜ？
親側自身の雑多な初期化処理は始まってもいない。
…と書いてみたが、自分が間違ってるわ。
これで対応できない例外シチュもあり、そんな場合は個別対応すればよいだろうとは思ってたけど、例外とは呼べないほどそんな場面は多い気がしてきた。
0208デフォルトの名無しさん
2016/01/28(木) 09:29:37.28ID:ptM8I7fQ「これで対応できない例外シチュ」ってどんなの？
0209デフォルトの名無しさん
2016/01/28(木) 11:10:21.47ID:5VmqP1pOdispose()とかclose()みたいな関数を呼んでやらないと終了処理できないやつ。
0210デフォルトの名無しさん
2016/01/28(木) 11:21:23.95ID:ptM8I7fQfclose や fstream みたいな、能動的操作処理と破棄処理が不可分になってるもののことかな。
そういうクラスをメンバを持つクラスのコンストラクタで例外が出たとした場合に行う「個別対応」って、
たとえばどんなの？
デストラクタが最低限の処理をしてくれてれば何もしなくていいケースがほとんどだと思うんだけど。
0211デフォルトの名無しさん
2016/01/28(木) 13:13:16.79ID:5VmqP1pO終了処理がsendfinとかwaittimeoutとかだったりしたら、デストラクタで勝手にやられたら困らね？
非対称的に終了処理関数が用意されてることも少なくないと思う。
バグなら直せと言えるけど、設計いけてないから直せとはなかなか要求しにくい。
0212デフォルトの名無しさん
2016/01/28(木) 13:56:52.11ID:tIrgtpz+ファイル操作をオブジェクトの寿命で扱うのって大掴みすぎねぇ？
だからコンストラクタやデストラクタでそんなもんの例外までに話が至っちまう
書き込む瞬間、読み無瞬間だけ一瞬だけファイルを開けや
そこまではバッファに書きこんどけや糞ども
0213デフォルトの名無しさん
2016/01/28(木) 14:51:57.24ID:Fy8z7rZ+RAIIと例外を背反と考えてる人がいる
0214デフォルトの名無しさん
2016/01/28(木) 19:35:11.13ID:CFwd7jm1ログライブラリを開発しているのですが
一瞬だけ開くようにすると処理時間が100 倍以上
になって困っています。
どうすればよいですか？
0215デフォルトの名無しさん
2016/01/28(木) 19:59:05.52ID:9zxCdjKYファイル書き込みオブジェクトをファクトリ関数経由で
一時オブジェクトとしてしか生成できないようにしたことがある。
書き込んだらすぐデストラクタが走るのさ。
0216デフォルトの名無しさん
2016/01/28(木) 19:59:21.20ID:D7v4IB1O0217デフォルトの名無しさん
2016/01/28(木) 20:01:49.04ID:VbpHGgsrkwsk
0219デフォルトの名無しさん
2016/01/28(木) 20:11:54.15ID:D7v4IB1O0220デフォルトの名無しさん
2016/01/28(木) 21:05:31.79ID:DYq8nyhg0221デフォルトの名無しさん
2016/01/28(木) 23:03:17.58ID:iP985GXo0222デフォルトの名無しさん
2016/01/28(木) 23:07:22.96ID:YmAPLaNv糞コテ＝馬鹿 で決まり
0223デフォルトの名無しさん
2016/01/28(木) 23:11:59.87ID:iP985GXoデバッグレベルならprintf()して何か条件を満たしたらfflush(stdout); throw;、が最強
0224デフォルトの名無しさん
2016/01/28(木) 23:17:33.09ID:Fy8z7rZ+>ログメッセージを複数スレッドから単一のコンソールに出す場合はcerrよりcoutの方がメッセージの1行同士が混ざる危険性が目に見えて減る
気のせいだろ
マルチスレッドなら、素直に同期したほうが良いぞ
0225デフォルトの名無しさん
2016/01/28(木) 23:50:40.02ID:ptM8I7fQその困る場合の「対処」の例が聞きたかった。
デストラクタに嫌な終了処理が埋まってて困るという場合は対処のしようも無い
＝結局何もしなくていいんじゃないの？
それで実用上の問題があるなら直せと言えるはず。
コンストラクタで例外が飛んだってことは問題の終了処理を持つオブジェクトを使って
やろうとしてた処理全体は失敗したわけで、正常処理の締めに必要な
終了処理（ fstream で close() とか）の明示的呼び出しも必要ないことが多いだろうし。
0226デフォルトの名無しさん
2016/01/29(金) 19:24:04.25ID:dpjhh/AA> > A *a(int i) {return as.add(new A(i));}
> add() の中の push_back() で例外飛んだらリークする。
これはpush_back()出来なかった分をケアしてやればおｋ？
https://ideone.com/s4ibLz
・天然のstd::bad_allocは得られなかったので誤魔化した
0227デフォルトの名無しさん
2016/01/29(金) 21:58:56.14ID:V57FZVNV↓こんなんでいいだろ
v.reserve(v.size() + 1);
v.push_back(new Fuck);
0228デフォルトの名無しさん
2016/01/29(金) 22:53:49.61ID:tuK26dsCブログラミングを種に喧嘩ばかりしてるやつって何なの
チンパンジーなの？
0229デフォルトの名無しさん
2016/01/29(金) 23:21:25.56ID:q1Jl0W+Y誤爆か？
0230デフォルトの名無しさん
2016/01/29(金) 23:29:27.61ID:HWJSMXKPそんな意味不明なreserveする奴が偉そうなこと言っても
0231デフォルトの名無しさん
2016/01/29(金) 23:35:27.84ID:ASWZHNV8おじいちゃん、「おとなしくスマートポインタ使えば」おｋだっていったでしょ。聞こえてる？
0232デフォルトの名無しさん
2016/01/29(金) 23:52:06.13ID:Hpd/92hjいや意味が全く無いわけではない
std::vector::push_back()呼び出し時点での余分な領域確保とか、速度低下が最小化される
0233デフォルトの名無しさん
2016/01/30(土) 00:09:33.50ID:VhIzDspW230 じゃないけど、 >227 の reserve() で「速度低下が最小化される」なんてことは無いでしょ。
単発なら変わらないだろうし、ループした場合は reserve() しないほうが速いし。
0234デフォルトの名無しさん
2016/01/30(土) 00:17:51.94ID:lYkNZO2mないない
push_backで領域が足りなければreserve相当のことは自動的にされるし
まあないだろうがstd::vectorの実装によってはsize()+1のreserveが速度に悪影響与えることだってあり得るんじゃないかな
>>227のもう一つ痛いところはreserveさえしておけばpush_backでの例外が無いと決めつけてるところ
そんな規定はないだろ？
0235デフォルトの名無しさん
2016/01/30(土) 00:21:53.24ID:nKxSIfYZ> push_backでの例外が無いと決めつけてるところ
というより、それを一切考慮してない希ガスｗ
そいつ一人だけ問題の本質に到達できていない
bad_allocが投げられるのは一緒ってことも知らないんだろうし
0236デフォルトの名無しさん
2016/01/30(土) 00:55:16.18ID:GfziY5060237デフォルトの名無しさん
2016/01/30(土) 03:14:53.57ID:HpDJFp9+漏れは慎重に「std::vector::push_back()呼び出し時点での」と限定して書いたで？
0238デフォルトの名無しさん
2016/01/30(土) 05:43:02.21ID:VhIzDspWん？だから何？
push_back() 関数内での領域確保・実行時間を減らして、それらを push_back() の
直前の処理に移動することに何か意味があるとでもいうの？それはどんな場合にうれしいの？
0239デフォルトの名無しさん
2016/01/30(土) 05:59:47.15ID:GfziY506「〜される」
B「そんなことは ない」
A「そんなこと ある だろ」
B「だから何？〜だと何かいいことあるのか？」
>>232の2つの文のどちらについて話をしているのかの認識がずれていることに気付かない低能どもの会話は滑稽だな
0240デフォルトの名無しさん
2016/01/30(土) 06:17:44.28ID:GfziY506メモリ確保のnew/deleteは禁止にしてスマポとコンテナーだけ使っとけ
ついでに馬鹿はshared_ptrも使用禁止にしといた方が安全
0241デフォルトの名無しさん
2016/01/30(土) 11:02:01.65ID:u8r8Wxi4> v.push_back(new Fuck);
やっぱり馬鹿にC++は無理だなｗ
push_backの直前で+1サイズのreserveとかｗ
http://www.cplusplus.com/reference/vector/vector/reserve/
ここのExampleみてお勉強しなおしたら？
例外投げるのも書いてくれるから学んどけよ
0242デフォルトの名無しさん
2016/01/30(土) 11:46:11.52ID:GfziY506push_backはcapacityに余裕が有るときに再アロケーションしないことは保証されているが
例外を出さない保証は23.3.6.5から読みとれないな
やはり馬鹿にはスマポを強制したほうがいい
0243デフォルトの名無しさん
2016/01/30(土) 13:13:55.69ID:VK1fBsAoreserve()とpush_back()のどちらで例外が発生するかという文脈において、
>>227のreserve()がpush_back()の直前行であるという解釈は一体…
まあv.reserve(v.size() + n);ならともかく、v.reserve(v.size() + 1);だったから気持ちはわからんでもない
0244デフォルトの名無しさん
2016/01/30(土) 14:18:45.97ID:GfziY506何を言ってるんだお前は
0245デフォルトの名無しさん
2016/01/30(土) 15:00:28.25ID:9j1RlcoP0246デフォルトの名無しさん
2016/01/30(土) 16:17:33.41ID:GfziY506挿入前に拡張すると(要素のコンストラクター以外では)例外が出ないという保証はある？
0247デフォルトの名無しさん
2016/01/30(土) 16:22:43.98ID:AurOqJPwCとなら関係あるかも知れないが、プログラミング言語でないC。
もちろん俺の読み違いかもしれない。
0248デフォルトの名無しさん
2016/01/30(土) 16:27:26.60ID:7MlWNObS☆一行のとき
v.push_back(foo); // ここで例外
☆二行のとき
v.reserve(v.size() + 1); // ここで例外
v.push_back(foo);
こうなるだけじゃないの？
新たな連続した一本のメモリが確保できないと例外なんだから
0249デフォルトの名無しさん
2016/01/30(土) 16:35:52.43ID:lYkNZO2m規格を読んだ限り保証はされてないね
現実に存在する実装ではreserve済みであれば生ポのpush_backじゃ例外発生しないだろうけどね
そんなことはアテにしちゃいけない
0250デフォルトの名無しさん
2016/02/01(月) 01:01:58.63ID:CuJD672cnewを一旦別の変数で受けるしかないでしょ
hoge h;
h = new hoge;
vec.push_back(h);
が正解。
0251デフォルトの名無しさん
2016/02/01(月) 01:58:17.63ID:fnCrDph6バカはnewを書くな！
0252デフォルトの名無しさん
2016/02/01(月) 02:09:31.02ID:CuJD672cあんたバカバカ言ってるけどnewを使うかmake_sharedを使うかはこの問題の本質じゃないから。
馬鹿じゃないならわかるよね？
■ このスレッドは過去ログ倉庫に格納されています