Glad to see it's coming along! Another couple of suggestions -- it would be nice if the clone_ptr took a clone allocator as a policy ( http://boost.org/libs/ptr_container/doc/reference.html#the-clone-allocator-c...), and as well, I would personally like to see the clone-on-copy vs clone-on-write implementation able to be toggled through a template argument if it's not too much trouble, since clone-on-copy still has the advantages of smaller size, more deterministic performance, and perhaps most importantly, more predictable exceptions. An explicit "separate" member function would also be nice, which would explicitly clone the object if it currently has shared ownership. The main purpose of this would be to get around the fact that non-const -> and * may throw an exception if the object isn't yet cloned -- this way, you may clone the object explicitly prior to doing other unrelated operations which otherwise would have a no-throw guarantee, potentially saving the programmer from having to explicitly try and catch or have to unintuitively call non-const get prior to performing other operations in order to implicitly remove the possibility of exceptions being thrown later on in code. Finally, I like the fact that you are propogating the constness to the stored object, however, since that is the path you are taking, I don't think that clone_ptr is a proper name. Traditionally, a pointer merely references the object and its constness doesn't affect the target, and as well, you don't normally expect copying of the target when copying something that merely references the target. In fact, with the way it is now, I'd argue that the * and -> operators are only used because there is no way to directly forward the interface of the object, not because you are implementing a pointer concept (i.e. they're only used because you can't overload the . operator), so I wouldn't really call it a smart pointer at all. As you said in documentation, it's really more like an object wrapper than a smart pointer. Because of this, perhaps "smart_object" or "dynamic_object" or something along those lines would be a more accurate name than "clone_ptr." Really, the pointer aspect is more of an implementation detail than it is a logical part of the concept. -- -Matt Calabrese