220 12798 <882aefbd-b21e-4ed3-8d08-f5cc8444f8ae@isocpp.org> article Path: news.gmane.org!not-for-mail From: Chet Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Local variables that overstay their welcome Date: Wed, 10 Sep 2014 18:09:47 -0700 (PDT) Lines: 267 Approved: news@gmane.org Message-ID: <882aefbd-b21e-4ed3-8d08-f5cc8444f8ae@isocpp.org> References: <778b6fbf-3b58-488c-9e51-32a05b95831e@isocpp.org> <94e564fc-f769-48d0-8a61-264f9c8f8480@isocpp.org> <66580c5b-0db4-4925-a4bd-9a5ef8f0c6c1@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2124_1075253516.1410397787417" X-Trace: ger.gmane.org 1410397807 30130 80.91.229.3 (11 Sep 2014 01:10:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Sep 2014 01:10:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCSONVVQUEDRBXPMYOQAKGQEX45U35I@isocpp.org Thu Sep 11 03:09:59 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f197.google.com ([209.85.213.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XRstS-0008LL-Qy for gclcip-std-proposals@m.gmane.org; Thu, 11 Sep 2014 03:09:51 +0200 Original-Received: by mail-ig0-f197.google.com with SMTP id h18sf1149276igc.0 for ; Wed, 10 Sep 2014 18:09: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=jE22RPXTivUjkpzXqVPOAvC+Owl46R82XMT8CC9oza4=; b=e5bBE4MDIDHKkNVcNL0eI7WeXm2QLXuxEvcTu4Ol10nbJkknCtVdsHUOZJxwy2fM2p pyi6myrzwjgUSi24hb8Xa5EWeZQFJjlZJTeD+UgDygUK9wfpHVWWOJve1uahhbmljZwl YpYjFGLnhh4Cphhs5oqPu/RqSZKxc+XueeKg/+pCCMLRNRmdGwTKqxLMqFW84S0g4q7i XTyxrhQYC0AtOptcwFLiRpbUJRi3MiGBlyJqnqZ3xUQYbyXVe7v2OWEYSCFpPnv9Xh1O j9ayWsUKf8QPTtb1koX/MGXerAARE/g+zroeaGJez1MFbO24pvI02nkKGiQtWErPlOPK GtaQ== 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=jE22RPXTivUjkpzXqVPOAvC+Owl46R82XMT8CC9oza4=; b=WDPBx3AjsY6VElo3gBZHshRqs7fS6O5H8VqGidCHa2XTPQQp/5EhaWcBB2x+zFz0aB VNKpt9hlvt7XbRZWjCr+reOvHkJ2H28FHC8Xm24yafsVzF5/wC53Lc9H4ICO4KupD49j qmjVWhcAP4l0GYEWp7JCtlZJaw6LibR7Sl136UQmqi6RBccBHBuR7Bmzsax/U9tC1WXF tB49oufe5eYLw24UuHrINfVylofVCfEMaFxrbxtHav+cDliinJmneQ8jPLQ0V4uZhFuF VUKqY2nRUGPCOgY9iofc+b1Pm1wuxHRQUdC6hAF3o9iEgwCdD+bA4MOcMTmVuvI603j2 r8ZQ== X-Gm-Message-State: ALoCoQn8whRm5ulLeQa7mkv6Q4P/rD0i6HhewBX2DwwRHXSLMh6b25O2Z/cDwK2WjHfkTz9Wr8vt X-Received: by 10.182.125.68 with SMTP id mo4mr2904938obb.49.1410397789912; Wed, 10 Sep 2014 18:09:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.4.102 with SMTP id j6ls3636984igj.42.canary; Wed, 10 Sep 2014 18:09:49 -0700 (PDT) X-Received: by 10.50.39.113 with SMTP id o17mr553329igk.14.1410397788998; Wed, 10 Sep 2014 18:09:48 -0700 (PDT) In-Reply-To: X-Original-Sender: chet.skolos@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:12798 Archived-At: ------=_Part_2124_1075253516.1410397787417 Content-Type: text/plain; charset=UTF-8 Adding a "disengage and move from" method to optional is good idea. However, the original code can be reworked to not use std::move. //Code with move: struct F { std::vector> v; void run() { auto i = std::make_unique(); v.push_back(std::move(i)); doSomethingWith(i.get()); //logic error. i is a "moved from" state. } }; //Code without move: struct F { std::vector> v; void run() { v.push_back(std::make_unique()); doSomethingWith(i.get()); // error here because no i } }; //Code without move allowing for more code between make and push back struct F { std::vector> v; void run() { v.push_back([&]()->std::unique_ptr{ auto i = std::make_unique(); //Do more things with i here. return i; }()); doSomethingWith(i.get()); // error here because no i } }; //With one more refactoring a potential fix... struct F { std::vector> v; void run() { v.push_back([&]()->std::unique_ptr{ auto i = std::make_unique(); // possible problem: vector v does not have the pointer when doSomethingWith is called. doSomethingWith(i.get()); return i; }()); } }; In C++14 it is possible to hide and kill variables by introducing and closing scopes. If there is a real need to keep multiple variables in the same scope, creative use of std::optional can also simulate killing a variable, or you can invent a similar template class that has additional specific features around killing and moving. (Also, if the indenting really gets you down, just don't indent; this is c++ not Python. ;-) On Tuesday, 9 September 2014 23:03:20 UTC-7, Brent Friedman wrote: > > Have you considered this alternative? > > optional x = ...; > x->thing(); > x = nullopt; // kill x > x->thing(); //undefined behavior > > To provide your error/warning, the compiler/static analyzer simply needs > to understand the well-defined semantics of optional. > > > The original examples you gave were dealing with std::move. Those could be > supported with some nice 'move the value out of the optional' syntax. > > optional x = ...; > y = x.pop(); //disengages x and returns T&&; requires x to be engaged. > x->thing(); //undefined behavior > > On Tue, Sep 9, 2014 at 11:25 PM, Adam Nevraumont > wrote: > >> Killing a variable woukd be roughky equivalent to retyping it as void. >> >> Retyping a T as const T, or a Derived* as Base*, would be variations. >> >> T x; >> virtual x = T const&;// treat access to x as if it was const >> virtual x = void; // treat access to x as illegal >> Derived* y; >> virtual y = Base*; >> virtual y = const Base*; >> >> In general, virtual V = type; is legal if: >> 1) V is a variable in the enclosing function local scope >> 2a) type is void **or** >> 2b) V is implicitly convertable to type >> >> In 2a) case, the variable V is killed. In 2b case, it is hidden by a new >> V, which is implicitly constructed from the old V. >> >> virtual V = const; >> virtual V = const*; >> >> could be used as shortcuts for const&, and decltype(*V) const*. >> >> (Virtual may not be ideal keyword, but) >> >> -- >> >> --- >> 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-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@isocpp.org . >> Visit this group at >> http://groups.google.com/a/isocpp.org/group/std-proposals/. >> > > -- --- 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_2124_1075253516.1410397787417 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adding a "disengage and move from" method to opt= ional is good idea.

