Re: [boost] Preliminary release of clone_ptr library

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2006-07-08 22:52:55

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-concept),
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