220 28017 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicolas Capens Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Specifier to cause the destructor to be called at last use instead of end of scope Date: Mon, 29 Aug 2016 17:02:30 +0000 Lines: 455 Approved: news@gmane.org Message-ID: References: <6aa24874-7bae-449f-ac2b-67f0605fbd65@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1147b804f865ad053b38d47d X-Trace: blaine.gmane.org 1472490168 11989 195.159.176.226 (29 Aug 2016 17:02:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Aug 2016 17:02:48 +0000 (UTC) To: Ren Industries , "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBC6MN3XGLYILDVMRXYCRUBAMRB6TU@isocpp.org Mon Aug 29 19:02:43 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f200.google.com ([209.85.216.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bePxJ-0002Rt-AC for gclcip-std-proposals@m.gmane.org; Mon, 29 Aug 2016 19:02:41 +0200 Original-Received: by mail-qt0-f200.google.com with SMTP id 93sf311092414qtg.1 for ; Mon, 29 Aug 2016 10:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=9tM4/fO/n0SGMT28Jx0yAZQRD1mf2JsesngDyDrRi9Q=; b=W/fwNYLvDj8n+G/iaVjuOFvTsYFpTSVnounN1z7XDTJ6FpXp7SQdgzos3jkq7BM8p+ PH3dWNPdxX5rZtEiBo65xRpX664cJtcZvE5fSQWb5EvONdNKrn7bQxe16hO0Wnbwnf9F aTQjPWtEsaq7cdA3U0XBwksigWesvTBTk/pk+G0z6Nl19b4FbBpT42oS8c8uDC4/kSh9 FoyGm1sJMhprhn+87wjQiZZI8fczYwMC/T6NMddpvRoPdz0HRPuW2xjAOCR7my60hxYx MxG2sRQD73YPc/zB9xvSKbZCTy7qLOP5PukIKOFsTHIrWRddsNg01XzWDQDUAsqeBNNT zVkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=9tM4/fO/n0SGMT28Jx0yAZQRD1mf2JsesngDyDrRi9Q=; b=E9qqsME5gzxps4N1ReMOGJ0ON1IkUxFx7CZByRIPHCzxoydd6KjDUXjWulHeIIIREK Cys6R1o2Ds3jNtWAtVysuvXqD+plRHkUphEySyq8mb/aqyq6q3VQAv0AuO3HVuL20G6h 7OsDVPewh005khf4F/997J+40B1pZhkcyNlhKCPTLf30n5ORHQXU9kukkPuqCO6MCn4O K2BmFE564cqHfudNE3fnOBZgVuycUQEpa8C9AwITB6BAPaPcxg9DTzC7IPN3zMGabqDv 4CVWCwqpFlZBsP69ejRCcqw8oagE2Ovr2Y6FeW36bdCiqU9yEGAp1dEpW+4H5pSCDNmJ nDhw== X-Gm-Message-State: AE9vXwPYSXFZKGhYGcZUAi53t1EvwyD3LlkHnOQqdNlAqX1cORCeXnj8yEy866UOfkHThg== X-Received: by 10.237.44.38 with SMTP id f35mr14496625qtd.18.1472490162115; Mon, 29 Aug 2016 10:02:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.48.71 with SMTP id w7ls7533662otd.43.gmail; Mon, 29 Aug 2016 10:02:41 -0700 (PDT) X-Received: by 10.129.46.136 with SMTP id u130mr17508370ywu.234.1472490161130; Mon, 29 Aug 2016 10:02:41 -0700 (PDT) Original-Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com. [2607:f8b0:400d:c09::230]) by mx.google.com with ESMTPS id p70si9422746qke.37.2016.08.29.10.02.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 10:02:41 -0700 (PDT) Received-SPF: pass (google.com: domain of nicolas.capens@gmail.com designates 2607:f8b0:400d:c09::230 as permitted sender) client-ip=2607:f8b0:400d:c09::230; Original-Received: by mail-qk0-x230.google.com with SMTP id v123so144219415qkh.2 for ; Mon, 29 Aug 2016 10:02:41 -0700 (PDT) X-Received: by 10.55.21.86 with SMTP id f83mr21082444qkh.285.1472490160807; Mon, 29 Aug 2016 10:02:40 -0700 (PDT) In-Reply-To: X-Original-Sender: Nicolas.Capens@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of nicolas.capens@gmail.com designates 2607:f8b0:400d:c09::230 as permitted sender) smtp.mailfrom=nicolas.capens@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:28017 Archived-At: --001a1147b804f865ad053b38d47d Content-Type: text/plain; charset=UTF-8 On Fri, Aug 26, 2016 at 5:46 PM Ren Industries wrote: > That in no way demonstrates it is similar to register allocation, which > is, again, a QOI issue. > My apologies. The example omitted how the equivalent scalar code would have its registers freed up for use by other variables after their last use. I thought that would be sufficiently clear. Here's an illustration of that: http://compilers.cs.ucla.edu/fernando/projects/puzzles/tutorial/. The end of the live ranges corresponds to where I'd like the destructors of objects to be called. Let me know if the similarities are still not obvious to you and I'll create a more detailed side-by-side example if I find the time. Anyway, yes, register allocation is a quality of implementation issue. One that is enabled by the standard allowing for it because scalars having no side-effects on destruction. I want to enable that same freedom of optimization for objects that do have side-effects, by telling the compiler that we don't care about these side-effects to happen at the end of the variable's scope. > It is not necessarily the case that a compiler need do that, and I can > think of at least a few counter examples. For example, there are projects > that output C++ to javascript or java, which have no notion of register > allocation as you point to it. These "machines" are perfectly valid C++ > targets, yet have absolutely no notion of what you are talking about. > I realize that. But I shouldn't have to care if a compiler strictly needs to do that today or not. I'm talking about adding a new feature to the language, and this may involve adding some new implementation requirements. If that causes some cross-compilers to no longer be able to support this new version of C++ without some non-trivial effort, too bad. It's certainly not my aim to make implementer's lives difficult, but I also don't want to cripple or abandon the feature because of it. Indeed, C++ supports a huge variety of applications. More than you know of, > it seems. > You're talking about Emscripten and alike. That's implementation side. I was talking about applications written in C++. You seemed to see no practical uses for this feature, presumably because you hadn't encountered such an application before. Did my trivial example clarify that manual freeing of the resources is not acceptable, or do you still disagree? > On Fri, Aug 26, 2016 at 3:21 PM, Nicolas Capens > wrote: > >> On Fri, Aug 26, 2016 at 1:16 PM, Ren Industries >> wrote: >> >>> Why is it such a terrible imposition to require manual interaction to >>> enforce this behavior? I don't buy your argument that it is similar to >>> register allocation; that's a QOI not a standards issue. >>> >> >> Consider this simple statement: >> >> x = a * b * c; >> >> Assume they're all scalars, and a, b, and c are no longer used after this >> statement. That means liveness analysis will make their registers available >> for other variables, without you having to worry about it. But if instead >> these variables were huge matrices and you had to manually free their >> storage to minimize memory consumption, then it would look something like >> this: >> >> Matrix t = a * b; >> a.~Matrix(); >> b.~Matrix(); >> x = t * c; >> t.~Matrix(); >> c.~Matrix(); >> >> Or if you wanted to do it with scopes: >> >> { >> Matrix t; >> { >> Matrix a = ...; >> Matrix b = ...; >> t = a * b; >> } >> Matrix c = ...; >> x = t * c; >> } >> >> To me the original statement looks a whole lot easier to read and >> maintain than the two workarounds. And this is just a trivial example! It >> would become insane to do it for any realistic data processing code. >> >> Also I think that calling something a "terrible imposition" or not is >> highly subjective. Many recent C++ features solve issues that already had >> workarounds which some considered acceptable but were unworkable for >> others. So please avoid being prejudiced by your own experience and having >> no direct use for this yourself. C++ supports a huge variety of >> applications. >> >> I hope the above example illustrates that this is very similar to >> register allocation, and it's a standards issue that we don't get this >> behavior today for non-scalar types. >> >> >>> On Fri, Aug 26, 2016 at 1:05 PM, Nicolas Capens < >>> nicolas.capens@gmail.com> wrote: >>> >>>> >>>> >>>> On Wed, Aug 24, 2016 at 4:22 PM Nevin Liber >>>> wrote: >>>> >>>>> On 24 August 2016 at 15:16, wrote: >>>>> >>>>>> The code would become littered with braces if you want to limit the >>>>>> scope of each object to its miminal range, >>>>>> >>>>> >>>>> I don't understand why you would want to do that. Could you elaborate? >>>>> >>>> >>>> Certainly. I wrote down three practical use cases here >>>> >>>> . >>>> >>>> >>>>> And if the objects are truly independent and have no observable >>>>> effect, can't a compiler do that under the as-if rule? >>>>> >>>> >>>> The problem is that the objects I'm using do have side-effects, so the >>>> compiler won't attempt to shorten their lifespan. But in my use cases the >>>> side effects are "self-contained", i.e. you could treat them as scalars and >>>> destruct them right after their last use. >>>> >>>> >>>>> Also, if you wish to have a lifetime shorter than a scope for an >>>>> object of type T, you can just use std::optional. >>>>> >>>> >>>> How would that work, without requiring manual actions to destruct it? >>>> >>>> >>>>> Fortunately we don't, because today's compilers do liveness analysis >>>>>> to optimize register allocation. >>>>>> >>>>> >>>>> One of the huge benefits to C++ is that destruction happens at well >>>>> defined times. This would break that. >>>>> >>>> >>>> Yes, in many cases it will be preferable to keep the well defined >>>> behavior of implicitly calling the destructor at the end of the variable's >>>> scope. The opt-in feature I'm proposing should be used sparingly and >>>> cautiously. But when used by a well written framework it should be >>>> foolproof for the users of the framework, and offer them significant >>>> benefits. >>>> >>>> >>>>> -- >>>>> Nevin ":-)" Liber +1-847-691-1404 >>>>> >>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "ISO C++ Standard - Future Proposals" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/IUxA4cx8yHc/unsubscribe >>>>> . >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> std-proposals+unsubscribe@isocpp.org. >>>>> To post to this group, send email to std-proposals@isocpp.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM3M43y_8jTg4mXce1sz7UQ5kzSkOVqL3F_nYEe-ogzNA%40mail.gmail.com >>>>> >>>>> . >>>>> >>>> -- >>>> 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. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAE7XuEVobd1QW2jJYW-hGTLTPgQxRJM-QkL9jNovOkhaaoXQEw%40mail.gmail.com >>>> >>>> . >>>> >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "ISO C++ Standard - Future Proposals" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/IUxA4cx8yHc/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> std-proposals+unsubscribe@isocpp.org. >>> To post to this group, send email to std-proposals@isocpp.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD_8zsoqfYdUsY%2BQe_QNvzFsH4c9uUjNYzw5BRFiLQRE%2BQ%40mail.gmail.com >>> >>> . >>> >> >> > -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAE7XuEXAELWV5xFYABGNy%2Bc1vQxatD7JEDY%3DJst%3DC_wgyrwj0w%40mail.gmail.com. --001a1147b804f865ad053b38d47d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 26= , 2016 at 5:46 PM Ren Industries <renindustries@gmail.com> wrote:
That in no way demonstrates it is similar to regi= ster allocation, which is, again, a QOI issue.

