220 12384 article Path: news.gmane.org!not-for-mail From: "'Geoffrey Romer' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Local variables that overstay their welcome Date: Wed, 20 Aug 2014 11:44:06 -0700 Lines: 186 Approved: news@gmane.org Message-ID: References: <778b6fbf-3b58-488c-9e51-32a05b95831e@isocpp.org> <75655d78-f533-40fe-8109-2725a5da77a9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2cc1825d2f5050113fd68 X-Trace: ger.gmane.org 1408560259 13378 80.91.229.3 (20 Aug 2014 18:44:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Aug 2014 18:44:19 +0000 (UTC) Cc: dibeas@ieee.org To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD74DCN5SYHBB56Y2OPQKGQEJHHBRTY@isocpp.org Wed Aug 20 20:44:12 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f197.google.com ([209.85.214.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XKArg-0000fw-J5 for gclcip-std-proposals@m.gmane.org; Wed, 20 Aug 2014 20:44:08 +0200 Original-Received: by mail-ob0-f197.google.com with SMTP id vb8sf50950034obc.8 for ; Wed, 20 Aug 2014 11:44:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=gVJq4+DmSgVsa+iQYVaf2WDBiyimIWsS5DemTp5lpT8=; b=dB3Gmtbn13EnXz8O/VX/WUrB8/uFURkEi90POMgaZLPrw1rYLFfnF+W/yKcIUj2+aN CSfi0nb3jd3OLHcWZJMaXjMy3Kuxqm8UM5viY7hS7eIgKYPz0uEy61vIzOQ5/NdB1i6C DN72MjzIkg0Y+eEj6mqIISlUbxKvMI4ERY0LPw3E2qieVoswRGyWRiVUk63R9z80gGfq XgfjawLxMv8eRPz9EQGBqhSzHYgXmNTo34f5ei89hdClJ4NTEpknqF9CZjaUEmiOPSd8 0K5KYLjiVYJ3wN9FGeEd6v6fqz7ZtoFROMCtR0jEOWAdzLvNZeD0LBsMhSIZ+D8F0XHS w6Sg== X-Gm-Message-State: ALoCoQm03I7uPtDEgZckhy55IzX2P9fSOWj2Rmg9FsF9aRflJFaFxv3QYNNO/z8mfL6Xs46tMYCd X-Received: by 10.43.1.133 with SMTP id nq5mr27770477icb.21.1408560247682; Wed, 20 Aug 2014 11:44:07 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.92.102 with SMTP id a93ls428411qge.15.gmail; Wed, 20 Aug 2014 11:44:06 -0700 (PDT) X-Received: by 10.140.18.211 with SMTP id 77mr75541571qgf.57.1408560246854; Wed, 20 Aug 2014 11:44:06 -0700 (PDT) Original-Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [2607:f8b0:400d:c00::22b]) by mx.google.com with ESMTPS id g106si35224091qge.32.2014.08.20.11.44.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Aug 2014 11:44:06 -0700 (PDT) Received-SPF: pass (google.com: domain of gromer@google.com designates 2607:f8b0:400d:c00::22b as permitted sender) client-ip=2607:f8b0:400d:c00::22b; Original-Received: by mail-qa0-f43.google.com with SMTP id w8so7357620qac.16 for ; Wed, 20 Aug 2014 11:44:06 -0700 (PDT) X-Received: by 10.224.127.74 with SMTP id f10mr81742197qas.100.1408560246658; Wed, 20 Aug 2014 11:44:06 -0700 (PDT) Original-Received: by 10.96.59.41 with HTTP; Wed, 20 Aug 2014 11:44:06 -0700 (PDT) In-Reply-To: <75655d78-f533-40fe-8109-2725a5da77a9@isocpp.org> X-Original-Sender: gromer@google.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gromer@google.com designates 2607:f8b0:400d:c00::22b as permitted sender) smtp.mail=gromer@google.com; dkim=pass header.i=@google.com; dmarc=pass (p=REJECT dis=NONE) header.from=google.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: , X-Original-From: Geoffrey Romer Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:12384 Archived-At: --001a11c2cc1825d2f5050113fd68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 20, 2014 at 9:50 AM, Matthew Fioravante wrote: > > On Wednesday, August 20, 2014 11:47:21 AM UTC-4, David Rodr=C3=ADguez Ibe= as > wrote: >> >> >> One possible way of tagging the code as intentional would be to >> explicitly reset the unique pointer: >> >> auto x =3D make_unique(); >> if (something) { >> v.push_back(std::move(x)); >> x =3D 0; // explicitly say that the st= ate >> is known >> } >> foo(x.get()); // don't warn >> > > I like this approach but I'm not sure it can be made to be generic for al= l > movable types. > Consider the case where the object is reused later. > > auto x =3D make_unique(); > v.push_back(std::move(x)); > a(x.get()); //Warning: use after move > x =3D make_unique(); > b(x.get()); //compiler saw a new assignment to x, so we know this is vali= d > v.push_back(std::move(x)); > c(x.get()); //Warning: use after move > > x.reset(new int()); > d(x.get()); //??? > > In the above example, the compiler needs to have know that > unique_ptr::reset() is special and makes the object reusable again. Hard > coding the rules for unique_ptr into a compiler warning may terrible > idea idea since it is used so often but that approach cannot be generaliz= ed. > > > The diagnostic could be made to only trigger for const operations after > move and be reset once a non-const operation occurs. This would not catch > all of the kinds of use-after-move bugs, though. After moving, its safe t= o > do operations which overwrite the state but not operations which modify t= he > current state. We don't currently have any way to differentiate between t= he > 2. > How about an annotation on reset(), which indicates that it's the moral equivalent of an assignment? Alternatively, there's something to be said for standing by the convention that you don't do anything to a moved-from value other than reassign or destroy it, and therefore you _shouldn't_ use reset() in this kind of situation. > > > -- > > --- > 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 > email 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-proposals/. > --=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/. --001a11c2cc1825d2f5050113fd68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Aug 20, 2014 at 9:50 AM, Matthew Fioravante <<= a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@gma= il.com> wrote:

