220 13874 <16366a2f-03b6-4e2a-9007-7819afe28460@isocpp.org> article Path: news.gmane.org!not-for-mail From: Michael Bruck Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal for a delete expression for local variables Date: Wed, 15 Oct 2014 02:18:59 -0700 (PDT) Lines: 562 Approved: news@gmane.org Message-ID: <16366a2f-03b6-4e2a-9007-7819afe28460@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2498_80284596.1413364739294" X-Trace: ger.gmane.org 1413364748 24814 80.91.229.3 (15 Oct 2014 09:19:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Oct 2014 09:19:08 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDO2X46R4AKRBA7Y7CQQKGQE4EUDJSI@isocpp.org Wed Oct 15 11:19:02 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f200.google.com ([209.85.192.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XeKjV-0005qF-FH for gclcip-std-proposals@m.gmane.org; Wed, 15 Oct 2014 11:19:01 +0200 Original-Received: by mail-pd0-f200.google.com with SMTP id ft15sf4384877pdb.11 for ; Wed, 15 Oct 2014 02:19:00 -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=Re+JI3cRIWBY+0EHXVDwCk340t+XgT3YOK00BI87hBg=; b=KZj6AT24uZ/Ptd+kZH2d70UA72yZQ91HWNgiEUJd6nRXkBKV6nO7SyLklFV1c07MSJ yhHHWc4T4coMacFNN8H41x+3Jyg5c6wHXBRp3iPIvxDZIEIz0BCG0r/zFt6ONH0c9puJ nLZGkqJuapYl2B7tHbPnBPZSixwWnWYgnsktrHWDBpVqkLvJL9F38cKyBk4Fn3brDbEu Z4EOaHKfRzUCoNK34K5JwF50Q20qzfKjhp5hKp3qkOVFOBIOKWYUf8dKaO/xmUVptIZu zm6Y9DptJzlkq/4W+fVo8UCuH6CiJr83RV6vzb0e+L42SRfT6xhnx2d/6kjpxCiL3ERe duVw== 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=Re+JI3cRIWBY+0EHXVDwCk340t+XgT3YOK00BI87hBg=; b=ddls2pRwByZHhiu/yh4g0er0qS9uRsRs3o1rmmGjk05yx/eCBOPsB+hjj/WA02hAC7 zTK+CurmvjQPdI0PPFAvAvyH6uqvKE1u7as5HfQ8Fsqx6HwszwODP3INaY5evmd+MlZI e63CkZXXbI93CyMzkVr37jukjzAp7otFad1NApftmXo/isAyqU3kJh9I6e2JoBmCn0Sv uFEEoxocPZzS7/BQLALUVWqcHJRoPgK9QRIufbWxsNAEyYdSyJZqpTC4NiIPpDnC+hIZ sc5ivFXsGwQ0BjSGyRL+ufY6j6lJsVb6cvFDpshPCkTGCXqc9T3QETgpBCDGF+U9PJdB uCCQ== X-Gm-Message-State: ALoCoQlCN7yT0P/kPOg896JO1ZNSdmhW3/mHHInE7m5UNRbNJgg6NLO8IMQz8MbzU5IRfBhAEuPj X-Received: by 10.66.222.98 with SMTP id ql2mr7389410pac.28.1413364740392; Wed, 15 Oct 2014 02:19:00 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.107.166 with SMTP id h35ls144375qgf.80.gmail; Wed, 15 Oct 2014 02:18:59 -0700 (PDT) X-Received: by 10.140.20.175 with SMTP id 44mr173656qgj.4.1413364739628; Wed, 15 Oct 2014 02:18:59 -0700 (PDT) In-Reply-To: X-Original-Sender: bruck.michael@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:13874 Archived-At: ------=_Part_2498_80284596.1413364739294 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the proposal addresses a number of drawbacks with that approach. I= =20 think that having a unified method to dispose of these objects without=20 needing special support in your library has clear advantages.=20 Michael On Wednesday, October 15, 2014 10:36:03 AM UTC+2, Andrew Tomazos wrote: > > If your classes depend on destructor ordering, then you are doing too muc= h=20 > in destructors, and are better off putting the interesting part of the=20 > destructor into a member function and explicitly calling it. In the=20 > destructor you can check if it has been called and then either error or= =20 > call it automatically. The member function will have an expressive name= =20 > that helps the reader understand what is going on, rather than hiding it = in=20 > a nameless destructor. > -Andrew. > > > On Wed, Oct 15, 2014 at 9:14 AM, Michael Bruck > wrote: > >> Hello everyone, >> >> >> >> I am looking for feedback on the outline for a proposal below. I would= =20 >> like to know if there is interest in such a feature and any ideas on=20 >> improvements. >> >> >> >> >> Regards, >> >> Michael >> >> >> >> Deleting local variables >> Summary >> >> This proposal introduces a way to end the scope of a variable before its= =20 >> enclosing block ends. >> >> { >> >> std::string foo, bar; >> >> ... >> >> delete local foo, bar; >> >> ... >> >> } >> >> Motivation >> >> The =E2=80=9C} operator=E2=80=9D is powerful but but comes with a pre-de= fined destruction=20 >> order which is not suitable for all applications. In real world programs= =20 >> the desired scopes of objects are not always cleanly nested but sometime= s=20 >> overlap in complex ways. >> >> Sometimes objects hold expensive resources and especially with=20 >> programming patterns like threading or resumable functions the resources= =20 >> can remain blocked long after use if other functions in the same block= =20 >> require a long time to complete. >> >> This leads to programming patterns that try to mitigate this problem in= =20 >> suboptimal ways. A typical approach looks like: >> >> { >> >> auto file =3D file_open_rlock("data_snippet"); >> >> auto blob =3D file.fetch_all(); >> >> file.close(); >> >> auto conn =3D connect_to_peer("192.128.0.1"); >> >> conn.send(blob); >> >> blob.destroy(); >> >> auto reply =3D conn.fetch_reply(); >> >> conn.disconnect(); >> >> auto file2 =3D file_create("output"); >> >> file2.write(reply); >> >> reply.destroy(); >> >> file2.close(); >> >> } >> >> There are a number of problems with this solution: >> >> -=20 >> =20 >> The library needs to provide a function that releases expensive=20 >> resources in addition to the destructor. >> -=20 >> =20 >> The library needs to keep track of the additional state in which=20 >> resources are freed but the object not yet destroyed. >> -=20 >> =20 >> The user needs to locate such a function and understand its semantics= =20 >> to see if it really releases enough resources. >> -=20 >> =20 >> The neutered object still lingers in some form on the stack until the= =20 >> end of the scope. >> -=20 >> =20 >> The compiler can not diagnose at compile time when such an already=20 >> neutered object is used accidentally due to code rewrite etc. >> -=20 >> =20 >> Diagnostics and other interactions that are tied to the destruction= =20 >> occur far removed in time from the time the object actually falls out= of=20 >> use. >> =20 >> >> This proposal would allow for the following code: >> >> { >> >> auto file =3D file_open_rlock("data_snippet"); >> >> auto blob =3D file.fetch_all(); >> >> delete local file; >> >> auto conn =3D connect_to_peer("192.128.0.1"); >> >> conn.send(blob); >> >> delete local blob; >> >> auto reply =3D conn.fetch_reply(); >> >> delete local conn; >> >> auto file =3D file_create("output"); >> >> file.write(reply); >> >> delete local file, reply; >> >> } >> >> Details >> >> Unlike the regular delete expression the argument is not a pointer but= =20 >> rather a list of variable or function parameter names. >> >> Variables in the enclosing scope cannot be deleted from within selection= =20 >> statements (if, switch), iteration statements (while, do, for), catch=20 >> clauses or other conditionally executed code. >> >> When goto crosses delete local in the direction of the program flow then= =20 >> it deletes the object in the same way as when crossing =E2=80=9C}=E2=80= =9D. When goto=20 >> passes delete local it must also pass the point of declaration of the=20 >> name. >> >> Optional: After delete local the name is free for reuse in a new=20 >> variable declaration. >> >> --=20 >> >> ---=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to std-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@isocpp.org . >> Visit this group at=20 >> 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/. ------=_Part_2498_80284596.1413364739294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the proposal addresses a number of drawbacks with = that approach. I think that having a unified method to dispose of these obj= ects without needing special support in your library has clear advantages.&= nbsp;

