From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id C807A385DC00 for ; Tue, 31 Mar 2020 18:18:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C807A385DC00 Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-38-YZIevBj2OvGFj9LxOCqb8Q-1; Tue, 31 Mar 2020 14:18:11 -0400 X-MC-Unique: YZIevBj2OvGFj9LxOCqb8Q-1 Received: by mail-ed1-f71.google.com with SMTP id g7so19361740edm.20 for ; Tue, 31 Mar 2020 11:18:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=02cywjTKnUchFNOJ6vYkeaCnNDdmp+pqgWUCxD/zitc=; b=SW0FQlbiq5wqz8IRs75z6agUJsgHUCpTpm1FdwYOvnSyx+LDf+BwXIsra9DtWooeD6 g/QuPonpxjpLW0XeFPdxizzsNg+tidyYuSAdA4EPOAOd3TQ44punOrpmXGjSYD7ja0UE vpSFq/l4LJxaX25w9+P32gbrYn8tRkAu96iFWApxvyGngdRLmpxN5TtyqUrQvQwg0Xp4 2IEGvmXqAx2dHhGXkPwI3BBhzhLl7j+y+GZDPhcUeE+GmcZ355Ungwu2RkohX8jl7o/F 9CJYsmjEjE5zerxOT8CbnlbfEigkYfIcAWaQCk97BZAdJgVlgb43DHr2wfwhBcm3GC7c XFvQ== X-Gm-Message-State: ANhLgQ1SL07CaPsHsk8jrPT8TIYgfn5Fcmd+NjekA9tzNsbsx4W81wxh CFjHA/4bUeVOFawPpOkcmsKOhdi4gDUMCMj1fCGaztgl7SQti4RIbUCSLomTWgaF85OTyPndrKM f/b+mt6dEyvUaLYHNAZS2oA== X-Received: by 2002:a50:d552:: with SMTP id f18mr17948810edj.341.1585678690207; Tue, 31 Mar 2020 11:18:10 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsh1EArDBDEw07I86tczg0571Kv+NVKhPLPwKb6k75NsnPR1jtxnK9KZm8rE/K5+ZIJwCiRbw== X-Received: by 2002:a50:d552:: with SMTP id f18mr17948796edj.341.1585678690028; Tue, 31 Mar 2020 11:18:10 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id bz14sm371302ejc.55.2020.03.31.11.18.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 Mar 2020 11:18:09 -0700 (PDT) Subject: Re: [PATCH 2/2] Avoid copying in lookup_name_info To: Tom Tromey , gdb-patches@sourceware.org References: <20200320204935.19509-1-tromey@adacore.com> <20200320204935.19509-3-tromey@adacore.com> From: Pedro Alves Message-ID: Date: Tue, 31 Mar 2020 19:18:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20200320204935.19509-3-tromey@adacore.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-22.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 18:18:15 -0000 On 3/20/20 8:49 PM, Tom Tromey wrote: > return lookup_name; > diff --git a/gdb/symtab.h b/gdb/symtab.h > index 771b5ec5bf7..c80acc3a68e 100644 > --- a/gdb/symtab.h > +++ b/gdb/symtab.h > @@ -186,28 +186,62 @@ class lookup_name_info final > { > public: > /* Create a new object. */ > - lookup_name_info (std::string name, > + lookup_name_info (std::string &&name, > symbol_name_match_type match_type, > bool completion_mode = false, > bool ignore_parameters = false) > : m_match_type (match_type), > m_completion_mode (completion_mode), > m_ignore_parameters (ignore_parameters), > - m_name (std::move (name)) > + m_name_holder (std::move (name)), > + m_name (m_name_holder.c_str ()) > + {} > + > + /* This overload requires that NAME have a lifetime at least as long > + as the lifetime of this object. */ > + lookup_name_info (const std::string &name, I think it would be better for this overload to take a gdb::string_view instead of a const std::string& . That way, it still works if you only have a string_view handy. As is, there's no way to created a lookup_name_info starting with a string_view without copying. WDYT? And if we do that, do we have any case where we really need the "std::string &&" overload? You mention that normally copying isn't needed -- but when is copying needed? I.e., do we have cases where the lookup_name_info object doesn't have a lifetime greater than the original string? If there isn't, then we could also get rid of name_holder, and avoid having to remember that different ctors behave differently. Thanks, Pedro Alves