From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42744 invoked by alias); 25 Jan 2017 18:37:30 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 42714 invoked by uid 89); 25 Jan 2017 18:37:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=dying, H*MI:sk:4ced996, H*f:sk:4ced996, H*i:sk:4ced996 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Jan 2017 18:37:28 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 007DBC001689; Wed, 25 Jan 2017 18:37:28 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0PIbOPN018151; Wed, 25 Jan 2017 13:37:27 -0500 Subject: Re: [PATCH v2 5/5] Eliminate make_cleanup_ui_file_delete / make ui_file a class hierarchy To: Simon Marchi References: <1484617147-2506-1-git-send-email-palves@redhat.com> <1484617147-2506-6-git-send-email-palves@redhat.com> <5533317a1fdb2e5f36e64731aef84993@polymtl.ca> <4a6cce94-1533-36e9-6015-330e2e014a98@redhat.com> <558e1e55-23eb-716e-8117-c18d7bded7b8@redhat.com> <79c06dbccef0c33309d208316be207f4@polymtl.ca> <4ced996ee1ea0ceef2ec994afeca6bb7@polymtl.ca> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <0d567b53-4944-2553-9bf7-81a189f15ca7@redhat.com> Date: Wed, 25 Jan 2017 18:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <4ced996ee1ea0ceef2ec994afeca6bb7@polymtl.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-01/txt/msg00550.txt.bz2 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