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 miss

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 ,

Nightly Only Containers Feature

This week we enabled the Containers feature for testing in Nightly. Containers is a way for users to have multiple browsing contexts within the sameprofile. With these different contexts, Containersallows users to login to multiple accounts on the same domain simultaneouslyin the same browser w

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 incur ref-counting o

Re: Nightly Only Containers Feature

Looks like there are some formatting issues with the blogpost link, so sending it again: https://blog.mozilla.org/tanvi/2016/06/16/contextual-identities-on-the-web/ On 6/16/16 11:42 AM, Tanvi Vyas wrote: This week we enabled the Containers feature for testing in Nightly. Containers is a way fo

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 in

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 seems like it's a feature

Triage for Component Leads

This afternoon I introduced the new triage process we've developed for bugs in Firefox-related components. My presentation is at https://docs.google.com/presentation/d/1qlXlDsMnvcpA5ppJVJWIBaBDPEyw5hbjU-Q7wjjrZQM/edit?usp=sharing The guide to the process is on the Mozilla wiki: https://wiki.mozil

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: Triage for Component Leads

The wiki says everything from July 1 onwards should be triaged, but the triage-center tool produces bugzilla links from June 1 onwards (when you select the "no priority decision" link). Is this intentional, or just a mix-up? On Thu, Jun 16, 2016 at 5:17 PM, Emma Humphries wrote: > This afternoon