220 12407 article Path: news.gmane.org!not-for-mail From: "col3435 via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Local variables that overstay their welcome Date: Thu, 21 Aug 2014 03:47:25 -0700 (PDT) Lines: 117 Approved: news@gmane.org Message-ID: References: <778b6fbf-3b58-488c-9e51-32a05b95831e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_141_420704534.1408618045065" X-Trace: ger.gmane.org 1408618058 23115 80.91.229.3 (21 Aug 2014 10:47:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Aug 2014 10:47:38 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCS5LL55TMARBPM426PQKGQERUILHNY@isocpp.org Thu Aug 21 12:47:31 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f70.google.com ([209.85.192.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XKPtu-0002A3-Rv for gclcip-std-proposals@m.gmane.org; Thu, 21 Aug 2014 12:47:27 +0200 Original-Received: by mail-qg0-f70.google.com with SMTP id i50sf18412720qgf.5 for ; Thu, 21 Aug 2014 03:47:25 -0700 (PDT) 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=wcZP3qMAwJ9WuzZ9WI2wI27OGzhKuKyf6Viz1K+rPvw=; b=FjNC2qgXmhWJ2/rEkOiIXnNafj21fVPQfqvvmui+p3mkTWQiSFt6JjEroB9pvfJdYv 3J5szHIqubdgBrzL9eTRk3R9orK0NeFbqcRx8Fyn82nEzOwXvxparLfBs7cktnFHMQPw 7YUYRHvBToFCrBGHkNcxLjIZ/Pr28RAoa0yeyPvJV24UOstnPEi6upNUzbG2r7TFnDhU AVxeZ+kIzN1dbRdR7MPgrmZ/sFSnr8MDrsOk7WVpvI5qtSoufaKlIKAS3BXzT8DwFZBr VajpNLu43H+3EKT3P8htlUAzSH1TWmTgG8uylyjDhK//Muznvl5LbU3n2hbKcuV63EDb 3fcA== X-Gm-Message-State: ALoCoQld6df3YKN3udFLA6IEnQjkf4xNk8eOBQJ2jruZ5L8lPSK2njNmDl6uSid7kS+mUNOBG94K X-Received: by 10.224.127.6 with SMTP id e6mr29002794qas.3.1408618045899; Thu, 21 Aug 2014 03:47:25 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.36.148 with SMTP id p20ls735852qgp.50.gmail; Thu, 21 Aug 2014 03:47:25 -0700 (PDT) X-Received: by 10.140.89.40 with SMTP id u37mr847qgd.37.1408618045349; Thu, 21 Aug 2014 03:47:25 -0700 (PDT) In-Reply-To: <778b6fbf-3b58-488c-9e51-32a05b95831e@isocpp.org> X-Original-Sender: col3435@yahoo.co.uk 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: col3435@yahoo.co.uk Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:12407 Archived-At: ------=_Part_141_420704534.1408618045065 Content-Type: text/plain; charset=UTF-8 On Wednesday, 20 August 2014 15:24:46 UTC+1, Matthew Fioravante wrote: > Here are some ideas: > > 1) Add a new keyword to prematurely remove an object from the current > scope. > > ... > > With this feature, you could kill the unique_ptr after moving from it, > preventing anyone from accidentally using it. > > auto i = std::make_unique(i); > v.push_back(std::move(i)); > kill i; > doSomething(i.get()); //<-compiler error, i does not exist! > I don't expect this will ever make it into C++. But for those of us who wish we had "destructive move semantics", rather than the "conservative" move semantics we got in C++11, this is part of how it could have worked. Briefly, with destructive move semantics, a function which took a rvalue reference parameter would take over responsibility for destroying the object from the calling code. The calling code would look something like this: auto i = std::make_unique(50); kill i: v.push_back(i); // now variable i may no longer be used The "kill" statement tells the compiler to treat i like a temporary object in the expression that follows. So if i is not passed to another function it will be destroyed at the end of that statement. But (as here) once i has been passed to a function by rvalue reference, the compiler will no longer make a call to the destructor in the calling code. (Note: it's required that a local variable is either known to be killed, or not killed, at any point in the code. You couldn't kill a variable in only one branch of an if-else pair, for example.) As for why you'd want destructive moves in the first place: it's much easier to write sensible destructive move operations, and in particular to write *no-throw* destructive move operations, than to write conservative ones. If we had destructive move we probably wouldn't have needed the noexcept hack in vector::push_back, and we wouldn't still be tearing our hair out over things like N4055. -- --- 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/. ------=_Part_141_420704534.1408618045065 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wednesday, 20 August 2014 15:24:46 UTC+1, Matth= ew Fioravante wrote:
Here are some ideas:
 
1) Add a n= ew keyword to prematurely remove an object from the current scope.
 
...
 
With this feature, you could ki= ll the unique_ptr after moving from it, preventing anyone from accidentally= using it.
 
auto i =3D std::make_unique<i= nt>(i);
v.push_back(std::move(i));
kill i;
doSomething(i.get()); //<-compiler error, i does not exist!
=
 
I don't expect this will ever make= it into C++. But for those of us who
wish we had "destructive move sema= ntics", rather than the "conservative"
move semantics we got in C++11, t= his is part of how it could have worked.
Briefly, with destructive move = semantics, a function which took a rvalue
reference parameter would take= over responsibility for destroying the
object from the calling code. Th= e calling code would look something like
this:

auto i =3D st= d::make_unique<int>(50);
kill i: v.push_back(i);
// now = variable i may no longer be used

The "kill" statement tells the comp= iler to treat i like a temporary object in
the expression that follows. = So if i is not passed to another function
it will be destroyed at the en= d of that statement. But (as here) once i has
been passed to a function = by rvalue reference, the compiler will no longer
make a call to the dest= ructor in the calling code. (Note: it's required that
a local variable i= s either known to be killed, or not killed, at any point in
the code. Yo= u couldn't kill a variable in only one branch of an if-else pair,
for ex= ample.)

As for why you'd want destructive moves in the first p= lace: it's much
easier to write sensible destructive move operations, an= d in particular
to write *no-throw* destructive move operations, than to= write
conservative ones. If we had destructive move we probably wouldn'= t have
needed the noexcept hack in vector::push_back, and we wouldn't st= ill
be tearing our hair out over things like N4055.

--

---
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_141_420704534.1408618045065-- .