220 11776 <1a858a77-310b-4591-aaf5-960c40d9f5fc@isocpp.org> article Path: news.gmane.org!not-for-mail From: tomaszkam@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N4078: Rvalue reference overloads for value() method returns object by value Date: Wed, 9 Jul 2014 22:11:47 -0700 (PDT) Lines: 161 Approved: news@gmane.org Message-ID: <1a858a77-310b-4591-aaf5-960c40d9f5fc@isocpp.org> References: <4DA018C3-2327-4F55-B7F8-7988EC7B789A@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1782_32662766.1404969107853" X-Trace: ger.gmane.org 1404969121 16973 80.91.229.3 (10 Jul 2014 05:12:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Jul 2014 05:12:01 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNPVXXG6IGBBFGB7COQKGQEIPNODDI@isocpp.org Thu Jul 10 07:11:52 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f200.google.com ([209.85.160.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X56e6-0007Ur-Du for gclcip-std-proposals@m.gmane.org; Thu, 10 Jul 2014 07:11:50 +0200 Original-Received: by mail-yk0-f200.google.com with SMTP id 20sf19578521yks.11 for ; Wed, 09 Jul 2014 22:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=/YeMHVyHdmGxLa5X4fJe0j5smZ7ffg1CdmH2j+7IRRo=; b=iR6X+OhsD0NMzxr0wFE/99zTPOvAZSa1zT+A7s5ukZCajO6RaVo4Lc9FBDZehaSRyO BXn+3Nzx9OzI1BMS1H4S0YwMyY12t3Rc+252iNEISVgCfgs5ec1i1E3EgnctvYjQ6/PJ FyMHtiUoZm+oHX7VyM/lHWz6bJJI/bUd7TEAoh4bMUDbCkUZ/ktuT1L/TpVVTcQGD9If mI+euCxExwp/oO0usDUvtpEaWfWfD44q2on+f1ysDMTqhjO6U0bKJGfVR2Pcm3JAdvJh aK6mPf3qALRMdUkp+QVko3EVl2gUAsCd/smHcHhlwVpGx6OnQMGb0gKP/YLQ3s573GZb ZfmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=/YeMHVyHdmGxLa5X4fJe0j5smZ7ffg1CdmH2j+7IRRo=; b=HZbi+VHdlkCmUe3sgxoz3fXarzJELeOY/9ZXw2+gItLY/pL77kH1WnSS0ogIeEiZIJ kNM6hR7DJLbUkLrI42glTaOJShTia8VCJ1sV313jW/K6vH03wdYUEsfIXwtQzAsPTBlp xv13h+RF5ZR84yRKvsVFxIRwjhOU7MGtg+ooz+14thiY1KBe7e8RtiVeiYWyh5L7OYel eeNgILT3d6RTG8bz3MiNusbo4O16gYiFTEbw/sb0AuJ0T9xOfBVMdIfwpD865OEqPIjz ZuURI8KH/wNM7JGCwI9WT13ciF1P+/ujoGv7ScXP4igdyQZw3mjdRDfYEJlykmJGxiPG +PSQ== X-Gm-Message-State: ALoCoQlpA5JnXQW4fvMUYdFFMHeqGfSNrl0R27SVzCvatW8u7GMa4JQGTVRNdEXKgh/ER6tyX4ir X-Received: by 10.58.209.227 with SMTP id mp3mr21749991vec.29.1404969109556; Wed, 09 Jul 2014 22:11:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.34.229 with SMTP id c5ls828015obj.84.gmail; Wed, 09 Jul 2014 22:11:48 -0700 (PDT) X-Received: by 10.182.98.136 with SMTP id ei8mr74obb.39.1404969108382; Wed, 09 Jul 2014 22:11:48 -0700 (PDT) In-Reply-To: <4DA018C3-2327-4F55-B7F8-7988EC7B789A@gmail.com> X-Original-Sender: tomaszkam@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:11776 Archived-At: ------=_Part_1782_32662766.1404969107853 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu czwartek, 10 lipca 2014 01:17:39 UTC+2 u=C5=BCytkownik David Krauss= =20 napisa=C5=82: > > > On 2014=E2=80=9307=E2=80=9310, at 3:09 AM, 'Jeffrey Yasskin' via ISO C++ = Standard - Future=20 > Proposals > wrote: > > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1651=20 > addresses: > > std::pair g(); > auto&& s =3D g().first; //will create a dangling reference > > It's in 'ready' status, meaning it's not in C++14, but it's likely to get= =20 > fixed immediately after, possibly as a "defect", which would mean that mo= st=20 > compilers would implement the fix in their C++14 modes. > > > This is already fixed in GCC and Clang in C++11 mode. Defect reports are= =20 > usually applied asynchronously. However, GCC has a lingering bug where a= =20 > reference bound to a scalar member will not extend the lifetime of a clas= s=20 > object. (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60297) > > Of course binding a reference to a subobject extends the complete object.= =20 > What else do you want, destruction of the rest of the object **except**= =20 > the subobject?? > > Sorry for replying to a message earlier in the thread, but the subsequent= =20 > messages here made me extremely confused, because they are dealing with a= =20 > hypothetical that seems already to have been prevented. > > auto && has some strong proponents, and although nothing is a silver=20 > bullet, it will always work except when a function returns an rvalue=20 > reference =E2=80=94 which, as the title of this thread and most of the ea= rly=20 > messages indicate, is a problem to be fixed. > No, the auto&& does not work with any function that return a any kind of=20 reference to subobject of it parameter (including this) is invoked on an=20 rvalue. In the examples above you my find: std::vector f(); auto&& s =3D f.front(); //This creates a dangling lvalue reference, and front() has not r-value=20 overloads. The whole discussion is about that the changes was made to the optional= =20 that makes following work correctly in cost on introducing temporaries in= =20 other places: std::optional g(); auto&& s =3D g().value(); --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_1782_32662766.1404969107853 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


