<div dir="ltr">On Mon, Sep 9, 2013 at 3:32 PM, Marshall Clow <span dir="ltr"><<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im"><div>
On Sep 9, 2013, at 11:59 AM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:</div><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 9, 2013 at 9:06 AM, Marshall Clow <span dir="ltr"><<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><dynarray> See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3662.html" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3662.html</a><br>
<br>Open Issues:<br>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.<br><br>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).<br>
<br>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.<br><br>4) There's an awful lot of duplication in the (many, many) constructors.<br>
</blockquote></div></div></blockquote><blockquote type="cite"><br></blockquote></div><div class="im"><blockquote type="cite"><div dir="ltr">It's not obvious to me that the behavior of max_size is correct.</div></blockquote>
<div><br></div></div>What do you suggest it return?</div><div>It returns the current size of the array - and that's the max size that array can be.</div><div>[ This is the same behavior as std::array, btw ]</div></div>
</blockquote><div><br></div><div>It's not obvious to me =)</div><div><br></div><div>The choices seem to either be that max_size() returns size() (the largest size for that *instance*), or that it returns the largest size that will not throw std::bad_array_length (the largest size for that *type*). It seems somewhat pointless to me to even have such a member, though. What's it for? (What generic code that operates on containers would care?)</div>
<div><br></div><div>For std::array, the case seems much clearer-cut, since the largest size for an instance is the same as the largest size for the type.</div><div><br></div><div>Here's the closest I've been able to find to a use case:</div>
<div><br></div><div>bool destructive_resize_dynarray(std::dynarray<int> &arr, size_type n) {</div><div>  if (n >= arr.max_size()) return false;</div><div><br></div><div>  arr.~dyn_array<int>();</div><div>
  new (&arr) std::dynarray<int>;</div><div>  return true;</div><div>}</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div dir="ltr"><div>To my reading, __allocate is required to throw std::bad_array_length if the multiplication overflows.</div></div></blockquote>
<div><br></div></div>Yes. Nice catch.</div><div>This led me down a bit of a rathole, b/c libc++ hasn't implemented std::bad_array_length yet.</div><div>I'll have a (separate) patch for that up in a bit.</div><div>
<br></div><div><div class="im"><blockquote type="cite"><div dir="ltr"><div>Your reinterpret_casts from void* to (const) _Tp* could be static_casts.</div></div></blockquote><div><br></div></div>Fixed.</div><div><div class="im">
<br><blockquote type="cite"><div dir="ltr"><div>The constructor overloads look... horribly broken. This won't work:</div><div><br></div><div>  std::dynarray<long> arr(20, 0);</div>
<div><br></div><div>... because it picks the (size_t, const _Alloc&) constructor, not the (size_t, const value_type&) constructor. Is there an LWG issue for that?</div></div></blockquote><div><br></div></div>No, actually, it picks the right version; but I've added that exact case to the test suite.</div>
</div></blockquote><div><br></div><div>It picks this constructor: dynarray(size_t, const _Alloc&), with _Alloc=int, which is a better match than the intended dynarray(size_t, const long&). This:</div><div><br></div>
<div><div>int main() {</div><div>  std::dynarray<long> dl(20, 3);</div><div>  return dl[0];</div><div>}</div></div><div><br></div><div>returns 0, not 3. (The "allocator" argument 3 is <b>silently ignored</b> because 'long' doesn't have an allocator-taking constructor.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I wouldn't mind some SFINAE here for the "Allocator" routines, though.</div>
<div>I need a good "is_allocator" template metafunction.</div><div><br></div><div>Thanks for the review.</div><div class="im"><div><br></div><div>
<span style="border-collapse:separate;border-spacing:0px">-- Marshall<br><br>Marshall Clow     Idio Software   <<a href="mailto:mclow.lists@gmail.com" target="_blank">mailto:mclow.lists@gmail.com</a>><br><br>A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).<br>
        -- Yu Suzuki</span>

</div>
<br></div></div></blockquote></div><br></div></div>