libc++: First cut at <dynarray>

[Richard Smith]

It's not obvious to me that the behavior of max_size is correct.

To my reading, __allocate is required to throw std::bad_array_length if the
multiplication overflows.

Your reinterpret_casts from void* to (const) _Tp* could be static_casts.

The constructor overloads look... horribly broken. This won't work:

  std::dynarray<long> arr(20, 0);

... because it picks the (size_t, const _Alloc&) constructor, not the
(size_t, const value_type&) constructor. Is there an LWG issue for that?


On Mon, Sep 9, 2013 at 9:06 AM, Marshall Clow <mclow.lists at gmail.com> wrote:

> <dynarray> See
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3662.html
>
> Open Issues:
> 1) This includes <tuple> because that's where __uses_alloc_ctor lives. I'm
> thinking that __uses_alloc_ctor should be hoisted into a common header.
> Maybe __functional_base.
>
> 2) This includes a general implementation of user-allocator construction
> (named __user_alloc_construct). This should probably be hoisted as well;
> and possibly the code in scoped_allocator can be reworked to use it (if it
> simplifies things).
>
> 3) There's no support for stack allocations at present; that requires
> compiler support. I'm working with some people on getting that into clang.
>
> 4) There's an awful lot of duplication in the (many, many) constructors.
>
> -- Marshall
>
> Marshall Clow     Idio Software   <mailto:mclow.lists at gmail.com>
>
> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is
> promptly moderated down to (-1, Flamebait).
>         -- Yu Suzuki
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130909/5bb024e3/attachment.html>