std::list<>::splice invalidates iterators. Rationale?

Question

I wonder what is the rationale behind making std::list<>::splice to invalidate the iterators that refer to the subsequence being spliced into the new container. This looks kinda illogical to me, especially in light of standard std::container::swap specification. According to the language standard std::container::swap does not invalidate any iterators. This is a perfectly reasonable practical specification. However, I'd say that std::list<>::splice would also benefit greatly from iterator-preserving behavior.

I understand that there might be some purely academic considerations based on the concepts of iterator reachability, etc. But at the same time splice is a std::list-specific operation, meaning that providing a custom-tailored specification for it probably would not make a serious conceptual damage to the STL design in general.

So what was it? Would it outlaw or overcomplicate some practical implementations of std::list, which I fail to recognize?

possible duplicate of [splice() on std::list and iterator invalidation](http://stackoverflow.com/questions/143156/splice-on-stdlist-and-iterator-invalidation) — jwismar, Jul 05 '12 at 21:31

score 8 · Accepted Answer · answered Jul 05 '12 at 21:29

8

In C++11 splice does not invalidate the iterators, but make them refer to the appropriate elements in the *this container. This is all described in 23.3.5.5.

answered Jul 05 '12 at 21:29

David Rodríguez - dribeas

204,818
23
294
489

Oh, OK. Just found that. So, apparently there was no good reason for the invalidation requirement. My question arises mostly after seeing how many hoops and loops Microsoft has to jump through in their STL implementation to provide "iterator debugging" support for both `swap` and `splice`. Thanks for the answer. – AnT stands with Russia Jul 05 '12 at 21:33
@AndreyT "_So, apparently there was no good reason for the invalidation requirement._" Not really. At some point, the committee wanted to fully support _unequal_ memory allocators, and these allocators are not compatible, so a some copying would be needed in _this very special case_. – curiousguy Aug 16 '12 at 03:13

score 4 · Answer 2 · answered Aug 11 '12 at 00:42

4

If the containers have customised, unequal (non compatible) allocators, you cannot swap pointers, you have no choice but to really copy elements around.

answered Aug 11 '12 at 00:42

curiousguy

8,038
2
40
58

std::list<>::splice invalidates iterators. Rationale?

2 Answers2