From -3755427040545684344 X-Google-Thread: f78e5,bd52daa8ac2e51f1 X-Google-Thread: 109fba,bd52daa8ac2e51f1 X-Google-Attributes: gidf78e5,gid109fba,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news2.google.com!news3.google.com!out02b.usenetserver.com!news.usenetserver.com!in02.usenetserver.com!news.usenetserver.com!pd7cy1no!shaw.ca!news.alt.net!comp-std-cpp-robomod!not-for-mail From: =?UTF-8?B?RXJpayBXaWtzdHLDtm0=?= Newsgroups: comp.std.c++,comp.lang.c++ Subject: Re: pre return optimization Date: Mon, 15 Oct 2007 11:35:18 CST Organization: Telia Internet Lines: 143 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <1191919832.635392.256930@d55g2000hsg.googlegroups.com> <1192343829.469097.231500@i13g2000prf.googlegroups.com> <1192366892.063805.202140@k35g2000prh.googlegroups.com> <1192434165.863496.171650@q3g2000prf.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: newsb.telia.net 1192463207 81.233.131.203 (Mon, 15 Oct 2007 17:46:47 CEST) X-Complaints-To: abuse@telia.com NNTP-Posting-Date: Mon, 15 Oct 2007 17:46:47 CEST Return-Path: X-Authentication-Warning: mulga.csse.unimelb.edu.au: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Original-To: std-c++@mailman.ucar.edu Delivered-To: std-c++@mailman.ucar.edu X-SMTP-Auth: no User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) X-MIME-Autoconverted: from 8bit to quoted-printable by newsb.telia.net id RAA09646 X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au X-MIME-Autoconverted: from quoted-printable to 8bit by mulga.csse.unimelb.edu.au id l9FFlOUH003553 X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au Xref: g2news2.google.com comp.std.c++:843 comp.lang.c++:22728 ===================================== MODERATOR'S COMMENT: Please trim unnecessary material when replying. ===================================== END OF MODERATOR'S COMMENT On 2007-10-15 17:52, terminator(jam) wrote: > On Oct 14, 10:00 pm, Erik-wikst...@telia.com (Erik Wikström) wrote: >> On 2007-10-14 21:19, terminator wrote: >> >> >> >> >> >> > On Oct 14, 11:08 am, Greg Herlihy wrote: >> >> On Oct 9, 8:56 am, "terminator(jam)" wrote: >> >> >> > consider: >> >> >> > struct memory_pig{//a really large type: >> >> >> > memory_pig(){ >> >> > std::cout<<"mem pig default\n"; >> >> > //etc... >> >> > }; >> >> >> > memory_pig(memory_pig const&){ >> >> > std::cout<<"mem pig copy\n"; >> >> > //etc... >> >> > }; >> >> >> > ~memory_pig(){ >> >> > std::cout<<"mem pig finish\n"; >> >> > //etc... >> >> > }; >> >> >> > //etc... >> >> >> > };///struct memory_pig >> >> >> > memory_pig foo(){ >> >> > memory_pig result; >> >> > result=something; >> >> > //etc... >> >> > result=something_else; >> >> > return result; >> >> >> > }; >> >> >> > any time 'foo' is called the output will contain the following >> >> > sequence: >> >> >> > mem pig default >> >> > mem pig copy >> >> > mem pig finish >> >> >> > the last line of output may repeat based on how the result is >> >> > stored(rvo) or not. >> >> > So,two objects of a large type will be constructed and at least one is >> >> > destructed on every call to 'foo' >> >> >> The C++ Standard already allows the "(Named) Return Value >> >> Optimization" (NRVO or RVO for short). The optimization allows (under >> >> certain conditions) the compiler to construct the result of a function >> >> call "in place" - that is, directly in the object initialized with the >> >> function call result. >> >> >> So, to take advantage of this optimization, a program should use the >> >> result of a function call to initialize an object, instead of >> >> assigning the function result to an existing object. >> >> >> For example: >> >> >> #include >> >> >> using std::cout; >> >> >> struct memory_pig >> >> { // a really large type: >> >> memory_pig() >> >> { >> >> cout << "mem pig default\n"; >> >> } >> >> memory_pig(memory_pig const&) >> >> { >> >> cout << "mem pig copy\n"; >> >> } >> >> ~memory_pig() >> >> { >> >> cout << "mem pig finish\n"; >> >> } >> >> }; >> >> >> memory_pig foo() >> >> { >> >> memory_pig result; >> >> // ... >> >> return result; >> >> } >> >> >> int main() >> >> { >> >> memory_pig m1 = foo(); >> >> memory_pig m2 = foo(); >> >> memory_pig m3 = foo(); >> >> } >> >> >> I compiled the above program twice, once with and once without NRVO. >> >> The output of both programs is shown in the two columns below. As this >> >> comparison shows, NRVO can be a particular effective optimization - >> >> even for a small C++ program like the one used in this example. >> >> > I knew about RVO but not NRVO(that is what I am talking about).Is NRVO >> > standard behavoir or unspecified? >> > At least my compiler does not perform the NRVO. >> >> The standard allows this optimisation, but it does not require it (see >> section 12.8 paragraph 15). I think that most newer compilers support >> it, but you might have to turn up the optimisation level a bit. >> >> One important thing to remember is that when NRVO is in use the >> destructor will not be called for the local object, nor will the copy- >> constructor for the non-local object (m1 to m3 in the code above) be >> called. Thus you should not depend on any side effects that the copy- >> constructor or destructor might have. >> > > prior to return and after return are two different case to me:I mean > before return even move should be disabled ,while after the return > either of move/copy must perform . Sorry, but you lost me there, what move? Of what to where? -- Erik Wikström --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]