220 10890 <799E7B56-C6B1-4223-84AE-D6BCE0A99FE8@gmail.com> article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: N4009: return type of erase_if Date: Tue, 27 May 2014 20:45:39 +0800 Lines: 98 Approved: news@gmane.org Message-ID: <799E7B56-C6B1-4223-84AE-D6BCE0A99FE8@gmail.com> References: <09b01713-0312-495e-b984-f492307f0f47@isocpp.org> <80B2AD70-C23C-474D-88E9-24B7EA7EE545@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_F934CA55-E327-471A-AAD4-9F22DEE20708" X-Trace: ger.gmane.org 1401207493 8727 80.91.229.3 (27 May 2014 16:18:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 May 2014 16:18:13 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBOXVSKOAKGQEW5LRUBQ@isocpp.org Tue May 27 18:18:05 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pb0-f70.google.com ([209.85.160.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WpK4i-0001IA-OG for gclcip-std-proposals@m.gmane.org; Tue, 27 May 2014 18:18:05 +0200 Original-Received: by mail-pb0-f70.google.com with SMTP id rq2sf44993855pbb.5 for ; Tue, 27 May 2014 09:18:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=Rv1GKd0UUdLUVsXuot63HiXhCPgXzDsU0R+mF70j5PQ=; b=kcS7Rv2LL1PRqOPbv/og2IVWnqTM9ockNR2C4o+sbgEVAt3vznlVLRldWixwNN+QaY YStg75otxlYJbNIS0ccPh0DXSVfnEYPOGQ0excwqJAsV3MrBZm6/W06f5oDw9IpwrgrT 6PEMyuBTT+WKHytqSGTfgZsxdF7aLVT2jCq96Easxx8uZrMUY7DaCjQOaJ4OMqxYxd9l S7+2P96mps0+6YjiqEs/m44S5fvdcY+JuW9IdvR547gylfNpdnHPF0YOY9Vb/21NwfOU ljN+BDXK5fmC+MPTOfrLN6JZzmLtoquEast/TeTnmQImKtbTeRINvllyO+W3HUtz9q5G 9YRA== X-Gm-Message-State: ALoCoQkeyS6sYbVY+6YfYUYWWr5L2dbi1NB18UNxhHcNAmUjqJggCgHdTttuFHGhy4paqnO8rlPf X-Received: by 10.66.142.169 with SMTP id rx9mr13594363pab.10.1401207483101; Tue, 27 May 2014 09:18:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.25.70 with SMTP id a6ls2199378igg.42.canary; Tue, 27 May 2014 09:18:02 -0700 (PDT) X-Received: by 10.50.118.69 with SMTP id kk5mr34473308igb.10.1401207482209; Tue, 27 May 2014 09:18:02 -0700 (PDT) Original-Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [2607:f8b0:4001:c03::232]) by mx.google.com with ESMTPS id rv3si6606658igb.34.2014.05.27.09.18.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 09:18:02 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:4001:c03::232 as permitted sender) client-ip=2607:f8b0:4001:c03::232; Original-Received: by mail-ie0-f178.google.com with SMTP id rl12so8723494iec.23 for ; Tue, 27 May 2014 09:18:02 -0700 (PDT) X-Received: by 10.42.120.15 with SMTP id d15mr31146063icr.35.1401207482086; Tue, 27 May 2014 09:18:02 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.60]) by mx.google.com with ESMTPSA id k20sm8713252igf.5.2014.05.27.09.17.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 09:18:00 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.1878.2) X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:4001:c03::232 as permitted sender) smtp.mail=potswa@gmail.com; dkim=pass header.i=@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:10890 Archived-At: --Apple-Mail=_F934CA55-E327-471A-AAD4-9F22DEE20708 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 On 2014-05-27, at 7:14 PM, vadim.petrochenkov@gmail.com wrote: > I'm curious, is there any general policy in the library on changing or no= t changing "return void" to something in any way useful? >=20 > Because assuming the statement > If the result is discarded, the compiler will be able to elide its comput= ation after inlining. > is true, a lot of member functions, for example, could potentially benefi= t from returning *this instead of void, but they still return void for some= reason. Returning this (or *this) is of no help to the CPU, which already has acces= s to the value from wherever it got it prior to the call. Some ABIs (well, at least one, for Windows x86 if I recall correctly) retur= n this from constructors, so as to relieve register pressure, but that's a = special case of integration between the optimizer and the ABI. Anyway, I'm unclear on the connection with my statement. Optimizers can per= form lifetime analysis on local variables, but variables accessed through p= ointers or references are trickier. Inlining a function may allow its local= variables to become locals in the calling function, and then lifetime anal= ysis may discover that the "number erased" result is never used aside from = increment instructions. If all this works correctly, which is reasonable to= suppose but far from a sure thing, then counting but ignoring the number o= f erased elements is free. That's all I'm saying. --=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/. --Apple-Mail=_F934CA55-E327-471A-AAD4-9F22DEE20708 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
= On 2014–05–27, at 7:14 PM, vadim.petrochenkov@gmail.com wrote:

I'm curiou= s, is there any general policy in the library on changing or not changing "= return void" to something in any way useful?

Because assum= ing the statement
If the result is discard= ed, the compiler will be able to elide its computation after inlining.
is true, a lot of member functions, for example, could potenti= ally benefit from returning *this instead of void, but they still return vo= id for some reason.

Retur= ning this (or *this) is of no help to the CPU, which already has access to = the value from wherever it got it prior to the call.

So= me ABIs (well, at least one, for Windows x86 if I recall correctly) return = this from constructors, so as to relieve register pressure, but that’= s a special case of integration between the optimizer and the ABI.

Anyway, I’m unclear on the connection with my statem= ent. Optimizers can perform lifetime analysis on local variables, but varia= bles accessed through pointers or references are trickier. Inlining a funct= ion may allow its local variables to become locals in the calling function,= and then lifetime analysis may discover that the “number erased&rdqu= o; result is never used aside from increment instructions. If all this work= s correctly, which is reasonable to suppose but far from a sure thing, then= counting but ignoring the number of erased elements is free. That’s = all I’m saying.

--

---
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>.
--Apple-Mail=_F934CA55-E327-471A-AAD4-9F22DEE20708-- .