<= /div>
My apologies. The example omitted how the equivalent scalar code = would have its registers freed up for use by other variables after their la= st use. I thought that would be sufficiently clear. Here's an illustrat= ion of that:=C2=A0http://compilers.cs.ucla.edu/fernando/projects/puzzles/= tutorial/. The end of the live ranges corresponds to where I'd like= the destructors of objects to be called. Let me know if the similarities a= re still not obvious to you and I'll create a more detailed side-by-sid= e example if I find the time.

Anyway, yes, registe= r allocation is a quality of implementation issue. One that is enabled by t= he standard allowing for it because scalars having no side-effects on destr= uction. I want to enable that same freedom of optimization for objects that= do have side-effects, by telling the compiler that we don't care about= these side-effects to happen at the end of the variable's scope.
=
=C2=A0
It is not = necessarily the case that a compiler need do that, and I can think of at le= ast a few counter examples. For example, there are projects that output C++= to javascript or java, which have no notion of register allocation as you = point to it. These "machines" are perfectly valid C++ targets, ye= t have absolutely no notion of what you are talking about.

I realize that. But I shouldn't have to care if a= compiler strictly needs to do that today or not. I'm talking about add= ing a new feature to the language, and this may involve adding some new imp= lementation requirements. If that causes some cross-compilers to no longer = be able to support this new version of C++ without some non-trivial effort,= too bad. It's certainly not my aim to make implementer's lives dif= ficult, but I also don't want to cripple or abandon the feature because= of it.

