- 昨日・今日と泊りがけで出かける
- 泊まり先で2時間ぶっ通しで卓球@真剣
- 筋肉痛(特に右足のふくらはぎはどうも痛めたらしい)
アフォですな.いや,楽しかったけれど.別に遊びに行っていたわけじゃないですよよよ?
アフォですな.いや,楽しかったけれど.別に遊びに行っていたわけじゃないですよよよ?
STL(に限らず多くのコード)の実装の中には「一見自由度があるように見えて実はそれしかない」って感じの部分があって,その真意を理解するとついついうれしくなるんですけれどこういうのって私だけじゃないですよね?何か「奥が深い症候群」とか「バッドノウハウ」って言葉が頭をよぎりますが気のせいに違いない・・・.
template<class InputIterator1, class InputIterator2, class OutputIterator> OutputIterator merge(InputIterator1 first1, InputIterator last1, InputIterator2 first2, InputIterator last2, OutputIterator dest) { while(first1 != last1 && first2 != last2){ if(*first2 < *first1) // 何故に"*first2 < *first1"? *dest++ = *first2++; else *dest++ = *first1++; } dest = copy(first1, last1, dest); return copy(first2, last2, dest); }
こんなリファラが.折角だからstd::vector(std:deque)の例外安全性の表でも作ってみましょうかね.本来なら実装依存ですけれど,まぁこの表より例外安全性緩める理由は無いはず(というか自分がstd::vector作るならこうする).
value_typeのコピーコンストラクタ及び代入 | 強い | nothrow |
---|---|---|
コンストラクタ | 強い | 強い |
デストラクタ | nothrow | nothrow |
代入 | 強い | 強い |
push_back | 強い | 強い |
pop_back | nothrow | nothrow |
insert(最後尾はpush_backと同じ) | 基本 | 強い |
erase(最後尾はpop_backと同じ) | 基本 | 強い |
resize(要素数が減る場合) | nothrow | nothrow |
resize(要素数が増える場合) | 強い | 強い |
reserve | 強い | 強い |
clear | nothrow | nothrow |
ご存知のようにstd::vector(std::deque)に対して中間でinsert/eraseをやると他の要素の移動を伴う.この際に呼ばれるvalue_typeのコピーコンストラクタ(代入)から例外が飛んでくるとロールバックのしようがないので基本的な例外安全しか達成できない.ただし,std::dequeはこれに関して強い例外安全を達成できるような実装も可能なはず(若干オーバーヘッド高いけれど).