(In reply to Olli Pettay [:smaug] from comment #12) > I don't quite understand this constructor part here. This is about refcounting. When constructor runs, refcnt is 0 initially, but if one wants, explicitly increasing it is of course possible. The caller just needs to know about it, so it can be a tad confusing. > The normal pattern however is to do something like > RefPtr<MyClass> myObject = new MyClass(); > myObject->Init(); // Init may do complicated stuff, and the RefPtr on the stack keeps 'myObject' alive. I might not use the same language here yet, sorry (looking forward to the CC session next week). The example you show makes clear, that complicated initialization logic (including JS calls) is better placed outside the constructor. Period. Then, if I understand right, there are two possible triggers for deleting an object: directly when the refcount goes zero and indirectly through cycle collection of orphaned cycles. In bug 1610692 I see the latter case caused by a missing assignment to any RefPtr before the constructor ended, that is why I was talking about CC. > > One needs to still remember that RefPtr as member variables aren't something which in general keep callee alive. > That is why > https://searchfox.org/mozilla-central/rev/f98dad153b59a985efd4505912588d4651033395/layout/base/nsDocumentViewer.cpp#1002-1004 > is rather common pattern. Thanks, that would be interesting for next week, too. :-)
Bug 1607276 Comment 14 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Olli Pettay [:smaug] from comment #12) > I don't quite understand this constructor part here. This is about refcounting. When constructor runs, refcnt is 0 initially, but if one wants, explicitly increasing it is of course possible. The caller just needs to know about it, so it can be a tad confusing. > The normal pattern however is to do something like > RefPtr<MyClass> myObject = new MyClass(); > myObject->Init(); // Init may do complicated stuff, and the RefPtr on the stack keeps 'myObject' alive. I might not use the same language here yet, sorry (looking forward to the CC session next week). The example you show makes clear, that complicated initialization logic (including JS calls) is better placed outside the constructor. Period. Then, if I understand right, there are two possible triggers for deleting an object: directly when the refcount goes zero and indirectly through cycle collection of orphaned cycles. In bug 1610692 I see the latter case caused by a missing assignment to any RefPtr before the constructor ended, that is why I was talking about CC. > > One needs to still remember that RefPtr as member variables aren't something which in general keep callee alive. > That is why > https://searchfox.org/mozilla-central/rev/f98dad153b59a985efd4505912588d4651033395/layout/base/nsDocumentViewer.cpp#1002-1004 > is rather common pattern. Thanks, that would be interesting for next week, too. :-)