On Sat, 27 Oct 2018 at 01:27, Joe Buck 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
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
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 empt
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
On 26/10/18 08:25 +0200, Marc Glisse wrote:
On Fri, 26 Oct 2018, Jonathan Wakely wrote:
For the libc++ string zeroing the length of a small string happens to
be faster.
Ah, yes, of course.
Is it? In debug mode, I'd be tempted to leave the string as
"moved" (size 5, short string so there is
On 26/10/18 12:16 +0300, Ville Voutilainen wrote:
On Fri, 26 Oct 2018 at 01:42, Marc Glisse 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 y
On Fri, 26 Oct 2018 at 01:42, Marc Glisse 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 we
On Fri, 26 Oct 2018, Jonathan Wakely wrote:
For the libc++ string zeroing the length of a small string happens to
be faster.
Ah, yes, of course.
Is it? In debug mode, I'd be tempted to leave the string as "moved" (size
5, short string so there is no allocation).
That's not a bad idea.
Al
On 26/10/18 00:17 +0100, Jonathan Wakely wrote:
On 26/10/18 00:42 +0200, Marc Glisse 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 c
On 26/10/18 00:42 +0200, Marc Glisse 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 k
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 slight
On Thu, 25 Oct 2018, Jonathan Wakely wrote:
When an SSO string is contained in the small string buffer or has an
unequal allocator a move operation performs a copy, leaving the original
data in the moved-from string. Setting the length of the moved-from
string to zero is not required, so we can
On Fri, 26 Oct 2018 at 00:54, Jonathan Wakely wrote:
>
> When an SSO string is contained in the small string buffer or has an
> unequal allocator a move operation performs a copy, leaving the original
> data in the moved-from string. Setting the length of the moved-from
> string to zero is not req
13 matches
Mail list logo
