------=_Part_5941_926231054.1503260569096
Content-Type: multipart/alternative;
 boundary="----=_Part_5942_1624128054.1503260569096"

------=_Part_5942_1624128054.1503260569096
Content-Type: text/plain; charset="UTF-8"

One performance problem with std::vector is that elements are always
default constructed with resize().
While this can be avoided by using a custom allocator, the problem is that
this optimization is unavailable for templates that need to work regardless
of the underlying allocator type. (so, where your template is provided the
vector, and you don't have control of the vector)
My motivating example consists of a serialization routine. Ideally, the
serialization routine would expand the vector uninitialized and then write
the data in. This can't be done however, because the resize function writes
0s to the data thanks to the default allocator's construct method.
While the reserve function might help to avoid reallocations, it doesn't
stop the checks against capacity and repetitive increments to the size
variable.

void * std::vector<T, Alloc>::expand_uninitialized(size_t n);

This function works like resize(size() + n), but it is the caller's
responsibility to call the Allocator::construct method on each element
before other operations on the vector. The function returns the beginning
of uninitialized memory.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/405bc3a4-4fbf-41af-b213-b24894ba2f6e%40isocpp.org.

------=_Part_5942_1624128054.1503260569096
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">One performance problem with std::vector is that elements =
are always default constructed with resize().<br>While this can be avoided =
 by using a custom allocator, the problem is that this optimization is unav=
ailable for templates that need to work regardless of the underlying alloca=
tor type. (so, where your template is provided the vector, and you don&#39;=
t have control of the vector)<br>My motivating example consists of a serial=
ization routine. Ideally, the serialization routine would expand the vector=
 uninitialized and then write the data in. This can&#39;t be done however, =
because the resize function writes 0s to the data thanks to the default all=
ocator&#39;s construct method.<br>While the reserve function might help to =
avoid reallocations, it doesn&#39;t stop the checks against capacity and re=
petitive increments to the size variable.<br><br><div style=3D"background-c=
olor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: s=
olid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">vector</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Alloc</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">expand_uninitialized</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">size_t n</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>This function wor=
ks like resize(size() + n), but it is the caller&#39;s responsibility to ca=
ll the Allocator::construct method on each element before other operations =
on the vector. The function returns the beginning of uninitialized memory.<=
br></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/405bc3a4-4fbf-41af-b213-b24894ba2f6e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/405bc3a4-4fbf-41af-b213-b24894ba2f6e=
%40isocpp.org</a>.<br />

------=_Part_5942_1624128054.1503260569096--

------=_Part_5941_926231054.1503260569096--

.

------=_Part_5666_720986361.1503263775112
Content-Type: multipart/alternative;
 boundary="----=_Part_5667_1713202019.1503263775112"

------=_Part_5667_1713202019.1503263775112
Content-Type: text/plain; charset="UTF-8"

On Sunday, August 20, 2017 at 4:22:49 PM UTC-4, Ryan Nicholl wrote:
>
> One performance problem with std::vector is that elements are always
> default constructed with resize().
> While this can be avoided by using a custom allocator, the problem is that
> this optimization is unavailable for templates that need to work regardless
> of the underlying allocator type. (so, where your template is provided the
> vector, and you don't have control of the vector)
> My motivating example consists of a serialization routine. Ideally, the
> serialization routine would expand the vector uninitialized and then write
> the data in. This can't be done however, because the resize function writes
> 0s to the data thanks to the default allocator's construct method.
> While the reserve function might help to avoid reallocations, it doesn't
> stop the checks against capacity and repetitive increments to the size
> variable.
>
> void * std::vector<T, Alloc>::expand_uninitialized(size_t n);
>
> This function works like resize(size() + n), but it is the caller's
> responsibility to call the Allocator::construct method on each element
> before other operations on the vector. The function returns the beginning
> of uninitialized memory.
>

So... what does `vector::size/begin/end` return? Because until you actually
*construct* those `T`s, for `vector` to include those elements in the
actual range makes `vector` lie. And it invokes UB, since you *cannot*
iterate over `T*`s that don't exist.

It'd make a lot more sense just to give us a way to invoke default
initialization. People keep trying to solve to problem without actually *solving
the problem*.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7999d17b-59a0-401f-8d74-40c5fd5a8419%40isocpp.org.

------=_Part_5667_1713202019.1503263775112
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, August 20, 2017 at 4:22:49 PM UTC-4, Ryan Nicho=
ll wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">One =
performance problem with std::vector is that elements are always default co=
nstructed with resize().<br>While this can be avoided  by using a custom al=
locator, the problem is that this optimization is unavailable for templates=
 that need to work regardless of the underlying allocator type. (so, where =
your template is provided the vector, and you don&#39;t have control of the=
 vector)<br>My motivating example consists of a serialization routine. Idea=
lly, the serialization routine would expand the vector uninitialized and th=
en write the data in. This can&#39;t be done however, because the resize fu=
nction writes 0s to the data thanks to the default allocator&#39;s construc=
t method.<br>While the reserve function might help to avoid reallocations, =
it doesn&#39;t stop the checks against capacity and repetitive increments t=
o the size variable.<br><br><div style=3D"background-color:rgb(250,250,250)=
;border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><=
div><span style=3D"color:#008">void</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">*</span><span style=3D"color:#000"> std</span>=
<span style=3D"color:#660">::</span><span style=3D"color:#000">vector</span=
><span style=3D"color:#660">&lt;</span><span style=3D"color:#000">T</span><=
span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span =
style=3D"color:#606">Alloc</span><span style=3D"color:#660">&gt;::</span><s=
pan style=3D"color:#000">expand_uninitialized</span><span style=3D"color:#6=
60">(</span><span style=3D"color:#000">s<wbr>ize_t n</span><span style=3D"c=
olor:#660">);</span><span style=3D"color:#000"><br></span></div></code></di=
v><br>This function works like resize(size() + n), but it is the caller&#39=
;s responsibility to call the Allocator::construct method on each element b=
efore other operations on the vector. The function returns the beginning of=
 uninitialized memory.<br></div></blockquote><div><br>So... what does `vect=
or::size/begin/end` return? Because until you actually <i>construct</i> tho=
se `T`s, for `vector` to include those elements in the actual range makes `=
vector` lie. And it invokes UB, since you <i>cannot</i> iterate over `T*`s =
that don&#39;t exist.<br><br>It&#39;d make a lot more sense just to give us=
 a way to invoke default initialization. People keep trying to solve to pro=
blem without actually <i>solving the problem</i>.<br></div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7999d17b-59a0-401f-8d74-40c5fd5a8419%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7999d17b-59a0-401f-8d74-40c5fd5a8419=
%40isocpp.org</a>.<br />

------=_Part_5667_1713202019.1503263775112--

------=_Part_5666_720986361.1503263775112--

.

--f403045cd788ec6c38055737e739
Content-Type: text/plain; charset="UTF-8"

On Sun, Aug 20, 2017 at 3:22 PM, Ryan Nicholl <r.p.nicholl@gmail.com> wrote:

> My motivating example consists of a serialization routine. Ideally, the
> serialization routine would expand the vector uninitialized and then write
> the data in. This can't be done however, because the resize function writes
> 0s to the data thanks to the default allocator's construct method.
>

Breaking vector's invariants is a non-starter for me.  I would be strongly
against such a beast.

This function works like resize(size() + n), but it is the caller's
> responsibility to call the Allocator::construct method on each element
> before other operations on the vector. The function returns the beginning
> of uninitialized memory.
>

Please write the exception safe code which uses this.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNaiJZp3npwCP2BrKjR%2Be5Vd1AQp7xdjNLSyXTjH7i41g%40mail.gmail.com.

--f403045cd788ec6c38055737e739
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sun, Aug 20, 2017 at 3:22 PM, Ryan Nicholl <span dir=3D=
"ltr">&lt;<a href=3D"mailto:r.p.nicholl@gmail.com" target=3D"_blank">r.p.ni=
choll@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">My moti=
vating example consists of a serialization routine. Ideally, the serializat=
ion routine would expand the vector uninitialized and then write the data i=
n. This can&#39;t be done however, because the resize function writes 0s to=
 the data thanks to the default allocator&#39;s construct method.<br></div>=
</blockquote><div><br></div><div>Breaking vector&#39;s invariants is a non-=
starter for me.=C2=A0 I would be strongly against such a beast.</div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This function work=
s like resize(size() + n), but it is the caller&#39;s responsibility to cal=
l the Allocator::construct method on each element before other operations o=
n the vector. The function returns the beginning of uninitialized memory.</=
div></blockquote><div><br></div><div>Please write the exception safe code w=
hich uses this.</div></div>-- <br><div class=3D"gmail_signature" data-smart=
mail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0=
Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-6=
91-1404</div></div></div></div></div>
</div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNaiJZp3npwCP2BrKjR%2Be5Vd1AQ=
p7xdjNLSyXTjH7i41g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNaiJ=
Zp3npwCP2BrKjR%2Be5Vd1AQp7xdjNLSyXTjH7i41g%40mail.gmail.com</a>.<br />

--f403045cd788ec6c38055737e739--

.

On 20.08.2017 22:22, Ryan Nicholl wrote:
> My motivating example consists of a serialization routine. Ideally, the
> serialization routine would expand the vector uninitialized and then
> write the data in. This can't be done however, because the resize
> function writes 0s to the data thanks to the default allocator's
> construct method.

Could you clarify why reserve + push_back() doesn't work here?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0304ee31-d873-25a5-1ff9-3364e76dff67%40gmail.com.

.

--001a114c71f8f034dc05574d6319
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+1. Really looks like a reserve() use-case to me.

2017-08-21 4:29 GMT-04:00 Jonathan M=C3=BCller <jonathanmueller.dev@gmail.c=
om>:

> On 20.08.2017 22:22, Ryan Nicholl wrote:
>
>> My motivating example consists of a serialization routine. Ideally, the
>> serialization routine would expand the vector uninitialized and then wri=
te
>> the data in. This can't be done however, because the resize function wri=
tes
>> 0s to the data thanks to the default allocator's construct method.
>>
>
> Could you clarify why reserve + push_back() doesn't work here?
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/0304ee31-d873-25a5-1ff9-
> 3364e76dff67%40gmail.com.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAKiZDp151PprK6Q_Gajnyh0URotphRK98M154jjPQEjAUOk=
X4Q%40mail.gmail.com.

--001a114c71f8f034dc05574d6319
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">+1. Really looks like a reserve() use-case to me.<br></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-08-21 4:29 =
GMT-04:00 Jonathan M=C3=BCller <span dir=3D"ltr">&lt;<a href=3D"mailto:jona=
thanmueller.dev@gmail.com" target=3D"_blank">jonathanmueller.dev@gmail.com<=
/a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 20.08=
..2017 22:22, Ryan Nicholl wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
My motivating example consists of a serialization routine. Ideally, the ser=
ialization routine would expand the vector uninitialized and then write the=
 data in. This can&#39;t be done however, because the resize function write=
s 0s to the data thanks to the default allocator&#39;s construct method.<br=
>
</blockquote>
<br></span>
Could you clarify why reserve + push_back() doesn&#39;t work here?<span cla=
ss=3D""><br>
<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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0304ee31-d873-25a5-1ff9-3364e76dff67%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/0304ee31-d873-25a5-1ff9-<wbr>=
3364e76dff67%40gmail.com</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp151PprK6Q_Gajnyh0URotphRK98M15=
4jjPQEjAUOkX4Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp151PprK6Q_=
Gajnyh0URotphRK98M154jjPQEjAUOkX4Q%40mail.gmail.com</a>.<br />

--001a114c71f8f034dc05574d6319--

.

------=_Part_7769_1398986133.1503366386239
Content-Type: multipart/alternative;
 boundary="----=_Part_7770_1460825058.1503366386240"

------=_Part_7770_1460825058.1503366386240
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Monday, August 21, 2017 at 9:19:46 PM UTC-4, Patrice Roy wrote:
>
> +1. Really looks like a reserve() use-case to me.
>
> 2017-08-21 4:29 GMT-04:00 Jonathan M=C3=BCller <jonathanm...@gmail.com=20
> <javascript:>>:
>
>> On 20.08.2017 22:22, Ryan Nicholl wrote:
>>
>>> My motivating example consists of a serialization routine. Ideally, the=
=20
>>> serialization routine would expand the vector uninitialized and then wr=
ite=20
>>> the data in. This can't be done however, because the resize function wr=
ites=20
>>> 0s to the data thanks to the default allocator's construct method.
>>>
>>
>> Could you clarify why reserve + push_back() doesn't work here?
>>
>
I expect it's the reason he stated: he wants to prevent the value=20
initialization of the object, since he's going to initialize it from the=20
serialization routine. He wants to avoid the double-initialization.

Again, that's a reason to allow default initialization, not to do what he=
=20
suggests.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/38511f1a-5d75-4c95-a240-89e19a03bbe6%40isocpp.or=
g.

------=_Part_7770_1460825058.1503366386240
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, August 21, 2017 at 9:19:46 PM UTC-4, Pa=
trice Roy wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">+1. Really looks like a reserve() use-case to me.<br></div><div><br><div=
 class=3D"gmail_quote">2017-08-21 4:29 GMT-04:00 Jonathan M=C3=BCller <span=
 dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"6q72mOxdCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;">jonathanm...@gmail.com</a><wbr>&gt;</span>:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><span>On 20.08.2017 22:22, Ryan Nicholl wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
My motivating example consists of a serialization routine. Ideally, the ser=
ialization routine would expand the vector uninitialized and then write the=
 data in. This can&#39;t be done however, because the resize function write=
s 0s to the data thanks to the default allocator&#39;s construct method.<br=
>
</blockquote>
<br></span>
Could you clarify why reserve + push_back() doesn&#39;t work here?<span></s=
pan><br></blockquote></div></div></blockquote><div><br>I expect it&#39;s th=
e reason he stated: he wants to prevent the value initialization of the obj=
ect, since he&#39;s going to initialize it from the serialization routine. =
He wants to avoid the double-initialization.<br><br>Again, that&#39;s a rea=
son to allow default initialization, not to do what he suggests. <br></div>=
</div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/38511f1a-5d75-4c95-a240-89e19a03bbe6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/38511f1a-5d75-4c95-a240-89e19a03bbe6=
%40isocpp.org</a>.<br />

------=_Part_7770_1460825058.1503366386240--

------=_Part_7769_1398986133.1503366386239--

.

On 2017-08-22 13:46, Nicol Bolas wrote:
>=20
>=20
> On Monday, August 21, 2017 at 9:19:46 PM UTC-4, Patrice Roy wrote:
>=20
>     +1. Really looks like a reserve() use-case to me.
>=20
>     2017-08-21 4:29 GMT-04:00 Jonathan M=C3=BCller <jonathanm...@gmail.co=
m
>     <javascript:>>:
>=20
>         On 20.08.2017 22:22, Ryan Nicholl wrote:
>=20
>             My motivating example consists of a serialization routine.
>             Ideally, the serialization routine would expand the vector
>             uninitialized and then write the data in. This can't be done
>             however, because the resize function writes 0s to the data
>             thanks to the default allocator's construct method.
>=20
>=20
>         Could you clarify why reserve + push_back() doesn't work here?
>=20
>=20
> I expect it's the reason he stated: he wants to prevent the value=20
> initialization of the object, since he's going to initialize it from the=
=20
> serialization routine. He wants to avoid the double-initialization.
>=20
> Again, that's a reason to allow default initialization, not to do what=20
> he suggests.

Isn't that why we have emplace_back()?

Ross Smith


--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a3ad5bed-1f56-bdb7-d020-5361be8c186c%40otoy.com.

.

------=_Part_7634_1578749786.1503373433477
Content-Type: multipart/alternative;
 boundary="----=_Part_7635_1660199952.1503373433477"

------=_Part_7635_1660199952.1503373433477
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Monday, August 21, 2017 at 10:09:43 PM UTC-4, Ross Smith wrote:
>
> On 2017-08-22 13:46, Nicol Bolas wrote:=20
> >=20
> >=20
> > On Monday, August 21, 2017 at 9:19:46 PM UTC-4, Patrice Roy wrote:=20
> >=20
> >     +1. Really looks like a reserve() use-case to me.=20
> >=20
> >     2017-08-21 4:29 GMT-04:00 Jonathan M=C3=BCller <jonathanm...@gmail.=
com=20
> >     <javascript:>>:=20
> >=20
> >         On 20.08.2017 22:22, Ryan Nicholl wrote:=20
> >=20
> >             My motivating example consists of a serialization routine.=
=20
> >             Ideally, the serialization routine would expand the vector=
=20
> >             uninitialized and then write the data in. This can't be don=
e=20
> >             however, because the resize function writes 0s to the data=
=20
> >             thanks to the default allocator's construct method.=20
> >=20
> >=20
> >         Could you clarify why reserve + push_back() doesn't work here?=
=20
> >=20
> >=20
> > I expect it's the reason he stated: he wants to prevent the value=20
> > initialization of the object, since he's going to initialize it from th=
e=20
> > serialization routine. He wants to avoid the double-initialization.=20
> >=20
> > Again, that's a reason to allow default initialization, not to do what=
=20
> > he suggests.=20
>
> Isn't that why we have emplace_back()?
>

Which:

1) Doesn't work on aggregate=20
<http://cplusplus.github.io/LWG/lwg-active.html#2089>s, except by=20
whole-object copy/move.

2) Requires the code doing the initialization to know about both `vector`=
=20
and `emplace_back`. Consider the case of calling a C routine to fill in an=
=20
array of integers.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/67cb16a7-2f87-4ce4-aa28-7edf8a588418%40isocpp.or=
g.

