4 ms·
Oh, I didn't know about this one. I did some search, and looks like it should be "valid but unspecified state" after move? I can't think of any case that rely
by kkimdev 7y ago
Oh, I didn't know about this one. I did some search, and looks like it should be "valid but unspecified state" after move?
I can't think of any case that relying on unspecified state is desirable even if it's valid, though I guess it's better if I change that to x.pop_back(); to be clear.
Please let me know if my understanding is incorrect and thanks for the information!
- lmitchell 7y agoThe only thing 'unspecified' guarantees you in this context is 'safe to destroy'. It specifically does not guarantee the safety of any other member functions - only the destructor. So either push_back() or pop_back() could potentially cause UB here (specifically, it's quite possible that the move swaps some internal pointers for nullptr, so you end up dereferencing null here - but morally, it's just never okay to continue using a moved-from object).
- millstone 7y agoThe vector is "valid" and that is what carries all the weight here. The vector is still a vector. push_back is absolutely defined. pop_back might be undefined, because pop_back is UB on an empty vector. If you like, call clear, and be assured of an empty, reusable vector. It's not idiomatic, but it's safe.
- pbsd 7y agoA moved-from std::vector<int> will always be empty. However, a moved-from std::vector<int, custom_stateful_allocator> may not be. Howard Hinnant had a Stack Overflow reply a while back going through the possible corner cases of this precise question: https://stackoverflow.com/a/17735913 https://stackoverflow.com/a/17735913