From: John Baldwin <jhb@freebsd.org>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 3/3] Do not use std::move when assigning an anonymous object to a unique_ptr.
Date: Wed, 23 Nov 2016 23:31:00 -0000 [thread overview]
Message-ID: <1950124.hOhKlgFiTt@ralph.baldwin.cx> (raw)
In-Reply-To: <f98690353911d4c4c1ea59c45d5b085f@polymtl.ca>
On Wednesday, November 23, 2016 04:19:29 PM Simon Marchi wrote:
> On 2016-11-23 15:06, John Baldwin wrote:
> > Using std::move forces an extra copy of the object. These changes fix
> > -Wpessimizing-move warnings from clang.
>
> For those who, like me, do not quite understand what is happening here,
> I suggest the following read:
>
> https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/RVO_V_S_std_move?lang=en
My head also hurts. I think what clang is warning about is that the
std::move() in these lines breaks RVO for the function being called,
not the function that the modified line belongs to. That is:
foo = bar ();
Is able to do RVO if bar() does the right things for RVO to work.
However:
foo = std::move (bar ());
forces an extra copy of the object since the return value of bar
can't use the storge of 'foo' directly, it has to be copied into
an anonymous object (I think) for std::move to consume.
The commit log for the warning is here:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20150427/128053.html
I think these instances fall under the "using a move to create a new object
from a temporary object" case.
--
John Baldwin
next prev parent reply other threads:[~2016-11-23 23:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-23 20:07 [PATCH 0/3] Fix various C++ related clang warnings John Baldwin
2016-11-23 20:08 ` [PATCH 2/3] Add noexcept to custom non-throwing new operators John Baldwin
2016-11-24 17:03 ` Pedro Alves
2016-11-23 20:08 ` [PATCH 3/3] Do not use std::move when assigning an anonymous object to a unique_ptr John Baldwin
2016-11-23 21:19 ` Simon Marchi
2016-11-23 23:31 ` John Baldwin [this message]
2016-11-24 0:08 ` Simon Marchi
2016-11-24 16:52 ` Pedro Alves
2016-11-23 20:08 ` [PATCH 1/3] Fix mismatched struct vs class tags John Baldwin
2016-11-23 20:58 ` Simon Marchi
2016-11-23 23:23 ` John Baldwin
2016-11-24 17:02 ` Pedro Alves
2016-11-24 17:47 ` John Baldwin
2016-11-24 18:50 ` Pedro Alves
2016-11-24 19:15 ` John Baldwin
2016-11-30 11:39 ` Pedro Alves
2016-11-30 16:23 ` John Baldwin
2016-11-30 16:38 ` Pedro Alves
2016-11-30 16:52 ` Simon Marchi
2016-11-30 16:51 ` Simon Marchi
2016-11-30 17:08 ` Pedro Alves
2016-11-30 17:54 ` Simon Marchi
2016-11-30 17:59 ` Eli Zaretskii
2016-11-23 22:18 ` [PATCH 0/3] Fix various C++ related clang warnings Simon Marchi
2016-11-23 23:23 ` John Baldwin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1950124.hOhKlgFiTt@ralph.baldwin.cx \
--to=jhb@freebsd.org \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox