This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
*_ptr<T[N]>Section: 20.3.1[unique.ptr]Status:CD1Submitter: Herb SutterOpened: 2007-10-04Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [unique.ptr].
View all issues withCD1 status.
Discussion:
Please don't provide*_ptr<T[N]>. It doesn't enable any usefulbounds-checking (e.g., you could imagine that doingop++ on ashared_ptr<T[N]> yields ashared_ptr<T[N-1]>, but that promising pathimmediately falters onop-- which can't reliably dereference because wedon't know the lower bound). Also, most buffers you'd want to point todon't have a compile-time known size.
To enable any bounds-checking would require run-time information, withthe usual triplet: base (lower bound), current offset, and max offset(upper bound). And I can sympathize with the point of view that youwouldn't want to require this on*_ptr itself. But please let's notfollow the<T[N]> path, especially not with additional functions toquery the bounds etc., because this sets wrong user expectations byembarking on a path that doesn't go all the way to bounds checking as itseems to imply.
If bounds checking is desired, consider achecked_*_ptr instead (e.g.,checked_shared_ptr). And make the interfaces otherwise identical so thatuser code could easily#define/typedef between prependingchecked_ ondebug builds and not doing so on release builds (for example).
Note that some may object thatchecked_*_ptr may seem to make the smartpointer more likevector, and we don't want two ways to spellvector. Idon't agree, but if that were true that would be another reason toremove*_ptr<T[N]> which equally makes the smart pointer more likestd::array. :-)
[Bellevue:]
Suggestion that fixed-size array instantiations are going to fail at compile time anyway (if we remove specialization) due to pointer decay, at least that appears to be result from available compilers.
So concerns about about requiring static_assert seem unfounded.
After a little more experimentation with compiler, it appears that fixed size arrays would only work at all if we supply these explicit specialization. So removing them appears less breaking than originally thought.
straw poll unanimous move to Ready.
Proposed resolution:
Change the synopsis under 20.3.1[unique.ptr] p2:
...template<class T> struct default_delete; template<class T> struct default_delete<T[]>;template<class T, size_t N> struct default_delete<T[N]>;template<class T, class D = default_delete<T>> class unique_ptr; template<class T, class D> class unique_ptr<T[], D>;template<class T, class D, size_t N> class unique_ptr<T[N], D>;...
Remove the entire section [unique.ptr.dltr.dflt2]default_delete<T[N]>.
Remove the entire section [unique.ptr.compiletime]unique_ptr for array objects with a compile time lengthand its subsections: [unique.ptr.compiletime.dtor], [unique.ptr.compiletime.observers], [unique.ptr.compiletime.modifiers].