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