220 28030 article Path: news.gmane.org!.POSTED!not-for-mail From: Peter Koch Larsen 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 00:07:11 +0200 Lines: 74 Approved: news@gmane.org Message-ID: References: <6aa24874-7bae-449f-ac2b-67f0605fbd65@isocpp.org> <2e647ba9-3f9c-4b2a-90c7-bcdffdd4153b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1472508438 19501 195.159.176.226 (29 Aug 2016 22:07:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Aug 2016 22:07:18 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDRIBXXKZQERBEPESK7AKGQE7LF6WNQ@isocpp.org Tue Aug 30 00:07:13 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f198.google.com ([209.85.220.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1beUi0-0004lE-TM for gclcip-std-proposals@m.gmane.org; Tue, 30 Aug 2016 00:07:13 +0200 Original-Received: by mail-qk0-f198.google.com with SMTP id f128sf3360497qkd.1 for ; Mon, 29 Aug 2016 15:07:14 -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=lPZMKzRcpRWjSC6y2tQyuvXU4c+GKdXfAGuJ8ASvHVA=; b=xNgUzyiDmz82ip/ksxCDAZKivwjTliumzDD5cBNyF0g3mOx6HpTwmVBJyU6tdlNEaP LPGmUHuMze4a/nxj1mhqnan84gzrz6QBlbSTS+n0r77ECvKXDWuMmaNwjDi0EJ8cxkHK PpP/lCrNamOAAQE2fffLDonzjMu757V1DgX65AmCFEkOPn01+LUn+V/ZLateXhFKt0/f F51sf1W+QqFyAFCGvuRy/qJJV6dD2dtFsrBsPeHS1dydmDVY/HSp1Mtetm9m5cdqw9YV DFcq5O7OxtefEC8S7kVqRPK3KlzTSDQwXXlz/ljYZrTizzI6VxN8BrSH78fiXaqzrcmy B0eg== 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=lPZMKzRcpRWjSC6y2tQyuvXU4c+GKdXfAGuJ8ASvHVA=; b=jCVpNTtIl5vfr/PORBeNZ9ZJr+LhgSmboo8Zb1/c8iwaWop6CqX0OMXStXMS4zT+zi y+trsWgXqk+ZqDi4GuBMRzi22RnGH4yiaS4+gnFEvyw3cQCFDstuWSg22CTZV7qysfU8 2jMtSxkHAj9aY+RlyQ5G195M7zUhzOhJTXBtaHe3SxxH9iBWD+d3A+WJ3kfd7LKcS21K V4HCtVrN+R0Ev3eHA7Za8adyhzitQD2RlFJYPTqO0h16Fr8Q+GHj+CSK49xXZmr61mSq jlWcQhpn7t47sxrU+M6LkKztxP6NHtrJmA/kfV1QPJUEBAoiFZdAMYhciDZmyJcbj81Q PlQg== X-Gm-Message-State: AE9vXwNK8X1SGr0zI/wxuC0KTRd8X0NDGjF7Wy6yOVxZ0jood1GodgDKw71eb91J3kNxzA== X-Received: by 10.200.56.115 with SMTP id r48mr263778qtb.28.1472508433683; Mon, 29 Aug 2016 15:07:13 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.6.108 with SMTP id 99ls8098292otn.17.gmail; Mon, 29 Aug 2016 15:07:12 -0700 (PDT) X-Received: by 10.159.40.165 with SMTP id d34mr215077uad.110.1472508432814; Mon, 29 Aug 2016 15:07:12 -0700 (PDT) Original-Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com. [2607:f8b0:400c:c08::232]) by mx.google.com with ESMTPS id i7si1551303uaa.242.2016.08.29.15.07.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 15:07:12 -0700 (PDT) Received-SPF: pass (google.com: domain of peter.koch.larsen@gmail.com designates 2607:f8b0:400c:c08::232 as permitted sender) client-ip=2607:f8b0:400c:c08::232; Original-Received: by mail-ua0-x232.google.com with SMTP id l94so2305140ual.0 for ; Mon, 29 Aug 2016 15:07:12 -0700 (PDT) X-Received: by 10.176.5.132 with SMTP id e4mr224827uae.34.1472508432385; Mon, 29 Aug 2016 15:07:12 -0700 (PDT) Original-Received: by 10.103.33.148 with HTTP; Mon, 29 Aug 2016 15:07:11 -0700 (PDT) In-Reply-To: X-Original-Sender: peter.koch.larsen@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of peter.koch.larsen@gmail.com designates 2607:f8b0:400c:c08::232 as permitted sender) smtp.mailfrom=peter.koch.larsen@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:28030 Archived-At: On Mon, Aug 29, 2016 at 8:54 PM, Nicolas Capens wrote: > > > On Fri, Aug 26, 2016 at 10:39 PM Arthur O'Dwyer > wrote: >> >> On Friday, August 26, 2016 at 12:21:42 PM UTC-7, 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(); >> >> >> Well, it would look like this: >> >> x = a * b * c; >> a.clear(); >> b.clear(); >> c.clear(); >> >> Or, if you wanted to be more C++11'ish about it, >> >> x = std::move(a) * std::move(b) * std::move(c); >> >> to indicate that you're really done using those named variables. It's >> really not a big deal. > > > It is a big deal. That was just a trivial example, but it already makes > things significantly less elegant. Now imagine manually indicating the end > of the live range of every Reactor variable in this code: > https://swiftshader.googlesource.com/SwiftShader/+/master/src/Shader/SetupRoutine.cpp > Also note that you'd have to update it for every change to the actual > algorithms, and you'd need perfect test coverage of every path. This is also > one of the shorter Reactor functions in that project. I just had a glance at the code in your link. A ~200 line function seemingly in dire need of refactoring. Such code is not a good example to argue about liveness of variables. You should refactor the code into smaller, logical elements and demonstrate that "eager destruction" is still needed. /Peter -- 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/CANPtknx5mC09L9x%2B2WmCagWL476DwUGqrthN%3D1pe4tizLj0v7w%40mail.gmail.com. .