libc++: First cut at <dynarray>

[Howard Hinnant]

On Sep 12, 2013, at 10:51 PM, Chandler Carruth <chandlerc at google.com> wrote:

> On Thu, Sep 12, 2013 at 6:23 PM, Howard Hinnant <howard.hinnant at gmail.com> wrote:
>> Please commit with these changes, and thanks much.  Nice job!
>> 
> I'm not sure it is worth it...
>  
> 
>> Clang team:  If we don't have at least some stack support by Chicago, I may recommend removing dynarray for lack of implementation experience.  I'm seeking feedback from the clang team on that course of action.  If I hear from you that such support is no problem and I'm just being a nervous nanny, I'll back down.  But if we're still figuring out how to do this, and no one else has either, then color me nervous nanny.  dynarray is not worthy of standardization without stack support.
>> 
> Speaking from both the Clang and LLVM side: I don't think we know what we want to have to put things on the stack, and I am confident we won't have it by Chicago. There are big, nasty, hard to answer questions in the space of compiler-aided variable sized stack allocation. Currently on x86 with LLVM, if the size is variable and you have a reasonably fast malloc library, putting dynarray on the stack will often be a pessimization. I'm not sure how often we can make variable sized stack allocation the right choice, but it will at the least require some reasonably significant changes to LLVM's optimizer itself.
> 
> Even then, I currently expect that small vector, or a standard allocator that pulls initially from a fixed-size stack-based pool, will be significantly faster, and the only reason for having dynarray at all was performance! Considering how hard it is to implement, I'm inclined currently to go back to the committee with the lesson "it's really hard, and it won't even be faster. can we just stick with vector?"

Ok.

Sorry Marshall.  Great job, but hold off on the commit.  I think we need to sort this out.

Howard