Re: [RFC] Add C++14's dynarray container (23.3.4, n3662).

[Marc Glisse <marc dot glisse at inria dot fr>]

On Thu, 26 Sep 2013, Rüdiger Sonderfeld wrote:

> I've also written an implementation for C++14's std::dynarray.

Thanks. Do tell us as soon as the paperwork is done. For various reasons, 
it is a bad idea to read your code too closely before that's done :-(

Note that dynarray is probably being removed from C++14 and added to a 
technical specification instead (doesn't change that we want an 
implementation).

> It theoretically supports both memory allocation using `operator new'
> and `alloca'.  (Switch by #defining USE_ALLOCA at the moment.)  However the
> alloca implementation is buggy because std::__uninitialized* seems to have
> issues initialising the memory.

alloca doesn't work the way you think it does. Memory is released at the 
end of the function where alloca is called, so you can't call it from some 
member function, you need to do it from the caller.

> In theory dynarray should be the C++ equivalent of VLAs.

Only for automatic variables of type dynarray. Note that C++14 also has a 
limited version of VLA with the usual array syntax.

> Which would require stack allocation.  But I'm not sure if this can be 
> safely handled at all and the implementation should instead simply stick 
> to operator new/delete.  Maybe this could be a configuration option (not 
> sure how such a thing would be handled).

Stack support requires help from the compiler. It seems to me that we want 
to store a boolean in the class to keep track of whether the memory was 
allocated on the stack or the heap, so the destructor knows to call delete 
or not. In any case, we need a library implementation, and then most of 
the work will be in the compiler itself doing the stack optimization.

--
Marc Glisse