[boost] Re: destructor in linked_ptr_base

From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-03-21 09:20:29

> -----Original Message-----
> From: Gavin Collings [mailto:gcollings_at_[hidden]]
> Sent: Tuesday, March 21, 2000 7:53 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: destructor in linked_ptr_base
> 
> 
> "miki jovanovic" <mik-_at_[hidden]> wrote: 
> original article:http://www.egroups.com/group/boost/?start=2704
> > 
> > Since linked_ptr must inherit publicly from linked_ptr_base, this in
> > theory means that the user can get the pointer to the 
> linked_ptr_base,
> > and then try to destroy it. Effect of this would be a GPF 
> or resource
> > leak. To stop the user from doig this, linked_ptr_base destructor
> > should be protected, and since it does nothing, it is empty.
> 

Good catch, Miki.

> That seems to take care of it, but is there a good reason why this
> inheritance relationship is public?  For compilers that support member
> template friends a fix like the following could be used.
[snip]

You hit the nail on the head.  The reason I used public inheritance was to
avoid making friends <<insert joke here>> .  Without any public members,
there is not much the user can do with linked_ptr_base anyway.  It seems I
overlooked the implicitly declared destructor.  

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)

> 
> In fact the entire class could do with having the member template
> macros applied.  If no-one objects, I'll make the changes to the
> docvault version.
> 

Yes, it could.  No objections here.

The only reason this was not done earlier was because the current config.hpp
says that MSVC doesn't support member templates.  This is only partially
true, since they can be made to work with a few tricks.

-- Mark