220 21837 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Germ=C3=A1n_Diago?= 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: Sat, 17 Oct 2015 15:52:10 +0700 Lines: 84 Approved: news@gmane.org Message-ID: 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> <894616d6-9609-4038-b2bc-d2c62df21e0f@isocpp.org> <99bdb3ae-9214-4440-8572-4c47a61eda46@isocpp.org> <58628096-14ae-42b2-89d3-c0bd2183bbc0@isocpp.org> <561DC957.8080603@gmail.com> <2e09660f-d688-474a-8811-85fb041f68b8@isocpp.org> <8b78abb4-16b6-4b65-8513-6e2c17317647@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114dbd1a1f5deb052249071c X-Trace: ger.gmane.org 1445071937 6997 80.91.229.3 (17 Oct 2015 08:52:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 08:52:17 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDC2VXM4YYDRBO4YRCYQKGQENS7JNRA@isocpp.org Sat Oct 17 10:52:17 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZnNDr-0004Wj-DZ for gclcip-std-proposals@m.gmane.org; Sat, 17 Oct 2015 10:52:15 +0200 Original-Received: by ioii196 with SMTP id i196sf126460483ioi.3 for ; Sat, 17 Oct 2015 01:52:14 -0700 (PDT) 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:date :message-id:subject:from:to:content-type: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=oMWO5JAa59qCih8od5/d/t3WCVtWzYVTl0dyKM1KVLc=; b=dWOBLwalZkxOqxQbRGT80hfBZY83uUwkrYrju5tqn7aroXYX6SF2pO9BhorgzO4PcB t53G0DQDLZ0bdNcNho396+7nKUvaeiv9xQR+gjpH16EGbsbclU4Kxu/AF4TX+fZFiJz7 K0adyHA9q91cbSx4FJv8o2PvGKnvlKWtGEqDmc+eWMppwEYOCcRd689C1cnPNFfcHdnb BAJ/bSugUG0Pa0C20yDo4iIu9vJffXg3zhsv05i+S0ggsrNKv5pSxhEyQ0HcAoMGnlkR Nprkq2j38HQluSWEquuo3GPP5I2Y282i+k59oveilB0jhrtVeeIqNFHQEG3kpwWhSon/ 8ueA== X-Gm-Message-State: ALoCoQmEQMHAnEqW2WF8ALGhR1jVaKayf7LSQufvCEnobLC4EHbcKa2pDwP9xdxN2RFrdZjBc6Cp X-Received: by 10.50.79.234 with SMTP id m10mr7985428igx.5.1445071934011; Sat, 17 Oct 2015 01:52:14 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.109.100 with SMTP id k91ls1689448qgf.38.gmail; Sat, 17 Oct 2015 01:52:11 -0700 (PDT) X-Received: by 10.129.107.84 with SMTP id g81mr12883476ywc.288.1445071931281; Sat, 17 Oct 2015 01:52:11 -0700 (PDT) Original-Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com. [2607:f8b0:4002:c07::22c]) by mx.google.com with ESMTPS id r10si9794230ywr.371.2015.10.17.01.52.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Oct 2015 01:52:11 -0700 (PDT) Received-SPF: pass (google.com: domain of germandiago@gmail.com designates 2607:f8b0:4002:c07::22c as permitted sender) client-ip=2607:f8b0:4002:c07::22c; Original-Received: by yknn9 with SMTP id n9so54094514ykn.0 for ; Sat, 17 Oct 2015 01:52:11 -0700 (PDT) X-Received: by 10.129.109.197 with SMTP id i188mr12993550ywc.179.1445071931003; Sat, 17 Oct 2015 01:52:11 -0700 (PDT) Original-Received: by 10.37.56.206 with HTTP; Sat, 17 Oct 2015 01:52:10 -0700 (PDT) Original-Received: by 10.37.56.206 with HTTP; Sat, 17 Oct 2015 01:52:10 -0700 (PDT) In-Reply-To: <8b78abb4-16b6-4b65-8513-6e2c17317647@isocpp.org> X-Original-Sender: germandiago@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of germandiago@gmail.com designates 2607:f8b0:4002:c07::22c as permitted sender) smtp.mailfrom=germandiago@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-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:21837 Archived-At: --001a114dbd1a1f5deb052249071c Content-Type: text/plain; charset=UTF-8 > Passive-aggressiveness does not prove your point. For example, you have yet to prove that the "burden on optimizers" is "high" by some definition of that word. It's merely "non-zero". I think there is no need to, well, insult anyone for having a different view insinuating he is being too agressive. I think it is good to have discussion. That said, one of the principles of C++ is the zero-overhead principle. Not the "little overhead" principle. Why? Because c++ is for max. performance, and if u do something suboptimal by design, people are going to invent another solution. Herb Sutter defined this zero overhead as nothing between c++ that is not assembly. I agrew with that. P The only library that does have a design I dnt like, and u mentioned before, is iostreams. No lib ever followed iostream path since then. We have templated non-inheritance components that are generic mostly. Erasure does have costs and there are alternatives. Chris paper mentions about the inherent erasure overhead. Why it is mentioned if it is not that important... Erasure cannot be controlled in all scenarios once it is embedded into the design. That is something that is simply true. So the question here should be if we can have a design with inherently minimal overhead, not if you sympathize with one solution or another only. -- --- 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/. --001a114dbd1a1f5deb052249071c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


> Passive-aggressiveness does not prove your point. For example, you hav= e yet to prove that the "burden on optimizers" is "high"= ; by some definition of that word. It's merely "non-zero".
I think there is no need to, well, insult anyone for having a different vie= w insinuating he is being too agressive. I think it is good to have discuss= ion.

That said, one of the principles of C++ is the zero-overhead= principle. Not the "little overhead" principle. Why? Because c++= is for max. performance, and if u do something suboptimal by design, peopl= e are going to invent another solution.

Herb Sutter defined this zero overhead as nothing between c= ++ that is not assembly. I agrew with that. P
The only library that does have a design I dnt like, and u mentioned before= , is iostreams. No lib ever followed iostream path since then. We have temp= lated non-inheritance components that are generic mostly.

Erasure does have costs and there are alternatives. Chris pa= per mentions about the inherent erasure overhead. Why it is mentioned if it= is not that important... Erasure cannot be controlled in all scenarios onc= e it is embedded into the design. That is something that is simply true. So= the question here should be if we can have a design with inherently minima= l overhead, not if you sympathize with one solution or another only.

--

---
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>.
--001a114dbd1a1f5deb052249071c-- .