220 27979 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: Fri, 26 Aug 2016 15:34:43 -0400 Lines: 193 Approved: news@gmane.org Message-ID: References: <20160824214337.GA18752@noemi> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c112468426f33053afe9ba1 X-Trace: blaine.gmane.org 1472240092 6924 195.159.176.226 (26 Aug 2016 19:34:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 26 Aug 2016 19:34:52 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBC6MN3XGLYINLM4CXYCRUBBMXJM7M@isocpp.org Fri Aug 26 21:34:48 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bdMtp-0001Di-5v for gclcip-std-proposals@m.gmane.org; Fri, 26 Aug 2016 21:34:45 +0200 Original-Received: by mail-pa0-f70.google.com with SMTP id ag5sf144108893pad.2 for ; Fri, 26 Aug 2016 12:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references: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=HOEY2t/ORL4xf7pjLTSrZNLmS5j+V+2CoLHAF+wf0YU=; b=qmTk9BDIcLNifSWZCxmGW04MnnwecYgrz6ElRG4ZPhT8wYXJ5OPnidPzzzUMGzXmqA LP5ICjep5FpQJBuESl0+HFwqGwIlfBP9BKPITvm9Try/9F9HwDQL7k1YyRkh1wzjgn7z XYAtTjZTHyeTkRiBJIJdef3ABzLRtaguVOo4j7nOR3wn0YBsww5ne4J+i+y5AB23bLTL bcdnRSoQA1g9R1Aahw8JI3QBG0AD1B4x2ldk40SVZEpgLF/5wTsuv7vnt6zgJneudv9g rJnr6uVOVxXXp510r5Ku3KtP9jManswMsBRVA/hIazxRYfHs/iE5ed0PgOJ4yiDR9V5A lsWg== 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: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=HOEY2t/ORL4xf7pjLTSrZNLmS5j+V+2CoLHAF+wf0YU=; b=RZROJWRuagfR/NEsfgyXV6pb85CT3qDolYMaOzEjkT9ClwXyMxOqpauiZdfP5E9H0D eAIlS4W0QWtBmLu9+eoeAjYCkpAoL/mBLhmgMzBvB4tWCWnMRD/tHPNhtYLM+XySxelv 9rr1jWcWJKMT2Sq+oNnXiureVdYHmtQY30UnLAHKjI9o4J4Xkyk0xSgqr9iFysdi7uKy mtsfEc1+CZh6fOeaQrumppXmcG8GYfGnZrcbulPzjRQEfZYUDLyoo88ZLJxu3FteirCC j8QFSn2p5WyvxadRxFilSd0lFUyS4E504Zw0vg4/cF0GCo0i5oLUykBKvkDZGAEhL/6N w5lg== X-Gm-Message-State: AE9vXwNc+gC+Jkrr59iNkYfR3nb+k8mzDSeBFBAigPRSfMnnh4F142P+mwbLHdmR7kHMDQ== X-Received: by 10.66.192.169 with SMTP id hh9mr3883414pac.24.1472240085698; Fri, 26 Aug 2016 12:34:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.51.35 with SMTP id f32ls3650728otc.33.gmail; Fri, 26 Aug 2016 12:34:44 -0700 (PDT) X-Received: by 10.55.88.199 with SMTP id m190mr5401879qkb.78.1472240084895; Fri, 26 Aug 2016 12:34:44 -0700 (PDT) Original-Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com. [2607:f8b0:400d:c09::22b]) by mx.google.com with ESMTPS id f81si15462478qke.6.2016.08.26.12.34.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Aug 2016 12:34:44 -0700 (PDT) Received-SPF: pass (google.com: domain of nicolas.capens@gmail.com designates 2607:f8b0:400d:c09::22b as permitted sender) client-ip=2607:f8b0:400d:c09::22b; Original-Received: by mail-qk0-x22b.google.com with SMTP id v123so86656058qkh.2 for ; Fri, 26 Aug 2016 12:34:44 -0700 (PDT) X-Received: by 10.233.232.195 with SMTP id a186mr5383652qkg.109.1472240084475; Fri, 26 Aug 2016 12:34:44 -0700 (PDT) Original-Received: by 10.55.180.4 with HTTP; Fri, 26 Aug 2016 12:34:43 -0700 (PDT) In-Reply-To: <20160824214337.GA18752@noemi> 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::22b 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:27979 Archived-At: --94eb2c112468426f33053afe9ba1 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 24, 2016 at 5:43 PM, Magnus Fromreide wrote: > On Wed, Aug 24, 2016 at 11:51:01AM -0700, nicolas.capens@gmail.com wrote: > > Hi all, > > > > I'd like to propose a new kind of destructor that gets called after a > local > > object's last use, instead of at the end of its scope. > > > > The use of this would be to free resources held by the object sooner. > This > > could be heap memory, file handles, mutex locks, etc. Releasing them as > > soon as we're done with the object that represents them would result in > > more efficient programs. > > > > Currently such optimization can only be achieved by explicitly releasing > > the resources, which is inconvenient, bug prone, and reduces readability. > > Limiting the scope with extra braces or by putting the operations in a > > subroutine also often isn't a desirable workaround. Note that compilers > > have been doing liveness analysis for register allocation and stack > > compaction for a very long time and we take these optimizations for > > granted. I'd like to see it get extended to heap memory and other > resources > > as well. > > > > The syntax for this could be an annotation of the destructor declaration > > with a keyword, symbol, or attribute. For example, "auto ~Object();", > > "volatile ~Object();", "~~Object();", or "[[eager]] ~Object();". > > This do sound like you are expecting the normal destructor to get called at > end of scope, is this correct? > No, I envisioned that there would just be one implicit call to the destructor, which is either a classic "lazy" one or the newly proposed "eager" one. The only thing that changes is the point where it gets called. So the default is still at the end of the scope, but when opting in to eager destruction it would get called after the last use of the object (with some unresolved wiggle room for the definition of last use). That said, it's worth entertaining the idea of having both kinds of destructor! Perhaps some objects can have some of their content destructed eagerly while other bits need to stick around until the end of the scope. I can't immediately think of an example, but that doesn't have to stop us from enabling this scenario too. Thanks! > If so then what would this extra destructor do that > > T(std::move(aT)); > > doesn't do today? > I need the eager destructor to be called automatically, not manually, to keep the code more readable. > /MF > > -- > 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/20160824214337.GA18752%40noemi. > -- 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/CAE7XuEVh4obh69JwLBOo7qgaRA5iu%2BHx87L9uv1eaGVSZvqPDA%40mail.gmail.com. --94eb2c112468426f33053afe9ba1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 24, 2016 at 5:43 PM, Magnus Fromreide <= ;magfr@lysator.li= u.se> wrote:
On Wed, Aug 24, 2016 at 11:51:01AM -0700, nicolas.capens@gmail.com wrote:
> Hi all,
>
> I'd like to propose a new kind of destructor that gets called afte= r a local
> object's last use, instead of at the end of its scope.
>
> The use of this would be to free resources held by the object sooner. = This
> could be heap memory, file handles, mutex locks, etc. Releasing them a= s
> soon as we're done with the object that represents them would resu= lt in
> more efficient programs.
>
> Currently such optimization can only be achieved by explicitly releasi= ng
> the resources, which is inconvenient, bug prone, and reduces readabili= ty.
> Limiting the scope with extra braces or by putting the operations in a=
> subroutine also often isn't a desirable workaround. Note that comp= ilers
> have been doing liveness analysis for register allocation and stack > compaction for a very long time and we take these optimizations for > granted. I'd like to see it get extended to heap memory and other = resources
> as well.
>
> The syntax for this could be an annotation of the destructor declarati= on
> with a keyword, symbol, or attribute. For example, "auto ~Object(= );",
> "volatile ~Object();", "~~Object();", or "[[e= ager]] ~Object();".

