On Thu, 25 Oct 2018, Jonathan Wakely wrote:
When an SSO string is contained in the small string buffer or has an
unequal allocator a move operation performs a copy, leaving the original
data in the moved-from string. Setting the length of the moved-from
string to zero is not required, so we can avoid two writes (to the
length member and to set the first character to nul) by leaving the
moved-from string unchanged.
This might be surprising to some users, who (wrongly) expect a string
to always be empty after a move. Is that acceptable?
It's worth noting that the current behaviour, where we do more work
than required, also surprises some people, e.g.
https://stackoverflow.com/q/52696413/981959
Some tests need to be adjusted due to the new behaviour, but they have
comments saying they're testing specific implementation details, so I
don't think needing to adjust them is an argument against making the
change:
// NOTE: This makes use of the fact that we know how moveable
// is implemented on string (via swap). If the implementation changed
// this test may begin to fail.
Should we make this change?
I didn't read the patch, but from the description above, I say yes.
Interesting that I got my relocate patch in before, because after your
patch relocate probably helps a little less than before.
--
Marc Glisse