Open Bug 1401008 Opened 3 years ago Updated 3 years ago

Consider adding something like Rc<T>/Arc<T> to easily make refcounted containers around things

Categories

(Core :: MFBT, enhancement, P3)

53 Branch
enhancement

Tracking

()

People

(Reporter: bzbarsky, Assigned: froydnj)

Details

I recently needed to decide whether to refcount an nsTArray or copy it, and decided to copy because it was simpler.  But with something like Rc<nsTArray> refcounting it would have been super-simple.

In bug 1400501 comment 2 mystor suggests:

  template<typename T>
  using Arc = RefPtr<ArcBox<T>>;

  template<typename T>
  class ArcBox : public T {
    //  ... constructors etc...
    NS_INLINE_DECL_THREADSAFE_REFCOUNTING(ArcBox)
  };

  // .. Probably a MakeArc free function to construct one?

and Rc would be similar but without the THREADSAFE bit.

Note that this is not the problem RefCounted solves.  That one solves the problem of adding intrinsic refcounting easily to a class, whereas I want to solve the problem of adding extrinsic refcounting easily.
I assume that we wouldn't want to use std::shared_ptr because we want:

1) The ability to choose the thread-safetyness of our refcounting;
2) Integration with leak-checking;
3) Maybe another reason I cannot think of right now.

(I agree with all of the above desires, btw, just stating them to be clear that everybody's on the same page.)  Is that correct?
Flags: needinfo?(bzbarsky)
And integration with cycle collection.

Though in my case (array of strings), I probably could have used std::shared_ptr...  I guess I just still feel a natural aversion to std::*.  :(
Flags: needinfo?(bzbarsky)
Oh, and I guess the other difference is that shared_ptr involves a bit more pointer-chasing than Arc, because it can't guarantee that a single allocation is used (i.e. that make_shared) is used.  This might not be a big deal in practice.
Assignee: nobody → nfroyd
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.