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

[Ted Kremenek]

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.

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.  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).

>> Classes that inherit from RefCountedBaseVPTR can't
>> +///  be allocated on stack.
>> +//
>> =
>> =
>> =
>> ----------------------------------------------------------------------=
>> ==//
>
> I don't think that classes inheriting from RefCountedBase should be
> allocated on the stack either.  release'ing them cause them to be
> delete'd, which is badness for stack memory.  Ref counted objects only
> make sense on the heap.

Neither classes should be allocated on the stack.  The comments for  
both classes say this.