[Webkit-unassigned] [Bug 205617] Add makeRefCounted<>

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jan 9 14:19:19 PST 2020


https://bugs.webkit.org/show_bug.cgi?id=205617

--- Comment #13 from Anders Carlsson <andersca at apple.com> ---
(In reply to Geoffrey Garen from comment #12)
> (In reply to Antti Koivisto from comment #8)
> > (In reply to Anders Carlsson from comment #6)
> > > It seems like stack-allocating RefCounted would already ASSERT on
> > > destruction due to the m_adoptionIsRequired checks in place.
> > 
> > Good point!
> 
> In addition to the ASSERT, a tool can tell us "you called new / constructor
> on a RefCounted object" -- and we are working to enforce other RefCounted
> rules that way.
> 
> I wonder if makeRefCounted can eventually take care of declaring and
> creating the refcount too, removing the need to inherit from RefCounted. In
> theory, it might be just fine to stack-allocate, unique-allocate, or
> refptr-allocate an object, depending on how you use it. (One option would be
> for makeRefCounted to allocate a RefCountWrapper<T> type, rather than T,
> where RefCountWrapper<T> inherited from RefCounted<T> and T.)

That's interesting. It's similar to how std::shared_ptr works if you use std::make_shared.

One thing it would break is "protecting yourself" - RefPtr<Foo> protect(this);.

std::shared_ptr handles this by requiring you to derive from std::enable_shared_from_this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200109/79c92876/attachment.htm>


More information about the webkit-unassigned mailing list