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

[Chris Lattner]

On Feb 26, 2008, at 11:10 AM, Ted Kremenek wrote:
>>> 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.

Sounds good, lets just go with RefCountedBase for now.  If we find a  
need for RefCountedBaseVPTR, we can always add it later.  Thanks!

-Chris