This do sound like you are expecting the normal destructor to get ca= lled at
end of scope, is this correct?

No, I en= visioned that there would just be one implicit call to the destructor, whic= h is either a classic "lazy" one or the newly proposed "eage= r" one. The only thing that changes is the point where it gets called.= So the default is still at the end of the scope, but when opting in to eag= er destruction it would get called after the last use of the object (with s= ome unresolved wiggle room for the definition of last use).

<= /div>
That said, it's worth entertaining the idea of having both ki= nds of destructor! Perhaps some objects can have some of their content dest= ructed eagerly while other bits need to stick around until the end of the s= cope. I can't immediately think of an example, but that doesn't hav= e to stop us from enabling this scenario too. Thanks!
=C2=A0
If so then what would this extra destructor do that

T(std::move(aT));

doesn't do today?

I need the eager = destructor to be called automatically, not manually, to keep the code more = readable.
=C2=A0
/MF

--
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/s= td-proposals/IUxA4cx8yHc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscrib= e@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/iso= cpp.org/d/msgid/std-proposals/20160824214337.GA18752%40noemi.=

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAE7XuEVh4obh69= JwLBOo7qgaRA5iu%2BHx87L9uv1eaGVSZvqPDA%40mail.gmail.com.
--94eb2c112468426f33053afe9ba1-- .