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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-11-29 12:36:39

Howard Hinnant wrote:

> 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.

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<T[]>. It's essentially syntactic 
sugar for unique_ptr< array<T,N> >, 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?