3 ms·
> when you std::move a string, the data() buffer would remain unchanged You cannot assume anything about the state of a moved-from object. AFAIK, the only vali
by zvrba 7y ago
> when you std::move a string, the data() buffer would remain unchanged
You cannot assume anything about the state of a moved-from object. AFAIK, the only valid operations are destruction and assigning something else to it.
- leni536 7y agoNot entirely true. Moving from std::vector is required to not invalidate iterators and references when moved from. This is why strings can be small buffer optimized and vectors can't be.
- zvrba 7y agoThis does not conflict with what I or the OP wrote; you're mixing up the vector and its contents. Moving from a vector can invalidate `data()`, yet references and iterators to its previous contents remain valid.
- steerablesafe 7y agoWell, kccqzy probably meant the pointer returned by data remaining valid, not calling data() again on a moved-from object.
- quietbritishjim 7y ago> You cannot assume anything about the state of a moved-from object. This is the right default assuption, but classes are allowed to have (and document) more specific behaviour. For example, it is guaranteed that std::unique_ptr and std::shared_ptr are empty (nullptr) after they have been moved from, and std::vector is guaranteed to be empty after it is moved from so long as the destination allocator is the same. > AFAIK, the only valid operations are destruction and assigning something else to it. Even for classes whose move constructors have no guarantees, there are often other methods that don't have any preconditions, such as calling clear() or resize(0). In fact is it allowed to call other operations and they should behave consistently, it's just not guaranteed what exact value the object should have (e.g. if size() > 0 then .at(0) should not throw and a second call to it should return the same value as the first call to it).
- zvrba 7y agoYou're right. But I've given up "language lawyering" a long time ago: I have a set of "rules of thumb" (like the one I just wrote) that exclude some technically valid programs, (but so be it) and that let me write robust code quickly without spending time on digging through the documentation for special cases. Even if I did know every single edge case in the language and library, the developers next to me might not. Then they decide to emulate me (many learn by example) and catastrophe ensues.
- scatters 7y agoYou're misinterpreting the parent. They mean that they thought data() of the target after the move would be the same as data() of the source before the move. This is guaranteed by vector, for example.