On Sep 9, 2013, at 8:26 PM, Richard Smith <[email protected]> wrote:
> > On Mon, Sep 9, 2013 at 4:48 PM, Howard Hinnant <[email protected]> > 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