On Wedn= esday, August 20, 2014 11:47:21 AM UTC-4, David Rodr=C3=ADguez Ibeas wrote:=

One possible way of tagging the code as intentional wo= uld be to explicitly reset the unique pointer:

auto x =3D make_uniqu= e<int>();
if (something) {
=C2=A0 =C2=A0v.push_back(std::move(x= ));
=C2=A0 =C2=A0x =3D 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// explic= itly say that the state is known
}
foo(x.get()); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// don't warn
=C2=A0
I like this approach but=C2=A0I'm not= sure it can be made=C2=A0to be generic for all movable types.
Co= nsider the case where the object is reused later.
=C2=A0
auto x =3D make_unique<int>();<= /div>
v.push_back(std::move(x));
a(x.get()); //Warning:= use after move
x =3D make_unique<int>(); <= /div>
b(x.get()); //compiler saw a new assignment to x, so we know this is v= alid
v.push_back(std::move(x));
c(x.get()); //Warning: = use after move
=C2=A0
x.reset(new int());
d(= x.get()); //???
=C2=A0
In the above example, the compiler needs to have know= that unique_ptr::reset() is special and makes the object reusable again. H= ard coding the rules for unique_ptr=C2=A0into a compiler=C2=A0warning may= =C2=A0terrible idea=C2=A0idea since it is used so often but that approach c= annot be generalized.
=C2=A0
=C2=A0
The diagnostic could be made to only= trigger for const operations after move and be reset once a non-const oper= ation occurs. This would not catch all of the kinds of use-after-move bugs,= though. After moving, its safe to do operations which overwrite the state = but not operations which modify the current state. We don't currently h= ave any way to differentiate between the 2.

How about an annotation on reset(), = which indicates that it's the moral equivalent of an assignment?
<= div>
Alternatively, there's something to be said for stan= ding by the convention that you don't do anything to a moved-from value= other than reassign or destroy it, and therefore you _shouldn't_ use r= eset() in this kind of situation.=C2=A0
=C2=A0
=C2= =A0

--

---
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-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/gro= up/std-proposals/.

--

---
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>.
--001a11c2cc1825d2f5050113fd68-- .