Szelethus added a comment. In https://reviews.llvm.org/D54563#1301893, @NoQ wrote:
> In https://reviews.llvm.org/D54563#1299918, @Szelethus wrote: > > > How about `std::list<T>::splice`? > > > Hmm, you mean that it leaves its argument empty? Interesting, i guess we may > need a separate facility for that. I looked it up, and this is what I found: (source: http://eel.is/c++draft/list.ops) > `list` provides three `splice` operations that destructively move elements > from one list to another. The behavior of splice operations is undefined if > `get_allocator() != x.get_allocator()`. > > void splice(const_iterator position, list& x); > void splice(const_iterator position, list&& x); > > **Effects:** Inserts the contents of `x` before position and `x` becomes > empty. Pointers and references to the moved elements of `x` now refer to > those same elements but as members of *this. Iterators referring to the moved > >elements will continue to refer to their elements, but they now behave as > iterators into `*this`, not into `x`. This suggests to me that `list1.splice(list1.begin(), std::move(list2))` leaves `list` in a valid, well-defined, but empty state. > I wonder how many other state-reset methods are we forgetting. `merge` does something similar too for `map`, `multimap`, `set`, `multiset`, as well as their unordered counterparts. > As a TODO, we might want to warn anyway when the value of the argument is not > 0. Maybe leave a `TODO` in the code as well? ^-^ Repository: rC Clang https://reviews.llvm.org/D54563 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
