libc++: First cut at <dynarray>

[Howard Hinnant]

On Sep 9, 2013, at 8:26 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> 
> On Mon, Sep 9, 2013 at 4:48 PM, Howard Hinnant <howard.hinnant at gmail.com> wrote:
> Thanks Marshall.  I've read Richard's excellent comments, and these are in addition to his.
> 
> ...
> 
> Marshall and I have already discussed this, but for the benefit of others:  I don't think dynarray should ever use the heap, and I don't want to commit even temporarily an implementation that does.
> 
> I don't think that's possible (and Nick has argued that it's not desirable, because it will probably be a pessimization; I don't have data there).
> 
> Consider:
> 
> void g(std::dynarray<int> &);
> 
> void f() {
>   std::dynarray<int> arr(10);
>   g(arr);
>   return arr[3];
> }
> 
> // Some other TU:
> void g(std::dynarray<int> &arr) {
>   arr.~std::dynarray<int>();
>   new (&arr) std::dynarray<int>(30);
> }
> 
> I believe this code is valid, and we can't promote the allocation in 'f' to the stack, nor the allocation in 'g'.
> 
> Also, if the dynarray object itself is on the heap, or in a global or thread-local variable, we can't promote its allocation to the stack. And if it's in a class type that's on the stack, we can only promote that if we manage to inline the constructor and destructor (and we see that the allocation doesn't escape).
> 
> You should think of putting the allocation on the stack as, at best, an optimization, and should expect the allocation to go on the heap if we cannot perform the optimization. FWIW, I'm not really sure why we have std::dynarray, rather than an allocator for std::vector that encourages a heap -> stack optimization.

Thanks for pointing out the corner cases.  It sure seems to me like we are the first party implementing this.  If I am correct, I have no idea what this is doing in a draft for C++1y.

Howard