Indeed, C++ supports a huge variety of applications. More than you kn= ow of, it seems.

You're tal= king about Emscripten and alike. That's implementation side. I was talk= ing about applications written in C++. You seemed to see no practical uses = for this feature, presumably because you hadn't encountered such an app= lication before. Did my trivial example clarify that manual freeing of the = resources is not acceptable, or do you still disagree?
=C2=A0
On Fri, Aug 26, 2016 at 3:21 PM, Nicolas Capens <nicola= s.capens@gmail.com> wrote:
=
On Fri, Aug 26, 2016 at 1:16 PM, Ren Industries <renindustries@gma= il.com> wrote:
Why is it such a terrible imposition to require man= ual interaction to enforce this behavior? I don't buy your argument tha= t it is similar to register allocation; that's a QOI not a standards is= sue.

Consider this simple stat= ement:

=C2=A0 =C2=A0 x =3D a * b * c;
Assume they're all scalars, and a, b, and c are no longer = used after this statement. That means liveness analysis will make their reg= isters available for other variables, without you having to worry about it.= But if instead these variables were huge matrices and you had to manually = free their storage to minimize memory consumption, then it would look somet= hing like this:

=C2=A0 =C2=A0 Matrix t =3D a * b;<= /div>
=C2=A0 =C2=A0 a.~Matrix();
=C2=A0 =C2=A0 b.~Matrix();
=C2=A0 =C2=A0 x =3D t * c;
=C2=A0 =C2=A0 t.~Matrix();
=C2=A0 =C2=A0 c.~Matrix();

