220 35831 article Path: news.gmane.org!.POSTED!not-for-mail From: odomobo@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Output parameters Date: Sat, 9 Dec 2017 13:38:10 -0800 (PST) Lines: 320 Approved: news@gmane.org Message-ID: References: <1c1bb50b-2d59-4247-a158-158065fb1a9a@isocpp.org> <0c471d5c-b9b2-40f9-a2bf-908edbb1f272@isocpp.org> <17e3b13c-eb1b-fc2c-590e-3d394f164f9a@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2166_1464354565.1512855490573" X-Trace: blaine.gmane.org 1512855490 27948 195.159.176.226 (9 Dec 2017 21:38:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 9 Dec 2017 21:38:10 +0000 (UTC) Cc: jmckesson@gmail.com, odomobo@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCIJNUOTWIOBBQ5PWHIQKGQEFTNMDBQ@isocpp.org Sat Dec 09 22:38:06 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eNmov-00078v-MX for gclcip-std-proposals@m.gmane.org; Sat, 09 Dec 2017 22:38:05 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id p143sf7630796vkf.1 for ; Sat, 09 Dec 2017 13:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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; bh=rrQvNf3yQg/xQMvYhSIUZ5C6+5lVQ6AgXMA0NYcDV6E=; b=iq0dCeeT5xyjxDOurGYxcHxoLC165nSfPD/uCCunSMR+pheS0RcNwUXtMjYTYwJkLG 0/ZsIhYZKquR+EWBZWjGRIPcIBrdaulk8M0RN7eohkGVP0gPTlo8I+C/l0myx2ftc7en tOnz61l90zp7ToDgkrBMI/kVMXt8NioCGw/dpq1D+MFwIL0NfcJZG+PdHawfCb4cyFKe TO5lHYwCqGL59pf70EG0bQNnPtf6fneD7QPsTqX42TWYnZjIjMnqAiKT7xis1kf9uLxx KApy5u7/tlcH0CH9+dzqPKfiB5koUtSBaa6KRc0blGeGB5vjx6PTP7wcfWRcpd6gq5HN +qPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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; bh=rrQvNf3yQg/xQMvYhSIUZ5C6+5lVQ6AgXMA0NYcDV6E=; b=A6AvlCh3cGBMTRFSOq1IaoPwU2UEd3tYzpq6Ziq/mQFyGAp74Zsr8yVcHOI0B6G/ay ELvUt3iivQ5sr5wUeYM/xB7XZ52NUZRWwt+5HVnA00HnxQJcwc944mCcT81bjlPGhzef 9IzHTop7H6gWm7AEU3Og0G/L753RbWOqahFHkUXEUGA8ERtoCP4Hr3TLzyqkIOjxXFum JxpL8x7D0N/GBFZTRZCPHGW+/NQGg4r2QtHho4ReMGKeuD3ufP4sVdaF2g6UGmFTyY9y sdkrzYxHeZSRRFnRZ0cytWk9t9UCtw+J9opy1QKqkHNng5UKnyQo+rsrd1kVlniJNPgp WO0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version: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=rrQvNf3yQg/xQMvYhSIUZ5C6+5lVQ6AgXMA0NYcDV6E=; b=iLN63t4Zw1B+F53+UKD/72gqjF6P+dOMyQq2hJ16X3aCBnCb4p811R8WIN026Z4ozZ IEOW2El/Opwo5rXA/WdsJ6i0oAiZIqDaAjQqkEjB7WEPpEfqTXVAQkL152Wz+zjL235X gq5XRJvUMZinOErKkqH+Bx61f125Wtb0b9TXILZbqLPxKzv46f/2xQYqJ/J/85gNzLOK e4HRmMZ/TO9uWTkU7I5+Nz7kl0cv7x3dYs152OKf7Ci2Srh1r/U76eptpVyO5XgGvrT6 H9B5r3Yw66LdvbSLC6xFAnFJgu8cN3QutEwMX3QVo5obSDc9ZWbL1FZFPY3OCQKzlo6I 5AMg== X-Gm-Message-State: AKGB3mKRtSwGma0q0nzjt4+30Ne9IIA54s/oC1h21pMTWiAG+XHfHV+m szUmMA2QxxxAqmQeA3qWnhhkgQ== X-Google-Smtp-Source: AGs4zMYtiRJpYja8Ii7KW7bqla4MzTYIWXPmfk+nKb5wOoYeIHPAlzI6Jgr+ffEXsj86Orpu9WWcCA== X-Received: by 10.31.189.4 with SMTP id n4mr3895630vkf.70.1512855492683; Sat, 09 Dec 2017 13:38:12 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.86.25 with SMTP id y25ls1731877uaa.10.gmail; Sat, 09 Dec 2017 13:38:11 -0800 (PST) X-Received: by 10.31.161.87 with SMTP id k84mr1653935vke.10.1512855491099; Sat, 09 Dec 2017 13:38:11 -0800 (PST) In-Reply-To: <17e3b13c-eb1b-fc2c-590e-3d394f164f9a@wanadoo.fr> X-Original-Sender: odomobo@gmail.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:35831 Archived-At: ------=_Part_2166_1464354565.1512855490573 Content-Type: multipart/alternative; boundary="----=_Part_2167_883784152.1512855490574" ------=_Part_2167_883784152.1512855490574 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I can think of one case where output parameters are arguably a better=20 choice than returning a struct/tuple: when you're returning multiple values= =20 of the same type, which aren't inherently related to each other. If they're different types, you can use a tuple -- the type parameters will= =20 give you info about what's being returned. If the data is inherently=20 related, then it arguably deserves its own type. Consider the following example, though: Case #1 tuple calculate_averages(vector values); Case #2 struct averages_out { int mean; int median; int mode; }; averages_out calculate_averages(vector values); Case #3 void calculate_averages(vector values, int& mean, int& median, int&=20 mode); Case #4 void calculate_averages(vector values, output_parameter mean,=20 output_parameter median, output_parameter mode); Case #1 would be the clear winner, if tuples had named parameters somehow.= =20 As it stands, I'd be hesitant to go this route even if I documented the=20 return type thoroughly. For case #2, Since the three results aren't really related, it feels clumsy= =20 to have a separate struct which is used only in one function. Case #3 seems pretty clear that they are supposed to be output parameters,= =20 and whose initial values are not for input. However, this isn't explicit. Case #4 seems the least bad to me. Output parameters aren't great, but the= =20 fact that the function definition describe its usage is a big win, IMO. Note, I think the recommendations given here are good, but I don't think=20 they apply to the above=20 example: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-out= -multi Also note, I thought about it, and I think Jake is right that a non-const= =20 reference is clearly an input/output parameter. A separate type for this=20 doesn't seem useful to me. On Saturday, December 9, 2017 at 2:14:10 PM UTC-6, Vicente J. Botet Escriba= =20 wrote: > > Le 09/12/2017 =C3=A0 20:36, Nicol Bolas a =C3=A9crit : > > On Saturday, December 9, 2017 at 2:22:47 PM UTC-5, odo...@gmail.com=20 > wrote:=20 >> >> It would be useful for c++ to have an idiomatic way to express strictly= =20 >> output parameters. >> > > Or we can just return multiple values from the function by sticking them= =20 > in a struct. To put it another way, functions should not have "strictly= =20 > output parameters". I can understand taking input/output parameters (like= a=20 > `vector` that you add data to), but there's no reason to have "*strictly*= =20 > output parameters" in C++. > > I agree. We don't have a way to ensure strictly output parameters in C++.= =20 > Or can we? > > I would be great to have some motivating examples where it could be bette= r=20 > to have out parameters than return then on the result type. > > As Jonathan wrote in his blog, an out factory seems a good thing to state= =20 > clearly at the call site the parameter is out. I believe this is could be= =20 > the more motivating advantage of such a class. > > If all the useful cases of out parameters require that the instance is at= =20 > least constructed, maybe, having an in_out parameter could be useful. > > Just my 2cts > Vicente > --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/d750d914-94c4-4f17-b20d-bc8ca51f58ea%40isocpp.or= g. ------=_Part_2167_883784152.1512855490574 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can think of one case where output parameters are arguab= ly a better choice than returning a struct/tuple: when you're returning= multiple values of the same type, which aren't inherently related to e= ach other.

