Re: Return-value-optimization when return type is RefPtr

On Mon, Aug 15, 2016 at 3:55 PM, Aryeh Gregor wrote: > IMO, it makes sense to move ahead with this. One more point I forgot to (re-?)mention: with proper move constructors, it's not just already_AddRefed return values that should be changed to RefPtr, but also T* return values,

Re: Return-value-optimization when return type is RefPtr

Sorry for the necroposting, but some points that I think are still worth correcting: On Thu, Jun 16, 2016 at 11:50 AM, Boris Zbarsky wrote: > On 6/16/16 3:15 AM, jww...@mozilla.com wrote: >> >> I think that is the legacy when we don't have move semantics. Returning >> RefPtr

Re: Return-value-optimization when return type is RefPtr

On 06/17/2016 04:01 PM, Gerald Squelart wrote: On Friday, June 17, 2016 at 3:57:01 PM UTC+1, Gerald Squelart wrote: On Friday, June 17, 2016 at 2:31:15 PM UTC+1, smaug wrote: On 06/16/2016 06:40 PM, smaug wrote: On 05/24/2016 08:33 AM, jw...@mozilla.com wrote: For RefPtr GetFoo() {

Re: Return-value-optimization when return type is RefPtr

On 17/06/2016 16:57, Gerald Squelart wrote: > From what *I* understand, RVO is guaranteed (or at least supported > everywhere?) when there is only one stack variable that is returned, e.g.: > C foo() > { > C rv; > // ... (put stuff in rv) > return rv; > } > In this case, the caller function

Re: Return-value-optimization when return type is RefPtr

On Friday, June 17, 2016 at 3:57:01 PM UTC+1, Gerald Squelart wrote: > On Friday, June 17, 2016 at 2:31:15 PM UTC+1, smaug wrote: > > On 06/16/2016 06:40 PM, smaug wrote: > > > On 05/24/2016 08:33 AM, jw...@mozilla.com wrote: > > >> For > > >> > > >> RefPtr GetFoo() { > > >>RefPtr foo; > > >>

Re: Return-value-optimization when return type is RefPtr

On Friday, June 17, 2016 at 2:31:15 PM UTC+1, smaug wrote: > On 06/16/2016 06:40 PM, smaug wrote: > > On 05/24/2016 08:33 AM, jw...@mozilla.com wrote: > >> For > >> > >> RefPtr GetFoo() { > >>RefPtr foo; > >>// ... > >> } > >> > >> should we: > >> > >> 1. return foo and expect RVO to kick

Re: Return-value-optimization when return type is RefPtr

On 06/16/2016 06:40 PM, smaug wrote: On 05/24/2016 08:33 AM, jww...@mozilla.com wrote: For RefPtr GetFoo() { RefPtr foo; // ... } should we: 1. return foo and expect RVO to kick in to eliminate additional AddRef/Release 2. return foo.forget() 3. return Move(foo) Which one is

Re: Return-value-optimization when return type is RefPtr

On 05/24/2016 08:33 AM, jww...@mozilla.com wrote: For RefPtr GetFoo() { RefPtr foo; // ... } should we: 1. return foo and expect RVO to kick in to eliminate additional AddRef/Release 2. return foo.forget() 3. return Move(foo) Which one is preferred? ps: I find gcc is able to apply RVO

Re: Return-value-optimization when return type is RefPtr

On Thu, Jun 16, 2016 at 2:15 PM, Michael Layzell wrote: > We pass T* as an argument to a function too often for this to e practical. > Can you explain why? Is your point here to avoid people having to type .get() or the mass conversion from the current code? The former

Re: Return-value-optimization when return type is RefPtr

We pass T* as an argument to a function too often for this to e practical. The best solution is probably to remove the conversion from RefPtr&& to T* which is I believe what froydnj is planning to do. This requires ref qualifiers for methods, which isn't supported in MSVC 2013, but is supported

Re: Return-value-optimization when return type is RefPtr

Is it worth reconsidering removing implicit conversion from RefPtr to T*? -Ekr On Thu, Jun 16, 2016 at 9:50 AM, Boris Zbarsky wrote: > On 6/16/16 3:15 AM, jww...@mozilla.com wrote: > >> I think that is the legacy when we don't have move semantics. Returning >> RefPtr won't

Re: Return-value-optimization when return type is RefPtr

On 6/16/16 3:15 AM, jww...@mozilla.com wrote: I think that is the legacy when we don't have move semantics. Returning RefPtr won't incur ref-counting overhead and is more expressive and functional. Except for the footgun described in

Re: Return-value-optimization when return type is RefPtr

Coincidentally: (?) https://bugzilla.mozilla.org/show_bug.cgi?id=1280296 "remove already_AddRefed" :-) For your original question, I would vote for RVO when possible, and Move() otherwise. It feels like static analysis should be able to detect cases where RVO is possible and suggest it if

Re: Return-value-optimization when return type is RefPtr

Kan-Ru Chen (陳侃如)於 2016年5月24日星期二 UTC+8下午4時00分12秒寫道： > I think the current practice is to use already_AddRefed as return > type and return foo.forget() > > Kanru I think that is the legacy when we don't have move semantics. Returning RefPtr won't incur ref-counting overhead and is more

Re: Return-value-optimization when return type is RefPtr

jww...@mozilla.com writes: > For > > RefPtr GetFoo() { > RefPtr foo; > // ... > } > > should we: > > 1. return foo and expect RVO to kick in to eliminate additional AddRef/Release > 2. return foo.forget() > 3. return Move(foo) > > Which one is preferred? > > ps: I find gcc is able to apply

Return-value-optimization when return type is RefPtr

For RefPtr GetFoo() { RefPtr foo; // ... } should we: 1. return foo and expect RVO to kick in to eliminate additional AddRef/Release 2. return foo.forget() 3. return Move(foo) Which one is preferred? ps: I find gcc is able to apply RVO even with "-O0". Not sure if it is also true for