W dniu czwartek, 10 lipca 2014 01:17:39 UTC+2 u=C5= =BCytkownik David Krauss napisa=C5=82:

On 2014=E2=80=930= 7=E2=80=9310, at 3:09 AM, 'Jeffrey Yasskin' via ISO C++ Standard - Future P= roposals <std-pr...@isocpp.org&= gt; wrote:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.h= tml#1651 addresses:

  std::pair<std::string, exception_ptr> g();<= br style=3D"font-family:arial,sans-serif">   auto&& s =3D g(= ).first; //will create a dangling reference

It's in 'ready= ' status, meaning it's not in C++14, but it's likely to get fixed immediate= ly after, possibly as a "defect", which would mean that most compilers woul= d implement the fix in their C++14 modes.

=
This is already fixed in GCC and Clang in C++11 mode. Defect= reports are usually applied asynchronously. However, GCC has a lingering b= ug where a reference bound to a scalar member will not extend the lifetime = of a class object. (https://gcc.gnu.org/= bugzilla/show_bug.cgi?id=3D60297)

Of cour= se binding a reference to a subobject extends the complete object. What els= e do you want, destruction of the rest of the object *except* the su= bobject??

Sorry for replying to a message earlier = in the thread, but the subsequent messages here made me extremely confused,= because they are dealing with a hypothetical that seems already to have be= en prevented.

auto &&am= p; has some strong proponents, and although nothing is a silver bull= et, it will always work except when a function returns an rvalue reference = =E2=80=94 which, as the title of this thread and most of the early messages= indicate, is a problem to be fixed.
No, the a= uto&& does not work with any function that return a any kind of ref= erence to subobject of it parameter (including this) is invoked on an rvalu= e. In the examples above you my find:
std::vector<std::string> f()= ;
auto&& s =3D f.front();
//This creates a dangling lvalue re= ference, and front() has not r-value overloads.

The whole discussion= is about that the changes was made to the optional<T> that makes fol= lowing work correctly in cost on introducing temporaries in other places:std::optional<T> g();
auto&& s =3D g().value();

<= br>

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_1782_32662766.1404969107853-- .