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

Reply via email to