220 28048 <7857a4a6-29af-47c0-b6ab-c555a0005935@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Edward Catmur 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: Tue, 30 Aug 2016 04:07:40 -0700 (PDT) Lines: 273 Approved: news@gmane.org Message-ID: <7857a4a6-29af-47c0-b6ab-c555a0005935@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_337_73619561.1472555260123" X-Trace: blaine.gmane.org 1472555271 24426 195.159.176.226 (30 Aug 2016 11:07:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 11:07:51 +0000 (UTC) Cc: nicolas.capens@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDZLZTXF7UJBB7WRSW7AKGQEXAVKOTI@isocpp.org Tue Aug 30 13:07:46 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f197.google.com ([209.85.213.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1begtL-0005fq-3q for gclcip-std-proposals@m.gmane.org; Tue, 30 Aug 2016 13:07:43 +0200 Original-Received: by mail-yb0-f197.google.com with SMTP id x93sf36862528ybh.2 for ; Tue, 30 Aug 2016 04:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=hCf+//VnlWPk9YCGRHqDi3R+bfqP+PsiBf4Xh/wchYM=; b=ccpKmvPHeMUtbSN/C1+AkG4h1dKoy6hwZqqQekhzB6q7pbsenQ1122kP+p9frFrxqN DjZzaoJGTfvlw1wo7vyDnfUzGcxBTQw3soXiYJB5eJQNBxRAJIG7D7pZOT/NOmrUep9c rbH7r0T7iQAttWPNilLkMmfPTIjiUQGxx8jQPO6EAqOEa6AF7D2NY06togylm2wimTj7 VI4ey2CORBBRseuaaIMGdzI4T+/MWfa1gGG2kFvErFmurBY0PrHscgcGGA1kQwIMlNNS MykfjN9GTn6jEZwOqMO4NGW2YqoOgW8/A88gaSfOHXEBmwZ3xaSZV+ON/V+QzssnJk+V 4noQ== 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:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=hCf+//VnlWPk9YCGRHqDi3R+bfqP+PsiBf4Xh/wchYM=; b=J9I+WJ1xtI4mGsqGFUxiXItt3td7FAJuMHgmX1NwvVJ4vqegMkPe1NosbwOvWj0R7R o3M9Mzujx9PbisEP8mNfuG8/5pJi/mjH6QGty/ILS/heLo+V0fIKVC1Qcrv5YONRjWZe ZTigf+31dZIX6VmEctQ6IV+oiKllpbocArfk5cvYShq84TYul7J7rWSOyODp7flyecnj lwzNFZNZ6bYDfy2tgpcCf2vyqM/VLLh2+abT0h0fABCVBfbTWjPDfrGyjeHNuAdJHOQL 2Jv/oZRbSl9N8EAnKbAf+IeqNuE/E2M+zHPLWXeG1QvdImecLehlNYv6Dj/uZJ7CoB5J 4n5g== X-Gm-Message-State: AE9vXwMT2W9MqH002mCIN+QBeuK+Ncfcu7VVkUTTlmqimL91p/EPsoEGpHlRRko35BACbg== X-Received: by 10.200.37.20 with SMTP id 20mr2402982qtm.17.1472555263860; Tue, 30 Aug 2016 04:07:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.91.212 with SMTP id g203ls1052469itb.13.gmail; Tue, 30 Aug 2016 04:07:42 -0700 (PDT) X-Received: by 10.36.239.3 with SMTP id i3mr509968ith.2.1472555261304; Tue, 30 Aug 2016 04:07:41 -0700 (PDT) In-Reply-To: X-Original-Sender: ed@catmur.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: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:28048 Archived-At: ------=_Part_337_73619561.1472555260123 Content-Type: multipart/alternative; boundary="----=_Part_338_1043379957.1472555260124" ------=_Part_338_1043379957.1472555260124 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, 30 August 2016 10:49:58 UTC+1, Andrzej Krzemie=C5=84ski wrote: > > > > W dniu czwartek, 25 sierpnia 2016 23:24:39 UTC+2 u=C5=BCytkownik Nicolas = Capens=20 > napisa=C5=82: >> >> Thanks all for the initial feedback! It's clear to me now that I haven't= =20 >> defined "last use" very well, and giving it an accurate definition based= on=20 >> my limited knowledge of compiler lingo is going to be tricky. >> >> So let me take a step back and describe what real-world issues I'm tryin= g=20 >> to solve. The first example is one where I'd like the heap memory manage= d=20 >> by an object to get freed at the same point where a scalar variable's=20 >> register would be made available for a different variable: >> >> class Matrix >> { >> public: >> Matrix(size_t rows, size_t columns); >> auto ~Matrix(); // Eager destructor >> ... >> private: >> double *m; >> }; >> >> { >> Matrix a(10'000, 10'000) =3D ...; >> Matrix b(10'000, 10'000) =3D ...; >> Matrix c(10'000, 10'000) =3D ...; >> >> a +=3D b; // Last use of b, destruct before the next line >> a +=3D c; >> } >> >> The alternative of using explicit destruction is really inconvenient: >> >> { >> Matrix a(10'000, 10'000) =3D ...; >> Matrix b(10'000, 10'000) =3D ...; >> Matrix c(10'000, 10'000) =3D ...; >> >> a +=3D b; >> b.~Matrix(); >> a +=3D c; >> } >> >> As is reducing the scope: >> >> { >> Matrix a(10'000, 10'000) =3D ...; >> >> { >> Matrix b(10'000, 10'000) =3D ...; >> a +=3D b; >> } >> >> Matrix c(10'000, 10'000) =3D ...; =20 >> a +=3D c; >> } >> >> > Note that to some extent you can fix this problem with std::optional (in= =20 > C++17, now in a TS): > > =20 > { > Matrix a(10'000, 10'000) =3D ...; > optional b(in_place, 10'000, 10'000) =3D ...; > Matrix c(10'000, 10'000) =3D ...; > > a +=3D *b; > b =3D nullopt; > a +=3D c; > } > (Reposting from correct account; sorry for the noise.) You can do better than that using the exchange-empty idiom: =20 a +=3D *std::exchange(b, nullopt); However I believe that OP considers this also too clumsy (look for=20 discussion of std::move above). =20 One thing I haven't seen mentioned yet in this discussion is that=20 allocation and deallocation is already elidable per [expr.new]/10. This=20 means that e.g. the destructor of std::string is not an observable=20 operation. --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/7857a4a6-29af-47c0-b6ab-c555a0005935%40isocpp.or= g. ------=_Part_338_1043379957.1472555260124 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, 30 August 2016 10:49:58 UTC+1, Andrzej Krzemie= =C5=84ski wrote:


