This is one of the places where I get *REALLY* confused - the 'real' code has multiple returns. Apologies: I should have included this psuedo code in the original example. It looks like this. <snippet> // v is populated somewhere else typedef vector<shared_ptr<int> > V; V v; shared_ptr<int> maybe_get_a_pointer() { shared_ptr<int>::iterator itr; itr = find_if(v.begin(), v.end(), some_op); if(itr != v.end) return(*itr); shared_ptr<int> p; return(p); } </snippet> Are compilers supposed to be able to match *itr to p in order to apply the NRVO? "Ben Hutchings" <ben.hutchings@businesswebso To: <Boost-Users@yahoogroups.com> ftware.com> cc: Subject: RE: [Boost-Users] Re: "Correct" way to return empty shared_ptr? 04/24/2003 08:56 AM Please respond to Boost-Users dick.bridges@tais.com wrote:
I don't understand C++ well enough to grok a compiler's interpretation of the code, but I seems like I'm creating an extra copy for the return. <snip>
Logically the local variable is copied to the the caller, but since the type of the returned expression matches the return type the compiler is allowed to optimise away that copy, even though the return type has a user-defined copy constructor. In this case you always return a certain named variable, so the compiler can arrange to construct it in the memory location where the caller expects the returned value. This is called the named-return-value optimisation, or NRVO. Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/