This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Fri, 26 Oct 2018, Ville Voutilainen wrote:

On Fri, 26 Oct 2018 at 12:55, Jonathan Wakely <> 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.

We all seem to want different things from move:

1) copy, possibly with a speed up because I don't care what the source looks like afterwards. That's what was standardized, and for a small string that means that moving it should just copy.

2) move and clear

3) move and destroy

(most likely many others)

The convenience does not seem that great to me, especially if it has a performance cost.

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.

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.

I am not sure what you are saying exactly, but I think "noexcept" is (kind of) playing the role of a complexity requirement here.

Marc Glisse

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]