220 4544 <519FB94F.7090703@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: N3558 :A standardized representation of Asynchronous operation Date: Fri, 24 May 2013 21:02:39 +0200 Lines: 116 Approved: news@gmane.org Message-ID: <519FB94F.7090703@wanadoo.fr> References: <519F9E48.7050700@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040602080006020708050402" X-Trace: ger.gmane.org 1369422165 21525 80.91.229.3 (24 May 2013 19:02:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 May 2013 19:02:45 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBU7S72GAKGQE7RARFII@isocpp.org Fri May 24 21:02:45 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-we0-f200.google.com ([74.125.82.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UfxGF-0000bW-P5 for gclcip-std-proposals@m.gmane.org; Fri, 24 May 2013 21:02:43 +0200 Original-Received: by mail-we0-f200.google.com with SMTP id u57sf3609750wes.3 for ; Fri, 24 May 2013 12:02:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=H7bB0mCcFHqnj9P9d/t2vzOU8Py+Ss2A7VjL3Xi1nlA=; b=ioZ9C68zw7Y7VJOi2MrMiBhyJp29SAgSTkBC4zbJ4XWwTLfOr/il35iFbXeq4U8+IM 99h70wluAtjcFTn/C3lwWyT5qJBq0/g8pAPpHGCMQPuUj54KsBt+ZKwGGFbuoWTD9yrB fxrA8rNlCZEMtr+uynmpJzLgXt286J3mupxSdhvJAo5ZiRMJ6KDbalI9LY35UtBZQbgy MWVczu84l2aOma8b5QdyRwqFnpBawzOJXcrQlNwrbGhefXB/gkFor3FhIzCTyfZk+qZu vbd93+VaMMKfAQWWIpCfET9OeuYkRiuH7bdzhkUe4vIs2hQdZxZVbu4jYif/wVM2qd8K TAqA== X-Received: by 10.180.85.5 with SMTP id d5mr226554wiz.0.1369422163472; Fri, 24 May 2013 12:02:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.183.237 with SMTP id ep13ls338659wic.2.gmail; Fri, 24 May 2013 12:02:42 -0700 (PDT) X-Received: by 10.180.105.231 with SMTP id gp7mr403517wib.23.1369422162502; Fri, 24 May 2013 12:02:42 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr. [80.12.242.133]) by mx.google.com with ESMTP id f6si413153wjy.24.2013.05.24.12.02.42 for ; Fri, 24 May 2013 12:02:42 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.133 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.133; Original-Received: from iMac-de-Vicente-Botet-Escriba.local ([2.13.6.91]) by mwinf5d21 with ME id fv2f1l00Q1xq0tN03v2gu3; Fri, 24 May 2013 21:02:42 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 In-Reply-To: X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.133 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mail=vicente.botet@wanadoo.fr 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:4544 Archived-At: This is a multi-part message in MIME format. --------------040602080006020708050402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Le 24/05/13 19:57, Xeo a =E9crit : > On Friday, May 24, 2013 7:07:20 PM UTC+2, Vicente J. Botet Escriba wrote: > > Hi, > > What is the rationale for when_all to return > future>> instead of future>? > > What is the rationale for when_any to return > future>> instead of future> ? > > > Likely, proper exception propagation for both. Oh, I see. No body has the need to get just: the vector of values when=20 no exception has been thrown or an exception when at least one exception=20 has been thrown? > For `when_any`, it's also important that you get access to *all*=20 > passed futures, not just the one that finished - this way, you don't=20 > have to keep the vector around yourself. > I understand what this solves. The drawback is that we need to to=20 iterate over the vector of futures when the when_any function could know=20 about the index of the future on the vector. Returning future>>> would provide=20 efficiency and safety. Vicente --=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/?hl=3Den. --------------040602080006020708050402 Content-Type: text/html; charset=ISO-8859-1
Le 24/05/13 19:57, Xeo a écrit :
On Friday, May 24, 2013 7:07:20 PM UTC+2, Vicente J. Botet Escriba wrote:
Hi,

What is the rationale for when_all to return future<vector<future<R>>> instead of  future<vector<R>>?
What is the rationale for when_any to return future<vector<future<R>>> instead of future<pair<size_t, R>> ?

Likely, proper exception propagation for both.
Oh, I see. No body has the need to get just: the vector of values when no exception has been thrown or an exception when at least one exception has been thrown?
For `when_any`, it's also important that you get access to *all* passed futures, not just the one that finished - this way, you don't have to keep the vector around yourself.

I understand what this solves. The drawback is that we need to to iterate over the vector of futures when the when_any function could know about the index of the future on the vector.
Returning future<pair<size_t, vector<future<R>>>> would provide efficiency and safety.

Vicente

--
 
---
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/?hl=en.
 
 
--------------040602080006020708050402-- .