Michael

On Wednesday, October 15,= 2014 10:36:03 AM UTC+2, Andrew Tomazos wrote:
If your classes depend on destructor order= ing, then you are doing too much in destructors, and are better off putting= the interesting part of the destructor into a member function and explicit= ly calling it.  In the destructor you can check if it has been called = and then either error or call it automatically.  The member function w= ill have an expressive name that helps the reader understand what is going = on, rather than hiding it in a nameless destructor.
  -Andrew.


On Wed, Oct 15, = 2014 at 9:14 AM, Michael Bruck <bruck....@gmail.com> wrote:

Hel= lo everyone,



I am looking for feedback on the= outline for a proposal below. I would like to know if there is interest in= such a feature and any ideas on improvements.




<= p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">R= egards,

Michael



Del= eting local variables

Summary

This proposal introduces a way to end the scope of a variable bef= ore its enclosing block ends.


{

std::string foo, bar;

...

delete<= /span> local foo, bar;

...

}


Motivation

The =E2=80=9C} operator=E2=80=9D is powe= rful but but comes with a pre-defined destruction order which is not suitab= le for all applications. In real world programs the desired scopes of objec= ts are not always cleanly nested but sometimes overlap in complex ways.

Sometimes objects hold expe= nsive resources and especially with programming patterns like threading or = resumable functions the resources can remain blocked long after use if othe= r functions in the same block require a long time to complete.