------=_Part_7635_1660199952.1503373433477
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, August 21, 2017 at 10:09:43 PM UTC-4, Ross Smit=
h wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-08-22 13:46, N=
icol Bolas wrote:
<br>&gt;=20
<br>&gt;=20
<br>&gt; On Monday, August 21, 2017 at 9:19:46 PM UTC-4, Patrice Roy wrote:
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 +1. Really looks like a reserve() use-case to me.
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 2017-08-21 4:29 GMT-04:00 Jonathan M=C3=BCller &lt;<=
a>jonathanm...@gmail.com</a>
<br>&gt; =C2=A0 =C2=A0 &lt;javascript:&gt;&gt;:
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 20.08.2017 22:22, Ryan Nicholl wrot=
e:
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 My motivating example co=
nsists of a serialization routine.
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ideally, the serializati=
on routine would expand the vector
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uninitialized and then w=
rite the data in. This can&#39;t be done
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 however, because the res=
ize function writes 0s to the data
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 thanks to the default al=
locator&#39;s construct method.
<br>&gt;=20
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 Could you clarify why reserve + push_b=
ack() doesn&#39;t work here?
<br>&gt;=20
<br>&gt;=20
<br>&gt; I expect it&#39;s the reason he stated: he wants to prevent the va=
lue=20
<br>&gt; initialization of the object, since he&#39;s going to initialize i=
t from the=20
<br>&gt; serialization routine. He wants to avoid the double-initialization=
..
<br>&gt;=20
<br>&gt; Again, that&#39;s a reason to allow default initialization, not to=
 do what=20
<br>&gt; he suggests.
<br>
<br>Isn&#39;t that why we have emplace_back()?<br></blockquote><div><br>Whi=
ch:<br><br>1) <a href=3D"http://cplusplus.github.io/LWG/lwg-active.html#208=
9">Doesn&#39;t work on aggregate</a>s, except by whole-object copy/move.<br=
><br>2) Requires the code doing the initialization to know about both `vect=
or` and `emplace_back`. Consider the case of calling a C routine to fill in=
 an array of integers.<br></div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/67cb16a7-2f87-4ce4-aa28-7edf8a588418%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/67cb16a7-2f87-4ce4-aa28-7edf8a588418=
%40isocpp.org</a>.<br />

------=_Part_7635_1660199952.1503373433477--

------=_Part_7634_1578749786.1503373433477--

.

------=_Part_8123_1632094126.1503394976638
Content-Type: multipart/alternative;
 boundary="----=_Part_8124_544072712.1503394976639"

------=_Part_8124_544072712.1503394976639
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8A=E5=8D=889:46:26=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
>
>
> On Monday, August 21, 2017 at 9:19:46 PM UTC-4, Patrice Roy wrote:
>>
>> +1. Really looks like a reserve() use-case to me.
>>
>> 2017-08-21 4:29 GMT-04:00 Jonathan M=C3=BCller <jonathanm...@gmail.com>:
>>
>>> On 20.08.2017 22:22, Ryan Nicholl wrote:
>>>
>>>> My motivating example consists of a serialization routine. Ideally, th=
e=20
>>>> serialization routine would expand the vector uninitialized and then w=
rite=20
>>>> the data in. This can't be done however, because the resize function w=
rites=20
>>>> 0s to the data thanks to the default allocator's construct method.
>>>>
>>>
>>> Could you clarify why reserve + push_back() doesn't work here?
>>>
>>
> I expect it's the reason he stated: he wants to prevent the value=20
> initialization of the object, since he's going to initialize it from the=
=20
> serialization routine. He wants to avoid the double-initialization.
>
> Again, that's a reason to allow default initialization, not to do what he=
=20
> suggests.=20
>

Why? Is it really necessary and intended to avoid uninitialized object=20
owned by vector directly without allocator hacks and/or changing of element=
=20
types (which are both likely to cause a change on the container type) by=20
design?

Also note that the internal state update can be different, even it is not=
=20
always observable for a vector (which may have no size field stored at=20
all). It is not merely a QoI problem because it do effect semantics of API.=
=20
Here, each 'push_back' call enforced a requirement of maintenance on the=20
invariant of equality between 'size()' result (as a public interface) and=
=20
count of initialized elements. Such maintenance is redundant as per the=20
zero overhead principle when applied on abstract machine semantics - there=
=20
is yet no guarantee to ensure it is without any additional cost. OTOH, a=20
transnational-styled operation of bulk updates can be preferred to reflect=
=20
the intent more precisely in such cases.


--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2e2acdaf-58ae-4be9-a541-28d0291a09d4%40isocpp.or=
g.

------=_Part_8124_544072712.1503394976639
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=E5=8D=889:46:26=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><br><br>On Monday, August 21, 2017 at 9:19:46 PM UTC-4, Patrice =
Roy wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">+1. Real=
ly looks like a reserve() use-case to me.<br></div><div><br><div class=3D"g=
mail_quote">2017-08-21 4:29 GMT-04:00 Jonathan M=C3=BCller <span dir=3D"ltr=
">&lt;<a rel=3D"nofollow">jonathanm...@gmail.com</a>&gt;</span>:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span>On 20.08.2017 22:22, Ryan Nicholl wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
My motivating example consists of a serialization routine. Ideally, the ser=
ialization routine would expand the vector uninitialized and then write the=
 data in. This can&#39;t be done however, because the resize function write=
s 0s to the data thanks to the default allocator&#39;s construct method.<br=
>
</blockquote>
<br></span>
Could you clarify why reserve + push_back() doesn&#39;t work here?<span></s=
pan><br></blockquote></div></div></blockquote><div><br>I expect it&#39;s th=
e reason he stated: he wants to prevent the value initialization of the obj=
ect, since he&#39;s going to initialize it from the serialization routine. =
He wants to avoid the double-initialization.<br><br>Again, that&#39;s a rea=
son to allow default initialization, not to do what he suggests. <br></div>=
</div></blockquote><div><br></div><div>Why? Is it really necessary and inte=
nded to avoid uninitialized object owned by vector directly without allocat=
or hacks and/or changing of element types (which are both likely to cause a=
 change on the container type) by design?</div><div><br></div><div>Also not=
e that the internal state update can be different, even it is not always ob=
servable for a vector (which may have no size field stored at all). It is n=
ot merely a QoI problem because it do effect semantics of API. Here, each &=
#39;push_back&#39; call enforced a requirement of maintenance on the invari=
ant of equality between &#39;size()&#39; result (as a public interface) and=
 count of initialized elements. Such maintenance  is redundant as per the z=
ero overhead principle when applied on abstract machine semantics - there i=
s yet no guarantee to ensure it is without any additional cost. OTOH, a tra=
nsnational-styled operation of bulk updates can be preferred to reflect the=
 intent more precisely in such cases.<br></div><div><br></div><br></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2e2acdaf-58ae-4be9-a541-28d0291a09d4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2e2acdaf-58ae-4be9-a541-28d0291a09d4=
%40isocpp.org</a>.<br />

------=_Part_8124_544072712.1503394976639--

------=_Part_8123_1632094126.1503394976638--

.

------=_Part_8625_323405099.1503411390711
Content-Type: multipart/alternative;
 boundary="----=_Part_8626_2074636164.1503411390711"

------=_Part_8626_2074636164.1503411390711
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tuesday, August 22, 2017 at 5:42:56 AM UTC-4, FrankHB1989 wrote:
>
> =E5=9C=A8 2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C U=
TC+8=E4=B8=8A=E5=8D=889:46:26=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> On Monday, August 21, 2017 at 9:19:46 PM UTC-4, Patrice Roy wrote:
>>>
>>> +1. Really looks like a reserve() use-case to me.
>>>
>>> 2017-08-21 4:29 GMT-04:00 Jonathan M=C3=BCller <jonathanm...@gmail.com>=
:
>>>
>>>> On 20.08.2017 22:22, Ryan Nicholl wrote:
>>>>
>>>>> My motivating example consists of a serialization routine. Ideally,=
=20
>>>>> the serialization routine would expand the vector uninitialized and t=
hen=20
>>>>> write the data in. This can't be done however, because the resize fun=
ction=20
>>>>> writes 0s to the data thanks to the default allocator's construct met=
hod.
>>>>>
>>>>
>>>> Could you clarify why reserve + push_back() doesn't work here?
>>>>
>>>
>> I expect it's the reason he stated: he wants to prevent the value=20
>> initialization of the object, since he's going to initialize it from the=
=20
>> serialization routine. He wants to avoid the double-initialization.
>>
>> Again, that's a reason to allow default initialization, not to do what h=
e=20
>> suggests.=20
>>
>
> Why? Is it really necessary and intended to avoid uninitialized object=20
> owned by vector directly without allocator hacks and/or changing of eleme=
nt=20
> types (which are both likely to cause a change on the container type) by=
=20
> design?
>

It's not "necessary", in the sense that we could avoid it. I appreciate the=
=20
desire to address the problem; what I don't like is these particular *means=
*.=20
It effectively breaks `vector`, since its size would have to include=20
objects that don't exist. Plus, C++ doesn't allow you to do pointer=20
arithmetic across objects that don't exist. You can only do pointer=20
arithmetic over arrays, and arrays require that all of their subobjects=20
actually are real, live objects.

Default initialization is a real process in C++ which creates real, live=20
objects. It can be used in placement new expressions; as such, there is no=
=20
technical reason why default initialization cannot be used to solve this=20
problem. Those objects would actually exist, and therefore it wouldn't=20
break the C++ object model or the meaning of `vector`.

The current issue is that there's no way to communicate that you *want*=20
default initialization rather than value initialization. So let's fix *that=
*=20
<https://github.com/NicolBolas/Proposal-Ideas/blob/master/Default%20Initial=
izer%20Value.md>,=20
and the rest will take care of itself.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c0fab574-25e3-4e14-8728-f4af550d6626%40isocpp.or=
g.

------=_Part_8626_2074636164.1503411390711
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 22, 2017 at 5:42:56 AM UTC-4, FrankHB19=
89 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=E5=
=9C=A8 2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=
=E4=B8=8A=E5=8D=889:46:26=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, August 21,=
 2017 at 9:19:46 PM UTC-4, Patrice Roy wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">+1. Really looks like a reserve() use-case to me=
..<br></div><div><br><div class=3D"gmail_quote">2017-08-21 4:29 GMT-04:00 Jo=
nathan M=C3=BCller <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jonathanm...@g=
mail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 20.08.2=
017 22:22, Ryan Nicholl wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
My motivating example consists of a serialization routine. Ideally, the ser=
ialization routine would expand the vector uninitialized and then write the=
 data in. This can&#39;t be done however, because the resize function write=
s 0s to the data thanks to the default allocator&#39;s construct method.<br=
>
</blockquote>
<br></span>
Could you clarify why reserve + push_back() doesn&#39;t work here?<span></s=
pan><br></blockquote></div></div></blockquote><div><br>I expect it&#39;s th=
e reason he stated: he wants to prevent the value initialization of the obj=
ect, since he&#39;s going to initialize it from the serialization routine. =
He wants to avoid the double-initialization.<br><br>Again, that&#39;s a rea=
son to allow default initialization, not to do what he suggests. <br></div>=
</div></blockquote><div><br></div><div>Why? Is it really necessary and inte=
nded to avoid uninitialized object owned by vector directly without allocat=
or hacks and/or changing of element types (which are both likely to cause a=
 change on the container type) by design?</div></div></blockquote><div><br>=
It&#39;s not &quot;necessary&quot;, in the sense that we could avoid it. I =
appreciate the desire to address the problem; what I don&#39;t like is thes=
e particular <i>means</i>. It effectively breaks `vector`, since its size w=
ould have to include objects that don&#39;t exist. Plus, C++ doesn&#39;t al=
low you to do pointer arithmetic across objects that don&#39;t exist. You c=
an only do pointer arithmetic over arrays, and arrays require that all of t=
heir subobjects actually are real, live objects.<br><br>Default initializat=
ion is a real process in C++ which creates real, live objects. It can be us=
ed in placement new expressions; as such, there is no technical reason why =
default initialization cannot be used to solve this problem. Those objects =
would actually exist, and therefore it wouldn&#39;t break the C++ object mo=
del or the meaning of `vector`.<br><br>The current issue is that there&#39;=
s no way to communicate that you <i>want</i> default initialization rather =
than value initialization. So <a href=3D"https://github.com/NicolBolas/Prop=
osal-Ideas/blob/master/Default%20Initializer%20Value.md">let&#39;s fix <i>t=
hat</i></a>, and the rest will take care of itself.</div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c0fab574-25e3-4e14-8728-f4af550d6626%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c0fab574-25e3-4e14-8728-f4af550d6626=
%40isocpp.org</a>.<br />

------=_Part_8626_2074636164.1503411390711--

------=_Part_8625_323405099.1503411390711--

.

On 22 August 2017 at 17:16, Nicol Bolas <jmckesson@gmail.com> wrote:
>>> Again, that's a reason to allow default initialization, not to do what he
>>> suggests.
>>
>>
>> Why? Is it really necessary and intended to avoid uninitialized object
>> owned by vector directly without allocator hacks and/or changing of element
>> types (which are both likely to cause a change on the container type) by
>> design?
>
>
> It's not "necessary", in the sense that we could avoid it. I appreciate the
> desire to address the problem; what I don't like is these particular means.
> It effectively breaks `vector`, since its size would have to include objects
> that don't exist. Plus, C++ doesn't allow you to do pointer arithmetic
> across objects that don't exist. You can only do pointer arithmetic over
> arrays, and arrays require that all of their subobjects actually are real,
> live objects.
>
> Default initialization is a real process in C++ which creates real, live
> objects. It can be used in placement new expressions; as such, there is no
> technical reason why default initialization cannot be used to solve this
> problem. Those objects would actually exist, and therefore it wouldn't break
> the C++ object model or the meaning of `vector`.
>
> The current issue is that there's no way to communicate that you want
> default initialization rather than value initialization. So let's fix that,
> and the rest will take care of itself.


It seems to me that we might want to consider adding a building block
of lower level than
vector. vector has always been a compromise, with certain overhead in
some of its operations.
Perhaps we should have a dynamic buffer that's not trying to be safe
to use, and makes
no compromises on speed. Such a type can still do automatic cleanup
and automatic
buffer growth, so it would not be just a raw array.

The reason for that suggestion is that different use cases use
different trade-offs, and it's
difficult to cover a significant fraction of the various use cases,
but at least we could perhaps
provide a low-level utility that can be a building block for all of
them. Trying to fix vector's performance
problems one by one runs the risk of breaking vector's class
invariants, which (all of them) somebody
somewhere is bound to rely on, so I'd expect fair amounts of
resistance to such an approach.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb7vE7YSChtdbfNfYm3V1ZkJWAmoRfYWjT7ApnvHwS3Hw%40mail.gmail.com.

.

--94eb2c1197ba528341055758c2d0
Content-Type: text/plain; charset="UTF-8"

On Tue, Aug 22, 2017 at 9:34 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> Trying to fix vector's performance
> problems one by one runs the risk of breaking vector's class
> invariants, which (all of them) somebody
> somewhere is bound to rely on, so I'd expect fair amounts of
> resistance to such an approach.


Nicol isn't breaking vector's invariants with his proposal.  He is looking
to add default-initialization in addition to the normal zero-initialization
usually performed with allocators; for classes with default constructors,
there is no difference.  One thing that bugs me about his proposal is that
he is changing allocator_traits from a class which always forwards to the
allocator if it can into a class which will always perform
default-initialization in this one case.

