Boost logo

Boost :

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:

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:


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at