This is the mail archive of the
mailing list for the libstdc++ project.
Re: RFC: Allow moved-from strings to be non-empty
- From: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- To: "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Cc: Jonathan Wakely <jwakely at redhat dot com>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 26 Oct 2018 12:16:16 +0300
- 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>
On Fri, 26 Oct 2018 at 01:42, Marc Glisse <firstname.lastname@example.org> wrote:
> On Fri, 26 Oct 2018, Ville Voutilainen wrote:
> > I would rather not introduce a behavioral difference between us and
> > libc++.
> 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?
> > 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
requirements on string constructors. Even so, I'd prefer string acting
so that it will leave the source of a move in an empty state, rather
than an unspecified
state. Despite the standard not requiring that, it's more useful
to have the empty state than the unspecified state, especially when the state
is empty in some cases anyway.