------=_Part_1472_13653020.1366712151069
Content-Type: text/plain; charset=ISO-8859-1

In dynarray's constructor that takes a `size_type`<http://isocpp.org/files/papers/N3662.html#dynarray.cons>,
the current wording states:

Allocates storage for c elements. May or may not invoke the global operator
> new. The c elements of the dynarray are default-initialized (8.5).
>

All other containers value-initialize their contents. If we're not going to
allow default-initialization in `std::vector`, we shouldn't allow
default-initialization in `dynarray`. And vice-versa: if we're going to
allow `dynarray` to default-initialize its contents, we should allow
`vector` to do the same.

I would really rather not have to use a `dynarray` where I would have
preferred a `vector`, just because it allows default initialization of its
contents and `vector` does not.

Also, this constructor should probably be `explicit`.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_1472_13653020.1366712151069
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

In <a href=3D"http://isocpp.org/files/papers/N3662.html#dynarray.cons">dyna=
rray's constructor that takes a `size_type`</a>, the current wording states=
:<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px s=
olid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">Allocate=
s storage for <var>c</var> elements.
May or may not invoke the global <code>operator new</code>.
The <tt>c</tt> elements of the dynarray are default-initialized (8.5).
<br></blockquote><br>All other containers value-initialize their contents. =
If we're not going to allow default-initialization in `std::vector`, we sho=
uldn't allow default-initialization in `dynarray`. And vice-versa: if we're=
 going to allow `dynarray` to default-initialize its contents, we should al=
low `vector` to do the same.<br><br>I would really rather not have to use a=
 `dynarray` where I would have preferred a `vector`, just because it allows=
 default initialization of its contents and `vector` does not.<br><br>Also,=
 this constructor should probably be `explicit`.<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1472_13653020.1366712151069--

.

------=_Part_2938_23890816.1366714244082
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, April 23, 2013 11:15:51 AM UTC+1, Nicol Bolas wrote:
>
> In dynarray's constructor that takes a `size_type`<http://isocpp.org/files/papers/N3662.html#dynarray.cons>,
> the current wording states:
>
> Allocates storage for c elements. May or may not invoke the global operator
>> new. The c elements of the dynarray are default-initialized (8.5).
>>
>
> All other containers value-initialize their contents. If we're not going
> to allow default-initialization in `std::vector`, we shouldn't allow
> default-initialization in `dynarray`. And vice-versa: if we're going to
> allow `dynarray` to default-initialize its contents, we should allow
> `vector` to do the same.
>

But that is consistent with default-initializing a std::array of  n
elements (the difference being that n is part of the type for std::array
and a constructor parameter for std::dynarray, which is the whole point of
dynarray.)


> I would really rather not have to use a `dynarray` where I would have
> preferred a `vector`, just because it allows default initialization of its
> contents and `vector` does not.
>

std::dynarray is closer in spirit to std::array, not std::vector (which is
why I dislike it supporting allocators, if you need the full power of an
allocator-aware sequence container with all the complexity that entails
then use std::vector, not std::dynarray.)


>
> Also, this constructor should probably be `explicit`.
>

The synopsis declares it as explicit, I'll prod the editor to add it to the
description of that constructor too.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_2938_23890816.1366714244082
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, April 23, 2013 11:15:51 AM UTC+1, Nicol Bolas wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">In <a href=3D"http://isocpp.org/f=
iles/papers/N3662.html#dynarray.cons" target=3D"_blank">dynarray's construc=
tor that takes a `size_type`</a>, the current wording states:<br><br><block=
quote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex" class=3D"gmail_quote">Allocates storage for <var>c</v=
ar> elements.
May or may not invoke the global <code>operator new</code>.
The <tt>c</tt> elements of the dynarray are default-initialized (8.5).
<br></blockquote><br>All other containers value-initialize their contents. =
If we're not going to allow default-initialization in `std::vector`, we sho=
uldn't allow default-initialization in `dynarray`. And vice-versa: if we're=
 going to allow `dynarray` to default-initialize its contents, we should al=
low `vector` to do the same.<br></blockquote><div><br>But that is consisten=
t with default-initializing a std::array of&nbsp; n elements (the differenc=
e being that n is part of the type for std::array and a constructor paramet=
er for std::dynarray, which is the whole point of dynarray.)<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><br>I would really rather not h=
ave to use a `dynarray` where I would have preferred a `vector`, just becau=
se it allows default initialization of its contents and `vector` does not.<=
br></blockquote><div><br>std::dynarray is closer in spirit to std::array, n=
ot std::vector (which is why I dislike it supporting allocators, if you nee=
d the full power of an allocator-aware sequence container with all the comp=
lexity that entails then use std::vector, not std::dynarray.)<br>&nbsp;<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Also, this construct=
or should probably be `explicit`.<br></blockquote><div><br>The synopsis dec=
lares it as explicit, I'll prod the editor to add it to the description of =
that constructor too.<br>&nbsp;<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2938_23890816.1366714244082--

