This is the mail archive of the libstdc++@gcc.gnu.org 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 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.

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

François


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