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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk