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