[boost] Re: ClonePtr and CopyPtr take 2

From: Kevin Atkinson (kevinatk_at_[hidden])
Date: 2000-03-09 08:53:36

On Wed, 8 Mar 2000, Beman Dawes wrote:

> At 02:23 PM 3/8/00 -0500, Kevin Atkinson wrote:
> 
> >On Wed, 8 Mar 2000, Beman Dawes wrote:
> >
> >> In CopyPtr, you are introducing two smart pointer techniques:
> >> 
> >> 1)  Deep copy semantics.  The current boost smart pointers used
> >> shallow copy semantics.  It isn't that one set of semantics is
> better
> >> than the other; both have their appropriate uses.
> >
> >Could you please define those terms I am not 100% as what you mean.
> 
> The terms come from Smalltalk which has two ways of implementing
> "copy"; "shallowCopy" and "deepCopy".  In C++ terms, shallow copy of
> a pointer just copies the pointer, deep copy of a pointer copies the
> thing pointed to.

Ok, thanks, thats what I thought.  Well deep copy is a LOT less pragmatic
than the any sort of shallow copy that involves reference counting and I
believe boost's smart pointer does.  For one thing deep copy is thread safe
with out any additional and sense the pointer ALWAYS owns its object with
my CopyPtr there is never the change of leaving a dangling pointer or
never freeing the pointer unless some other object is pointing to the raw
pointer which in that case there might be a chance of a dangling pointer
however this is also a danger with boost's smart pointer.

> 
> >> 2)  Incomplete type support via implementation in a separate
> header
> >> of member functions requiring complete types.  This can lead to
> >> better designs by keeping implementation details opaque (hidden
> >> behind an incomplete type) and reducing compilation
> >> interdependencies.

Yes my pointer is interducing those two techniques amoung other things,
algough I never really thought about it like that.

> >Yes it would but The more diffrent varites of pointers we have the
> more
> >combinations we will get.  There has got to be a better way.
> 
> Yes, hopefully.  Particularly since there are other dimensions not
> discussed here.  But how to put it all together isn't clear, at least
> to me.

Maybe my GenericCopyPtr is a start?

> >Also what is the point of deep_ptr?  Why not just store the object
> >directly with out any pointers?
> 
> I don't know if there is a point; I just trying to understand to what
> extent (1) and (2) are separable.  Actually I can think of a couple
> of uses; if the pointed to object is sometimes not required, a
> deep_ptr could just be 0.  That could be a big savings.  Also, if the
> pointed to object holds a resource, a deep_ptr would provide
> exception safety if the containing object's constructor throws. 

True.

---
Kevin Atkinson
kevinatk_at_[hidden]
http://metalab.unc.edu/kevina/