This isn't to say that there shouldn't be a low-level utility, but I'd
still like to have this functionality as well, without having to resort to
a custom allocator, and definitely without breaking vector's invariants.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM%2BfCjSm5RQGStWXaAegpx0kZsnNw%3Deojvoqnw6SCh-tQ%40mail.gmail.com.

--94eb2c1197ba528341055758c2d0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Aug 22, 2017 at 9:34 AM, Ville Voutilainen <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bl=
ank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Trying =
to fix vector&#39;s performance<br>
problems one by one runs the risk of breaking vector&#39;s class<br>
invariants, which (all of them) somebody<br>
somewhere is bound to rely on, so I&#39;d expect fair amounts of<br>
resistance to such an approach.</blockquote><div><br></div><div>Nicol isn&#=
39;t breaking vector&#39;s invariants with his proposal.=C2=A0 He is lookin=
g to add default-initialization in addition to the normal zero-initializati=
on usually performed with allocators; for classes with default constructors=
, there is no difference.=C2=A0 One thing that bugs me about his proposal i=
s that he is changing allocator_traits from a class which always forwards t=
o the allocator if it can into a class which will always perform default-in=
itialization in this one case.</div><div><br></div><div>This isn&#39;t to s=
ay that there shouldn&#39;t be a low-level utility, but I&#39;d still like =
to have this functionality as well, without having to resort to a custom al=
locator, and definitely without breaking vector&#39;s invariants.</div></di=
v>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">=
<div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Lib=
er=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_bl=
ank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</div></div></div>=
</div></div>
</div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM%2BfCjSm5RQGStWXaAegpx0kZsn=
Nw%3Deojvoqnw6SCh-tQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM%=
2BfCjSm5RQGStWXaAegpx0kZsnNw%3Deojvoqnw6SCh-tQ%40mail.gmail.com</a>.<br />

--94eb2c1197ba528341055758c2d0--

.

------=_Part_361_5237740.1503413672146
Content-Type: multipart/alternative;
 boundary="----=_Part_362_1044701633.1503413672147"

------=_Part_362_1044701633.1503413672147
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 22, 2017 at 10:34:28 AM UTC-4, Ville Voutilainen wrote:
>
> On 22 August 2017 at 17:16, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >>> Again, that's a reason to allow default initialization, not to do what
> he
> >>> suggests.
> >>
> >>
> >> Why? Is it really necessary and intended to avoid uninitialized object
> >> owned by vector directly without allocator hacks and/or changing of
> element
> >> types (which are both likely to cause a change on the container type)
> by
> >> design?
> >
> >
> > It's not "necessary", in the sense that we could avoid it. I appreciate
> the
> > desire to address the problem; what I don't like is these particular
> means.
> > It effectively breaks `vector`, since its size would have to include
> objects
> > that don't exist. Plus, C++ doesn't allow you to do pointer arithmetic
> > across objects that don't exist. You can only do pointer arithmetic over
> > arrays, and arrays require that all of their subobjects actually are
> real,
> > live objects.
> >
> > Default initialization is a real process in C++ which creates real, live
> > objects. It can be used in placement new expressions; as such, there is
> no
> > technical reason why default initialization cannot be used to solve this
> > problem. Those objects would actually exist, and therefore it wouldn't
> break
> > the C++ object model or the meaning of `vector`.
> >
> > The current issue is that there's no way to communicate that you want
> > default initialization rather than value initialization. So let's fix
> that,
> > and the rest will take care of itself.
>
>
> It seems to me that we might want to consider adding a building block
> of lower level than
> vector. vector has always been a compromise, with certain overhead in
> some of its operations.
> Perhaps we should have a dynamic buffer that's not trying to be safe
> to use, and makes
> no compromises on speed. Such a type can still do automatic cleanup
> and automatic
> buffer growth, so it would not be just a raw array.
>
> The reason for that suggestion is that different use cases use
> different trade-offs, and it's
> difficult to cover a significant fraction of the various use cases,
> but at least we could perhaps
> provide a low-level utility that can be a building block for all of
> them. Trying to fix vector's performance
> problems one by one runs the risk of breaking vector's class
> invariants, which (all of them) somebody
> somewhere is bound to rely on, so I'd expect fair amounts of
> resistance to such an approach.
>

If we're going to go that route, I would suggest focusing on operations
rather than a type. With a type, you have to deal with ownership of storage
and other things. Whereas if we provide operations, we will effectively
make it easy for users to create their own vector-like types. This would
also allow users to gain access to implementation-specific optimizations
(like trivial copying through `memcpy`) without having to write it all
themselves.

The ideal would be that if a user has some `std::aligned_storage` of a
particular size, and they want to build/manage an array of `T`s within that
storage, they can use these operations to do so without having to use a
specific type.

So we should start with a list of the operations that implementers of
`vector` need to do. These would include, but would not be limited to:

* Performing destruction on a given range of elements.
* Performing construction on a given range of elements, likely through the
use of a user-provided callback to actually do the initialization
* Performing the right-shifting needed to be able to insert elements.
* Performing the left-shifting needed to be able to remove elements.

Any other operations?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4994a214-a226-48f0-bc58-8ef34198acaf%40isocpp.org.

------=_Part_362_1044701633.1503413672147
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 22, 2017 at 10:34:28 AM UTC-4, Ville Vo=
utilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 22 August 2=
017 at 17:16, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"pVgWS0qJCwAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;&gt;&gt; Again, that&#39;s a reason to allow default initialization=
, not to do what he
<br>&gt;&gt;&gt; suggests.
<br>&gt;&gt;
<br>&gt;&gt;
<br>&gt;&gt; Why? Is it really necessary and intended to avoid uninitialize=
d object
<br>&gt;&gt; owned by vector directly without allocator hacks and/or changi=
ng of element
<br>&gt;&gt; types (which are both likely to cause a change on the containe=
r type) by
<br>&gt;&gt; design?
<br>&gt;
<br>&gt;
<br>&gt; It&#39;s not &quot;necessary&quot;, in the sense that we could avo=
id it. I appreciate the
<br>&gt; desire to address the problem; what I don&#39;t like is these part=
icular means.
<br>&gt; It effectively breaks `vector`, since its size would have to inclu=
de objects
<br>&gt; that don&#39;t exist. Plus, C++ doesn&#39;t allow you to do pointe=
r arithmetic
<br>&gt; across objects that don&#39;t exist. You can only do pointer arith=
metic over
<br>&gt; arrays, and arrays require that all of their subobjects actually a=
re real,
<br>&gt; live objects.
<br>&gt;
<br>&gt; Default initialization is a real process in C++ which creates real=
, live
<br>&gt; objects. It can be used in placement new expressions; as such, the=
re is no
<br>&gt; technical reason why default initialization cannot be used to solv=
e this
<br>&gt; problem. Those objects would actually exist, and therefore it woul=
dn&#39;t break
<br>&gt; the C++ object model or the meaning of `vector`.
<br>&gt;
<br>&gt; The current issue is that there&#39;s no way to communicate that y=
ou want
<br>&gt; default initialization rather than value initialization. So let&#3=
9;s fix that,
<br>&gt; and the rest will take care of itself.
<br>
<br>
<br>It seems to me that we might want to consider adding a building block
<br>of lower level than
<br>vector. vector has always been a compromise, with certain overhead in
<br>some of its operations.
<br>Perhaps we should have a dynamic buffer that&#39;s not trying to be saf=
e
<br>to use, and makes
<br>no compromises on speed. Such a type can still do automatic cleanup
<br>and automatic
<br>buffer growth, so it would not be just a raw array.
<br>
<br>The reason for that suggestion is that different use cases use
<br>different trade-offs, and it&#39;s
<br>difficult to cover a significant fraction of the various use cases,
<br>but at least we could perhaps
<br>provide a low-level utility that can be a building block for all of
<br>them. Trying to fix vector&#39;s performance
<br>problems one by one runs the risk of breaking vector&#39;s class
<br>invariants, which (all of them) somebody
<br>somewhere is bound to rely on, so I&#39;d expect fair amounts of
<br>resistance to such an approach.
<br></blockquote><div><br>If we&#39;re going to go that route, I would sugg=
est focusing on operations rather than a type. With a type, you have to dea=
l with ownership of storage and other things. Whereas if we provide operati=
ons, we will effectively make it easy for users to create their own vector-=
like types. This would also allow users to gain access to implementation-sp=
ecific optimizations (like trivial copying through `memcpy`) without having=
 to write it all themselves.<br><br>The ideal would be that if a user has s=
ome `std::aligned_storage` of a particular size, and they want to build/man=
age an array of `T`s within that storage, they can use these operations to =
do so without having to use a specific type.<br><br>So we should start with=
 a list of the operations that implementers of `vector` need to do. These w=
ould include, but would not be limited to:<br><br>* Performing destruction =
on a given range of elements.<br>* Performing construction on a given range=
 of elements, likely through the use of a user-provided callback to actuall=
y do the initialization<br>* Performing the right-shifting needed to be abl=
e to insert elements.<br>* Performing the left-shifting needed to be able t=
o remove elements.<br><br>Any other operations?<br></div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4994a214-a226-48f0-bc58-8ef34198acaf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4994a214-a226-48f0-bc58-8ef34198acaf=
%40isocpp.org</a>.<br />

------=_Part_362_1044701633.1503413672147--

------=_Part_361_5237740.1503413672146--

.

------=_Part_8544_2114911079.1503413817092
Content-Type: multipart/alternative;
 boundary="----=_Part_8545_1101919143.1503413817092"

------=_Part_8545_1101919143.1503413817092
Content-Type: text/plain; charset="UTF-8"



On Tuesday, August 22, 2017 at 10:53:35 AM UTC-4, Nevin ":-)" Liber wrote:
>
> On Tue, Aug 22, 2017 at 9:34 AM, Ville Voutilainen <ville.vo...@gmail.com
> <javascript:>> wrote:
>
>> Trying to fix vector's performance
>> problems one by one runs the risk of breaking vector's class
>> invariants, which (all of them) somebody
>> somewhere is bound to rely on, so I'd expect fair amounts of
>> resistance to such an approach.
>
>
> Nicol isn't breaking vector's invariants with his proposal.  He is looking
> to add default-initialization in addition to the normal zero-initialization
> usually performed with allocators; for classes with default constructors,
> there is no difference.  One thing that bugs me about his proposal is that
> he is changing allocator_traits from a class which always forwards to the
> allocator if it can into a class which will always perform
> default-initialization in this one case.
>

No, it isn't; it changes nothing about `allocator_traits`.

It changes the *language* itself, so that it reacts to
`std::default_init_t` by performing default initialization. As such, when
the system calls `allocator_traits<...>::construct(std::default_init)`, it
*will* perform default initialization. Not because `allocator_traits` is
modified, but because that's what happens when you invoke `new
T(std::default_init)`.

This isn't to say that there shouldn't be a low-level utility, but I'd
> still like to have this functionality as well, without having to resort to
> a custom allocator, and definitely without breaking vector's invariants.
>

Agreed.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/15c73856-2a40-43a3-9e9c-62780dc12030%40isocpp.org.

------=_Part_8545_1101919143.1503413817092
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, August 22, 2017 at 10:53:35 AM UTC-4, =
Nevin &quot;:-)&quot; Liber wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">On Tue, Aug 22, 2017 at 9:34 AM, Ville Voutilainen <=
span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"qzEib1WKCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39=
;;return true;">ville.vo...@gmail.com</a>&gt;</span> wrote:<br><div><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">Trying to fix vector&#39=
;s performance<br>
problems one by one runs the risk of breaking vector&#39;s class<br>
invariants, which (all of them) somebody<br>
somewhere is bound to rely on, so I&#39;d expect fair amounts of<br>
resistance to such an approach.</blockquote><div><br></div><div>Nicol isn&#=
39;t breaking vector&#39;s invariants with his proposal.=C2=A0 He is lookin=
g to add default-initialization in addition to the normal zero-initializati=
on usually performed with allocators; for classes with default constructors=
, there is no difference.=C2=A0 One thing that bugs me about his proposal i=
s that he is changing allocator_traits from a class which always forwards t=
o the allocator if it can into a class which will always perform default-in=
itialization in this one case.</div></div></div></div></blockquote><div><br=
>No, it isn&#39;t; it changes nothing about `allocator_traits`.<br><br>It c=
hanges the <i>language</i> itself, so that it reacts to `std::default_init_=
t` by performing default initialization. As such, when the system calls `al=
locator_traits&lt;...&gt;::construct(std::default_init)`, it <i>will</i> pe=
rform default initialization. Not because `allocator_traits` is modified, b=
ut because that&#39;s what happens when you invoke `new T(std::default_init=
)`.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div></div><div>This isn&#39;t to say t=
hat there shouldn&#39;t be a low-level utility, but I&#39;d still like to h=
ave this functionality as well, without having to resort to a custom alloca=
tor, and definitely without breaking vector&#39;s invariants.</div></div></=
div></div></blockquote><div><br>Agreed.</div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/15c73856-2a40-43a3-9e9c-62780dc12030%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/15c73856-2a40-43a3-9e9c-62780dc12030=
%40isocpp.org</a>.<br />

------=_Part_8545_1101919143.1503413817092--

------=_Part_8544_2114911079.1503413817092--

.

On 22 August 2017 at 17:52, Nevin Liber <nevin@eviloverlord.com> wrote:
> On Tue, Aug 22, 2017 at 9:34 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>>
>> Trying to fix vector's performance
>> problems one by one runs the risk of breaking vector's class
>> invariants, which (all of them) somebody
>> somewhere is bound to rely on, so I'd expect fair amounts of
>> resistance to such an approach.
>
>
> Nicol isn't breaking vector's invariants with his proposal.  He is looking

A vector that's not using a custom allocator today has the invariant
that its elements
are value-initialized. Adding an operation that does default-init
instead of value-init
will break that invariant. Whether that breaks a significant amount of
code is another
matter.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbU6o_buSKWrUx9uO2BHNo%2B6O2MOd-u3%2B12xn3ehQ5oHA%40mail.gmail.com.

.

On 22 August 2017 at 17:54, Nicol Bolas <jmckesson@gmail.com> wrote:
>> It seems to me that we might want to consider adding a building block
>> of lower level than
>> vector. vector has always been a compromise, with certain overhead in
> If we're going to go that route, I would suggest focusing on operations
> rather than a type. With a type, you have to deal with ownership of storage
> and other things. Whereas if we provide operations, we will effectively make
> it easy for users to create their own vector-like types. This would also
> allow users to gain access to implementation-specific optimizations (like
> trivial copying through `memcpy`) without having to write it all themselves.
>
> The ideal would be that if a user has some `std::aligned_storage` of a
> particular size, and they want to build/manage an array of `T`s within that
> storage, they can use these operations to do so without having to use a
> specific type.
>
> So we should start with a list of the operations that implementers of
> `vector` need to do. These would include, but would not be limited to:
>
> * Performing destruction on a given range of elements.
> * Performing construction on a given range of elements, likely through the
> use of a user-provided callback to actually do the initialization
> * Performing the right-shifting needed to be able to insert elements.
> * Performing the left-shifting needed to be able to remove elements.
>
> Any other operations?


I would seriously entertain the idea of carving out the operations you
mentioned, trying
to fit std::vector and something like QVector (any third-party vector
will do) in terms
of those operations, and seeing whether anything's missing. I wonder
whether assignment
needs something more.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbP9D3zvA6UCzagJbYvc6RuXqOfe5jkTLkp5Vf-scz74g%40mail.gmail.com.

.

------=_Part_8628_594584894.1503415772769
Content-Type: multipart/alternative;
 boundary="----=_Part_8629_270745702.1503415772769"

------=_Part_8629_270745702.1503415772769
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 22, 2017 at 11:01:01 AM UTC-4, Ville Voutilainen wrote:
>
> On 22 August 2017 at 17:52, Nevin Liber <ne...@eviloverlord.com
> <javascript:>> wrote:
> > On Tue, Aug 22, 2017 at 9:34 AM, Ville Voutilainen
> > <ville.vo...@gmail.com <javascript:>> wrote:
> >>
> >> Trying to fix vector's performance
> >> problems one by one runs the risk of breaking vector's class
> >> invariants, which (all of them) somebody
> >> somewhere is bound to rely on, so I'd expect fair amounts of
> >> resistance to such an approach.
> >
> >
> > Nicol isn't breaking vector's invariants with his proposal.  He is
> looking
>
> A vector that's not using a custom allocator today has the invariant
> that its elements
> are value-initialized.


vector<int> ivec(256, 1);

`ivec`'s elements are *not* value-initialized.

The invariant is that the elements are always initialized to a known value.
We would be changing that rule for types where `T` can be uninitialized.

Also, it should be noted that this would hardly be limited to `vector`.
Indeed, that's kind of the point of the way I defined the feature: it
permits default initialization in *any circumstance* where you provide the
parameter list to the constructor. So `optional<int>`, `variant<int,
float>`, and even `any` can have their data be default initialized. You can
even create uninitialized prvalue temporaries with `T(std::default_init)`.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7f139050-6355-40a5-8fe9-f44015538afa%40isocpp.org.

------=_Part_8629_270745702.1503415772769
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 22, 2017 at 11:01:01 AM UTC-4, Ville Vo=
utilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 22 August 2=
017 at 17:52, Nevin Liber &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"OLuJLr2KCwAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">ne...@eviloverlord.com</a>&gt; wrote:
<br>&gt; On Tue, Aug 22, 2017 at 9:34 AM, Ville Voutilainen
<br>&gt; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"OLuJLr2KCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">ville.vo...@gmail.com</a>&gt; wrote:
<br>&gt;&gt;
<br>&gt;&gt; Trying to fix vector&#39;s performance
<br>&gt;&gt; problems one by one runs the risk of breaking vector&#39;s cla=
ss
<br>&gt;&gt; invariants, which (all of them) somebody
<br>&gt;&gt; somewhere is bound to rely on, so I&#39;d expect fair amounts =
of
<br>&gt;&gt; resistance to such an approach.
<br>&gt;
<br>&gt;
<br>&gt; Nicol isn&#39;t breaking vector&#39;s invariants with his proposal=
.. =C2=A0He is looking
<br>
<br>A vector that&#39;s not using a custom allocator today has the invarian=
t
<br>that its elements
<br>are value-initialized.</blockquote><div><br><div style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">vector</span><span style=3D"color: =
#080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> ivec</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">256</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">1=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
/div></code></div><br>`ivec`&#39;s elements are <i>not</i> value-initialize=
d.<br><br>The invariant is that the elements are always initialized to a kn=
own value. We would be changing that rule for types where `T` can be uninit=
ialized.<br><br>Also, it should be noted that this would hardly be limited =
to `vector`. Indeed, that&#39;s kind of the point of the way I defined the =
feature: it permits default initialization in <i>any circumstance</i> where=
 you provide the parameter list to the constructor. So `optional&lt;int&gt;=
