Re: RFC: Allow moved-from strings to be non-empty

[Jonathan Wakely <jwakely at redhat dot com>]

On 30/10/18 07:48 +0100, François Dumont wrote:
> On 10/27/18 12:33 AM, Ville Voutilainen wrote:
> > On Sat, 27 Oct 2018 at 01:27, Joe Buck <joe.buck@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.
> +1 to allow moved-from strings to be non-empty
>
> In many cases move will take place on temporary instances which future 
> is just to be destroyed.
>
> It's already too bad that in such situation we sometimes do some 
> allocation because current implementation do not support none 
> (std::deque)
>
> Note that on vector we already have this undefined behavior within 
> libstdc++ itself. On std::vector move constructor empty the moved 
> instance but allocator extended one with equal allocator instance 
> don't, it just swap content.

But the content of the new object being constructed is empty, because
it's a new object being constructed. It doesn't have any elements. So
if you swap the content, the moved instance becomes empty. Or have I
misunderstood what you're saying?

> I'll add to my TODO to detect this kind of invalid usage in Debug 
> pendantic mode.

I'm not sure we want to do that; code relying on it might be
non-portable, but it's not undefined.