[llvm-commits] [llvm] r47482 - /llvm/trunk/include/llvm/ADT/IntrusiveRefCntPtr.h
clattner at apple.com
Tue Feb 26 13:19:50 PST 2008
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!
More information about the llvm-commits