W dniu czwartek, 25 sierpnia 2016 23:24:39 UTC+2 u=C5=BCytkowni= k Nicolas Capens napisa=C5=82:
Thanks all for the initial feedback! It's clear to me now t= hat I haven't defined "last use" very well, and giving it an = accurate definition based on my limited knowledge of compiler lingo is goin= g to be tricky.

So let me take a step back and describe = what real-world issues I'm trying to solve. The first example is one wh= ere I'd like the heap memory managed by an object to get freed at the s= ame point where a scalar variable's register would be made available fo= r a different variable:

= =C2=A0 =C2=A0 class Matrix
=C2=A0= =C2=A0 {
=C2=A0 =C2=A0 public:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Matrix= (size_t rows, size_t columns);
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto ~Matrix(); =C2=A0 // Eager destructor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 private:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 double *m;
=C2=A0 =C2=A0 };

=C2=A0 =C2= =A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0= Matrix a(10'000, 10'000) =3D ...;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Matrix b(10'000, 10'000) =3D = ....;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Matrix c(10'000, 10'000) =3D ...;

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 a=C2=A0+=3D b; =C2=A0 // Last use of b, destruct before t= he next line
=C2=A0 =C2=A0 =C2=A0= =C2=A0 a=C2=A0+=3D c;
=C2=A0 =C2= =A0 =C2=A0}

The alternativ= e of using explicit destruction is really inconvenient:

=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Matrix a(10'000, 10'= 000) =3D ...;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Matrix b(10'000, 10'000) =3D ...;
<= font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 Matrix c(10'000, 10= '000) =3D ...;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 a=C2=A0+= =3D b;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 b.~Matrix();
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 a=C2=A0+=3D c;
=C2= =A0 =C2=A0 }

As is reducing the scope= :

=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Matrix = a(10'000, 10'000) =3D ...;

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 Matrix b(10'000, 10'000) =3D ...;
<= font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a=C2=A0+= =3D b;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 }

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Matrix c(10'000, 10'000) =3D ...;=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a=C2=A0+=3D c;<= /font>
=C2=A0 =C2=A0 }


Note that to s= ome extent you can fix this problem with std::optional (in C++17, now in a = TS):

=C2=A0
{
=C2=A0 Matrix a(10'000, 10'000) =3D ...;
=C2=A0 optional<Matrix>= ; b(in_place,<= /span> 10'000, 10'000) =3D = ...;=C2=A0 Matrix c(10'000, 10'000) =3D ...;

=C2=A0 a +=3D *b;
=C2=A0 b =3D nullopt;
=C2=A0 a +=3D<= /span> c;
}=

(Reposting from correct account; sorry for the noise.)


You can do better than tha= t using the exchange-empty idiom:

=C2=A0

a = +=3D *std::exchange(b, nullopt);


However I believe that OP considers this also too cl= umsy (look for discussion of std::move above).

=C2=A0

One thing I haven't seen mentioned yet in this d= iscussion is that allocation and deallocation is already elidable per [expr.new]/10. Thi= s means that e.g. the destructor of std::string is not an observable operatio= n.


--
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/7857a4a6-29af-47c0-b6ab-c555a0005935= %40isocpp.org.
------=_Part_338_1043379957.1472555260124-- ------=_Part_337_73619561.1472555260123-- .