Re: [Boost-users] Suggestion for boost`s smart pointers

Howard Hinnant wrote:

The motivation for unique_ptr 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 (but instead use only unique_ptr) 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 calls D(pointer, N). The default D ignores the N.

Thanks. This is somewhat implementation-oriented, though. I was trying to imagine use cases for T[N]. In what situations I would use it? A fixed-size buffer on the heap... it can make sense at times, but it's hard to squeeze it between array<>, vector<> and unique_ptr. It's essentially syntactic sugar for unique_ptr< array >, except it (or the result of dereferencing it) can't be used as a generic container. Then again, T[N] cannot either. I'm not interested in how free it is, just in how useful it is. :-) One could probably advance the argument that since we support T[], we might as well support T[N]. But the incompatible deleter interface makes it hard to transition from T[] to T[N] and back as code evolves. OTOH, one could just provide both overloads in the deleter. If it isn't a function pointer. <shakes head> Where was I?