[llvm-commits] [llvm] r47482 - /llvm/trunk/include/llvm/ADT/IntrusiveRefCntPtr.h

[Chris Lattner]

On Feb 26, 2008, at 8:44 AM, Ted Kremenek wrote:

>
> On Feb 25, 2008, at 1:22 PM, Chris Lattner wrote:
>
>>> +  template <class Derived>
>>> +  class RefCountedBaseVPTR {
>>
>> Why do you need this class?  The only way a ref counted object should
>> be destroyable is through Release(), which should handle the case  
>> when
>> "Derived" itself has a virtual dtor, no?
>
> I suppose that is true since "RefCountedBase::Release" performs a  
> static cast to the derived class.

Right.

> The advantage of RefCountedBaseVPTR is that classes that derive from  
> it (as opposed to deriving from RefCountedBase) can have the  
> compiler *enforce* that they are never statk allocated.

But we want this for RefCountedBase also, right?

> By making the dstor protected in RefCountedBaseVPTR, an object  
> cannot be stack allocated (although subclasses have to make their  
> dstor protected as well for this to work).  With RefCountedBase,  
> clients must make the dstor public in order for the static cast with  
> the Release method to work.  Thus clients that are already using a  
> VPTR can engineer extra safety into their code by having the  
> compiler enforce that objects derived from RefCountedBaseVPTR are  
> never stack allocated; this same trick cannot be done with  
> RefCountedBase (at least as far as I can tell without making  
> RefCountedBase<Derived> a friend class of Derived).

I don't really understand how having a vptr is relevant here. access  
control doesn't care about virtualness.  In any case, is the  
complexity worth supporting for marginal utility?

-Chris