[boost] Re: ClonePtr and CopyPtr take 2

From: Beman Dawes (beman_at_[hidden])
Date: 2000-03-08 16:19:26

At 02:23 PM 3/8/00 -0500, Kevin Atkinson wrote:

>On Wed, 8 Mar 2000, Beman Dawes wrote:
>
>> At 05:05 AM 3/8/00 -0500, Kevin Atkinson wrote:
>> 
>> >Hopefully now that you finally understand the point of these
classes
>> you
>> >can understand the more generic code.
>> 
>> Let's make sure I understand the ideas first.
>> 
>> 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.

>> 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.
>> 
>> The two techniques are somewhat orthogonal.  Incomplete type
support
>> is particularly appropriate for deep copy semantics, but it could
>> also be used in variations of the current boost smart pointers so
>> they could work with opaque types having non-trivial destructors. 
>> 
>> In other words, it would be complete (although not necessarily
>> desirable) to have:
>> 
>>   deep_opaque_ptr    // also known as CopyPtr
>>   deep_ptr
>>   shared_opaque_ptr
>>   shared_ptr         // same as current
>>   scoped_opaque_ptr
>>   scoped_ptr         // same as current
>
>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.

>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. 

--Beman