[boost] opinions on new clone_ptr semantics

From: Kevin Spinar (spinarkm_at_[hidden])
Date: 2006-07-18 00:29:15

There's previously been much discussion on the semantics of my
proposed clone_ptr class.  Taking the suggestions into mind, I've made
changes to the class synopsis:

http://www.peltkore.net/~alipha/clone_ptr.html

I was curious if anyone had any addition input before I continue with
the new design.  The features that were brought up in discussion that
I plan to include are:

clone-on-copy

A clone_ptr can't be null.  A default-constructed clone_ptr<T, D>
attempts to construct a D object for the clone_ptr to refer to. (where
D defaults to T if the second argument is not specified)

Stateful clone allocators

Separate const and non-const versions of *, ->, and get function to
access the stored object in either a const or non-const manner,
depending upon the constness of the clone_ptr object.  All these
accessor functions don't throw.

Since this is suppose to be an "object wrapper" and not a "clone
pointer", the constructors and reset functions accept references not
pointers, eg:
clone_ptr<base> p((derived()));
Which p then stores a clone of the derived object.

Operator forwarding for the relational operators; clone_ptr<T>'s
relational operators call T's relational operators.

I declined to include an explicit clone function because I felt it
would be confuse users into believing that the object is only cloned
when the clone function is invoked and not cloned everytime the
clone_ptr is copied.  Furthermore, the clone function idea was a
suggestion to get around problems involving clone-on-write, which I'm
not implementing for now.  Also, I'm still unsure of a name; clone_ptr
is more recognizable but clone_obj is more accurate of a name.

Kevin Spinar