`, `variant&lt;int, float&gt;`, and even `any` can have their data be defau=
lt initialized. You can even create uninitialized prvalue temporaries with =
`T(std::default_init)`.</div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7f139050-6355-40a5-8fe9-f44015538afa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7f139050-6355-40a5-8fe9-f44015538afa=
%40isocpp.org</a>.<br />

------=_Part_8629_270745702.1503415772769--

------=_Part_8628_594584894.1503415772769--

.

--94eb2c0cb250b2c0860557595ba6
Content-Type: text/plain; charset="UTF-8"

On Tue, Aug 22, 2017 at 10:29 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> A vector that's not using a custom allocator today has the invariant
>> that its elements
>> are value-initialized.
>
>
> vector<int> ivec(256, 1);
>
> `ivec`'s elements are *not* value-initialized.
>
> The invariant is that the elements are always initialized to a known
> value. We would be changing that rule for types where `T` can be
> uninitialized.
>

Ville is right (as usual :-)).  That may be problematic.

vector<double> v1(1, std::default_init);
vector<double> v2(v1);  // is this legal?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404
<(847)%20691-1404>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNfSvE7BLtFT4fa%2BviCAE5_KGE_-ccJrLQoAfZPV1qRFQ%40mail.gmail.com.

--94eb2c0cb250b2c0860557595ba6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Aug 22, 2017 at 10:29 AM, Nicol Bolas <span dir=3D=
"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesso=
n@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><span>A vector that&#39;s not using a custom =
allocator today has the invariant
<br>that its elements
<br>are value-initialized.</span></blockquote><div><br><div style=3D"backgr=
ound-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:soli=
d;border-width:1px" class=3D"m_-956810737741084338m_-515220239631859718pret=
typrint"><code class=3D"m_-956810737741084338m_-515220239631859718prettypri=
nt"><div class=3D"m_-956810737741084338m_-515220239631859718subprettyprint"=
><span style=3D"color:#000" class=3D"m_-956810737741084338m_-51522023963185=
9718styled-by-prettify">vector</span><span style=3D"color:#080" class=3D"m_=
-956810737741084338m_-515220239631859718styled-by-prettify">&lt;int&gt;</sp=
an><span style=3D"color:#000" class=3D"m_-956810737741084338m_-515220239631=
859718styled-by-prettify"> ivec</span><span style=3D"color:#660" class=3D"m=
_-956810737741084338m_-515220239631859718styled-by-prettify">(</span><span =
style=3D"color:#066" class=3D"m_-956810737741084338m_-515220239631859718sty=
led-by-prettify">256</span><span style=3D"color:#660" class=3D"m_-956810737=
741084338m_-515220239631859718styled-by-prettify">,</span><span style=3D"co=
lor:#000" class=3D"m_-956810737741084338m_-515220239631859718styled-by-pret=
tify"> </span><span style=3D"color:#066" class=3D"m_-956810737741084338m_-5=
15220239631859718styled-by-prettify">1</span><span style=3D"color:#660" cla=
ss=3D"m_-956810737741084338m_-515220239631859718styled-by-prettify">);</spa=
n></div></code></div><br>`ivec`&#39;s elements are <i>not</i> value-initial=
ized.<br><br>The invariant is that the elements are always initialized to a=
 known value. We would be changing that rule for types where `T` can be uni=
nitialized.<br></div></div></blockquote><div><br></div><div>Ville is right =
(as usual :-)).=C2=A0 That may be problematic.</div><div><br></div><div>vec=
tor&lt;double&gt; v1(1, std::default_init);</div><div>vector&lt;double&gt; =
v2(v1); =C2=A0// is this legal?</div></div>-- <br><div class=3D"m_-95681073=
7741084338gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"l=
tr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;=
mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@ev=
iloverlord.com</a><wbr>&gt; =C2=A0<a href=3D"tel:(847)%20691-1404" value=3D=
"+18476911404" target=3D"_blank">+1-847-691-1404</a></div></div></div></div=
></div>
</div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNfSvE7BLtFT4fa%2BviCAE5_KGE_=
-ccJrLQoAfZPV1qRFQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNfSv=
E7BLtFT4fa%2BviCAE5_KGE_-ccJrLQoAfZPV1qRFQ%40mail.gmail.com</a>.<br />

--94eb2c0cb250b2c0860557595ba6--

.

On Tuesday, 22 August 2017 08:04:32 PDT Ville Voutilainen wrote:
> I would seriously entertain the idea of carving out the operations you
> mentioned, trying
> to fit std::vector and something like QVector (any third-party vector
> will do) in terms
> of those operations, and seeing whether anything's missing. I wonder
> whether assignment
> needs something more.

We developed those for Qt 5.0 in QArrayOps with specialisation for primitive
types (can initialise with memset) and for other relocatable types (can
relocate with memcpy), but they're unused. They operate on ranges. They're
also supposedly exception-safe, but we've never written the unit-testing code
to confirm that.

But even then they have the same invariant problem: they try to update the
"size" member of the container.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1813171.BaAi2EVzev%40tjmaciei-mobl1.

.

On Tuesday, 22 August 2017 08:35:45 PDT Nevin Liber wrote:
> On Tue, Aug 22, 2017 at 10:29 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> > A vector that's not using a custom allocator today has the invariant
> >
> >> that its elements
> >> are value-initialized.
> >
> > vector<int> ivec(256, 1);
> >
> > `ivec`'s elements are *not* value-initialized.
> >
> > The invariant is that the elements are always initialized to a known
> > value. We would be changing that rule for types where `T` can be
> > uninitialized.
>
> Ville is right (as usual :-)).  That may be problematic.
>
> vector<double> v1(1, std::default_init);
> vector<double> v2(v1);  // is this legal?

I don't see why not. You can copy uninitialised data (think of padding).

You just can't perform decisions based on it.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2554367.d1IRiJ4OzG%40tjmaciei-mobl1.

.

------=_Part_8995_1787597092.1503433452933
Content-Type: multipart/alternative;
 boundary="----=_Part_8996_905942304.1503433452933"

------=_Part_8996_905942304.1503433452933
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=E5=9C=A8 2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=8810:16:30=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tuesday, August 22, 2017 at 5:42:56 AM UTC-4, FrankHB1989 wrote:
>>
>> =E5=9C=A8 2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C =
UTC+8=E4=B8=8A=E5=8D=889:46:26=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>>>
>>> On Monday, August 21, 2017 at 9:19:46 PM UTC-4, Patrice Roy wrote:
>>>>
>>>> +1. Really looks like a reserve() use-case to me.
>>>>
>>>> 2017-08-21 4:29 GMT-04:00 Jonathan M=C3=BCller <jonathanm...@gmail.com=
>:
>>>>
>>>>> On 20.08.2017 22:22, Ryan Nicholl wrote:
>>>>>
>>>>>> My motivating example consists of a serialization routine. Ideally,=
=20
>>>>>> the serialization routine would expand the vector uninitialized and =
then=20
>>>>>> write the data in. This can't be done however, because the resize fu=
nction=20
>>>>>> writes 0s to the data thanks to the default allocator's construct me=
thod.
>>>>>>
>>>>>
>>>>> Could you clarify why reserve + push_back() doesn't work here?
>>>>>
>>>>
>>> I expect it's the reason he stated: he wants to prevent the value=20
>>> initialization of the object, since he's going to initialize it from th=
e=20
>>> serialization routine. He wants to avoid the double-initialization.
>>>
>>> Again, that's a reason to allow default initialization, not to do what=
=20
>>> he suggests.=20
>>>
>>
>> Why? Is it really necessary and intended to avoid uninitialized object=
=20
>> owned by vector directly without allocator hacks and/or changing of elem=
ent=20
>> types (which are both likely to cause a change on the container type) by=
=20
>> design?
>>
>
> It's not "necessary", in the sense that we could avoid it. I appreciate=
=20
> the desire to address the problem; what I don't like is these particular=
=20
> *means*. It effectively breaks `vector`, since its size would have to=20
> include objects that don't exist. Plus, C++ doesn't allow you to do point=
er=20
> arithmetic across objects that don't exist. You can only do pointer=20
> arithmetic over arrays, and arrays require that all of their subobjects=
=20
> actually are real, live objects.
>
You're right that it effectively breaks `vector` when there is no=20
initialization performed later, before these elements destroyed at the end=
=20
of the lifetime of the vector. However, is there any real invariant to keep=
=20
every element alive during the whole lifetime of the container object? For=
=20
instance, what about something like an explicit destructor call and a=20
placement new expression to initialize a new element in the same location?

>
> Default initialization is a real process in C++ which creates real, live=
=20
> objects. It can be used in placement new expressions; as such, there is n=
o=20
> technical reason why default initialization cannot be used to solve this=
=20
> problem. Those objects would actually exist, and therefore it wouldn't=20
> break the C++ object model or the meaning of `vector`.
>
The current issue is that there's no way to communicate that you *want*=20
> default initialization rather than value initialization. So let's fix=20
> *that*=20
> <https://github.com/NicolBolas/Proposal-Ideas/blob/master/Default%20Initi=
alizer%20Value.md>,=20
> and the rest will take care of itself.
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9824081e-169a-4f23-8938-bc10c048b0f8%40isocpp.or=
g.

------=_Part_8996_905942304.1503433452933
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=8810:16:30=EF=BC=8CNicol Bolas=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">On Tuesday, August 22, 2017 at 5:42:56 AM UTC-4, FrankHB1989 =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=E5=9C=A8 20=
17=E5=B9=B48=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8A=
=E5=8D=889:46:26=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, August 21, 2017 at =
9:19:46 PM UTC-4, Patrice Roy wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">+1. Really looks like a reserve() use-case to me.<br></di=
v><div><br><div class=3D"gmail_quote">2017-08-21 4:29 GMT-04:00 Jonathan M=
=C3=BCller <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jonathanm...@gmail.com=
</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 20.08.2017 22:2=
2, Ryan Nicholl wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
My motivating example consists of a serialization routine. Ideally, the ser=
ialization routine would expand the vector uninitialized and then write the=
 data in. This can&#39;t be done however, because the resize function write=
s 0s to the data thanks to the default allocator&#39;s construct method.<br=
>
</blockquote>
<br></span>
Could you clarify why reserve + push_back() doesn&#39;t work here?<span></s=
pan><br></blockquote></div></div></blockquote><div><br>I expect it&#39;s th=
e reason he stated: he wants to prevent the value initialization of the obj=
ect, since he&#39;s going to initialize it from the serialization routine. =
He wants to avoid the double-initialization.<br><br>Again, that&#39;s a rea=
son to allow default initialization, not to do what he suggests. <br></div>=
</div></blockquote><div><br></div><div>Why? Is it really necessary and inte=
nded to avoid uninitialized object owned by vector directly without allocat=
or hacks and/or changing of element types (which are both likely to cause a=
 change on the container type) by design?</div></div></blockquote><div><br>=
It&#39;s not &quot;necessary&quot;, in the sense that we could avoid it. I =
appreciate the desire to address the problem; what I don&#39;t like is thes=
e particular <i>means</i>. It effectively breaks `vector`, since its size w=
ould have to include objects that don&#39;t exist. Plus, C++ doesn&#39;t al=
low you to do pointer arithmetic across objects that don&#39;t exist. You c=
an only do pointer arithmetic over arrays, and arrays require that all of t=
heir subobjects actually are real, live objects.<br></div></div></blockquot=
e><div>You&#39;re right that it effectively breaks `vector` when there is n=
o initialization performed later, before these elements destroyed at the en=
d of the lifetime of the vector. However, is there any real invariant to ke=
ep every element alive during the whole lifetime of the container object? F=
or instance, what about something like an explicit destructor call and a pl=
acement new expression to initialize a new element in the same location?<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><=
br>Default initialization is a real process in C++ which creates real, live=
 objects. It can be used in placement new expressions; as such, there is no=
 technical reason why default initialization cannot be used to solve this p=
roblem. Those objects would actually exist, and therefore it wouldn&#39;t b=
reak the C++ object model or the meaning of `vector`.</div></div></blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>The c=
urrent issue is that there&#39;s no way to communicate that you <i>want</i>=
 default initialization rather than value initialization. So <a href=3D"htt=
ps://github.com/NicolBolas/Proposal-Ideas/blob/master/Default%20Initializer=
%20Value.md" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FNicolBolas%=
2FProposal-Ideas%2Fblob%2Fmaster%2FDefault%2520Initializer%2520Value.md\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFWGMpLgYYNLKFmAaDkng6OEyAjCg&#39;;retu=
rn true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps=
%3A%2F%2Fgithub.com%2FNicolBolas%2FProposal-Ideas%2Fblob%2Fmaster%2FDefault=
%2520Initializer%2520Value.md\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFWGMp=
LgYYNLKFmAaDkng6OEyAjCg&#39;;return true;">let&#39;s fix <i>that</i></a>, a=
nd the rest will take care of itself.</div></div></blockquote></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9824081e-169a-4f23-8938-bc10c048b0f8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9824081e-169a-4f23-8938-bc10c048b0f8=
%40isocpp.org</a>.<br />

------=_Part_8996_905942304.1503433452933--

------=_Part_8995_1787597092.1503433452933--

.

--f403045c61faa8a33405575d79d2
Content-Type: text/plain; charset="UTF-8"

On Tue, Aug 22, 2017 at 3:24 PM, FrankHB1989 <frankhb1989@gmail.com> wrote:

>
>
> You're right that it effectively breaks `vector` when there is no
> initialization performed later, before these elements destroyed at the end
> of the lifetime of the vector. However, is there any real invariant to keep
> every element alive during the whole lifetime of the container object? For
> instance, what about something like an explicit destructor call and a
> placement new expression to initialize a new element in the same location?
>

What exactly do you plan on doing if an exception is thrown while
initializing the new element?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMNVbCkqcYyqRjrmeiyJNZ-b-rFM%3Dg-gRrwnM1uyQ%3DP%2Bg%40mail.gmail.com.

--f403045c61faa8a33405575d79d2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Aug 22, 2017 at 3:24 PM, FrankHB1989 <span dir=3D"=
ltr">&lt;<a href=3D"mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb=
1989@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>=
<div>You&#39;re right that it effectively breaks `vector` when there is no =
initialization performed later, before these elements destroyed at the end =
of the lifetime of the vector. However, is there any real invariant to keep=
 every element alive during the whole lifetime of the container object? For=
 instance, what about something like an explicit destructor call and a plac=
ement new expression to initialize a new element in the same location?<br><=
/div></div></blockquote><div><br></div><div>What exactly do you plan on doi=
ng if an exception is thrown while initializing the new element?</div></div=
>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><=
div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Libe=
r=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_bla=
nk">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</div></div></div><=
/div></div>
</div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMNVbCkqcYyqRjrmeiyJNZ-b-rFM%=
3Dg-gRrwnM1uyQ%3DP%2Bg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
MNVbCkqcYyqRjrmeiyJNZ-b-rFM%3Dg-gRrwnM1uyQ%3DP%2Bg%40mail.gmail.com</a>.<br=
 />

--f403045c61faa8a33405575d79d2--

.

--94eb2c0a21eee6af5105575d83fd
Content-Type: text/plain; charset="UTF-8"

On Tue, Aug 22, 2017 at 11:31 AM, Thiago Macieira <thiago@macieira.org>
wrote:

> > vector<double> v1(1, std::default_init);
> > vector<double> v2(v1);  // is this legal?
>
> I don't see why not. You can copy uninitialised data (think of padding).
>

The random bit pattern could be signaling NaN.

Also, if you have an integer type with a trap representation and you happen
to hit that bit pattern, I believe that copying it would be UB (memcpy may
be able to get away with it, but there is no requirement that memcpy be
used).
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP4r9Ljc42-BoGs%3DGLh6CLywQ00zE29hBvr6CkQuxNhwQ%40mail.gmail.com.

--94eb2c0a21eee6af5105575d83fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Aug 22, 2017 at 11:31 AM, Thiago Macieira <span di=
r=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thia=
go@macieira.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">&gt; ve=
ctor&lt;double&gt; v1(1, std::default_init);<br>
&gt; vector&lt;double&gt; v2(v1);=C2=A0 // is this legal?<br>
<br>
</span>I don&#39;t see why not. You can copy uninitialised data (think of p=
adding).<br></blockquote><div><br></div><div>The random bit pattern could b=
e signaling NaN.</div><div><br></div><div>Also, if you have an integer type=
 with a trap representation and you happen to hit that bit pattern, I belie=
ve that copying it would be UB (memcpy may be able to get away with it, but=
 there is no requirement that memcpy be used).</div></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><d=
iv><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto=
:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilover=
lord.com</a>&gt; =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP4r9Ljc42-BoGs%3DGLh6CLywQ00=
zE29hBvr6CkQuxNhwQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP4r9=
Ljc42-BoGs%3DGLh6CLywQ00zE29hBvr6CkQuxNhwQ%40mail.gmail.com</a>.<br />

--94eb2c0a21eee6af5105575d83fd--

.

------=_Part_8887_1734951954.1503434451705
Content-Type: multipart/alternative;
 boundary="----=_Part_8888_1494396021.1503434451705"

------=_Part_8888_1494396021.1503434451705
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 22, 2017 at 4:34:02 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On Tue, Aug 22, 2017 at 11:31 AM, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
>
>> > vector<double> v1(1, std::default_init);
>> > vector<double> v2(v1);  // is this legal?
>>
>> I don't see why not. You can copy uninitialised data (think of padding).
>>
>
> The random bit pattern could be signaling NaN.
>
> Also, if you have an integer type with a trap representation and you
> happen to hit that bit pattern, I believe that copying it would be UB
> (memcpy may be able to get away with it, but there is no requirement that
> memcpy be used).
>

[dcl.init]/12 <http://eel.is/c++draft/dcl.init#12> makes this UB, in
general. [dcl.init]/12.4 <http://eel.is/c++draft/dcl.init#12.4> has this
example:

> unsigned char c;
> unsigned char d = c;    // OK, d has an indeterminate value
> int e = d;              // undefined behavior
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ed1fe1d3-016a-4b18-8e33-eb70eb1f7ff7%40isocpp.org.

------=_Part_8888_1494396021.1503434451705
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 22, 2017 at 4:34:02 PM UTC-4, Nevin &qu=
ot;:-)&quot; Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr">On Tue, Aug 22, 2017 at 11:31 AM, Thiago Macieira <span dir=3D"=
ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"9y35H1YNAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:=
&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;">thi...@macieira.org</a>&gt;</span> wrote:<br><div><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span>&gt; vector&lt;double&gt; v1(1, =
std::default_init);<br>
&gt; vector&lt;double&gt; v2(v1);=C2=A0 // is this legal?<br>
<br>
</span>I don&#39;t see why not. You can copy uninitialised data (think of p=
adding).<br></blockquote><div><br></div><div>The random bit pattern could b=
e signaling NaN.</div><div><br></div><div>Also, if you have an integer type=
 with a trap representation and you happen to hit that bit pattern, I belie=
ve that copying it would be UB (memcpy may be able to get away with it, but=
 there is no requirement that memcpy be used).</div></div></div></div></blo=
ckquote><div><br><a href=3D"http://eel.is/c++draft/dcl.init#12">[dcl.init]/=
12</a> makes this UB, in general. <a href=3D"http://eel.is/c++draft/dcl.ini=
t#12.4">[dcl.init]/12.4</a> has this example:<br><blockquote class=3D"gmail=
_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204,=
 204, 204); padding-left: 1ex;"><span style=3D"font-family: courier new,mon=
ospace;">unsigned char c;</span><br><span style=3D"font-family: courier new=
,monospace;">unsigned char d =3D c;=C2=A0=C2=A0=C2=A0 // OK, d has an indet=
erminate value</span><br><span style=3D"font-family: courier new,monospace;=
">int e =3D d;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 // undefined behavior</span><br></blockquote></div></div=
>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ed1fe1d3-016a-4b18-8e33-eb70eb1f7ff7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ed1fe1d3-016a-4b18-8e33-eb70eb1f7ff7=
%40isocpp.org</a>.<br />

------=_Part_8888_1494396021.1503434451705--

------=_Part_8887_1734951954.1503434451705--

.

On Tuesday, 22 August 2017 13:33:19 PDT Nevin Liber wrote:
> On Tue, Aug 22, 2017 at 11:31 AM, Thiago Macieira <thiago@macieira.org>
>
> wrote:
> > > vector<double> v1(1, std::default_init);
> > > vector<double> v2(v1);  // is this legal?
> >
> > I don't see why not. You can copy uninitialised data (think of padding).
>
> The random bit pattern could be signaling NaN.
>
> Also, if you have an integer type with a trap representation and you happen
> to hit that bit pattern, I believe that copying it would be UB (memcpy may
> be able to get away with it, but there is no requirement that memcpy be
> used).

That's a good point for trap representations. I'm not sure signalling NaNs
signal just on copy, though. I'd have to look up to find out more.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1550914.HSsDttMrnJ%40tjmaciei-mobl1.

.

On Tuesday, 22 August 2017 13:40:51 PDT Chris Hallock wrote:
> On Tuesday, August 22, 2017 at 4:34:02 PM UTC-4, Nevin ":-)" Liber wrote:
> > On Tue, Aug 22, 2017 at 11:31 AM, Thiago Macieira <thi...@macieira.org
> >
> > <javascript:>> wrote:
> >> > vector<double> v1(1, std::default_init);
> >> > vector<double> v2(v1);  // is this legal?
> >>
> >> I don't see why not. You can copy uninitialised data (think of padding).
> >
> > The random bit pattern could be signaling NaN.
> >
> > Also, if you have an integer type with a trap representation and you
> > happen to hit that bit pattern, I believe that copying it would be UB
> > (memcpy may be able to get away with it, but there is no requirement that
> > memcpy be used).
>
> [dcl.init]/12 <http://eel.is/c++draft/dcl.init#12> makes this UB, in
> general. [dcl.init]/12.4 <http://eel.is/c++draft/dcl.init#12.4> has this

Thanks, I stand corrected. You're only allowed to evaluate indeterminate
values so long as it's a narrow character (byte). For any other type, it's UB.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1734632.beeTJ9AUWJ%40tjmaciei-mobl1.

.

------=_Part_1208_569684155.1503439093682
Content-Type: multipart/alternative;
 boundary="----=_Part_1209_1628563254.1503439093682"

------=_Part_1209_1628563254.1503439093682
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 22, 2017 at 12:30:01 PM UTC-4, Thiago Macieira wrote:
>
> On Tuesday, 22 August 2017 08:04:32 PDT Ville Voutilainen wrote:
> > I would seriously entertain the idea of carving out the operations you
> > mentioned, trying
> > to fit std::vector and something like QVector (any third-party vector
> > will do) in terms
> > of those operations, and seeing whether anything's missing. I wonder
> > whether assignment
> > needs something more.
>
> We developed those for Qt 5.0 in QArrayOps with specialisation for
> primitive
> types (can initialise with memset) and for other relocatable types (can
> relocate with memcpy), but they're unused. They operate on ranges. They're
> also supposedly exception-safe, but we've never written the unit-testing
> code
> to confirm that.
>
> But even then they have the same invariant problem: they try to update the
> "size" member of the container.
>

The idea here is that it's the caller's responsibility to keep track of the
size.

When you go to perform reallocation of the vector, you know how big it was
and you know how big the new storage needs to be. And you know how to
allocate that storage. What you need is the ability to say, "here's the
range of stuff that I have, here's where it's going, so
move/copy/memcpy/etc it as appropriate to the type." The function that does
the copying doesn't keep track of the size; you do.

The same goes for insertion operations. If you are inserting 20 new
elements in the middle of the vector, and you have that much additional
space, then you need a function that will shift the existing elements down
by 20 elements. That function is given the start of the shifting range and
the end of that range, plus the number to shift by. You're the one who
keeps track of the size.

That being said, I realize that we would still need one more feature to
handle the OP's needs: the ability to force a `vector` to adopt
pre-initialized memory of a given size/capacity (which also requires that
the vector's given allocator be able to handle that memory).

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b626e21e-06b3-4344-a712-789797bb8d40%40isocpp.org.

------=_Part_1209_1628563254.1503439093682
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 22, 2017 at 12:30:01 PM UTC-4, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday, 22 A=
ugust 2017 08:04:32 PDT Ville Voutilainen wrote:
<br>&gt; I would seriously entertain the idea of carving out the operations=
 you
<br>&gt; mentioned, trying
<br>&gt; to fit std::vector and something like QVector (any third-party vec=
tor
<br>&gt; will do) in terms
<br>&gt; of those operations, and seeing whether anything&#39;s missing. I =
wonder
<br>&gt; whether assignment
<br>&gt; needs something more.
<br>
<br>We developed those for Qt 5.0 in QArrayOps with specialisation for prim=
itive=20
<br>types (can initialise with memset) and for other relocatable types (can=
=20
<br>relocate with memcpy), but they&#39;re unused. They operate on ranges. =
They&#39;re=20
<br>also supposedly exception-safe, but we&#39;ve never written the unit-te=
sting code=20
<br>to confirm that.
<br>
<br>But even then they have the same invariant problem: they try to update =
the=20
<br>&quot;size&quot; member of the container.
<br></blockquote><div><br>The idea here is that it&#39;s the caller&#39;s r=
esponsibility to keep track of the size.<br></div><br>When you go to perfor=
m reallocation of the vector, you know how big it was and you know how big =
the new storage needs to be. And you know how to allocate that storage. Wha=
t you need is the ability to say, &quot;here&#39;s the range of stuff that =
I have, here&#39;s where it&#39;s going, so move/copy/memcpy/etc it as appr=
opriate to the type.&quot; The function that does the copying doesn&#39;t k=
eep track of the size; you do.<br><br>The same goes for insertion operation=
s. If you are inserting 20 new elements in the middle of the vector, and yo=
u have that much additional space, then you need a function that will shift=
 the existing elements down by 20 elements. That function is given the star=
t of the shifting range and the end of that range, plus the number to shift=
 by. You&#39;re the one who keeps track of the size.<br><br>That being said=
, I realize that we would still need one more feature to handle the OP&#39;=
s needs: the ability to force a `vector` to adopt pre-initialized memory of=
 a given size/capacity (which also requires that the vector&#39;s given all=
ocator be able to handle that memory).<br></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b626e21e-06b3-4344-a712-789797bb8d40%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b626e21e-06b3-4344-a712-789797bb8d40=
%40isocpp.org</a>.<br />

------=_Part_1209_1628563254.1503439093682--

------=_Part_1208_569684155.1503439093682--

.

On Tuesday, 22 August 2017 14:58:13 PDT Nicol Bolas wrote:
> On Tuesday, August 22, 2017 at 12:30:01 PM UTC-4, Thiago Macieira wrote:
> > We developed those for Qt 5.0 in QArrayOps with specialisation for
> > primitive
> > types (can initialise with memset) and for other relocatable types (can
> > relocate with memcpy), but they're unused. They operate on ranges. They're
> > also supposedly exception-safe, but we've never written the unit-testing
> > code
> > to confirm that.
> >
> > But even then they have the same invariant problem: they try to update the
> > "size" member of the container.
>
> The idea here is that it's the caller's responsibility to keep track of the
> size.

Right, this is just not how they were designed in 2011/2012. We did not think
to make the algorithms generic; instead, they are supposed to operate on a
container that wraps a QArrayData object.

> When you go to perform reallocation of the vector, you know how big it was
> and you know how big the new storage needs to be. And you know how to
> allocate that storage. What you need is the ability to say, "here's the
> range of stuff that I have, here's where it's going, so
> move/copy/memcpy/etc it as appropriate to the type." The function that does
> the copying doesn't keep track of the size; you do.
>
> The same goes for insertion operations. If you are inserting 20 new
> elements in the middle of the vector, and you have that much additional
> space, then you need a function that will shift the existing elements down
> by 20 elements. That function is given the start of the shifting range and
> the end of that range, plus the number to shift by. You're the one who
> keeps track of the size.

Except if one of the new items throw, in which case you need to shift down.

The way this code was written, it's supposed to be exception-safe without
using try/catch.

> That being said, I realize that we would still need one more feature to
> handle the OP's needs: the ability to force a `vector` to adopt
> pre-initialized memory of a given size/capacity (which also requires that
> the vector's given allocator be able to handle that memory).

True.

I'd imagine if we create a std::dynamic_buffer (which is equivalent to Qt's
QArrayData / QTypedArrayData<T>), then it would take the allocator as a
template & constructor parameter, and std::vector would need to be able to
adopt that buffer as its own.

If that existed, I'd attempt to switch QVector to it, so you can std::move
from std::vector to QVector without memory copy and vice-versa (provided the
QVector object is not shared).

That may not be easy, if in addition to the buffer the container needs to
store some book-keeping information. QVector currently needs to store at least
two further 32-bit fields: one containing flags and one containing the reference
count for the data block. It could be more depending on the flags: one of the
designs in 2012 was so that we could store a function pointer to be called
when the reference count dropped to zero -- the "foreign" allocation case.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1750604.CSntZNyp2C%40tjmaciei-mobl1.

.

------=_Part_9302_201045282.1503448146468
Content-Type: text/plain; charset="UTF-8"

On Tuesday, 22 August 2017 21:48:02 UTC+1, Thiago Macieira  wrote:
> On Tuesday, 22 August 2017 13:40:51 PDT Chris Hallock wrote:
> > On Tuesday, August 22, 2017 at 4:34:02 PM UTC-4, Nevin ":-)" Liber wrote:
> > > On Tue, Aug 22, 2017 at 11:31 AM, Thiago Macieira <thi...@macieira.org
> > >
> > > <javascript:>> wrote:
> > >> > vector<double> v1(1, std::default_init);
> > >> > vector<double> v2(v1);  // is this legal?
> > >>
> > >> I don't see why not. You can copy uninitialised data (think of padding).
> > >
> > > The random bit pattern could be signaling NaN.
> > >
> > > Also, if you have an integer type with a trap representation and you
> > > happen to hit that bit pattern, I believe that copying it would be UB
> > > (memcpy may be able to get away with it, but there is no requirement that
> > > memcpy be used).
> >
> > [dcl.init]/12 <http://eel.is/c++draft/dcl.init#12> makes this UB, in
> > general. [dcl.init]/12.4 <http://eel.is/c++draft/dcl.init#12.4> has this
>
> Thanks, I stand corrected. You're only allowed to evaluate indeterminate
> values so long as it's a narrow character (byte). For any other type, it's UB.
>

This isn't a new problem, though.

vector<double> v1(1);
double d;
memcpy(v1.data(), &d, sizeof(d)); // ok
vector<double> v2(v1); // ub

There is no invariant that a vector does not hold indeterminate values; default_init doesn't change that, though it might make it easier.

And it doesn't have to be intentional:

struct S { double d; S() {} }; // forgot to init d
vector<S> v1;
v1.emplace_back();
vector<S> v2(v1); // ub

> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2c874574-679b-4a43-a1b6-0ca25baa2278%40isocpp.org.

------=_Part_9302_201045282.1503448146468--

.

------=_Part_188_348832488.1503528452518
Content-Type: multipart/alternative;
 boundary="----=_Part_189_1835915170.1503528452518"

------=_Part_189_1835915170.1503528452518
Content-Type: text/plain; charset="UTF-8"

Until you call Alloc::construct using iterators would be UB, yes.

On Sunday, August 20, 2017 at 5:16:15 PM UTC-4, Nicol Bolas wrote:
>
> On Sunday, August 20, 2017 at 4:22:49 PM UTC-4, Ryan Nicholl wrote:
>>
>> One performance problem with std::vector is that elements are always
>> default constructed with resize().
>> While this can be avoided by using a custom allocator, the problem is
>> that this optimization is unavailable for templates that need to work
>> regardless of the underlying allocator type. (so, where your template is
>> provided the vector, and you don't have control of the vector)
>> My motivating example consists of a serialization routine. Ideally, the
>> serialization routine would expand the vector uninitialized and then write
>> the data in. This can't be done however, because the resize function writes
>> 0s to the data thanks to the default allocator's construct method.
>> While the reserve function might help to avoid reallocations, it doesn't
>> stop the checks against capacity and repetitive increments to the size
>> variable.
>>
>> void * std::vector<T, Alloc>::expand_uninitialized(size_t n);
>>
>> This function works like resize(size() + n), but it is the caller's
>> responsibility to call the Allocator::construct method on each element
>> before other operations on the vector. The function returns the beginning
>> of uninitialized memory.
>>
>
> So... what does `vector::size/begin/end` return? Because until you
> actually *construct* those `T`s, for `vector` to include those elements
> in the actual range makes `vector` lie. And it invokes UB, since you
> *cannot* iterate over `T*`s that don't exist.
>
> It'd make a lot more sense just to give us a way to invoke default
> initialization. People keep trying to solve to problem without actually *solving
> the problem*.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ba998905-e8c0-4049-83e1-feabad490271%40isocpp.org.

------=_Part_189_1835915170.1503528452518
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Until you call Alloc::construct using iterators would be U=
B, yes.<br><br>On Sunday, August 20, 2017 at 5:16:15 PM UTC-4, Nicol Bolas =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Sund=
ay, August 20, 2017 at 4:22:49 PM UTC-4, Ryan Nicholl wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr">One performance problem with std:=
:vector is that elements are always default constructed with resize().<br>W=
hile this can be avoided  by using a custom allocator, the problem is that =
this optimization is unavailable for templates that need to work regardless=
 of the underlying allocator type. (so, where your template is provided the=
 vector, and you don&#39;t have control of the vector)<br>My motivating exa=
mple consists of a serialization routine. Ideally, the serialization routin=
e would expand the vector uninitialized and then write the data in. This ca=
n&#39;t be done however, because the resize function writes 0s to the data =
thanks to the default allocator&#39;s construct method.<br>While the reserv=
e function might help to avoid reallocations, it doesn&#39;t stop the check=
s against capacity and repetitive increments to the size variable.<br><br><=
div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187=
);border-style:solid;border-width:1px"><code><div><span style=3D"color:#008=
">void</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
*</span><span style=3D"color:#000"> std</span><span style=3D"color:#660">::=
</span><span style=3D"color:#000">vector</span><span style=3D"color:#660">&=
lt;</span><span style=3D"color:#000">T</span><span style=3D"color:#660">,</=
span><span style=3D"color:#000"> </span><span style=3D"color:#606">Alloc</s=
pan><span style=3D"color:#660">&gt;::</span><span style=3D"color:#000">expa=
nd_uninitialized</span><span style=3D"color:#660">(</span><span style=3D"co=
lor:#000">s<wbr>ize_t n</span><span style=3D"color:#660">);</span><span sty=
le=3D"color:#000"><br></span></div></code></div><br>This function works lik=
e resize(size() + n), but it is the caller&#39;s responsibility to call the=
 Allocator::construct method on each element before other operations on the=
 vector. The function returns the beginning of uninitialized memory.<br></d=
iv></blockquote><div><br>So... what does `vector::size/begin/end` return? B=
ecause until you actually <i>construct</i> those `T`s, for `vector` to incl=
ude those elements in the actual range makes `vector` lie. And it invokes U=
B, since you <i>cannot</i> iterate over `T*`s that don&#39;t exist.<br><br>=
It&#39;d make a lot more sense just to give us a way to invoke default init=
ialization. People keep trying to solve to problem without actually <i>solv=
ing the problem</i>.<br></div></div></blockquote></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ba998905-e8c0-4049-83e1-feabad490271%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ba998905-e8c0-4049-83e1-feabad490271=
%40isocpp.org</a>.<br />

------=_Part_189_1835915170.1503528452518--

------=_Part_188_348832488.1503528452518--

.

------=_Part_195_1276981904.1503528828642
Content-Type: multipart/alternative;
 boundary="----=_Part_196_2055421100.1503528828642"

------=_Part_196_2055421100.1503528828642
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

reserve + push_back does "work" in the sense that you can get the correct=
=20
resulting data. The problem is performance, each invocation of push back=20
incurs a read on capacity, a read on size, a write to size, and a write to=
=20
the data stream. When the function accessing the data stream is recursive,=
=20
the compiler wont be smart enough to optimize these excess unneeded calls=
=20
away.

I was actually wanting to do this for a simple uint8_t case, but the=20
default allocator invokes Alloc::construct which 0s the memory in the=20
resize() case and we have extra reads/writes to size/capacity in the=20
push_back case.

It would be easy to specify that the call to "expand_uninitialized"=20
*suspends* the class invariants and doing anything with the vector other=20
than constructing the elements or reading elements prior to the suspension=
=20
point is UB until all elements are initialized.
Possibly we could change to a T* instead of void*, to avoid aliasing issues=
=20
with the C++ standard.

On Monday, August 21, 2017 at 4:29:49 AM UTC-4, Jonathan M=C3=BCller wrote:
>
> On 20.08.2017 22:22, Ryan Nicholl wrote:=20
> > My motivating example consists of a serialization routine. Ideally, the=
=20
> > serialization routine would expand the vector uninitialized and then=20
> > write the data in. This can't be done however, because the resize=20
> > function writes 0s to the data thanks to the default allocator's=20
> > construct method.=20
>
> Could you clarify why reserve + push_back() doesn't work here?=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d00929bd-af05-46c9-b377-e388b7ca1de6%40isocpp.or=
g.

------=_Part_196_2055421100.1503528828642
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">reserve + push_back does &quot;work&quot; in the sense tha=
t you can get the correct resulting data. The problem is performance, each =
invocation of push back incurs a read on capacity, a read on size, a write =
to size, and a write to the data stream. When the function accessing the da=
ta stream is recursive, the compiler wont be smart enough to optimize these=
 excess unneeded calls away.<br><br>I was actually wanting to do this for a=
 simple uint8_t case, but the default allocator invokes Alloc::construct wh=
ich 0s the memory in the resize() case and we have extra reads/writes to si=
ze/capacity in the push_back case.<br><br>It would be easy to specify that =
the call to &quot;expand_uninitialized&quot; <i>suspends</i> the class inva=
riants and doing anything with the vector other than constructing the eleme=
nts or reading elements prior to the suspension point is UB until all eleme=
nts are initialized.<br>Possibly we could change to a T* instead of void*, =
to avoid aliasing issues with the C++ standard.<br><br>On Monday, August 21=
, 2017 at 4:29:49 AM UTC-4, Jonathan M=C3=BCller wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">On 20.08.2017 22:22, Ryan Nicholl wrote:
<br>&gt; My motivating example consists of a serialization routine. Ideally=
, the=20
<br>&gt; serialization routine would expand the vector uninitialized and th=
en=20
<br>&gt; write the data in. This can&#39;t be done however, because the res=
ize=20
<br>&gt; function writes 0s to the data thanks to the default allocator&#39=
;s=20
<br>&gt; construct method.
<br>
<br>Could you clarify why reserve + push_back() doesn&#39;t work here?
<br>
<br></blockquote></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d00929bd-af05-46c9-b377-e388b7ca1de6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d00929bd-af05-46c9-b377-e388b7ca1de6=
%40isocpp.org</a>.<br />

------=_Part_196_2055421100.1503528828642--

------=_Part_195_1276981904.1503528828642--

.

--Apple-Mail=_F0D7C06B-467A-423C-A933-11912784297F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

> On Aug 22, 2017, at 11:32 AM, std-proposals@isocpp.org wrote:
>=20
> It seems to me that we might want to consider adding a building block of =
lower level than vector. vector has always been a compromise, with certain =
overhead in some of its operations.
> Perhaps we should have a dynamic buffer that=E2=80=99s not trying to be s=
afe to use, and makes no compromises on speed. Such a type can still do aut=
omatic cleanup and automatic buffer growth, so it would not be just a raw a=
rray.
> =20
> The reason for that suggestion is that different use cases use different =
trade-offs, and it=E2=80=99s difficult to cover a significant fraction of t=
he various use cases, but at least we could perhaps provide a low-level uti=
lity that can be a building block for all of them. Trying to fix vector=E2=
=80=99s performance problems one by one runs the risk of breaking vector=E2=
=80=99s class invariants, which (all of them) somebody somewhere is bound t=
o rely on, so I=E2=80=99d expect fair amounts of resistance to such an appr=
oach.

     For some reason, this sounds like one reason to investigate reviving t=
he currently still abandoned Array Fundamentals TS idea=E2=80=A6

Just a friendly lurker,=20
     Bryce Glover
     RandomDSdevel@gmail.com

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/76F34900-7586-4CCC-8F79-AAEFE36B519E%40gmail.com=
..

--Apple-Mail=_F0D7C06B-467A-423C-A933-11912784297F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D"">On Aug 22, 2017, at 11:32 AM, <a hr=
ef=3D"mailto:std-proposals@isocpp.org" class=3D"">std-proposals@isocpp.org<=
/a> wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><sp=
an style=3D"color: rgb(46, 46, 46); font-family: arial; font-size: inherit;=
 font-style: normal; font-variant-caps: normal; font-weight: normal; letter=
-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-=
transform: none; white-space: normal; widows: auto; word-spacing: 0px; -web=
kit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); float: no=
ne; display: inline !important;" class=3D"">It seems to me that we might wa=
nt to consider adding a building block&nbsp;</span><span style=3D"color: rg=
b(46, 46, 46); font-family: arial; font-size: inherit; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orp=
hans: auto; text-align: start; text-indent: 0px; text-transform: none; whit=
e-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width=
: 0px; background-color: rgb(255, 255, 255); float: none; display: inline !=
important;" class=3D"">of lower level than&nbsp;</span><span style=3D"color=
: rgb(46, 46, 46); font-family: arial; font-size: inherit; font-style: norm=
al; font-variant-caps: normal; font-weight: normal; letter-spacing: normal;=
 orphans: auto; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-w=
idth: 0px; background-color: rgb(255, 255, 255); float: none; display: inli=
ne !important;" class=3D"">vector. vector has always been a compromise, wit=
h certain overhead in&nbsp;</span><span style=3D"color: rgb(46, 46, 46); fo=
nt-family: arial; font-size: inherit; font-style: normal; font-variant-caps=
: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-=
align: start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background=
-color: rgb(255, 255, 255); float: none; display: inline !important;" class=
=3D"">some of its operations.</span><br style=3D"color: rgb(46, 46, 46); fo=
nt-family: arial; font-style: normal; font-variant-caps: normal; font-weigh=
t: normal; letter-spacing: normal; orphans: auto; text-align: start; text-i=
ndent: 0px; text-transform: none; white-space: normal; widows: auto; word-s=
pacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255=
, 255);" class=3D""><span style=3D"color: rgb(46, 46, 46); font-family: ari=
al; font-size: inherit; font-style: normal; font-variant-caps: normal; font=
-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(25=
5, 255, 255); float: none; display: inline !important;" class=3D"">Perhaps =
we should have a dynamic buffer that=E2=80=99s not trying to be safe&nbsp;<=
/span><span style=3D"color: rgb(46, 46, 46); font-family: arial; font-size:=
 inherit; font-style: normal; font-variant-caps: normal; font-weight: norma=
l; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0=
px; text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); =
float: none; display: inline !important;" class=3D"">to use, and makes&nbsp=
;</span><span style=3D"color: rgb(46, 46, 46); font-family: arial; font-siz=
e: inherit; font-style: normal; font-variant-caps: normal; font-weight: nor=
mal; letter-spacing: normal; orphans: auto; text-align: start; text-indent:=
 0px; text-transform: none; white-space: normal; widows: auto; word-spacing=
: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255)=
; float: none; display: inline !important;" class=3D"">no compromises on sp=
eed. Such a type can still do automatic cleanup&nbsp;</span><span style=3D"=
color: rgb(46, 46, 46); font-family: arial; font-size: inherit; font-style:=
 normal; font-variant-caps: normal; font-weight: normal; letter-spacing: no=
rmal; orphans: auto; text-align: start; text-indent: 0px; text-transform: n=
one; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-str=
oke-width: 0px; background-color: rgb(255, 255, 255); float: none; display:=
 inline !important;" class=3D"">and automatic&nbsp;</span><span style=3D"co=
lor: rgb(46, 46, 46); font-family: arial; font-size: inherit; font-style: n=
ormal; font-variant-caps: normal; font-weight: normal; letter-spacing: norm=
al; orphans: auto; text-align: start; text-indent: 0px; text-transform: non=
e; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-strok=
e-width: 0px; background-color: rgb(255, 255, 255); float: none; display: i=
nline !important;" class=3D"">buffer growth, so it would not be just a raw =
array.</span><br style=3D"color: rgb(46, 46, 46); font-family: arial; font-=
style: normal; font-variant-caps: normal; font-weight: normal; letter-spaci=
ng: normal; orphans: auto; text-align: start; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px; background-color: rgb(255, 255, 255);" class=3D""><sp=
an style=3D"color: rgb(46, 46, 46); font-family: arial; font-size: inherit;=
 font-style: normal; font-variant-caps: normal; font-weight: normal; letter=
-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-=
transform: none; white-space: normal; widows: auto; word-spacing: 0px; -web=
kit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); float: no=
ne; display: inline !important;" class=3D"">&nbsp;</span><br style=3D"color=
: rgb(46, 46, 46); font-family: arial; font-style: normal; font-variant-cap=
s: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
 widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; backgroun=
d-color: rgb(255, 255, 255);" class=3D""><span style=3D"color: rgb(46, 46, =
46); font-family: arial; font-size: inherit; font-style: normal; font-varia=
nt-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; bac=
kground-color: rgb(255, 255, 255); float: none; display: inline !important;=
" class=3D"">The reason for that suggestion is that different use cases use=
&nbsp;</span><span style=3D"color: rgb(46, 46, 46); font-family: arial; fon=
t-size: inherit; font-style: normal; font-variant-caps: normal; font-weight=
: normal; letter-spacing: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,=
 255); float: none; display: inline !important;" class=3D"">different trade=
-offs, and it=E2=80=99s&nbsp;</span><span style=3D"color: rgb(46, 46, 46); =
font-family: arial; font-size: inherit; font-style: normal; font-variant-ca=
ps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; backgrou=
nd-color: rgb(255, 255, 255); float: none; display: inline !important;" cla=
ss=3D"">difficult to cover a significant fraction of the various use cases,=
&nbsp;</span><span style=3D"color: rgb(46, 46, 46); font-family: arial; fon=
t-size: inherit; font-style: normal; font-variant-caps: normal; font-weight=
: normal; letter-spacing: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,=
 255); float: none; display: inline !important;" class=3D"">but at least we=
 could perhaps&nbsp;</span><span style=3D"color: rgb(46, 46, 46); font-fami=
ly: arial; font-size: inherit; font-style: normal; font-variant-caps: norma=
l; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; widows:=
 auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color:=
 rgb(255, 255, 255); float: none; display: inline !important;" class=3D"">p=
rovide a low-level utility that can be a building block for all of&nbsp;</s=
pan><span style=3D"color: rgb(46, 46, 46); font-family: arial; font-size: i=
nherit; font-style: normal; font-variant-caps: normal; font-weight: normal;=
 letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px=
; text-transform: none; white-space: normal; widows: auto; word-spacing: 0p=
x; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); fl=
oat: none; display: inline !important;" class=3D"">them. Trying to fix vect=
or=E2=80=99s performance&nbsp;</span><span style=3D"color: rgb(46, 46, 46);=
 font-family: arial; font-size: inherit; font-style: normal; font-variant-c=
aps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; te=
xt-align: start; text-indent: 0px; text-transform: none; white-space: norma=
l; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; backgro=
und-color: rgb(255, 255, 255); float: none; display: inline !important;" cl=
ass=3D"">problems one by one runs the risk of breaking vector=E2=80=99s cla=
ss&nbsp;</span><span style=3D"color: rgb(46, 46, 46); font-family: arial; f=
ont-size: inherit; font-style: normal; font-variant-caps: normal; font-weig=
ht: normal; letter-spacing: normal; orphans: auto; text-align: start; text-=
indent: 0px; text-transform: none; white-space: normal; widows: auto; word-=
spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 25=
5, 255); float: none; display: inline !important;" class=3D"">invariants, w=
hich (all of them) somebody&nbsp;</span><span style=3D"color: rgb(46, 46, 4=
6); font-family: arial; font-size: inherit; font-style: normal; font-varian=
t-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto;=
 text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; back=
ground-color: rgb(255, 255, 255); float: none; display: inline !important;"=
 class=3D"">somewhere is bound to rely on, so I=E2=80=99d expect fair amoun=
ts of&nbsp;</span><span style=3D"color: rgb(46, 46, 46); font-family: arial=
; font-size: inherit; font-style: normal; font-variant-caps: normal; font-w=
eight: normal; letter-spacing: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255,=
 255, 255); float: none; display: inline !important;" class=3D"">resistance=
 to such an approach.</span></div></blockquote></div><br class=3D""><div cl=
ass=3D"">&nbsp; &nbsp; &nbsp;For some reason, this sounds like one reason t=
o investigate reviving the currently still abandoned Array Fundamentals TS =
idea=E2=80=A6</div><br class=3D""><div class=3D"">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-w=
rap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-=
space;" class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-=
break: after-white-space;" class=3D""><div style=3D"color: rgb(0, 0, 0); le=
tter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; t=
ext-transform: none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">Ju=
st a friendly lurker,&nbsp;</div><div class=3D"">&nbsp; &nbsp; &nbsp;Bryce =
Glover</div><div class=3D"">&nbsp; &nbsp; &nbsp;<a href=3D"mailto:RandomDSd=
evel@gmail.com" class=3D"">RandomDSdevel@gmail.com</a></div></div></div></d=
iv></div></body></html>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/76F34900-7586-4CCC-8F79-AAEFE36B519E%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/76F34900-7586-4CCC-8F79-AAEFE36B519E%=
40gmail.com</a>.<br />

--Apple-Mail=_F0D7C06B-467A-423C-A933-11912784297F--

.

------=_Part_1034_1095822872.1503614604808
Content-Type: multipart/alternative;
 boundary="----=_Part_1035_325380517.1503614604808"

------=_Part_1035_325380517.1503614604808
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

My entire problem is that I can't make my template work for people already=
=20
using std::vector. Since I don't control the input type to the template,=20
but I expect a vector back insert iterator to be a common enough case to=20
specialize the template for. What I'm trying to say is that there should be=
=20
a way to improve performance without using a non-vector type.

I agree that an exception could pose a problem (not for=20
std::vector<uint8_t> though,  which is the motivating case for me, since=20
uint8_t never throws exceptions) but this can be solved by adding:
void shrink_uninitialized(size_t n);

Thus, if you want to gain the benefits of expand_uninitialized with a type=
=20
that can throw, the procedure is as follows:
(1) expand
(2) loop with try catch(...) block to construct every element
(3) in event of failure, call destructors for any extra elements that were=
=20
added and then do shrink_uninitialized.
(4) [optional] use saved exception_ptr and throw it

On Thursday, August 24, 2017 at 6:13:22 PM UTC-4, Bryce Glover wrote:
>
> On Aug 22, 2017, at 11:32 AM, std-pr...@isocpp.org <javascript:> wrote:
>
> It seems to me that we might want to consider adding a building block of=
=20
> lower level than vector. vector has always been a compromise, with=20
> certain overhead in some of its operations.
> Perhaps we should have a dynamic buffer that=E2=80=99s not trying to be s=
afe to=20
> use, and makes no compromises on speed. Such a type can still do=20
> automatic cleanup and automatic buffer growth, so it would not be just a=
=20
> raw array.
> =20
> The reason for that suggestion is that different use cases use different=
=20
> trade-offs, and it=E2=80=99s difficult to cover a significant fraction of=
 the=20
> various use cases, but at least we could perhaps provide a low-level=20
> utility that can be a building block for all of them. Trying to fix=20
> vector=E2=80=99s performance problems one by one runs the risk of breakin=
g=20
> vector=E2=80=99s class invariants, which (all of them) somebody somewhere=
 is=20
> bound to rely on, so I=E2=80=99d expect fair amounts of resistance to suc=
h an=20
> approach.
>
>
>      For some reason, this sounds like one reason to investigate reviving=
=20
> the currently still abandoned Array Fundamentals TS idea=E2=80=A6
>
> Just a friendly lurker,=20
>      Bryce Glover
>      Random...@gmail.com <javascript:>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/48c3a699-2ced-4df9-a3a6-031768132a62%40isocpp.or=
g.

------=_Part_1035_325380517.1503614604808
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">My entire problem is that I can&#39;t make my template wor=
k for people already using std::vector. Since I don&#39;t control the input=
 type to the template, but I expect a vector back insert iterator to be a c=
ommon enough case to specialize the template for. What I&#39;m trying to sa=
y is that there should be a way to improve performance without using a non-=
vector type.<br><br>I agree that an exception could pose a problem (not for=
 std::vector&lt;uint8_t&gt; though,=C2=A0 which is the motivating case for =
me, since uint8_t never throws exceptions) but this can be solved by adding=
:<br><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: brea=
k-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">voi=
d</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> shrink_u=
ninitialized</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">size_t =
n</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div>=
</code></div><br>Thus, if you want to gain the benefits of expand_uninitial=
ized with a type that can throw, the procedure is as follows:<br>(1) expand=
<br>(2) loop with try catch(...) block to construct every element<br>(3) in=
 event of failure, call destructors for any extra elements that were added =
and then do shrink_uninitialized.<br>(4) [optional] use saved exception_ptr=
 and throw it<br><br>On Thursday, August 24, 2017 at 6:13:22 PM UTC-4, Bryc=
e Glover wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"w=
ord-wrap:break-word"><div><blockquote type=3D"cite"><div>On Aug 22, 2017, a=
t 11:32 AM, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"fbl4amN0CwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;">std-pr...@isocpp.org</a> wrote:</div><br><div><span style=3D"color:r=
gb(46,46,46);font-family:arial;font-size:inherit;font-style:normal;font-wei=
ght:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-tran=
sform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255=
,255);float:none;display:inline!important">It seems to me that we might wan=
t to consider adding a building block=C2=A0</span><span style=3D"color:rgb(=
46,46,46);font-family:arial;font-size:inherit;font-style:normal;font-weight=
:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transfo=
rm:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,25=
5);float:none;display:inline!important">of lower level than=C2=A0</span><sp=
an style=3D"color:rgb(46,46,46);font-family:arial;font-size:inherit;font-st=
yle:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-i=
ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgroun=
d-color:rgb(255,255,255);float:none;display:inline!important">vector. vecto=
r has always been a compromise, with certain overhead in=C2=A0</span><span =
style=3D"color:rgb(46,46,46);font-family:arial;font-size:inherit;font-style=
:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-inde=
nt:0px;text-transform:none;white-space:normal;word-spacing:0px;background-c=
olor:rgb(255,255,255);float:none;display:inline!important">some of its oper=
ations.</span><br style=3D"color:rgb(46,46,46);font-family:arial;font-style=
:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-inde=
nt:0px;text-transform:none;white-space:normal;word-spacing:0px;background-c=
olor:rgb(255,255,255)"><span style=3D"color:rgb(46,46,46);font-family:arial=
;font-size:inherit;font-style:normal;font-weight:normal;letter-spacing:norm=
al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inlin=
e!important">Perhaps we should have a dynamic buffer that=E2=80=99s not try=
ing to be safe=C2=A0</span><span style=3D"color:rgb(46,46,46);font-family:a=
rial;font-size:inherit;font-style:normal;font-weight:normal;letter-spacing:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:i=
nline!important">to use, and makes=C2=A0</span><span style=3D"color:rgb(46,=
46,46);font-family:arial;font-size:inherit;font-style:normal;font-weight:no=
rmal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:=
none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);=
float:none;display:inline!important">no compromises on speed. Such a type c=
an still do automatic cleanup=C2=A0</span><span style=3D"color:rgb(46,46,46=
);font-family:arial;font-size:inherit;font-style:normal;font-weight:normal;=
letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;=
white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float=
:none;display:inline!important">and automatic=C2=A0</span><span style=3D"co=
lor:rgb(46,46,46);font-family:arial;font-size:inherit;font-style:normal;fon=
t-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(25=
5,255,255);float:none;display:inline!important">buffer growth, so it would =
not be just a raw array.</span><br style=3D"color:rgb(46,46,46);font-family=
:arial;font-style:normal;font-weight:normal;letter-spacing:normal;text-alig=
n:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing=
:0px;background-color:rgb(255,255,255)"><span style=3D"color:rgb(46,46,46);=
font-family:arial;font-size:inherit;font-style:normal;font-weight:normal;le=
tter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;wh=
ite-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:n=
one;display:inline!important">=C2=A0</span><br style=3D"color:rgb(46,46,46)=
;font-family:arial;font-style:normal;font-weight:normal;letter-spacing:norm=
al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px;background-color:rgb(255,255,255)"><span style=3D"color:rg=
b(46,46,46);font-family:arial;font-size:inherit;font-style:normal;font-weig=
ht:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-trans=
form:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,=
255);float:none;display:inline!important">The reason for that suggestion is=
 that different use cases use=C2=A0</span><span style=3D"color:rgb(46,46,46=
);font-family:arial;font-size:inherit;font-style:normal;font-weight:normal;=
letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;=
white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float=
:none;display:inline!important">different trade-offs, and it=E2=80=99s=C2=
=A0</span><span style=3D"color:rgb(46,46,46);font-family:arial;font-size:in=
herit;font-style:normal;font-weight:normal;letter-spacing:normal;text-align=
:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:=
0px;background-color:rgb(255,255,255);float:none;display:inline!important">=
difficult to cover a significant fraction of the various use cases,=C2=A0</=
span><span style=3D"color:rgb(46,46,46);font-family:arial;font-size:inherit=
;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:star=
t;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;b=
ackground-color:rgb(255,255,255);float:none;display:inline!important">but a=
t least we could perhaps=C2=A0</span><span style=3D"color:rgb(46,46,46);fon=
t-family:arial;font-size:inherit;font-style:normal;font-weight:normal;lette=
r-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white=
-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:none=
;display:inline!important">provide a low-level utility that can be a buildi=
ng block for all of=C2=A0</span><span style=3D"color:rgb(46,46,46);font-fam=
ily:arial;font-size:inherit;font-style:normal;font-weight:normal;letter-spa=
cing:normal;text-align:start;text-indent:0px;text-transform:none;white-spac=
e:normal;word-spacing:0px;background-color:rgb(255,255,255);float:none;disp=
lay:inline!important">them. Trying to fix vector=E2=80=99s performance=C2=
=A0</span><span style=3D"color:rgb(46,46,46);font-family:arial;font-size:in=
herit;font-style:normal;font-weight:normal;letter-spacing:normal;text-align=
:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:=
0px;background-color:rgb(255,255,255);float:none;display:inline!important">=
problems one by one runs the risk of breaking vector=E2=80=99s class=C2=A0<=
/span><span style=3D"color:rgb(46,46,46);font-family:arial;font-size:inheri=
t;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;=
background-color:rgb(255,255,255);float:none;display:inline!important">inva=
riants, which (all of them) somebody=C2=A0</span><span style=3D"color:rgb(4=
6,46,46);font-family:arial;font-size:inherit;font-style:normal;font-weight:=
normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255=
);float:none;display:inline!important">somewhere is bound to rely on, so I=
=E2=80=99d expect fair amounts of=C2=A0</span><span style=3D"color:rgb(46,4=
6,46);font-family:arial;font-size:inherit;font-style:normal;font-weight:nor=
mal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:n=
one;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);f=
loat:none;display:inline!important">resistance to such an approach.</span><=
/div></blockquote></div><br><div>=C2=A0 =C2=A0 =C2=A0For some reason, this =
sounds like one reason to investigate reviving the currently still abandone=
d Array Fundamentals TS idea=E2=80=A6</div><br><div>
<div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-=
indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wra=
p:break-word"><div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-ali=
gn:start;text-indent:0px;text-transform:none;white-space:normal;word-spacin=
g:0px;word-wrap:break-word"><div style=3D"color:rgb(0,0,0);letter-spacing:n=
ormal;text-align:start;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px;word-wrap:break-word"><div>Just a friendly lurker,=C2=
=A0</div><div>=C2=A0 =C2=A0 =C2=A0Bryce Glover</div><div>=C2=A0 =C2=A0 =C2=
=A0<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"fbl4a=
mN0CwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;=
return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">Ra=
ndom...@gmail.com</a></div></div></div></div></div></div></blockquote></div=
>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/48c3a699-2ced-4df9-a3a6-031768132a62%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/48c3a699-2ced-4df9-a3a6-031768132a62=
%40isocpp.org</a>.<br />

------=_Part_1035_325380517.1503614604808--

------=_Part_1034_1095822872.1503614604808--

.

------=_Part_2210_826508851.1503698405541
Content-Type: multipart/alternative;
 boundary="----=_Part_2211_1406483047.1503698405542"

------=_Part_2211_1406483047.1503698405542
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think that the easiest solution to this would be to introduce a new=20
method overload in std::allocator:

    construct(char* mem, std::default_init_t) { new(mem) value_type; }   =
=20
// Note: No trailing () on value_type so default construct.

This would have the effect of calling the default constructor if there is=
=20
one, and not initializing the memory if there isn't.

There could be no issues with constructor exceptions as the only time this=
=20
has any other behaviour than a construct is when there _isn't_ any default=
=20
constructor. I'm pretty sure that when there is no code to run no=20
exceptions will be thrown.

This leaves the case with this non-construction happening to result in a=20
signaling NaN or trap integer value, which later gets copied in a further=
=20
vector resize. But as mentioned earlier in this thread there are many other=
=20
ways to cause this type of UB, the simplest being:

double a;
double b =3D a;   // UB.

I tried googling copying of signaling NaN. What I came up with is that for=
=20
IEE754 floats a signaling NaN _may_ cause an exception when it occurs as=20
the parameter of an _arithmetic operation_. Whether copying is an operation=
=20
is unclear, but I would think that calling copy an arithmetic operation=20
would be a long stretch. I could not find any explicit mention of whether=
=20
it was allowed that copying a signalling NaN would raise an exception or=20
not. The only thing we can be really sure of is that it doesn't happen all=
=20
the time as compilers are not required to copy doubles using CPU=20
instructions specifically designed to copy floating point numbers.

When it comes to integer traps I dare anyone to find a C++ compiler under=
=20
active development that supports an architecture which reserves particular=
=20
integer values as invalid. Compilers without active development are=20
unlikely to support C++20 or later anyway.

Given these circumstances I think we can ignore the programmer safety=20
aspects of allowing resizing vectors to contain default constructed=20
elements, as long as it is an opt-in feature.

My proposed way of doing this may not be optimal but it is simple. It does=
=20
not automatically give custom allocators this ability but it is trivial to=
=20
add it to any custom allocators you have. It does give custom containers=20
this ability as long as they use standard the standard's allocator ideas.=
=20
It does not require any core language changes and does not affect code that=
=20
does not use the new std::default_init_t type.

Nicol's idea with connecting the std::default_init_t type to special core=
=20
language behaviour has the advantage of reaching automatically to custom=20
allocators and classes that construct elements in other ways. As these=20
classes are more likely to rely on the actual values stored in them and=20
they have no way to protect themselves from being called with the=20
default_init_t type this poses a somewhat elevated risk compared to my=20
proposal. Also, the inversion between library and core language this=20
presents is ugly, although there is some precedent (such as=20
initializer_list). Here is an example of a class that can get into trouble:

struct MyClass {
    double v;
    template<typename T> MyClass(T&& val) : v(std::forward<T>(val)) {
        assert(!std::isnan(v));
    }
};

Currently this test will check if you explicitly sent a nan value to the=20
constructor while in the future you can get unlucky if you do:

    MyClass myValue(std::default_init);

as a speed optimization of the current declaration:

    MyClass myValue;    // myValue.v is inited to 0

With Nicol's proposal in effect. I think this risk is small as you actively=
=20
have to want to be "smart" and save an initialization to get into trouble,=
=20
but the risk is definitely smaller than with my proposal which only affects=
=20
containers using the std::allocator class.

Overall I think this is a problem worth addressing, and I would be willing=
=20
to help write a proposal if need be.


Den fredag 25 augusti 2017 kl. 00:43:24 UTC+2 skrev Ryan Nicholl:
>
> My entire problem is that I can't make my template work for people alread=
y=20
> using std::vector. Since I don't control the input type to the template,=
=20
> but I expect a vector back insert iterator to be a common enough case to=
=20
> specialize the template for. What I'm trying to say is that there should =
be=20
> a way to improve performance without using a non-vector type.
>
> I agree that an exception could pose a problem (not for=20
> std::vector<uint8_t> though,  which is the motivating case for me, since=
=20
> uint8_t never throws exceptions) but this can be solved by adding:
> void shrink_uninitialized(size_t n);
>
> Thus, if you want to gain the benefits of expand_uninitialized with a typ=
e=20
> that can throw, the procedure is as follows:
> (1) expand
> (2) loop with try catch(...) block to construct every element
> (3) in event of failure, call destructors for any extra elements that wer=
e=20
> added and then do shrink_uninitialized.
> (4) [optional] use saved exception_ptr and throw it
>
> On Thursday, August 24, 2017 at 6:13:22 PM UTC-4, Bryce Glover wrote:
>>
>> On Aug 22, 2017, at 11:32 AM, std-pr...@isocpp.org wrote:
>>
>> It seems to me that we might want to consider adding a building block of=
=20
>> lower level than vector. vector has always been a compromise, with=20
>> certain overhead in some of its operations.
>> Perhaps we should have a dynamic buffer that=E2=80=99s not trying to be =
safe to=20
>> use, and makes no compromises on speed. Such a type can still do=20
>> automatic cleanup and automatic buffer growth, so it would not be just a=
=20
>> raw array.
>> =20
>> The reason for that suggestion is that different use cases use different=
=20
>> trade-offs, and it=E2=80=99s difficult to cover a significant fraction o=
f the=20
>> various use cases, but at least we could perhaps provide a low-level=20
>> utility that can be a building block for all of them. Trying to fix=20
>> vector=E2=80=99s performance problems one by one runs the risk of breaki=
ng=20
>> vector=E2=80=99s class invariants, which (all of them) somebody somewher=
e is=20
>> bound to rely on, so I=E2=80=99d expect fair amounts of resistance to su=
ch an=20
>> approach.
>>
>>
>>      For some reason, this sounds like one reason to investigate revivin=
g=20
>> the currently still abandoned Array Fundamentals TS idea=E2=80=A6
>>
>> Just a friendly lurker,=20
>>      Bryce Glover
>>      Random...@gmail.com
>>
>

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/217d3451-be54-40b9-9f51-d9c8d94b2341%40isocpp.or=
g.

------=_Part_2211_1406483047.1503698405542
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think that the easiest solution to this would be to intr=
oduce a new method overload in std::allocator:<div><br></div><div>=C2=A0 =
=C2=A0 construct(char* mem, std::default_init_t) { new(mem) value_type; }=
=C2=A0 =C2=A0 // Note: No trailing () on value_type so default construct.</=
div><div><br></div><div>This would have the effect of calling the default c=
onstructor if there is one, and not initializing the memory if there isn&#3=
9;t.</div><div><br></div><div>There could be no issues with constructor exc=
eptions as the only time this has any other behaviour than a construct is w=
hen there _isn&#39;t_ any default constructor. I&#39;m pretty sure that whe=
n there is no code to run no exceptions will be thrown.</div><div><br></div=
><div>This leaves the case with this non-construction happening to result i=
n a signaling NaN or trap integer value, which later gets copied in a furth=
er vector resize. But as mentioned earlier in this thread there are many ot=
her ways to cause this type of UB, the simplest being:</div><div><br></div>=
<div>double a;</div><div>double b =3D a;=C2=A0 =C2=A0// UB.</div><div><br><=
/div><div>I tried googling copying of signaling NaN. What I came up with is=
 that for IEE754 floats a signaling NaN _may_ cause an exception when it oc=
curs as the parameter of an _arithmetic operation_. Whether copying is an o=
peration is unclear, but I would think that calling copy an arithmetic oper=
ation would be a long stretch. I could not find any explicit mention of whe=
ther it was allowed that copying a signalling NaN would raise an exception =
or not. The only thing we can be really sure of is that it doesn&#39;t happ=
en all the time as compilers are not required to copy doubles using CPU ins=
tructions specifically designed to copy floating point numbers.<br></div><d=
iv><br></div><div>When it comes to integer traps I dare anyone to find a C+=
+ compiler under active development that supports an architecture which res=
erves particular integer values as invalid. Compilers without active develo=
pment are unlikely to support C++20 or later anyway.</div><div><br></div><d=
iv>Given these circumstances I think we can ignore the programmer safety as=
pects of allowing resizing vectors to contain default constructed elements,=
 as long as it is an opt-in feature.</div><div><br></div><div>My proposed w=
ay of doing this may not be optimal but it is simple. It does not automatic=
ally give custom allocators this ability but it is trivial to add it to any=
 custom allocators you have. It does give custom containers this ability as=
 long as they use standard the standard&#39;s allocator ideas. It does not =
require any core language changes and does not affect code that does not us=
e the new std::default_init_t type.</div><div><br></div><div>Nicol&#39;s id=
ea with connecting the std::default_init_t type to special core language be=
haviour has the advantage of reaching automatically to custom allocators an=
d classes that construct elements in other ways. As these classes are more =
likely to rely on the actual values stored in them and they have no way to =
protect themselves from being called with the default_init_t type this pose=
s a somewhat elevated risk compared to my proposal. Also, the inversion bet=
ween library and core language this presents is ugly, although there is som=
e precedent (such as initializer_list). Here is an example of a class that =
can get into trouble:</div><div><br></div><div>struct MyClass {</div><div>=
=C2=A0 =C2=A0 double v;</div><div>=C2=A0 =C2=A0 template&lt;typename T&gt; =
MyClass(T&amp;&amp; val) : v(std::forward&lt;T&gt;(val)) {</div><div>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 assert(!std::isnan(v));</div><div>=C2=A0 =C2=A0 }</di=
v><div>};</div><div><br></div><div>Currently this test will check if you ex=
plicitly sent a nan value to the constructor while in the future you can ge=
t unlucky if you do:</div><div><br></div><div>=C2=A0 =C2=A0 MyClass myValue=
(std::default_init);</div><div><br></div><div>as a speed optimization of th=
e current declaration:</div><div><br></div><div>=C2=A0 =C2=A0 MyClass myVal=
ue;=C2=A0 =C2=A0 // myValue.v is inited to 0</div><div><br></div><div>With =
Nicol&#39;s proposal in effect. I think this risk is small as you actively =
have to want to be &quot;smart&quot; and save an initialization to get into=
 trouble, but the risk is definitely smaller than with my proposal which on=
ly affects containers using the std::allocator class.</div><div><br></div><=
div>Overall I think this is a problem worth addressing, and I would be will=
ing to help write a proposal if need be.</div><div><br><br>Den fredag 25 au=
gusti 2017 kl. 00:43:24 UTC+2 skrev Ryan Nicholl:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr">My entire problem is that I can&#39;t m=
ake my template work for people already using std::vector. Since I don&#39;=
t control the input type to the template, but I expect a vector back insert=
 iterator to be a common enough case to specialize the template for. What I=
&#39;m trying to say is that there should be a way to improve performance w=
ithout using a non-vector type.<br><br>I agree that an exception could pose=
 a problem (not for std::vector&lt;uint8_t&gt; though,=C2=A0 which is the m=
otivating case for me, since uint8_t never throws exceptions) but this can =
be solved by adding:<br><div style=3D"background-color:rgb(250,250,250);bor=
der-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div>=
<span style=3D"color:#008">void</span><span style=3D"color:#000"> shrink_un=
initialized</span><span style=3D"color:#660">(</span><span style=3D"color:#=
000">size_t n</span><span style=3D"color:#660">);</span><span style=3D"colo=
r:#000"><br></span></div></code></div><br>Thus, if you want to gain the ben=
efits of expand_uninitialized with a type that can throw, the procedure is =
as follows:<br>(1) expand<br>(2) loop with try catch(...) block to construc=
t every element<br>(3) in event of failure, call destructors for any extra =
elements that were added and then do shrink_uninitialized.<br>(4) [optional=
] use saved exception_ptr and throw it<br><br>On Thursday, August 24, 2017 =
at 6:13:22 PM UTC-4, Bryce Glover wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div style=3D"word-wrap:break-word"><div><blockquote type=3D"cite"><di=
v>On Aug 22, 2017, at 11:32 AM, <a rel=3D"nofollow">std-pr...@isocpp.org</a=
> wrote:</div><br><div><span style=3D"color:rgb(46,46,46);font-family:arial=
;font-size:inherit;font-style:normal;font-weight:normal;letter-spacing:norm=
al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inlin=
e!important">It seems to me that we might want to consider adding a buildin=
g block=C2=A0</span><span style=3D"color:rgb(46,46,46);font-family:arial;fo=
nt-size:inherit;font-style:normal;font-weight:normal;letter-spacing:normal;=
text-align:start;text-indent:0px;text-transform:none;white-space:normal;wor=
d-spacing:0px;background-color:rgb(255,255,255);float:none;display:inline!i=
mportant">of lower level than=C2=A0</span><span style=3D"color:rgb(46,46,46=
);font-family:arial;font-size:inherit;font-style:normal;font-weight:normal;=
letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;=
white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float=
:none;display:inline!important">vector. vector has always been a compromise=
, with certain overhead in=C2=A0</span><span style=3D"color:rgb(46,46,46);f=
ont-family:arial;font-size:inherit;font-style:normal;font-weight:normal;let=
ter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;whi=
te-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:no=
ne;display:inline!important">some of its operations.</span><br style=3D"col=
or:rgb(46,46,46);font-family:arial;font-style:normal;font-weight:normal;let=
ter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;whi=
te-space:normal;word-spacing:0px;background-color:rgb(255,255,255)"><span s=
tyle=3D"color:rgb(46,46,46);font-family:arial;font-size:inherit;font-style:=
normal;font-weight:normal;letter-spacing:normal;text-align:start;text-inden=
t:0px;text-transform:none;white-space:normal;word-spacing:0px;background-co=
lor:rgb(255,255,255);float:none;display:inline!important">Perhaps we should=
 have a dynamic buffer that=E2=80=99s not trying to be safe=C2=A0</span><sp=
an style=3D"color:rgb(46,46,46);font-family:arial;font-size:inherit;font-st=
yle:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-i=
ndent:0px;text-transform:none;white-space:normal;word-spacing:0px;backgroun=
d-color:rgb(255,255,255);float:none;display:inline!important">to use, and m=
akes=C2=A0</span><span style=3D"color:rgb(46,46,46);font-family:arial;font-=
size:inherit;font-style:normal;font-weight:normal;letter-spacing:normal;tex=
t-align:start;text-indent:0px;text-transform:none;white-space:normal;word-s=
pacing:0px;background-color:rgb(255,255,255);float:none;display:inline!impo=
rtant">no compromises on speed. Such a type can still do automatic cleanup=
=C2=A0</span><span style=3D"color:rgb(46,46,46);font-family:arial;font-size=
:inherit;font-style:normal;font-weight:normal;letter-spacing:normal;text-al=
ign:start;text-indent:0px;text-transform:none;white-space:normal;word-spaci=
ng:0px;background-color:rgb(255,255,255);float:none;display:inline!importan=
t">and automatic=C2=A0</span><span style=3D"color:rgb(46,46,46);font-family=
:arial;font-size:inherit;font-style:normal;font-weight:normal;letter-spacin=
g:normal;text-align:start;text-indent:0px;text-transform:none;white-space:n=
ormal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display=
:inline!important">buffer growth, so it would not be just a raw array.</spa=
n><br style=3D"color:rgb(46,46,46);font-family:arial;font-style:normal;font=
-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-=
transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255=
,255,255)"><span style=3D"color:rgb(46,46,46);font-family:arial;font-size:i=
nherit;font-style:normal;font-weight:normal;letter-spacing:normal;text-alig=
n:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing=
:0px;background-color:rgb(255,255,255);float:none;display:inline!important"=
>=C2=A0</span><br style=3D"color:rgb(46,46,46);font-family:arial;font-style=
:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-inde=
nt:0px;text-transform:none;white-space:normal;word-spacing:0px;background-c=
olor:rgb(255,255,255)"><span style=3D"color:rgb(46,46,46);font-family:arial=
;font-size:inherit;font-style:normal;font-weight:normal;letter-spacing:norm=
al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inlin=
e!important">The reason for that suggestion is that different use cases use=
=C2=A0</span><span style=3D"color:rgb(46,46,46);font-family:arial;font-size=
:inherit;font-style:normal;font-weight:normal;letter-spacing:normal;text-al=
ign:start;text-indent:0px;text-transform:none;white-space:normal;word-spaci=
ng:0px;background-color:rgb(255,255,255);float:none;display:inline!importan=
t">different trade-offs, and it=E2=80=99s=C2=A0</span><span style=3D"color:=
rgb(46,46,46);font-family:arial;font-size:inherit;font-style:normal;font-we=
ight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-tra=
nsform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,25=
5,255);float:none;display:inline!important">difficult to cover a significan=
t fraction of the various use cases,=C2=A0</span><span style=3D"color:rgb(4=
6,46,46);font-family:arial;font-size:inherit;font-style:normal;font-weight:=
normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255=
);float:none;display:inline!important">but at least we could perhaps=C2=A0<=
/span><span style=3D"color:rgb(46,46,46);font-family:arial;font-size:inheri=
t;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:sta=
rt;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;=
background-color:rgb(255,255,255);float:none;display:inline!important">prov=
ide a low-level utility that can be a building block for all of=C2=A0</span=
><span style=3D"color:rgb(46,46,46);font-family:arial;font-size:inherit;fon=
t-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backg=
round-color:rgb(255,255,255);float:none;display:inline!important">them. Try=
ing to fix vector=E2=80=99s performance=C2=A0</span><span style=3D"color:rg=
b(46,46,46);font-family:arial;font-size:inherit;font-style:normal;font-weig=
ht:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-trans=
form:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,=
255);float:none;display:inline!important">problems one by one runs the risk=
 of breaking vector=E2=80=99s class=C2=A0</span><span style=3D"color:rgb(46=
,46,46);font-family:arial;font-size:inherit;font-style:normal;font-weight:n=
ormal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform=
:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)=
;float:none;display:inline!important">invariants, which (all of them) someb=
ody=C2=A0</span><span style=3D"color:rgb(46,46,46);font-family:arial;font-s=
ize:inherit;font-style:normal;font-weight:normal;letter-spacing:normal;text=
-align:start;text-indent:0px;text-transform:none;white-space:normal;word-sp=
acing:0px;background-color:rgb(255,255,255);float:none;display:inline!impor=
tant">somewhere is bound to rely on, so I=E2=80=99d expect fair amounts of=
=C2=A0</span><span style=3D"color:rgb(46,46,46);font-family:arial;font-size=
:inherit;font-style:normal;font-weight:normal;letter-spacing:normal;text-al=
ign:start;text-indent:0px;text-transform:none;white-space:normal;word-spaci=
ng:0px;background-color:rgb(255,255,255);float:none;display:inline!importan=
t">resistance to such an approach.</span></div></blockquote></div><br><div>=
=C2=A0 =C2=A0 =C2=A0For some reason, this sounds like one reason to investi=
gate reviving the currently still abandoned Array Fundamentals TS idea=E2=
=80=A6</div><br><div>
<div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-=
indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wra=
p:break-word"><div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-ali=
gn:start;text-indent:0px;text-transform:none;white-space:normal;word-spacin=
g:0px;word-wrap:break-word"><div style=3D"color:rgb(0,0,0);letter-spacing:n=
ormal;text-align:start;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px;word-wrap:break-word"><div>Just a friendly lurker,=C2=
=A0</div><div>=C2=A0 =C2=A0 =C2=A0Bryce Glover</div><div>=C2=A0 =C2=A0 =C2=
=A0<a rel=3D"nofollow">Random...@gmail.com</a></div></div></div></div></div=
></div></blockquote></div></blockquote></div></div>

<p></p>

-- <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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/217d3451-be54-40b9-9f51-d9c8d94b2341%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/217d3451-be54-40b9-9f51-d9c8d94b2341=
%40isocpp.org</a>.<br />

------=_Part_2211_1406483047.1503698405542--

------=_Part_2210_826508851.1503698405541--

.