However, the original code ca= n be reworked to not use std::move.

//Code with move:
struct F {
  std::vector<std::unique_ptr<= int>> v;
  void run() {
  &nb= sp; auto i =3D std::make_unique<int>();
    = v.push_back(std::move(i));
    doSomethingWith(i.g= et()); //logic error. i is a "moved from" state.
  }
};

//Code without move:
struct F= {
  std::vector<std::unique_ptr<int>> v;
  void run() {
    v.push_back(std::= make_unique<int>());
    doSomethingWith(i.g= et()); // error here because no i
  }
};

//Code without move allowing for more code between ma= ke and push back
struct F {
   std::vect= or<std::unique_ptr<int>> v;
   void run() {=
      v.push_back([&]()->std::unique_ptr&l= t;int>{
         auto i =3D std::make= _unique<int>();
         //Do more= things with i here.
         return i;<= /div>
         }());
    &= nbsp; doSomethingWith(i.get()); // error here because no i
 =     }
   };

/= /With one more refactoring a potential fix...
struct F {
   std::vector<std::unique_ptr<int>> v;
<= div>   void run() {
      v.push_back([&= amp;]()->std::unique_ptr<int>{
      &nbs= p;  auto i =3D std::make_unique<int>();
    =      // possible problem: vector v does not have the pointer= when doSomethingWith is called.
        =  doSomethingWith(i.get()); 
       =   return i;
         }());
      }
   };

=

In C= ++14 it is possible to hide and kill variables by introducing and closing scopes. If there is a real need to keep multiple variables in the same scope, creative use of std::optional ca= n also simulate killing a variable, or you can invent a similar template clas= s that has additional specific features around killing and moving. (Also, if = the indenting really gets you down, just don't indent; this is c++ not Python. = ;-)


On Tuesday, 9 September 2014 23:03:20 UT= C-7, Brent Friedman wrote:
Have you considered this alternative?

opti= onal<T> x =3D ...;
x->thing();
x =3D nullopt; = // kill x
x->thing(); //undefined behavior

To provide your error/warning, the compiler/static analyzer simply ne= eds to understand the well-defined semantics of optional.


The original examples you gave were dealing with std= ::move. Those could be supported with some nice 'move the value out of the = optional' syntax.

optional<T> x =3D ...;
y =3D x.pop(); //disengages x and returns T&&; requires x to= be engaged.
x->thing(); //undefined behavior
=
On Tue, Sep 9, 2014 at 11:25 PM, Adam Nevrau= mont <a...@theore= m.ca> wrote:
Killing a vari= able woukd be roughky equivalent to retyping it as void.

Retyping a T as const T, or a Derived* as Base*, would be variations.

T x;
virtual x =3D T const&;// treat access to x as if it was const
virtual x =3D void; // treat access to x as illegal
Derived* y;
virtual y =3D Base*;
virtual y =3D const Base*;

In general, virtual V =3D type; is legal if:
1) V is a variable in the enclosing function local scope
2a) type is void **or**
2b) V is implicitly convertable to type

In 2a) case, the variable V is killed.  In 2b case, it is hidden by a = new V, which is implicitly constructed from the old V.

virtual V =3D const;
virtual V =3D const*;

could be used as shortcuts for const&, and decltype(*V) const*.

(Virtual may not be ideal keyword, but)

--

---
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-proposal...@isocpp.or= g.
To post to this group, send email to s= td-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposal= s/.

--

---
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_2124_1075253516.1410397787417-- .