On Nov 29, 2006, at 10:33 AM, Richard Hadsell wrote:

David Klein wrote:

...

so are there any objections about adding this feature to scoped_ptr?

I'm sure I have seen this discussion before. I believe the issue was the size of scoped_ptr itself. It is supposed to be a lightweight object, no bigger than the pointer it holds. Any added overhead is unacceptable. If you can implement the feature without adding any data members, fine. Otherwise, please create a new class.

<nod> This comes up now and then. Fwiw, anyone/everyone is welcome to my emulation of the proposed C+ +0X unique_ptr: http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr_03.html Sorry, it isn't documented. Here's the best documentation I currently have: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/ n1856.html#Addition%20-%20Class%20template%20unqiue_ptr The (non)copyright at the top means you can do whatever you want with the code, including stripping my name out of it. In a nutshell: * It has a deleter. * If the deleter is an empty class, sizeof(unique_ptr<T, D>) == sizeof(T*). * It has unique ownership semantics like auto_ptr/scoped_ptr. * It does not transfer ownership with copy syntax (modulo a bug mentioned in the source code). * It has cute syntax to safely handle arrays: unique_ptr<T[]>. * You can also customize the storage type (defaults to T*) by giving your deleter an optional D::pointer type. * The deleter can be a reference to a deleter. The sizeof the unique_ptr swells by a word when you do this, but it does come in handy when you want to reference some other deleter instead of copy it in to the unique_ptr. * The deleter can be a function pointer. sizeof swells here too. * It has been proposed for standardization. -Howard

On Nov 29, 2006, at 11:07 AM, Peter Dimov wrote:

Howard Hinnant wrote:

...

* It has cute syntax to safely handle arrays: unique_ptr<T[]>. * You can also customize the storage type (defaults to T*) by giving your deleter an optional D::pointer type.

Do you have a rationale/use cases for D::pointer and unique_ptr<T[N]>?

Not written up. But D::pointer was put in in an attempt to support shared memory. In this use case you really need a smart pointer instead of a T*. This use case hasn't been tested with actual code. However the feature is about as free as it gets. It consumes no code size or run time. And the author of D can completely ignore the pointer type and not even provide it. unique_ptr searches D, and if pointer isn't found, uses T*. Put this one in the "might be useful, costs nothing to provide" category. On unique_ptr<T[N]> I'm assuming you're specifically talking about providing the N, as opposed to just unique_ptr<T[]>. If you're talking about array support in general, let me know and I'll address that. The motivation for unique_ptr<T[N]> is so that vendors can offer range checking on operator[](size_t i) (perhaps only in debug builds). The N is a compile time constant, so takes up no storage space. The main cost is potential code bloat as you'll get a different instantiation for every different N. But if you don't use unique_ptr<T[N]> (but instead use only unique_ptr<T[]>) then you don't pay for this feature. Oh, and though most deleters don't need to know the size of the allocation, some might. So unique_ptr<T[N], D> calls D(pointer, N). The default D ignores the N. -Howard

On Nov 29, 2006, at 12:36 PM, Peter Dimov wrote:

I'm not interested in how free it is, just in how useful it is. :-)

<nod> If I were to scale usefulness as: 1. Would never use it. 2. ... 3. Might use it once in a while. 4. ... 5. I'd find it handy sometimes. 6. ... 7. ... 8. Lots of uses for it. 9. ... 10. Have to have it. It might go something like: unique_ptr<T> : 10 unique_ptr<T[]> : 5 unique_ptr<T[N]>: 3 If it costs me a bundle to support a 3 or a 5, I wouldn't even consider them. But these have very low costs in terms of: * Conceptual complexity (simple, intuitive interface) * Run time (none if not used, cheap if used) * Code size (none if not used, cheap if used) * Compile time (extremely little) * Implementation support (little) (those are listed in order of importance, imho of course) -Howard