220 14247 <9ffa9e35-172f-4079-99b0-99649b57522a@isocpp.org> article Path: news.gmane.org!not-for-mail From: german.gomez@personifyinc.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: comment on n4244 Date: Mon, 27 Oct 2014 04:14:51 -0700 (PDT) Lines: 76 Approved: news@gmane.org Message-ID: <9ffa9e35-172f-4079-99b0-99649b57522a@isocpp.org> References: <5d78c59b-4d67-45f6-9d99-8c4beeeac055@isocpp.org> <5344687e-e1de-4205-885c-b5c2f9580129@isocpp.org> <187da710-8adc-4516-bf64-263951503bc7@isocpp.org> <42ddf641-27c7-42a5-ab1c-772667797e5b@isocpp.org> <05a08ac6-f9b8-4ebb-9cb8-9a37a6fd4527@isocpp.org> <3ff7fe35-37c6-4f95-8701-1798b0112c10@isocpp.org> <7a0d78d9-e5dd-4786-b205-32cdf800b910@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_269_1323241347.1414408491790" X-Trace: ger.gmane.org 1414408502 19186 80.91.229.3 (27 Oct 2014 11:15:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Oct 2014 11:15:02 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDWYPV7DUIFRBLOSXCRAKGQEG4EBDJI@isocpp.org Mon Oct 27 12:14:55 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XiiGE-0000GG-PC for gclcip-std-proposals@m.gmane.org; Mon, 27 Oct 2014 12:14:54 +0100 Original-Received: by mail-oi0-f72.google.com with SMTP id a3sf29788797oib.3 for ; Mon, 27 Oct 2014 04:14:53 -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:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=nFmiYKTm9CZFbhlSWTGBtQcK8ils7gvEIuZ+/wKm/Tw=; b=B4Y+WBfC0pB3zNhfo8UX40IvV4UCQOgRsTVyA65YFd6ie2EYca/8s3zvma/TceoRc+ ANi07pCjWkXdjEgwo4ZRICIMhQA/3UiQbz1hZNNeNdqtIuha3LJy+F15DB3/bphXpeR4 b2WDJbWL+nGXW0yzOBRphXRwQt9EM1NTnNyWxgmjc5XS/kMEIZz/8VczFeNapS+j18S5 A1X+amTgPRir9dUv04YORMjLJfoDf4jKIc2HfjVSxGdRMSP0uUn948MC0U0cpm4Sj8FW yUsEUuR7Fr0JT3HLDqe26p1SAra8fOhe8vcdAR2O2BN+R7TcEy+4FgLG6ImEqsKaBEdx jBuQ== X-Gm-Message-State: ALoCoQkcXcZrpLv9t8pNWYHd96xuCN7GRvyeB3HBLLC+i7nL0hTtCwethpZeStLwPlRsgitGlcP8 X-Received: by 10.42.139.131 with SMTP id g3mr4486588icu.28.1414408493746; Mon, 27 Oct 2014 04:14:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.18.167 with SMTP id 39ls945496ios.91.gmail; Mon, 27 Oct 2014 04:14:53 -0700 (PDT) X-Received: by 10.51.16.65 with SMTP id fu1mr210272igd.10.1414408492955; Mon, 27 Oct 2014 04:14:52 -0700 (PDT) In-Reply-To: <7a0d78d9-e5dd-4786-b205-32cdf800b910@isocpp.org> X-Original-Sender: german.gomez@personifyinc.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:14247 Archived-At: ------=_Part_269_1323241347.1414408491790 Content-Type: text/plain; charset=UTF-8 On Monday, October 27, 2014 5:38:11 PM UTC+7, Giovanni Piero Deretta wrote: > > > Fast forward a few years later, in both benchmarks and real code which use > higher order functions (which in Rust is pretty much everything, including > 'for' loops), Rust has troubles matching the performance of c++ because of > of boxed closures. Now the developers are in the process of ripping them > out and replacing them with unboxed, uniquely typed closures (with pretty > much the same semantics of C++ lambdas, including explicit capture lists). > > > -- gpd > > [1] as far as I understand closures which are bound to an automatic scope > are not actually heap allocated, but they are still boxed, i.e. type erased > and behind a indirect call. > The more I hear, the more I favour n4244 function object approach. It is the ONLY way to have a guaranteed zero overhead abstraction. -- --- 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/. ------=_Part_269_1323241347.1414408491790 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Monday, October 27, 2014 5:38:11 PM UTC+7, Giov= anni Piero Deretta wrote:

Fast forward a few years later, in both benchmarks and= real code which use higher order functions (which in Rust is pretty much e= verything, including 'for' loops), Rust has troubles matching the performan= ce of c++ because of of boxed closures. Now the developers are in the proce= ss of ripping them out and replacing them with unboxed, uniquely typed clos= ures (with pretty much the same semantics of C++ lambdas, including explici= t capture lists).


-- gpd
 
[1] as far as I understand= closures which are bound to an automatic scope are not actually heap alloc= ated, but they are still boxed, i.e. type erased and behind a indirect call= ..

The more I hear, the more= I favour n4244 function object approach. It is the ONLY way to have a guar= anteed zero overhead abstraction.


&= nbsp;

--

---
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>.
------=_Part_269_1323241347.1414408491790-- .