220 14902 article Path: news.gmane.org!not-for-mail From: Farid Mehrabi Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Earlier creation of function return-value. Date: Mon, 8 Dec 2014 21:31:49 +0330 Lines: 298 Approved: news@gmane.org Message-ID: References: <3c0ee2e3-8706-44b0-a3d2-985e494dd8ac@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d04389251abba580509b83923 X-Trace: ger.gmane.org 1418061742 18914 80.91.229.3 (8 Dec 2014 18:02:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Dec 2014 18:02:22 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBC27JR6ERAOBBJOPS6SAKGQEDQTKKTA@isocpp.org Mon Dec 08 19:02:16 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ee0-f70.google.com ([74.125.83.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xy2dS-0002Zc-1A for gclcip-std-proposals@m.gmane.org; Mon, 08 Dec 2014 19:02:14 +0100 Original-Received: by mail-ee0-f70.google.com with SMTP id b57sf3103837eek.5 for ; Mon, 08 Dec 2014 10:02:13 -0800 (PST) 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:from:date :message-id:subject:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=oliiq616/L02d/kLw5o6Vau82zTWqLH9SelbV/71bNg=; b=kN2YhsfiRxfCWQGMH6H5k6yHKaWwkhR6rIa4IcAfhqBBi9r8n9tX4OfLWAIIORVJMX ADvb9RUiVkNiGNNzozKAJBVpRLwv1YfOUchbhMtDcFWavydBe9JZNV/uuTYk2nGi7LpD 83zZDQHJROYzndHn++wTS00OZyylIFK6iPwNbrNDn0rvqfxoKHqvkppR1TDS5erk5tGh rEoTRq7jWqoBz63SGCK+EqMm8sVPu5dn5O3mE3I56Gcib3LOOA/ezANRighkEM5QHS7M q0va/8tdICFoeoZhjsE+7Ym6qKmkcKWPilU16DUX5we3vyVtREjdAEF8nPCrn3220Es2 N/Mg== X-Gm-Message-State: ALoCoQnjLuOHJyEYr/Uc5ObxoZBLuGBAZ8a1iwP4m/3cysNonOeW8TbDcT8uIMr0q9lSuH02hiRl X-Received: by 10.180.24.35 with SMTP id r3mr3675309wif.0.1418061733666; Mon, 08 Dec 2014 10:02:13 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.14.99 with SMTP id o3ls632255wic.9.canary; Mon, 08 Dec 2014 10:02:12 -0800 (PST) X-Received: by 10.194.8.34 with SMTP id o2mr30853671wja.129.1418061732143; Mon, 08 Dec 2014 10:02:12 -0800 (PST) Original-Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com. [2a00:1450:400c:c05::235]) by mx.google.com with ESMTPS id za2si62690487wjc.44.2014.12.08.10.02.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Dec 2014 10:02:12 -0800 (PST) Received-SPF: pass (google.com: domain of farid.mehrabi@gmail.com designates 2a00:1450:400c:c05::235 as permitted sender) client-ip=2a00:1450:400c:c05::235; Original-Received: by mail-wi0-f181.google.com with SMTP id r20so5601023wiv.2 for ; Mon, 08 Dec 2014 10:02:11 -0800 (PST) X-Received: by 10.180.90.147 with SMTP id bw19mr25440480wib.69.1418061729739; Mon, 08 Dec 2014 10:02:09 -0800 (PST) Original-Received: by 10.217.59.131 with HTTP; Mon, 8 Dec 2014 10:01:49 -0800 (PST) In-Reply-To: <3c0ee2e3-8706-44b0-a3d2-985e494dd8ac@isocpp.org> X-Original-Sender: farid.mehrabi@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of farid.mehrabi@gmail.com designates 2a00:1450:400c:c05::235 as permitted sender) smtp.mail=farid.mehrabi@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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:14902 Archived-At: --f46d04389251abba580509b83923 Content-Type: text/plain; charset=UTF-8 Sorry fo overmuch frankness, but regarding your other posts, IMHO u better collect more info about "rvalue ref", "perfect forwarding", "std::move", "copy ellision", "RVO" & "NRVO". I don`t think there exists any practical motivation for this kind of syntax proposals today. 10 years ago they might. cheers, FM. 2014-12-08 0:52 GMT+03:30 sasho648 : > I thought it would be a good idea to implement a language solution of the > return by value additional temporary creation which is optimized by > most-compilers but - you know it's better to make their life easier and > also fix the problem in those where the optimization isn't done at all. > What I mean is this: > > struct SomeData { int a, int b, int c }; > > > SomeData FuncRetSomeData() > > { > SomeData tmp; //creation of additional unneeded temporary > > > > //store some data in 'tmp' > > > > return tmp; //now second return object is created in the calling > stack with data copied from 'tmp' > > } > > > Most compilers will optimize this code and never create the local 'tmp' > but instead store the data supposed to be held in it, directly in the > return temporary. I suggest creating an old-code compatible new syntax for > allowing similar behavior to be done explicitly by using '(return)' as an > alias to the return value temporary which will be created at function > beginning. Also an initialization syntax for the '(return)' will be > supported like when initializing a class members (if it was named > 'return'). This new syntax will be supported only when used, otherwise > 'return' statements will be the ones which will create the return value. So > the function "FuncRetSomeData" can be now written optimized like: > > struct SomeData { int a, int b, int c }; > > > SomeData FuncRetSomeData() > > { > > //store some data in '(return)', like > > > (return).a = 0; > > > (return).b = 3; //etc. > > > return; //only return statement with no value will be supported to > exit the function > > } > > > '(return)' variable could be also initialized like class members. Example: > > struct SomeData { int a, int b, int c }; > > > SomeData FuncRetSomeData(int a, int b, int c) : return { a, b, c } {} > > > Old code will be supported too: > > SomeData &FuncReturningRef() > { > //Do Something and never use '(return)' > > > > return ref; //if 'ref' is from type 'SomeData', the return value will > be created now and the function will return (note if the '(return)' was > used above - this statement would be illegal) > > } > > -- > > --- > 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/. > -- how am I supposed to end the twisted road of your hair in the dark night?? unless the candle of your face does turn a lamp up on my way!!! -- --- 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/. --f46d04389251abba580509b83923 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry fo overmuch frankness, but regardin= g your other posts, IMHO u better collect more info about "rvalue ref&= quot;, "perfect forwarding", "std::move", "copy el= lision", "RVO" & "NRVO". I don`t think there e= xists any practical motivation for this kind of syntax proposals today. 10 = years ago they might.

chee= rs,
FM.

2014-12-08 0:52 GMT+03:30 sasho648= <sasho648@mail.bg>:
I thought it would be a good idea to implement a language solu= tion of the return by value additional temporary creation which is optimize= d by most-compilers but - you know it's better to make their life easie= r and also fix the problem in those where the optimization isn't done a= t all. What I mean is this:

= struct = SomeData { int a, int b, int c };


SomeData FuncRetSomeData()

{
=C2=A0 =C2=A0 SomeData tmp; //creation of additional unneeded temporary



=C2=A0 =C2=A0 /= /store some data in 'tmp'

=

=C2=A0 =C2=A0 return tmp; //now second return o= bject is created in the calling stack with data copied from 'tmp'

}=


Most compilers= will optimize this code and never create the local 'tmp' but inste= ad store the data supposed to be held in it, directly in the return tempora= ry. I suggest creating an old-code compatible new syntax for allowing simil= ar behavior to be done explicitly by using '(return)' as an alias t= o the return value temporary which will be created at function beginning. A= lso an initialization syntax for the '(return)' will be supported l= ike when initializing a class members (if it was named 'return').= =C2=A0This new syntax will be supported only when used, otherwise 'retu= rn' statements will be the ones which will create the return value. So = the function "FuncRetSomeData" can be no= w written optimized like:

struct<= span style=3D"color:#000"> SomeData { int a, int b, int c };


SomeData FuncRetSomeData<= span style=3D"color:#660">()

{

=C2= =A0 =C2=A0 //store some data in '(ret= urn)', like


=C2=A0 =C2=A0 = (return= ).a =3D 0;


=C2=A0 =C2=A0 (return).b =3D 3; //etc.

=C2=A0 =C2=A0 return; //only return statement with no value will be supported to= exit the function

}


'(retu= rn)' variable could be also=C2=A0initialized like class members.= Example:

struct SomeData { int a, i= nt b, int c };=


So= meData = FuncRetSomeData(int a, int b= , int c) : return { a, b, c } {}


Old code will be supporte= d too:

SomeData &FuncReturningRef()
{
=C2=A0= =C2=A0 //Do Something and never use '= ;(return)'



=C2=A0 =C2= =A0 return ref= ; //if = 'ref' is from type 'SomeData', the return value will be cre= ated now and the function will return (note if the '(return)' was u= sed above - this statement would be illegal)

}

--

---
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-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/gro= up/std-proposals/.



--
how am I supposed to end = the twisted road of=C2=A0 your hair in the dark night??
unless the candl= e of your face does turn a lamp up on my way!!!

--

---
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>.
--f46d04389251abba580509b83923-- .