220 21719 <894616d6-9609-4038-b2bc-d2c62df21e0f@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: is await an extension of the do-notation? (was Re: Re: Resumable expressions p0114r0 vs async/await P0057R0) Date: Tue, 13 Oct 2015 15:22:39 -0700 (PDT) Lines: 92 Approved: news@gmane.org Message-ID: <894616d6-9609-4038-b2bc-d2c62df21e0f@isocpp.org> References: <639f0012-8cb4-4db3-82a6-8d042a3497f9@isocpp.org> <401aa118-ed0b-4c7b-92cf-3fbd706eff9d@isocpp.org> <1d15dbc4-e0c1-4df1-86db-014e11f14d26@isocpp.org> <56114953.4030701@wanadoo.fr> <561B403D.4030403@gmail.com> <561C07D1.3080304@gmail.com> <561C213F.1060009@gmail.com> <561C3875.2050701@gmail.com> <86924069-44d0-447f-bf8a-a42e46579832@isocpp.org> <561D79A7.8080007@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3781_961209670.1444774959910" X-Trace: ger.gmane.org 1444774971 14790 80.91.229.3 (13 Oct 2015 22:22:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Oct 2015 22:22:51 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBMEI62YAKGQEGN7NASI@isocpp.org Wed Oct 14 00:22:51 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zm7xy-0008Dv-Nw for gclcip-std-proposals@m.gmane.org; Wed, 14 Oct 2015 00:22:42 +0200 Original-Received: by oixx6 with SMTP id x6sf6270771oix.3 for ; Tue, 13 Oct 2015 15:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type: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=NQ739r9+qjBBaNeFmK2+QqRqO8AlcqAn5PqVqd/JqQk=; b=bjEBQwYDNHm1OwbPuio+QvRJSNdrIFbMkVhUgAYUTsqnCxmDu1++R7iKMMUt3nmejz NdEcoG9B6Hr9+pPijgOD2y3bSV9hTpU6Y55r+wYl02iPsTbCVrPoLiZ2BLmYzEjQe7qb nj9GeYwuCA8SwiP2T3I56DPW8z9e2aoxJBps2bBF+gyW4+9XIozd2GQVZSkkACfVU3Na TjosUSg7igclGMO0jPNkQH4EC6fn6vKOub+sLsoevfFGaCjdZZaZgLm47dJaKq8DGh/B edHRXaIMHmqR6Y3Cvc553Z89w/gubHZk+zQWzmJlMhwevQDgH7XZGodca5qDCBvIafvh p3LQ== 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:content-type: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=NQ739r9+qjBBaNeFmK2+QqRqO8AlcqAn5PqVqd/JqQk=; b=jaULL1w00o9pqUSoqiVK7BooAHd7guzXuIH7LxP0IGFOtuVxU0uA1VDo/b5+TS8DM2 rM6MexGXZKTjMHhto0K0wPpEStwV+GHV8G92CWuhpWYjzkOSV9ox/7BU9V456ncRiEnb uJphy3z9EaDc0agw375D9EftUpnjikylOigwaXw5yAwBha19PpyYn/4pah5KllLo+RSo mFdnvLEfmgK5W/hUgXhui6taLWp4OJENYA4W9+F3dZnq1YC0iKU5sQQm7tyvchy3aOq6 EznNgAhaUK/8wPFe5hJ0oc7thjHndZiEtFw2RVy94RuS7dFKqjS6hucRvCKHEZeraqgy 0EPA== X-Gm-Message-State: ALoCoQn5CYm3tJq1uKzlmCE+TYXG5ZS/4i1tvfXzVwL5A2kyrBPz+0xh8zGR6GK7krEVS2DM10Tx X-Received: by 10.182.126.228 with SMTP id nb4mr30465957obb.19.1444774961169; Tue, 13 Oct 2015 15:22:41 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.138.156 with SMTP id c28ls166788ioj.109.gmail; Tue, 13 Oct 2015 15:22:40 -0700 (PDT) X-Received: by 10.50.17.41 with SMTP id l9mr9058igd.2.1444774960562; Tue, 13 Oct 2015 15:22:40 -0700 (PDT) In-Reply-To: <561D79A7.8080007@gmail.com> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:21719 Archived-At: ------=_Part_3781_961209670.1444774959910 Content-Type: multipart/alternative; boundary="----=_Part_3782_700194794.1444774959910" ------=_Part_3782_700194794.1444774959910 Content-Type: text/plain; charset=UTF-8 On Tuesday, October 13, 2015 at 5:37:50 PM UTC-4, Evgeny Panasyuk wrote: > > 13.10.2015 2:03, Gor Nishanov: > > > > My main concern about P0057R0 is type-erasure - it is far from being > > zero-overhead. > > > > > > I have had an outstanding challenge for a year already to anyone who > > thinks that way to come up with a real world problem, reduce it to > > managable size (say async_tcp_reader) write it up it both ways using > > P0057 and whatever you consider zero overhead and evaluate on three > > criteria: > > Example of real world problem is generator/yield. > An extra allocation here results in significant overhead. Even if some > kind of "small object optimization" scheme is used - it is still not > zero overhead. > Except that he's already proven (in this thread no less) that a good optimizer can elide the allocation. If the compiler can reasonably *make* it zero overhead, then it *is* zero overhead. -- --- 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_3782_700194794.1444774959910 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, October 13, 2015 at 5:37:50 PM UTC-4, Evgeny P= anasyuk wrote:
13.10.2015 2:03,= Gor Nishanov:
>
> =C2=A0 =C2=A0 My main concern about P0057R0 is type-erasure - it i= s far from being
> =C2=A0 =C2=A0 zero-overhead.
>
>
> I have had an outstanding challenge for a year already to anyone w= ho
> thinks that way to come up with a real world problem, reduce it to
> managable size (say async_tcp_reader) write it up it both ways usi= ng
> P0057 and whatever you consider zero overhead and evaluate on thre= e
> criteria:

Example of real world problem is generator/yield.
An extra allocation here results in significant overhead. Even if some= =20
kind of "small object optimization" scheme is used - it is st= ill not=20
zero overhead.

Except that he's already proven (in this thre= ad no less) that a good optimizer can elide the allocation. If the compiler= can reasonably make it zero overhead, then it is zero overhe= ad.

--

---
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_3782_700194794.1444774959910-- ------=_Part_3781_961209670.1444774959910-- .