Or if you wante= d to do it with scopes:

=C2=A0 =C2=A0 {
= =C2=A0 =C2=A0 Matrix t;
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 M= atrix a =3D ...;
=C2=A0 =C2=A0 Matrix b =3D ...;
=C2=A0= =C2=A0 t =3D a * b;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 Matr= ix c =3D ...;
=C2=A0 =C2=A0 x =3D t * c;
=C2=A0 =C2= =A0 }

To me the original statement looks a whole l= ot easier to read and maintain than the two workarounds. And this is just a= trivial example! It would become insane to do it for any realistic data pr= ocessing code.

Also I think that calling something= a "terrible imposition" or not is highly subjective. Many recent= C++ features solve issues that already had workarounds which some consider= ed acceptable but were unworkable for others. So please avoid being prejudi= ced by your own experience and having no direct use for this yourself. C++ = supports a huge variety of applications.

I hope th= e above example illustrates that this is very similar to register allocatio= n, and it's a standards issue that we don't get this behavior today= for non-scalar types.
=C2=A0
On Fri, Aug 26, 2016 at 1:05 PM, Nicolas Capens <nicolas.capens@gmail.com> wrote:


On Wed, Aug 24, 2016 at 4:2= 2 PM Nevin Liber <nevin@eviloverlord.com> wrote:
On 24 August 2016 at 15:16, <= span dir=3D"ltr"><nicolas.capens@gmail.com> wrote:
The code would bec= ome littered with braces if you want to limit the scope of each object to i= ts miminal range,

=
I don't understand why you would want to do that.=C2=A0 Could you elab= orate?

Certa= inly. I wrote down three practical use cases here.
=C2=A0
And if the objects are truly independent and h= ave no observable effect, can't a compiler do that under the as-if rule= ?

The proble= m is that the objects I'm using do have side-effects, so the compiler w= on't attempt to shorten their lifespan. But in my use cases the side ef= fects are "self-contained", i.e. you could treat them as scalars = and destruct them right after their last use.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Also, if you wish to have= a lifetime shorter than a scope for an object of type T, you can just use = std::optional<T>.

=
How would that work, without requiring manual actions to destru= ct it?
=C2=A0
<= div>Fortunately we don't, because today's compilers do liveness ana= lysis to optimize register allocation.

One of the huge benefits to C++ is that destruction h= appens at well defined times.=C2=A0 This would break that.

Yes, in many cases it will b= e preferable to keep the well defined behavior of implicitly calling the de= structor at the end of the variable's scope. The opt-in feature I'm= proposing should be used sparingly and cautiously. But when used by a well= written framework it should be foolproof for the users of the framework, a= nd offer them significant benefits.
=C2=A0
--
=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:= nevin@eviloverl= ord.com> =C2=A0+1-847-691-1404

--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/IUxA4cx8yHc= /unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-prop= osals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-pro= posals/CAGg_6%2BM3M43y_8jTg4mXce1sz7UQ5kzSkOVqL3F_nYEe-ogzNA%40mail.gmail.c= om.

--
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.
 To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-propo= sals/CAE7XuEVobd1QW2jJYW-hGTLTPgQxRJM-QkL9jNovOkhaaoXQEw%40mail.gmail.com.

--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/IUxA4cx8yHc= /unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-prop= osals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-p= roposals/CAMD6iD_8zsoqfYdUsY%2BQe_QNvzFsH4c9uUjNYzw5BRFiLQRE%2BQ%40mail.gma= il.com.


--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAE7XuEXAEL= WV5xFYABGNy%2Bc1vQxatD7JEDY%3DJst%3DC_wgyrwj0w%40mail.gmail.com.
--001a1147b804f865ad053b38d47d-- .