From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21319 invoked by alias); 29 Oct 2012 23:40:04 -0000 Received: (qmail 21303 invoked by uid 22791); 29 Oct 2012 23:40:03 -0000 X-SWARE-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-ie0-f169.google.com (HELO mail-ie0-f169.google.com) (209.85.223.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Oct 2012 23:39:57 +0000 Received: by mail-ie0-f169.google.com with SMTP id 10so9183230ied.0 for ; Mon, 29 Oct 2012 16:39:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.151.238 with SMTP id ut14mr11010564igb.58.1351553996549; Mon, 29 Oct 2012 16:39:56 -0700 (PDT) Received: by 10.42.158.202 with HTTP; Mon, 29 Oct 2012 16:39:56 -0700 (PDT) In-Reply-To: <87txtdz76a.fsf@fleche.redhat.com> References: <87txtdz76a.fsf@fleche.redhat.com> Date: Mon, 29 Oct 2012 23:40:00 -0000 Message-ID: Subject: Re: PR symtab/14441 - rvalue references From: Jonathan Wakely To: Tom Tromey Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-10/txt/msg00111.txt.bz2 On 29 October 2012 14:25, Tom Tromey wrote: > Jonathan> Before I continue altering every function that checks TYPE_CODE_REF, > Jonathan> is my approach the right one? Is adding TYPE_CODE_RVAL_REF and > Jonathan> touching dozens of functions the best approach, or should I go back to > Jonathan> my first attempt and just fix the few places that need to handle > Jonathan> lvalue and rvalue references differently? > > I would accept either one. Abstractly, I suppose a new type code would > be more in keeping with the current design. But I think the other > choice would be ok, too, if it is a reasonably accurate model of C++. I > don't know enough about rvalue references to say whether this is the > case. I believe it is the case. An rvalue-reference can only bind to an rvalue, however once it's bound to a variable the reference *is* an lvalue, so for all intents and purposes GDB could treat variables of rvalue-reference type exactly the same as lvalue references, except for showing "&&" when printing types. For example: struct X { }; X f (X&& param) { // param is an lvalue here! return param; // return a copy } X g (void) { X x; return x; // return a copy } int main() { X&& rv = f ( g () ); // rv is an lvalue! X* addr = &rv; // OK to take address } In this example, although the function parameter param and variable rv are rvalue-references and bound to rvalues, they are named variables and are lvalues. i.e. the act of binding an rvalue reference to an rvalue, thereby giving it a name, makes it an lvalue. Which is why my gut feeling (having barely looked at the gdb code two days ago) is that rvalue references don't need any special handling different to existing TYPE_CODE_REF variables, except for "ptype" printing "X&&" instead of "X&" Unfortunately my first attempt at doing that didn't work, so I started adding TYPE_CODE_RVAL_REF and handling it everywhere ... but I'm having second thoughts.