This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Allow moved-from strings to be non-empty
On Fri, 26 Oct 2018 at 12:55, Jonathan Wakely <jwakely@redhat.com> wrote:
> >> Why not? There are already several, and it helps find bugs. Maybe you
> >> could convince libc++ to change as well if you want to keep the behavior
> >> the same?
> >
> >What bugs?
>
> Assuming the string is empty after a move and appending to it without
> calling clear() first.
I find it bloody unfortunate that the standard considers that a bug.
It seems quite convenient
to me that it's possible to have a bag of strings, move some of them
out to be processed,
and be able to tell the processed ones from the unprocessed ones
without having to separately
clear them when moving.
> >> > It does slightly concern me that some users might
> >> > actually semantically expect a moved-from string to be empty, even
> >> > though that's not guaranteed, although for non-SSO cases
> >> > it *is* guaranteed.
> >>
> >> Is it? In debug mode, I'd be tempted to leave the string as "moved" (size
> >> 5, short string so there is no allocation).
> >
> >Sigh. Apparently it isn't, because the standard doesn't bother placing
> >complexity
> >requirements on string constructors.
>
> Writing 5 bytes into the SSO buffer would be constant complexity :-P
Indeed it would, but the standard doesn't seem to have complexity
requirements on string constructors
at all. If it did, moving a non-sso string would *have to* steal from
the source, and the sso case
would not have to do that, but could.
> >Even so, I'd prefer string acting
> >like vector,
> >so that it will leave the source of a move in an empty state, rather
> >than an unspecified
> >state.
>
> It's not guaranteed for vector either. An allocator with POCMA==false
> doesn't propagate on move assignment and if the source object's
> allocator isn't equal to the target's it will copy, and there's no
> guarantee the source will be empty.
Right, I was talking about homogeneous vectors; it is well-known that
non-propagating allocators
don't move. Except when they do (on move construction).