On Sat, 27 Oct 2018 at 01:27, Joe Buck <joe.b...@synopsys.com> wrote: > > The reason move constructors were introduced was to speed up code in cases > where an object > Is copied and the copy is no longer needed. It is unfortunate that there may > now be code out > there that relies on accidental properties of library implementations. It > would be best if the > Implementation is not constrained. Unless the standard mandates that, after > a string is moved, > the string is empty, the user should only be able to assume that it is in > some consistent but > unspecified state. Otherwise we pay a performance penalty forever. > > If the standard explicitly states that the argument to the move constructor > is defined to be > empty after the call, we're stuck.
It certainly doesn't specify so for an SSO string, so we're not stuck. On the other hand, we already get a speed-up, it's just not as much of a speed-up as it can be. What I really loathe is the potential implementation divergence; it's all good for the priesthood to refer to the standard and say "you shouldn't have done that", but that's, as a good friend of mine provided as a phrasing on a different manner, spectacularly unhelpful.
