From: Pedro Alves <palves@redhat.com>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v2 5/5] Eliminate make_cleanup_ui_file_delete / make ui_file a class hierarchy
Date: Wed, 25 Jan 2017 18:37:00 -0000 [thread overview]
Message-ID: <0d567b53-4944-2553-9bf7-81a189f15ca7@redhat.com> (raw)
In-Reply-To: <4ced996ee1ea0ceef2ec994afeca6bb7@polymtl.ca>
On 01/24/2017 07:14 PM, Simon Marchi wrote:
> Oh, I guess it's because buf.string() returns a reference and not a
> string directly. Otherwise, then I guess the compiler could have done
> some return value optimization (look at me, using words I don't
> understand).
I think that if buf.string() returned a copy instead of
a reference, then all the compiler could do in
std::string foo ()
{
string_file buf;
...
return buf.string_copy ();
}
or:
std::string foo ()
{
string_file buf;
std::string tmp;
tmp = buf.string_copy ();
return tmp;
}
is make sure to copy only once, from the buf straight
to the caller. But there would still be one copy. Unless
the compiler is smart enough to understand that buf is dying
at the end of the function and all buf destruction does is
destroy the string, so it could safely move the string
out of buf before buf is destroyed. But I don't think
compilers are that smart, unfortunately.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2017-01-25 18:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-17 1:39 [PATCH 0/5] Eliminate cleanups & make ui_file a C++ " Pedro Alves
2017-01-17 1:39 ` [PATCH 5/5] Eliminate make_cleanup_ui_file_delete / make ui_file a " Pedro Alves
2017-01-17 19:57 ` Simon Marchi
2017-01-17 19:58 ` Simon Marchi
2017-01-23 16:58 ` Pedro Alves
2017-01-23 17:17 ` Pedro Alves
2017-01-23 19:18 ` Simon Marchi
2017-01-23 23:19 ` [PATCH v2 " Pedro Alves
2017-01-24 18:29 ` Simon Marchi
2017-01-24 19:14 ` Simon Marchi
2017-01-25 18:37 ` Pedro Alves [this message]
2017-01-25 17:52 ` Pedro Alves
2017-01-25 19:31 ` Pedro Alves
2017-01-25 19:47 ` [PATCH v3 " Pedro Alves
2017-02-01 0:31 ` Pedro Alves
2017-01-25 18:27 ` [PATCH v2 " Pedro Alves
2017-01-24 19:11 ` Simon Marchi
2017-01-25 18:28 ` Pedro Alves
2017-01-25 18:39 ` Simon Marchi
2017-01-25 18:41 ` Pedro Alves
2017-01-17 1:39 ` [PATCH 2/5] gdb/varobj.c: Fix leak Pedro Alves
2017-01-17 1:39 ` [PATCH 1/5] gdb: make_scoped_restore and types convertible to T Pedro Alves
2017-01-17 1:39 ` [PATCH 3/5] gdb/stack.c: Remove unused mem_fileopen Pedro Alves
2017-01-17 1:47 ` [PATCH 4/5] gdb/mi/mi-interp.c: Fix typos Pedro Alves
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=0d567b53-4944-2553-9bf7-81a189f15ca7@redhat.com \
--to=palves@redhat.com \
--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