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

[Ted Kremenek]

On Feb 26, 2008, at 9:52 AM, Chris Lattner wrote:

> 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?

Sure.

>
>
>> 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?

The problem (I believe) is that a parent class cannot call a protected/ 
private method of a derived class unless its virtual.  That's why  
RefCountedBaseVPTR does "delete this", instead of performing a static  
cast to Derived. The only way for the parent class to call Derived's  
private/protected non-virtual methods is if the parent class is  
registered as a friend of Derived.

To answer your other question: no, the complexity is not worth it.  If  
someone really wants to prevent a Derived class from being allocated  
on the stack, they can make the dstor private and make RefCountedBase  
a friend.