If they're different types, you can use a= tuple -- the type parameters will give you info about what's being ret= urned. If the data is inherently related, then it arguably deserves its own= type.

Consider the following example, though:

Case #1

tuple<int, int= , <= span style=3D"color: #008;" class=3D"styled-by-prettify">int> calculate_averages(vector<int> values);

Case = #2

struct= averages_out
{=C2=A0in= t mean;
=C2=A0int median;
=C2=A0int mode;
};

averages_out calculate_averages(vector<int> values);

Case #3=

void calculate_averages(vector<int> values, int& mean, int& median, int&= amp; mode<= /span>);

Case = #4

void calculate_averages(vector<int> values, outp= ut_parameter<int> mean,<= /span> output_par= ameter<= int> me= dian, output_paramet= er<int&= gt; mode);

Case #1 would be the clear winner, if tuples= had named parameters somehow. As it stands, I'd be hesitant to go this= route even if I documented the return type thoroughly.

For case #2, Since the three results aren't really related, it fe= els clumsy to have a separate struct which is used only in one function.

Case #3 seems pretty clear that they are supposed to= be output parameters, and whose initial values are not for input. However,= this isn't explicit.

Case #4 seems the least = bad to me. Output parameters aren't great, but the fact that the functi= on definition describe its usage is a big win, IMO.


Note, I think the recommendations given here are good, but= I don't think they apply to the above example:=C2=A0http://isocpp.gith= ub.io/CppCoreGuidelines/CppCoreGuidelines#Rf-out-multi

=
Also note, I thought about it, and I think Jake is right that a non-co= nst reference is clearly an input/output parameter. A separate type for thi= s doesn't seem useful to me.

On Saturday, December 9, 201= 7 at 2:14:10 PM UTC-6, Vicente J. Botet Escriba wrote:
=20 =20 =20
Le 09/12/2017 =C3=A0 20:36, Nicol Bolas a =C3=A9crit=C2=A0:
On Saturday, December 9, 2017 at 2:22:47 PM UTC-5, odo...@gmail.com wrote:
It would be useful for c++ to have an idiomatic way to express strictly output parameters.

Or we can just return multiple values from the function by sticking them in a struct. To put it another way, functions should not have "strictly output parameters". I can und= erstand taking input/output parameters (like a `vector` that you add data to), but there's no reason to have "strictly output parameters" in C++.

I agree. We don't have a way to ensure strictly output parameters i= n C++. Or can we?

I would be great to have some motivating examples where it could be better to have out parameters than return then on the result type.

As Jonathan wrote in his blog, an out factory seems a good thing to state clearly at the call site the parameter is out. I believe this is could be the more motivating advantage of such a class.

If all the useful cases of out parameters require that the instance is at least constructed, maybe, having an in_out parameter could be useful.

Just my 2cts
Vicente

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/d750d914-94c4-4f17-b20d-bc8ca51f58ea= %40isocpp.org.
------=_Part_2167_883784152.1512855490574-- ------=_Part_2166_1464354565.1512855490573-- .