This leads to programming patter= ns that try to mitigate this problem in suboptimal ways. A typical approach= looks like:


{

auto file =3D file_open_rlock("data_snippet");

auto blob =3D file= ..fetch_all();

file.close();


auto conn =3D connect_to_peer("192.128.0.= 1");

conn.send(blob);

blob.destroy();

auto reply =3D conn.fetch_rep= ly();

conn.disconnect();


auto file2 =3D file_create("output");=

reply.destroy();

file2.close();

}


There are a number of problems with this solution:

  • The library needs to = provide a function that releases expensive resources in addition to the des= tructor.

  • The library needs to keep track of the additi= onal state in which resources are freed but the object not yet destroyed.

  • The user needs to locate such a function and understand= its semantics to see if it really releases enough resources.

  • The neutered object still lingers in some form on the stack until t= he end of the scope.

  • The compiler can not diagnose at = compile time when such an already neutered object is used accidentally due = to code rewrite etc.

  • Diagnostics and other interaction= s that are tied to the destruction occur far removed in time from the time = the object actually falls out of use.


This proposal would allow for the following c= ode:

{

auto fil= e =3D file_open_rlock("data_snippet");

auto blob =3D file.fetch_all(= );

delete local file;


auto conn =3D connect_to_peer= ("192.128.0.1");

conn.send(blob);

delete local blob= ;

auto reply =3D conn.fetch_reply();

delete local conn;<= /span>


auto file =3D file_create("output");

file.write(reply);

delete local file, reply;

}


Details


Unlike the regular delete expression the= argument is not a pointer but rather a list of variable or function parame= ter names.


Variables= in the enclosing scope cannot be deleted from within selection statements = (if, switch), ite= ration statements (= while, do, for<= /span>), catch clauses or other conditionally executed code.


When goto = crosses delete loca= l in the direction of the p= rogram flow then it deletes the object in the same way as when crossing =E2= =80=9C}=E2=80=9D. When goto passes delete local it must also pass the point of declaration o= f the name.


Optional= : After delete loca= l the name is free for reus= e in a new variable declaration.

=

--

---
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_2498_80284596.1413364739294-- .