.

On Apr 23, 2013, at 11:50 AM, Jonathan Wakely <cxx@kayari.org> wrote:

> std::dynarray is closer in spirit to std::array, not std::vector (which i=
s why I dislike it supporting allocators, if you need the full power of an =
allocator-aware sequence container with all the complexity that entails the=
n use std::vector, not std::dynarray.)

If it supports allocators, it should use the construct method from the
allocator (which is a pain for the common use case).
 --
 Nevin ":-)" Liber
 <mailto:nevin@eviloverlord.com>
 (847) 691-1404
(sent from my iPad)

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

------=_Part_3079_8954964.1366719539780
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, April 23, 2013 12:58:39 PM UTC+1, Nevin ":-)" Liber wrote:
>
> On Apr 23, 2013, at 11:50 AM, Jonathan Wakely <c...@kayari.org<javascript:>>
> wrote:
>
> > std::dynarray is closer in spirit to std::array, not std::vector (which
> is why I dislike it supporting allocators, if you need the full power of an
> allocator-aware sequence container with all the complexity that entails
> then use std::vector, not std::dynarray.)
>
> If it supports allocators, it should use the construct method from the
> allocator (which is a pain for the common use case).
>

That would be true if it's an allocator-aware container, but it can't be
because it doesn't define allocator_type.

The requirement that "each element is constructed with uses-allocator
construction" is roughly equivalent (it uses allocator_traits and allows
scoped allocators to add themselves to the constructor arguments) and only
applies to the constructors taking an allocator, so imposes no burden on
the constructors without an allocator (the common use case.)  So I don't
think the constructors without allocators should be required to use the
construct() method, and will object strongly to imposing such a requirement.



--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_3079_8954964.1366719539780
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Tuesday, April 23, 2013 12:58:39 PM UTC+1, Nevin ":-)" Liber wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Apr 23, 2013, at 11:50 A=
M, Jonathan Wakely &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"bj7PZ5pa4FMJ">c...@kayari.org</a>&gt; wrote:
<br>
<br>&gt; std::dynarray is closer in spirit to std::array, not std::vector (=
which is why I dislike it supporting allocators, if you need the full power=
 of an allocator-aware sequence container with all the complexity that enta=
ils then use std::vector, not std::dynarray.)
<br>
<br>If it supports allocators, it should use the construct method from the
<br>allocator (which is a pain for the common use case).
<br></blockquote><div><br></div>That would be true if it's an allocator-awa=
re container, but it can't be because it doesn't define allocator_type.<br>=
<br>The requirement that "each element is constructed
with uses-allocator construction" is roughly equivalent (it uses allocator_=
traits and allows scoped allocators to add themselves to the constructor ar=
guments) and only applies to the constructors taking an allocator, so impos=
es no burden on the constructors without an allocator (the common use case.=
)&nbsp; So I don't think the constructors without allocators should be requ=
ired to use the construct() method, and will object strongly to imposing su=
ch a requirement.<br><br><br><br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3079_8954964.1366719539780--

.

2013/4/23 Jonathan Wakely <cxx@kayari.org>:
>
>
> On Tuesday, April 23, 2013 12:58:39 PM UTC+1, Nevin ":-)" Liber wrote:
>>
>> On Apr 23, 2013, at 11:50 AM, Jonathan Wakely <c...@kayari.org> wrote:
>>
>> > std::dynarray is closer in spirit to std::array, not std::vector (which
>> > is why I dislike it supporting allocators, if you need the full power of an
>> > allocator-aware sequence container with all the complexity that entails then
>> > use std::vector, not std::dynarray.)
>>
>> If it supports allocators, it should use the construct method from the
>> allocator (which is a pain for the common use case).
>
> That would be true if it's an allocator-aware container, but it can't be
> because it doesn't define allocator_type.
>
> The requirement that "each element is constructed with uses-allocator
> construction" is roughly equivalent (it uses allocator_traits and allows
> scoped allocators to add themselves to the constructor arguments) and only
> applies to the constructors taking an allocator, so imposes no burden on the
> constructors without an allocator (the common use case.)  So I don't think
> the constructors without allocators should be required to use the
> construct() method, and will object strongly to imposing such a requirement.

In addition to what Jonathan describes: uses_allocator construction
always only calls a (somehow selected) constructor of T, therefore
cleanup via the destructor of T is the correct counter-part. If an
object of type T would be created by allocator-construct, it really
should use cleanup via allocator-destroy. Since dynarray does not
store an allocator, it really should not calling construct, especially
if this is not backed by a corresponding destroy.

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.