return value optimization vs. returning a boost::shared_ptr of container
in [C++]
|
Prev: return value optimization vs. returning a boost::shared_ptr of container
Next: return value optimization vs. returning a boost::shared_ptr of container
From: Mathias Gaunard on 15 Jun 2010 09:45 On 15 juin, 10:05, Peng Yu <pengyu...(a)gmail.com> wrote: > If there is return value optimization (RVO), I think that I can return > tr1::unordered_map as the compile can optimize away unnecessary coping > in certain cases. But I think that there cases where RVO doesn't help. > For example, if tr1::unordered_map is returned from a function that is > only available in the object format (through linkage), the copying can > not be avoided, right? RVO, if implemented, is consistent. NRVO should also be consistent if all exit paths from the function return the same named object. You should expect any compiler of good quality to implement NRVO, and any decent compiler to implement RVO. Therefore you should return by value if that's what semantically makes sense. There is no useless copy (or even move) going on when returning a local variable by value (assuming the return type is the same of the type of the return expression). -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 15 Jun 2010 09:45 On 15 juin, 15:51, Goran <goran.pu...(a)gmail.com> wrote: > I think so, too, but you have swap method, which is efficient. So: > > LibMapType map; > map.swap(LibFuncReturningMap(...)); Or simpler and more efficient, LibMapType map = LibFuncReturningMap(...); -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 17 Jun 2010 03:56 On 16 juin, 14:56, "Martin B." <0xCDCDC...(a)gmx.at> wrote: > Except of course if someone wrote: > container_t fn() { ... } > ... > container_t obj; > obj = fn(); > In this case (N)RVO cannot work and you always have to copy(move). NRVO or RVO remove useless copies, not assignments. That's a different thing altogether and that simply cannot be done because: 1) this is not allowed by the language 2) this doesn't work when fn may throw. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 18 Jun 2010 04:19
On 18 juin, 16:30, "Martin B." <0xCDCDC...(a)gmx.at> wrote: > Mathias Gaunard wrote: > > On 16 juin, 14:56, "Martin B." <0xCDCDC...(a)gmx.at> wrote: > > >> Except of course if someone wrote: > >> container_t fn() { ... } > >> ... > >> container_t obj; > >> obj = fn(); > >> In this case (N)RVO cannot work and you always have to copy(move). > > > NRVO or RVO remove useless copies, not assignments. > > Well, for me in day-to-day language, an assignment *is* a copy. It's conceptually a fairly different operation. You could see assignment as destruction + copy. Except that if the copy fails, you need a way to revert the destruction. Typical way to implement this is to make a temporary and swap it with the current object (assuming a nothrow swap). > True. That's why I pointed out that return-by-value may be more > expensive that other alternatives when doing an assignment instead of > initialization. (I do think it does not really matter with C++0x move > semantics, because this is also applied when assigning?) If you write your assignment operator well (take the object by *value*), you can still benefit from NRVO and have zero useless copies. The above code you provided would not call the copy constructor even once, it would just do one swap. And I'm talking about C++03 here. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |