220 10856 <20140527063521.GA26732@sara.home> article Path: news.gmane.org!not-for-mail From: Magnus Fromreide Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: N4009: return type of erase_if Date: Tue, 27 May 2014 08:35:21 +0200 Lines: 79 Approved: news@gmane.org Message-ID: <20140527063521.GA26732@sara.home> References: <09b01713-0312-495e-b984-f492307f0f47@isocpp.org> <3e98c8c3-ade8-40d3-9815-9e9f407cfe8f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1401172533 19981 80.91.229.3 (27 May 2014 06:35:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 May 2014 06:35:33 +0000 (UTC) Cc: jgottman6@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELLREETMBRBLHESCOAKGQE7XEDIWY@isocpp.org Tue May 27 08:35:27 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-we0-f198.google.com ([74.125.82.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WpAyq-0003Wf-TR for gclcip-std-proposals@m.gmane.org; Tue, 27 May 2014 08:35:24 +0200 Original-Received: by mail-we0-f198.google.com with SMTP id k48sf4836998wev.1 for ; Mon, 26 May 2014 23:35:24 -0700 (PDT) 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:subject:message-id :mail-followup-to:references:mime-version:in-reply-to:user-agent :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:content-disposition; bh=yulMDIXB+Sx8j96NmEC6Pr3kXWo1GwJ+mxdwHz5NVu4=; b=XHbWy1GQQbGdKoDV+lyRfQy16CKoSfR7P+0YZKheKHJ6coPeXVjPLb1g5/OuoWPOBM OQtt0plg5+ZjNuar7RCNFwV+V6pTZQB+CGf6xe9mozfedICZH6CJwwjPcVi4yYbkQVeV DfgTyKE3SHr3A729ohey6WiEKXqBIe5+zqRZ+u2eufTJXaFtUVYH7ELXegDAd8fzndRE inrBmWUgk8bltPUKe1b5dwm9jI6TtEOgQdx6EP3Y8QII8cQz22LNs4IsRS+ysyfxYaZD TvNNYNWnBAhoUHX8Ni77dBTMpRoVqcnuQOEHvUB2MKT/n+8YDeutKE6HPYLev1u5mX9 X-Gm-Message-State: ALoCoQmzTeipx/M0bu1opYTcHZQlCbo8idlwSTY2FJKpiQsOk2jn+eRXXq9L/Zzouh/FWsJPdXGk X-Received: by 10.152.36.226 with SMTP id t2mr2392360laj.1.1401172524592; Mon, 26 May 2014 23:35:24 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.43.200 with SMTP id y8ls129158lal.28.gmail; Mon, 26 May 2014 23:35:23 -0700 (PDT) X-Received: by 10.152.37.229 with SMTP id b5mr21347316lak.40.1401172523510; Mon, 26 May 2014 23:35:23 -0700 (PDT) Original-Received: from mail.lysator.liu.se (mail.lysator.liu.se. [2001:6b0:17:f0a0::3]) by mx.google.com with ESMTPS id mw4si29971911lbc.17.2014.05.26.23.35.23 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 26 May 2014 23:35:23 -0700 (PDT) Received-SPF: pass (google.com: domain of magfr@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) client-ip=2001:6b0:17:f0a0::3; Original-Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 42CA440037; Tue, 27 May 2014 08:35:23 +0200 (CEST) Original-Received: from sara.home (h-176-10-249-241.na.cust.bahnhof.se [176.10.249.241]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 1906E40002; Tue, 27 May 2014 08:35:23 +0200 (CEST) Mail-Followup-To: std-proposals@isocpp.org, jgottman6@gmail.com In-Reply-To: <3e98c8c3-ade8-40d3-9815-9e9f407cfe8f@isocpp.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Virus-Scanned: ClamAV using ClamSMTP X-Original-Sender: magfr@lysator.liu.se X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of magfr@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mail=magfr@lysator.liu.se 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: , Content-Disposition: inline Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:10856 Archived-At: On Mon, May 26, 2014 at 04:32:10PM -0700, gmisocpp@gmail.com wrote: > Hi > > On Sunday, May 25, 2014 1:45:04 PM UTC+12, jgot...@gmail.com wrote: > > > N4009 proposes a new template > > function, erase_if, that takes a reference to container and a predicate as > > parameters and erases every element of the container for which that > > predicate is true. It is overloaded for each container type, so for > > instance the vector version is > > > > template > > void erase_if(vector& c, Predicate pred); > > > > > > > > > > I think this is a very good idea except for the return type of the > > function. Often, when coders are erasing more than one element from a > > container they need to know the number of elements that were erased. While > > for std::vector it would be easy to compute this by saving the size before > > the erasure and after the erase_if operator and subtracting, if a container > > does not provide size() or has a linear-time size() function this isn't > > that easy. Also, the version of container's erase() function that takes a > > value returns the number of elements erased. Therefore, I think the > > erase_if function should return the number of elements that were erased. It > > can be declared as > > > > template > > typename vector::size_type erase_if(vector& c, Predicate pred); > > > > > > > > > > Joe Gottman > > > > > I'm keen on N4009. I'm not strongly opposed to the return value being > changed, but I think void return is the right answer. > I say this because while I've found knowing a count of erased items > occasionally useful, I've mostly not needed it in my own code. > > I also think if you want to know a count, you can supply a predicate that > does the counting. Right? > This would seem to be inline with the don't pay for what you don't use > principle. > > I can also imagine (perhaps in a future stl) where you are erasing over > some kind of container that is stream like making the count logically > infinite. That's not a well thought out worry or probably relevant here; > but it might be something to think about in future designs. > > If there is going to be a return value though, I'm not sure which is the > more useful return value to return: a count or what's been erased, or an > index to the position of the first erased item? Which is more useful? Or > perhaps a pair containing both values? This would not be valid for all > container types but it could be zero in that case I imagine. > > Ultimately though I'm of the opinion the void return value is the right > answer, on the basis that if you want a count you can count it yourself > easy enough via the predicate and not forcing the algorithm to provide a > count might make the implementation easier and provide more optimisation > opportunities. If the predicate is supposed to do any processing then I think the right return value might be the predicate, similarly to for_each. This should also work well together with the proxy support from N4035. /MF -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. .