std::list::clear invalidates end iterator (bug?)

IIRC this was clarified in the standards between C++03 and C++11. In C++11, it is mandated by the standard that end() is invalidated when the container is cleared in this manner. C++03 was vague on this front and different SC++L implementations have been known to act differently.

I don't think C++11 mandates end() is invalidated, but specifies it may be invalidated. I'll have to grab an official copy later to double check, but the most recent draft says clear() for sequences in general "may invalidate the pass-the-end iterator." C++98 and C++03's description of std::list::clear() states that "Invalidates only the iterators and references to the erased elements." (Emphasis in both cases added by myself.) Interestingly, this draft of C++11 maintains the same wording for std::list::clear().

IIRC this was clarified in the standards between C++03 and C++11. In C++11, it is mandated by the standard that end() is invalidated when the container is cleared in this manner. C++03 was vague on this front and different SC++L implementations have been known to act differently.

My copy of the current standard states in [23.3.5.4](3) "Effects: Invalidates only the iterators and references to the erased elements."

However, Table 100, Sequence container requirements, in [23.2.3] states "Destroys all elements in a. Invalidates all references, pointers, and iterators referring to the elements of a and may invalidate the past-the-end iterator."

Both specifications are normative, but I would expect the stronger language of the specific specification in [23.3.5.4] would have stronger weight than the may clause of table 100. Nevertheless, given that there is no "unless otherwise specified" clause in [23.2.3](3), an implementation might just get away with invalidating end() on list::clear() and still be conforming.

DR 1213 points out that the meaning of "invalid iterator" is underdefined.

Ok, thanks for clarification. Rewrote the affected code.