[boost] Re: destructor in linked_ptr_base

From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-03-21 14:00:57

> -----Original Message-----
> From: Gavin Collings [mailto:gcollings_at_[hidden]]
> Sent: Tuesday, March 21, 2000 12:14 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: destructor in linked_ptr_base
> 
> 
> "borgerding, mark a." <marka-_at_[hidden]> wrote: 
> original article:http://www.egroups.com/group/boost/?start=2709
> > 
> > There are a few reasons I shied away from using template friends
> > 1) Compiler support for template friends is less than universal.
> Avoiding
> > them reduces the amount of #ifdef code to maintain.
> > 2) I don't like using friends unless they clearly strengthen
> encapulation
> > (This point is arguable for linked_ptr_base)
> > 3) I think it reads better without the template friends. (Personal
> > preference perhaps)
> 
> There do seem to be arguments in both directions for this type of
> thing.  I tend to go with Scott Meyers et al and use public 
> inheritance
> only to express an is-a relationship.  Though I have to confess to
> getting a little tired of the using directives that the approach
> implies (and have bypassed them on occasion).
> 

If template friends are allowed, then the linked_ptr_base inheritance could
also be replaced by containment.  I think this is more attractive in the
long-term.  However, because of current lack of support for this feature, it
would mean that on many compilers, the link data member would need to be
public in order to have polymorphic casts.

I just had a thought.

Suppose the linking functionality was contained as a member, as I describe
above.  But the polymorphic copy bahvior is delegated to a third class, that
is non-templated, but has a templated member function to perform the
copying.  Hmm, this is starting to sound pretty messy.  I don't know how the
interface could enforce outsiders from accessing the copy function without
making the linked_ptr<T> a template friend, which is what I'm trying to get
around.

Well, maybe it's not such a hot idea.

> Answering your points.
> 
> 1) Yes it is a pain that template friends aren't universally 
> supported,
> but hopefully, it's a temporary situation.

Indeed, it will be nice when all major compilers are compliant to the
standard.

> 2) The argument for increased encapsulation is exactly that for which
> Miki proposed his fix - that of clients getting hold of a
> linked_ptr_base pointer.  This is highly unlikely in itself, since
> linked_ptrs would typically be used by value, so polymorphism wouldn't
> enter in to it.  But having acknowledged that a problem exists, better
> to make more explicit the fact that a linked_ptr should not be used as
> a linked_ptr_base IMO.

I guess I see your point that using private inheritance (or containment )
increases the encapsulation. I am still not sure it is enough to be worth
adding conditional compiles.

> 
> 3) My personal preference leans the other way.  Not strongly 
> though, if
> you say no, I'll leave it as it is.
> 

I don't really have strong feelings about it either.

-- Mark