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 <[email protected]> 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:[email protected]> > > A.D. 1517: Martin Luther nails his 95 Theses to the church door and is > promptly moderated down to (-1, Flamebait). > -- Yu Suzuki > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
