This is the mail archive of the
mailing list for the libstdc++ project.
Re: RFC: Allow moved-from strings to be non-empty
- From: François Dumont <frs dot dumont at gmail dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Fri, 28 Dec 2018 09:02:28 +0100
- Subject: Re: RFC: Allow moved-from strings to be non-empty
- References: <20181025215349.GA12654@redhat.com> <CAFk2RUYJJSXGZB2fVYebAC-1xgoSRQH99kfmmqK=DksSS02hXw@mail.gmail.com> <alpine.DEB.email@example.com> <CAFk2RUZGtHycvWjqGGtpbvK6TG0oQWjt4oPzCh65eoH2HFYcgw@mail.gmail.com> <20181026095539.GX23172@redhat.com> <CAFk2RUbu_81F1obeViygmm_+fW+e5DB8O7DDPu1=VjouS-Tafw@mail.gmail.com> <alpine.DEB.firstname.lastname@example.org> <CCD865889A560649BA947E1B934A8D7D02234DB6EC@US01WEMBX2.internal.synopsys.com> <CAFk2RUaCO8jWUqHQOqCbXFpCPpDpjFj=Oygj__GTwZXDUFCC1Q@mail.gmail.com> <email@example.com> <20181221204226.GH3077@redhat.com>
On 12/21/18 9:42 PM, Jonathan Wakely wrote:
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 <firstname.lastname@example.org> 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
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 am even misunderstanding myself ! Sorry, wrong analogy indeed.
Yes, pedantic mode is not meant for that. We would need an option to
detect portability issue for behaviors that are not described by the
Standard but if it is limited to this situation it might not worth it.
This is why I consider using pedantic mode for it in the first place I
I'll add to my TODO to detect this kind of invalid usage in Debug
I'm not sure we want to do that; code relying on it might be
non-portable, but it's not undefined.