On 02/12/2013 12:21 AM, Dave Abrahams wrote:
Random thoughts:
I don't know where this discussion stands on the issue, but it just occurred to me that I wouldn't want copying a ptr to automatically do anything to the ptee (pointee).
I could imagine something like shared_ptr taking an optional cloner (as well as a deleter) and having
shared_ptr<T const> x(new T); shared_ptr<T> y = x.clone_ptee(); I like the idea of making cow_ptr<T const> somewhat special. At least it should be convertible to cow_ptr<T>. I like the way const qualification integrates with that. I wonder if everyone who wants to implement CoW also wants the cost of shared_xxx, though. What costs do you mean? CoW is especially useful (in my opinion) to
Well, that's exacly what value_ptr does: Whenever the pointer is copied, its pointee is copied or cloned. This enables proper value semantics on polymorphic types. Copying a cow_ptr would only copy pointers and increment a reference count. Later the copy can be made, if writing occurs. prevent expensive copies in terms of time and memory (and maybe even other stuff). It should not be overused. Probably the ranking of pointer type usage for me would be 1. raw pointers (as functions arguments, etc., no memory management involved) 2. unique_ptr (when it's needed only in one place) 3. shared_ptr and weak_ptr (when you want to extend the lifetime of a pointed to object, or if there are several owners) 4. cow_ptr (to implement copy-on-write when copying is expensive and/or to give polymorphic types value semantics) Thanks for the feedback, Ralph