From 6352337668179662852 X-Google-Thread: f78e5,bd52daa8ac2e51f1 X-Google-Thread: 109fba,bd52daa8ac2e51f1 X-Google-Attributes: gidf78e5,gid109fba,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!newsfeed.stanford.edu!news.kjsl.com!news-xfer.nntp.sonic.net!news.alt.net!comp-std-cpp-robomod!not-for-mail From: int19h@gmail.com Newsgroups: comp.std.c++,comp.lang.c++ Subject: Re: pre return optimization Date: Mon, 15 Oct 2007 23:44:30 CST Organization: http://groups.google.com Lines: 80 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <1192280210.586133.256780@e34g2000pro.googlegroups.com> References: <1191919832.635392.256930@d55g2000hsg.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1192280211 5255 127.0.0.1 (13 Oct 2007 12:56:51 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 13 Oct 2007 12:56:51 +0000 (UTC) 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: G2/1.0 X-HTTP-UserAgent: Opera/9.20 (Windows NT 5.2; U; en),gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: e34g2000pro.googlegroups.com; posting-host=195.214.233.225; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au X-Virus-Scanned: amavisd-new at csse.unimelb.edu.au Xref: g2news2.google.com comp.std.c++:851 comp.lang.c++:22785 On Oct 9, 7:56 pm, "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 It won't. It certainly won't do that with the example given, since there's no clear association in it between the copy constructor and the assignment operator (considering that the latter isn't even defined). Assuming there was such an association, though, I'd rather expect to see: mem pig default mem pig copy // first assignment mem pig copy // second assignment mem pig finish Which is correct and fine - if you have explicitly written the assignment operator twice, then surely you want the associated side- effects? And if you do not, then perhaps you shouldn't have written it that way. > that is you can refrence the returned object inside the function and > decrease the overhead for copying large objects.C++ lacks such syntax > and IMHO we should be able to mark the result object as referencing > the actual return so that there is no need for the extra copy > construction This is precisely what NRVO does. I have a feeling that you're confusing assignment with initialization in this case. Assignment operator always applies to an already- initialized object - the compiler cannot elide the initialization except for the trivial cases (e.g. POD types), which is why operator= still results in unnecessary copying even when the compiler implements NRVO. It's not a problem with NRVO though - it's because assignment is used where just initialization would suffice. Direct initialization is still more efficient then assignment-following-initialization, even with the move semantics of C++0x. --- [ 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 ]