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