From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 970C3385BF83 for ; Tue, 31 Mar 2020 19:23:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 970C3385BF83 Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-240-JvdvbbyMMe2Zu_NR2bBVWQ-1; Tue, 31 Mar 2020 15:23:55 -0400 X-MC-Unique: JvdvbbyMMe2Zu_NR2bBVWQ-1 Received: by mail-ed1-f72.google.com with SMTP id eb6so19484794edb.12 for ; Tue, 31 Mar 2020 12:23:55 -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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZdT/ZE9QpiSF9V+lOAdsjHjlPgwCZfcaDR9kftD/alQ=; b=Hw75AuDbMXhCy72YuQZVUwG1l0CGpbmlvDr+mLI/DcwKPRGo3A7woDu1VxoBnKHqdT j7cxJGRwTw5IRTnKdK+Vm0dBzu1H24WXBT9PE3RgygrBHo8ePCYofyPOFmc5s/H3r4C9 NHA3Tv4TdyhDxXq3A3ENZaOP2loXu5VOnTEQjLb8OsFUKhd8XYt4iP7UCPSFMxVJgV3v 7KtMEB8vKwiRlWD9sQcDB+DFhL80KjHiFRR8U5grefmvXhaF1X4LxMLx/NGQCd7XODZQ 3wWFFulclu51tf8hvc+AdLXUvQbXd3o01FH7t70cyoR0CEfYu9yLp9kRBOrDx0EU4UeU HGpA== X-Gm-Message-State: ANhLgQ37wx4NPxnjdGGv0K9jZTyp8/arzMZCsrJtQeAG85QfegZK80qR UnnRr3SUKD2UemFK08gkVw4s1pdGD1srrg0ysywts6oV+kY89U4u2OJQW1PNCLtNRLWILxszQQ1 gKuLdg9PTUvVT5YQ5pTsM4g== X-Received: by 2002:a17:906:33d3:: with SMTP id w19mr16435866eja.134.1585682634219; Tue, 31 Mar 2020 12:23:54 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtFPfqNbmgUb4CKHDe++6yxUMmyhSV3iNEvvHdsuTnytrU5kAZKzLyIS90kYTzEf7+txm0MyA== X-Received: by 2002:a17:906:33d3:: with SMTP id w19mr16435851eja.134.1585682634028; Tue, 31 Mar 2020 12:23:54 -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 r9sm2304918ejb.8.2020.03.31.12.23.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 Mar 2020 12:23:53 -0700 (PDT) Subject: Re: [PATCH 2/2] Avoid copying in lookup_name_info To: Tom Tromey References: <20200320204935.19509-1-tromey@adacore.com> <20200320204935.19509-3-tromey@adacore.com> <87wo70baqu.fsf@tromey.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <3b48b922-0320-504a-36a4-3c14f6d789d7@redhat.com> Date: Tue, 31 Mar 2020 20:23:52 +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: <87wo70baqu.fsf@tromey.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=-8.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 19:23:58 -0000 On 3/31/20 8:11 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Pedro> I think it would be better for this overload to take a > Pedro> gdb::string_view instead of a const std::string& . That > Pedro> way, it still works if you only have a string_view handy. > Pedro> As is, there's no way to created a lookup_name_info starting > Pedro> with a string_view without copying. WDYT? > > The issue is that there's a trick in the implementation: > > /* Like the "name" method but guarantees that the returned string is > \0-terminated. */ > const char *c_str () const > { > /* Actually this is always guaranteed due to how the class is > constructed. */ > return m_name.data (); > } > > This is needed in some spots. > > However, if we take a string_view at construction, then we'd be > violating the string_view contract, or we'd need to make a copy -- but > the former is bad, and the latter is the goal the patch. I see. I agree with leaving it as is then. Thanks, Pedro Alves