Use string_file::release in some places

Message ID 20230921194207.2401885-1-tromey@adacore.com
State New
Headers
Series Use string_file::release in some places |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 success Testing passed
linaro-tcwg-bot/tcwg_gdb_build--master-arm success Testing passed

Commit Message

Tom Tromey Sept. 21, 2023, 7:42 p.m. UTC
  I found a few spots like:

    string_file f;
    std::string x = f.string ();

However, string_file::string returns a 'const std::string &'...  so it
seems to me that this must be copying the string (? I find it hard to
reason about this in C++).

This patch changes these spots to use release() instead, which moves
the string.
---
 gdb/breakpoint.c | 2 +-
 gdb/top.c        | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
  

Comments

Keith Seitz Sept. 22, 2023, 8:42 p.m. UTC | #1
On Thu, Sep 21, 2023 at 12:42 PM Tom Tromey via Gdb-patches
<gdb-patches@sourceware.org> wrote:
>
> I found a few spots like:
>
>     string_file f;
>     std::string x = f.string ();
>
> However, string_file::string returns a 'const std::string &'...  so it
> seems to me that this must be copying the string (? I find it hard to
> reason about this in C++).

I admit, you now have me doubting everything I thought I remembered
on this subject! [TODO: reread the standard literature]

As far as I can tell, your assessment is at least consistent with what is
done elsewhere, e.g., location.c, ada-lang,c, and just about everywhere
else except the two locations you've identified in this patch.

Would symtab.c's symbol_to_info_string and valops.c:incomplete_type_hint
also qualify for similar treatment? They use addition assignment, so maybe
that alters the analogy?

In any case:
Reviewed-by: Keith Seitz <keiths@redhat.com>

Keith
  
Lancelot SIX Sept. 25, 2023, 9:40 a.m. UTC | #2
On Fri, Sep 22, 2023 at 01:42:22PM -0700, Keith Seitz via Gdb-patches wrote:
> On Thu, Sep 21, 2023 at 12:42 PM Tom Tromey via Gdb-patches
> <gdb-patches@sourceware.org> wrote:
> >
> > I found a few spots like:
> >
> >     string_file f;
> >     std::string x = f.string ();
> >
> > However, string_file::string returns a 'const std::string &'...  so it
> > seems to me that this must be copying the string (? I find it hard to
> > reason about this in C++).

Hi Tom and Keith,

I think your assessment is correct.  Such case calls the string copy
operator[1] (i.e. `std::string::string (const std::string &)` - plus the
template expansion).

Same goes for the "return f.string ();" cases from a function returning
a std::string.

FWIW, the changes you made seems good to me.
Reviewed-by: Lancelot Six <lancelot.six@amd.com>

> 
> I admit, you now have me doubting everything I thought I remembered
> on this subject! [TODO: reread the standard literature]
> 
> As far as I can tell, your assessment is at least consistent with what is
> done elsewhere, e.g., location.c, ada-lang,c, and just about everywhere
> else except the two locations you've identified in this patch.
> 
> Would symtab.c's symbol_to_info_string and valops.c:incomplete_type_hint
> also qualify for similar treatment? They use addition assignment, so maybe
> that alters the analogy?

In those cases, because the += operator is used, there is no move
semantics which can be leveraged[2].  This operator can only be used
with:
- const std::string & (what is currently used)
- char
- const char *
- std::initializer_list<char>

C++17 also adds string_view based option, but in all the cases we copy
the data from the argument.

Best,
Lancelot.
> 
> In any case:
> Reviewed-by: Keith Seitz <keiths@redhat.com>
> 
> Keith
> 

[1] https://en.cppreference.com/w/cpp/language/copy_initialization
[2] https://en.cppreference.com/w/cpp/string/basic_string/operator%2B%3D
  
Tom Tromey Sept. 26, 2023, 12:59 p.m. UTC | #3
>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:

Keith> Would symtab.c's symbol_to_info_string and valops.c:incomplete_type_hint
Keith> also qualify for similar treatment? They use addition assignment, so maybe
Keith> that alters the analogy?

These two could accumulate all the text into a single string_file.
Maybe that would be slightly better.

Anyway I'm checking this in.

Tom
  

Patch

diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index d807ae3c9b5..f9b20a7d62d 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -7581,7 +7581,7 @@  bp_location::to_string () const
   string_file stb;
   ui_out_redirect_pop redir (current_uiout, &stb);
   print_breakpoint_location (this->owner, this);
-  return stb.string ();
+  return stb.release ();
 }
 
 /* Decrement reference count.  If the reference count reaches 0,
diff --git a/gdb/top.c b/gdb/top.c
index 2322e55f1db..cbe14b01046 100644
--- a/gdb/top.c
+++ b/gdb/top.c
@@ -647,12 +647,12 @@  execute_fn_to_string (std::string &res, std::function<void(void)> fn,
   catch (...)
     {
       /* Finally.  */
-      res = std::move (str_file.string ());
+      res = str_file.release ();
       throw;
     }
 
   /* And finally.  */
-  res = std::move (str_file.string ());
+  res = str_file.release ();
 }
 
 /* See gdbcmd.h.  */