What are the advantage of scoped_refptr vs. shared_ptr

[xiaofeng zhang]

Hi

Could someone help to list what are the advantages of scoped_refptr vs. std::shared_ptr?

thanks a lot.

[Peter Kasting]

On Wed, Mar 10, 2021 at 10:32 PM xiaofeng zhang <xfzha...@gmail.com> wrote:

Could someone help to list what are the advantages of scoped_refptr vs. std::shared_ptr?

scoped_refptr is an intrusive refcounting design that requires people to opt-in on a per-type basis, which has the effect of reducing the amount of refcounting use in practice.  Since we generally want to discourage refcounting, this is often thought of as a feature rather than a bug.

The actual implementation should be slightly more performant as well.

PK 

[dan...@chromium.org]

When shared_ptr is created from a raw pointer, it has to hold 2 pointers - one to the object and one to the reference count. base::RefCounted always places the refcount inside the object - due to its intrusiveness. So it requires one malloc per creation of a refcounted object.

std::make_shared() enables shared_ptr to be like base::RefCounted, putting the refcount into the object's allocation: https://github.com/llvm-mirror/libcxx/blob/master/include/memory#L4419

If we can get to a world where we use base::MakeRefCounted instead of bare `new` to make all our refcounted objects, we could consider switching to shared_ptr without regressing this.

Cheers,

Dana

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/d87d3de9-0275-4271-9b84-ecbbc494466cn%40chromium.org.

[Simeon Anfinrud]

scoped_refptr is an intrusive refcounting design that requires people to opt-in on a per-type basis, which has the effect of reducing the amount of refcounting use in practice.  Since we generally want to discourage refcounting, this is often thought of as a feature rather than a bug.

I disagree that using the intrusive CRTP discourages refcounting. If anything, it makes refcounting contagious, because if any one instantiator of the class wants to make a refcounted instance, it forces all instantiators to construct a refcounted instance. This means, for example, you have to use MakeRefCounted in unittests where it's clear that the object outlives things that reference it. If you have multiple places in production code that instantiate the class, it's hard to tell which ones need to be refcounted and which ones are refcounted only because base::RefCounted forces it to be stored in a scoped_refptr.