------=_Part_107_15747559.1378505103956
Content-Type: text/plain; charset=ISO-8859-1

[I suspect I am re-inventing the wheel, but a quick search of this forum
didn't yield any similar proposal.]

vector::push_back() is inefficient, as every time it checks whether
the vector has reached its full capacity and needs to allocate more memory.
Such a check is often unnecessary, e.g. if reserve() was called, see the
example below. Hence, the proposal is to add vector::push_back_() which
skips this check. Calling it for a full vector results in undefined
behaviour (consistent with operator[] which does not check that the index
is valid). Of course, an assertion checking the capacity should be used in
push_back_() to simplify debugging, but the optimised code has no overhead.

---------
Example: The vector class is often used like this:

vector<Widget> vw;
vw.reserve(...);
for(...){
    vw.push_back(...); // inefficient due to unnecessary capacity checks;
push_back_() should be used instead
}

The capacity check is unnecessary in this example and leads to loss of
performance (code like this is likely to be in a tight internal
loop). Furthermore, unnecessary overhead cannot be removed, e.g. replacing
this code by

vector<Widget> vw(...);
for(...){
    vw[...]=...;
}

does not solve the problem, as now the default constructor of Widget is
called many times, only for the created objects to be immediately
overwritten in the loop.
---------

Of course, the same argument works for emplace_back_(). One might also
consider adding back_inserter_ to further exploit the new functionality,
e.g.:

vector<Widget> vw;
vw.reserve(...);
transform(...,back_inserter_(vw),...);



--

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

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

<div dir=3D"ltr"><div>[I suspect I am re-inventing the wheel, but&nbsp;a qu=
ick search of this forum didn't yield any similar proposal.]</div><div>&nbs=
p;</div><div>vector::push_back() is inefficient, as&nbsp;every time it chec=
ks whether the&nbsp;vector has&nbsp;reached its full capacity and needs to =
allocate more memory. Such a check is often unnecessary, e.g. if reserve() =
was called, see the example below. Hence, the proposal is to add&nbsp;vecto=
r::push_back_() which skips this check.&nbsp;Calling it for a full vector r=
esults in undefined behaviour (consistent with operator[] which does not ch=
eck that the index is valid). Of course, an assertion checking the capacity=
 should be used&nbsp;in push_back_() to simplify debugging, but&nbsp;the op=
timised code has no overhead.</div><div>&nbsp;</div><div>---------</div><di=
v>Example: The vector class is often used like this:</div><div>&nbsp;</div>=
<div>vector&lt;Widget&gt; vw;</div><div>vw.reserve(...);</div><div>for(...)=
{</div><div>&nbsp;&nbsp;&nbsp; vw.push_back(...); //&nbsp;inefficient due t=
o unnecessary capacity checks; push_back_() should be used instead</div><di=
v>}</div><div>&nbsp;</div><div>The capacity&nbsp;check is unnecessary in th=
is example and leads&nbsp;to&nbsp;loss of performance (code like this is li=
kely to be in a tight internal loop).&nbsp;Furthermore, unnecessary overhea=
d cannot be removed, e.g. replacing this code by</div><div>&nbsp;</div><div=
><div>vector&lt;Widget&gt; vw(...);</div><div>for(...){</div><div>&nbsp;&nb=
sp;&nbsp; vw[...]=3D...;</div><div>}</div><div>&nbsp;</div><div>does not so=
lve the problem, as now the default constructor of Widget is called many ti=
mes, only for&nbsp;the created objects to be immediately overwritten in the=
 loop.</div><div>---------</div><div>&nbsp;</div><div><div>Of course, the s=
ame argument works for&nbsp;emplace_back_(). One might also consider adding=
 back_inserter_ to further&nbsp;exploit the new functionality, e.g.:</div><=
div>&nbsp;</div></div><div><div>vector&lt;Widget&gt; vw;</div><div>vw.reser=
ve(...);</div><div>transform(...,back_inserter_(vw),...);</div></div><div>&=
nbsp;</div><div>&nbsp;</div></div></div>

<p></p>

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

------=_Part_107_15747559.1378505103956--

.

------=_Part_134_16436430.1378521271168
Content-Type: text/plain; charset=ISO-8859-1

In principle it's a valid problem, such checks can adversely affect inner
loops, but the solution is way too specialized and obtuse.

How about a means to pass hints to the allocator, maybe a dispatch tag
indicating to forward arguments from push_*, insert_*, emplace_*, and
constructors to allocator::allocate? This would in general enable dumb
allocators where the client can specify where allocations go, and when they
are allowed. It would be a powerful interface.

--

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

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

<div dir=3D"ltr">In principle it's a valid problem, such checks can adverse=
ly affect inner loops, but the solution is way too specialized and obtuse.<=
br><br>How about a means to pass hints to the allocator, maybe a dispatch t=
ag indicating to forward arguments from <span style=3D"font-family: courier=
 new,monospace;">push_*</span>, <span style=3D"font-family: courier new,mon=
ospace;">insert_*</span>, <span style=3D"font-family: courier new,monospace=
;">emplace_*</span>, and constructors to <span style=3D"font-family: courie=
r new,monospace;">allocator::allocate</span>? This would in general enable =
dumb allocators where the client can specify where allocations go, and when=
 they are allowed. It would be a powerful interface.<br></div>

<p></p>

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

------=_Part_134_16436430.1378521271168--

.

------=_Part_362_11068018.1378544385614
Content-Type: text/plain; charset=ISO-8859-1

Hello Victor,

>
> vector::push_back() is inefficient, as every time it checks whether
> the vector has reached its full capacity and needs to allocate more memory.
> Such a check is often unnecessary, e.g. if reserve() was called, see the
> example below.
>

I don't deny that there is a textual check at every push_back(). Do you
have measurements on the acutal impact on execution? My theory is, if you
reserved enough memory, the check should pass everytime and branch
prediction would make your insertions throttle full speed.

Laurent

--

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

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

<div dir=3D"ltr">Hello Victor,<br>&nbsp;<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div>vector::push_back() is inefficient, as&nbsp=
;every time it checks whether the&nbsp;vector has&nbsp;reached its full cap=
acity and needs to allocate more memory. Such a check is often unnecessary,=
 e.g. if reserve() was called, see the example below. </div></div></blockqu=
ote><div><br>I don't deny that there is a textual check at every push_back(=
). Do you have measurements on the acutal impact on execution? My theory is=
, if you reserved enough memory, the check should pass everytime and branch=
 prediction would make your insertions throttle full speed.<br><br>Laurent<=
/div></div>

<p></p>

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

------=_Part_362_11068018.1378544385614--

.

------=_Part_370_8187579.1378552225073
Content-Type: text/plain; charset=ISO-8859-1



On Saturday, September 7, 2013 4:59:45 PM UTC+8, the.ultim...@gmail.com
wrote:
>
> Hello Victor,
>
>>
>> vector::push_back() is inefficient, as every time it checks whether
>> the vector has reached its full capacity and needs to allocate more memory.
>> Such a check is often unnecessary, e.g. if reserve() was called, see the
>> example below.
>>
>
> I don't deny that there is a textual check at every push_back(). Do you
> have measurements on the acutal impact on execution? My theory is, if you
> reserved enough memory, the check should pass everytime and branch
> prediction would make your insertions throttle full speed.
>

I can vouch that it makes a difference. For frequent enough insertions, the
cost comes not from mispredicted branches but the integer instructions to
fetch and compare the capacity pointer.

The workaround is to not use push_back, but IMHO it should be the right
tool for the job.

--

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

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

<div dir=3D"ltr"><br><br>On Saturday, September 7, 2013 4:59:45 PM UTC+8, t=
he.ultim...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">Hello Victor,<br>&nbsp;<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>vector::push_back() is inefficient, as&nbsp;every =
time it checks whether the&nbsp;vector has&nbsp;reached its full capacity a=
nd needs to allocate more memory. Such a check is often unnecessary, e.g. i=
f reserve() was called, see the example below. </div></div></blockquote><di=
v><br>I don't deny that there is a textual check at every push_back(). Do y=
ou have measurements on the acutal impact on execution? My theory is, if yo=
u reserved enough memory, the check should pass everytime and branch predic=
tion would make your insertions throttle full speed.<br></div></div></block=
quote><div><br>I can vouch that it makes a difference. For frequent enough =
insertions, the cost comes not from mispredicted branches but the integer i=
nstructions to fetch and compare the capacity pointer.<br><br>The workaroun=
d is to not use <span style=3D"font-family: courier new,monospace;">push_ba=
ck</span>, but IMHO it should be the right tool for the job.<br></div></div=
>

<p></p>

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

------=_Part_370_8187579.1378552225073--

.

--e89a8fb1ef64fd80b204e5c9dce7
Content-Type: text/plain; charset=ISO-8859-1

On 7 September 2013 14:10, David Krauss <potswa@gmail.com> wrote:

>
>
> On Saturday, September 7, 2013 4:59:45 PM UTC+8, the.ultim...@gmail.comwrote:
>>
>> Hello Victor,
>>
>>>
>>> vector::push_back() is inefficient, as every time it checks whether
>>> the vector has reached its full capacity and needs to allocate more memory.
>>> Such a check is often unnecessary, e.g. if reserve() was called, see the
>>> example below.
>>>
>>
>> I don't deny that there is a textual check at every push_back(). Do you
>> have measurements on the acutal impact on execution? My theory is, if you
>> reserved enough memory, the check should pass everytime and branch
>> prediction would make your insertions throttle full speed.
>>
>
> I can vouch that it makes a difference. For frequent enough insertions,
> the cost comes not from mispredicted branches but the integer instructions
> to fetch and compare the capacity pointer.
>
> The workaround is to not use push_back, but IMHO it should be the right
> tool for the job.
>
>
>
>
Well, if I don't want to resize the vector (and construct objects), I can't
see what work-around would
allow avoiding push_back. A vector of optionals would allow the resize
without constructing
the underlying objects, and then I could just use operator[].

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 7 September 2013 14:10, David Krauss <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><br><br>O=
n Saturday, September 7, 2013 4:59:45 PM UTC+8, <a href=3D"mailto:the.ultim=
....@gmail.com" target=3D"_blank">the.ultim...@gmail.com</a> wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Hello Victor,<br>=A0<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div>vector::push_back() is inefficient, as=A0every time=
 it checks whether the=A0vector has=A0reached its full capacity and needs t=
o allocate more memory. Such a check is often unnecessary, e.g. if reserve(=
) was called, see the example below. </div>
</div></blockquote><div><br>I don&#39;t deny that there is a textual check =
at every push_back(). Do you have measurements on the acutal impact on exec=
ution? My theory is, if you reserved enough memory, the check should pass e=
verytime and branch prediction would make your insertions throttle full spe=
ed.<br>
</div></div></blockquote></div><div><br>I can vouch that it makes a differe=
nce. For frequent enough insertions, the cost comes not from mispredicted b=
ranches but the integer instructions to fetch and compare the capacity poin=
ter.<br>
<br>The workaround is to not use <span style=3D"font-family:courier new,mon=
ospace">push_back</span>, but IMHO it should be the right tool for the job.=
<br></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>Well, if I don&#39;t w=
ant to resize the vector (and construct objects), I can&#39;t see what work=
-around would<br>allow avoiding push_back. A vector of optionals would allo=
w the resize without constructing<br>
the underlying objects, and then I could just use operator[]. <br></div></d=
iv><br></div></div>

<p></p>

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

--e89a8fb1ef64fd80b204e5c9dce7--

.

------=_Part_476_19230603.1378557082416
Content-Type: text/plain; charset=ISO-8859-1



> I can vouch that it makes a difference. For frequent enough insertions,
> the cost comes not from mispredicted branches but the integer instructions
> to fetch and compare the capacity pointer.
>
> The workaround is to not use push_back, but IMHO it should be the right
> tool for the job.
>

And we're back at the von Neumann bottleneck. Wouldn't a cleaner way to
work around this be to leave the control flow of the filling to the vector
itself?

My thought on this isn't complete yet, but now that we can write function
objects more easily, wouldn't the right approach be to generalize the
following "fill" constructor:

vector (size_type n, const value_type& val,
 const allocator_type& alloc = allocator_type());


Into:

template<typename Generator>
vector (size_type n, Generator gen,
 const allocator_type& alloc = allocator_type());

If we then had a way to write the algorithm as a coroutine, the vector would determine its capacity only once and let the filling flow.

--

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

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

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>I can vouch that it makes a difference. For frequent enough i=
nsertions, the cost comes not from mispredicted branches but the integer in=
structions to fetch and compare the capacity pointer.<br><br>The workaround=
 is to not use <span style=3D"font-family:courier new,monospace">push_back<=
/span>, but IMHO it should be the right tool for the job.<br></div></div></=
blockquote><div><br>And we're back at the von Neumann bottleneck. Wouldn't =
a cleaner way to work around this be to leave the control flow of the filli=
ng to the vector itself?<br><br>My thought on this isn't complete yet, but =
now that we can write function objects more easily, wouldn't the right appr=
oach be to generalize the following "fill" constructor:<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">vector </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">size_type n</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> value_type</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> val</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>&nbsp;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> allo=
cator_type</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> allo=
c </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> allocator_type=
</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><pre><span style=3D"font-family: arial,sans-serif;"><br>Into<=
/span>:<br><br></pre><div class=3D"prettyprint" style=3D"background-color: =
rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; =
border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div=
 class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">template</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>typename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Generator<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>vector </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">size_type n</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">Generator</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> gen</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>&nbsp;</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> allocator_type</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> alloc </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> allocator_type</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">());</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span></div></code></div><span style=3D"font-family: arial,sans-serif=
;"><br></span><pre><span style=3D"font-family: arial,sans-serif;">If we the=
n had a way to write the algorithm as a coroutine, the vector would determi=
ne its capacity only once and let the filling flow.</span><br></pre></div><=
/div>

<p></p>

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

------=_Part_476_19230603.1378557082416--

.

--001a11c3fe90c82bf004e5ca75f2
Content-Type: text/plain; charset=ISO-8859-1

Shouldn't this be a task of the compiler? (To inline push_back and optimize
away the 'if (size == capacity)' check if it knows that 'size < capacity'
because of a previous .reserve().)


2013/9/7 <the.ultimate.koala@gmail.com>

>
> I can vouch that it makes a difference. For frequent enough insertions,
>> the cost comes not from mispredicted branches but the integer instructions
>> to fetch and compare the capacity pointer.
>>
>> The workaround is to not use push_back, but IMHO it should be the right
>> tool for the job.
>>
>
> And we're back at the von Neumann bottleneck. Wouldn't a cleaner way to
> work around this be to leave the control flow of the filling to the vector
> itself?
>
> My thought on this isn't complete yet, but now that we can write function
> objects more easily, wouldn't the right approach be to generalize the
> following "fill" constructor:
>
> vector (size_type n, const value_type& val,
>  const allocator_type& alloc = allocator_type());
>
>
> Into:
>
> template<typename Generator>
> vector (size_type n, Generator gen,
>  const allocator_type& alloc = allocator_type());
>
> If we then had a way to write the algorithm as a coroutine, the vector would determine its capacity only once and let the filling flow.
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--001a11c3fe90c82bf004e5ca75f2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Shouldn&#39;t this be a task of the compiler? (To inline p=
ush_back and optimize away the &#39;if (size =3D=3D capacity)&#39; check if=
 it knows that &#39;size &lt; capacity&#39; because of a previous .reserve(=
).)<br>


</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/9/=
7  <span dir=3D"ltr">&lt;<a href=3D"mailto:the.ultimate.koala@gmail.com" ta=
rget=3D"_blank">the.ultimate.koala@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">

<div dir=3D"ltr"><div class=3D"im"><br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div>I can vouch that it makes a difference. For frequ=
ent enough insertions, the cost comes not from mispredicted branches but th=
e integer instructions to fetch and compare the capacity pointer.<br>

<br>The workaround is to not use <span style=3D"font-family:courier new,mon=
ospace">push_back</span>, but IMHO it should be the right tool for the job.=
<br></div></div></blockquote></div><div><br>And we&#39;re back at the von N=
eumann bottleneck. Wouldn&#39;t a cleaner way to work around this be to lea=
ve the control flow of the filling to the vector itself?<br>

<br>My thought on this isn&#39;t complete yet, but now that we can write fu=
nction objects more easily, wouldn&#39;t the right approach be to generaliz=
e the following &quot;fill&quot; constructor:<br><br><div style=3D"backgrou=
nd-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;=
border-width:1px;word-wrap:break-word">

<code><div><span style>vector </span><span style=3D"color:#660">(</span><sp=
an style>size_type n</span><span style=3D"color:#660">,</span><span style> =
</span><span style=3D"color:#008">const</span><span style> value_type</span=
><span style=3D"color:#660">&amp;</span><span style> val</span><span style=
=3D"color:#660">,</span><span style><br>

=A0</span><span style=3D"color:#008">const</span><span style> allocator_typ=
e</span><span style=3D"color:#660">&amp;</span><span style> alloc </span><s=
pan style=3D"color:#660">=3D</span><span style> allocator_type</span><span =
style=3D"color:#660">());</span><span style><br>

</span></div></code></div><pre><span style=3D"font-family:arial,sans-serif"=
><br>Into</span>:<br><br></pre><div style=3D"background-color:rgb(250,250,2=
50);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-=
wrap:break-word">

<code><div><span style=3D"color:#008">template</span><span style=3D"color:#=
660">&lt;</span><span style=3D"color:#008">typename</span><span style> </sp=
an><span style=3D"color:#606">Generator</span><span style=3D"color:#660">&g=
t;</span><span style><br>

vector </span><span style=3D"color:#660">(</span><span style>size_type n</s=
pan><span style=3D"color:#660">,</span><span style> </span><span style=3D"c=
olor:#606">Generator</span><span style> gen</span><span style=3D"color:#660=
">,</span><span style><br>

=A0</span><span style=3D"color:#008">const</span><span style> allocator_typ=
e</span><span style=3D"color:#660">&amp;</span><span style> alloc </span><s=
pan style=3D"color:#660">=3D</span><span style> allocator_type</span><span =
style=3D"color:#660">());</span><span style><br>

</span></div></code></div><span style=3D"font-family:arial,sans-serif"><br>=
</span><pre><span style=3D"font-family:arial,sans-serif">If we then had a w=
ay to write the algorithm as a coroutine, the vector would determine its ca=
pacity only once and let the filling flow.</span><br>

</pre></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11c3fe90c82bf004e5ca75f2--

.

------=_Part_468_33537910.1378561535418
Content-Type: text/plain; charset=ISO-8859-1

You should refactor your loop into a range, and construct the vector
directly from that. This would resolve the issue.

--

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

------=_Part_468_33537910.1378561535418
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">You should refactor your loop into a range, and construct the vector directly from that. This would resolve the issue.</div>

<p></p>

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

------=_Part_468_33537910.1378561535418--

.

------=_Part_736_28816781.1378577544014
Content-Type: text/plain; charset=ISO-8859-1


On Saturday, September 7, 2013 3:34:31 AM UTC+1, David Krauss wrote:
>
> In principle it's a valid problem, such checks can adversely affect inner
> loops, but the solution is way too specialized and obtuse.
>
> How about a means to pass hints to the allocator, maybe a dispatch tag
> indicating to forward arguments from push_*, insert_*, emplace_*, and
> constructors to allocator::allocate? This would in general enable dumb
> allocators where the client can specify where allocations go, and when they
> are allowed. It would be a powerful interface.
>

If we modify vector class anyway, such a solution is more heavy-weight.
Also difficult to teach. In fact, I'm not convinced it would actually give
any speedup in practice.

--

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

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

<div dir=3D"ltr"><br>On Saturday, September 7, 2013 3:34:31 AM UTC+1, David=
 Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-l=
eft-width: 1px; border-left-style: solid;"><div dir=3D"ltr">In principle it=
's a valid problem, such checks can adversely affect inner loops, but the s=
olution is way too specialized and obtuse.<div>&nbsp;</div><div>How about a=
 means to pass hints to the allocator, maybe a dispatch tag indicating to f=
orward arguments from <span style=3D"font-family: courier new,monospace;">p=
ush_*</span>, <span style=3D"font-family: courier new,monospace;">insert_*<=
/span>, <span style=3D"font-family: courier new,monospace;">emplace_*</span=
>, and constructors to <span style=3D"font-family: courier new,monospace;">=
allocator::allocate</span>? This would in general enable dumb allocators wh=
ere the client can specify where allocations go, and when they are allowed.=
 It would be a powerful interface.</div></div></blockquote><div>&nbsp;</div=
><div>If we modify&nbsp;vector class anyway,&nbsp;such a&nbsp;solution is m=
ore heavy-weight. Also difficult to teach. In fact, I'm not convinced it wo=
uld actually give any speedup in practice.</div></div>

<p></p>

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

------=_Part_736_28816781.1378577544014--

.

------=_Part_243_13921731.1378577943456
Content-Type: text/plain; charset=ISO-8859-1


On Saturday, September 7, 2013 12:10:25 PM UTC+1, David Krauss wrote:
>
>
>
> On Saturday, September 7, 2013 4:59:45 PM UTC+8, the.ultim...@gmail.comwrote:
>>
>> Hello Victor,
>>
>>>
>>> vector::push_back() is inefficient, as every time it checks whether
>>> the vector has reached its full capacity and needs to allocate more memory.
>>> Such a check is often unnecessary, e.g. if reserve() was called, see the
>>> example below.
>>>
>>
>> I don't deny that there is a textual check at every push_back(). Do you
>> have measurements on the acutal impact on execution? My theory is, if you
>> reserved enough memory, the check should pass everytime and branch
>> prediction would make your insertions throttle full speed.
>>
>
> I can vouch that it makes a difference. For frequent enough insertions,
> the cost comes not from mispredicted branches but the integer instructions
> to fetch and compare the capacity pointer.
>

Just to add: the implementation of push_back_() would be something like

*ptr_end++=parameter;

and so almost certainly inlined. In contrast, push_back() is unlikely to
get inlined, as it does some complicated stuff, like reallocation and
handling the ugly special case like v.push_back(v[i]).



--

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

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

<div dir=3D"ltr"><br>On Saturday, September 7, 2013 12:10:25 PM UTC+1, Davi=
d Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br><br>On Sat=
urday, September 7, 2013 4:59:45 PM UTC+8, <a>the.ultim...@gmail.com</a> wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
 1px; border-left-style: solid;"><div dir=3D"ltr">Hello Victor,<br>&nbsp;<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding=
-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; =
border-left-style: solid;"><div dir=3D"ltr"><div>vector::push_back() is ine=
fficient, as&nbsp;every time it checks whether the&nbsp;vector has&nbsp;rea=
ched its full capacity and needs to allocate more memory. Such a check is o=
ften unnecessary, e.g. if reserve() was called, see the example below. </di=
v></div></blockquote><div><br>I don't deny that there is a textual check at=
 every push_back(). Do you have measurements on the acutal impact on execut=
ion? My theory is, if you reserved enough memory, the check should pass eve=
rytime and branch prediction would make your insertions throttle full speed=
..<br></div></div></blockquote><div><br>I can vouch that it makes a differen=
ce. For frequent enough insertions, the cost comes not from mispredicted br=
anches but the integer instructions to fetch and compare the capacity point=
er.<br></div></div></blockquote><div>&nbsp;</div><div>Just to add: the impl=
ementation of push_back_() would be something like</div><div>&nbsp;</div><d=
iv>*ptr_end++=3Dparameter;</div><div>&nbsp;</div><div>and so almost certain=
ly&nbsp;inlined. In contrast, push_back() is unlikely to get inlined, as it=
 does some complicated stuff, like reallocation and handling the ugly speci=
al case like v.push_back(v[i]).</div><div>&nbsp;</div><div>&nbsp;</div></di=
v>

<p></p>

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

------=_Part_243_13921731.1378577943456--

.

------=_Part_818_7857193.1378578381548
Content-Type: text/plain; charset=ISO-8859-1


On Saturday, September 7, 2013 1:31:22 PM UTC+1, the.ultim...@gmail.com
wrote:
>
>
> I can vouch that it makes a difference. For frequent enough insertions,
>> the cost comes not from mispredicted branches but the integer instructions
>> to fetch and compare the capacity pointer.
>>
>> The workaround is to not use push_back, but IMHO it should be the right
>> tool for the job.
>>
>
> And we're back at the von Neumann bottleneck. Wouldn't a cleaner way to
> work around this be to leave the control flow of the filling to the vector
> itself?
>
> My thought on this isn't complete yet, but now that we can write function
> objects more easily, wouldn't the right approach be to generalize the
> following "fill" constructor:
>
> vector (size_type n, const value_type& val,
>  const allocator_type& alloc = allocator_type());
>
>
> Into:
>
> template<typename Generator>
> vector (size_type n, Generator gen,
>  const allocator_type& alloc = allocator_type());
>
> If we then had a way to write the algorithm as a coroutine, the vector would determine its capacity only once and let the filling flow.
>
>
I believe this will not result in any speedup, as the generator will
have internal state, and will need extra calls (unless fully inlined).
Moreover, it is less convinient to use - there are generate and generate_n
functions in <algorithm> which do essentially the same, and in my
experience they are rarely used.


--

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

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

<div dir=3D"ltr"><br>On Saturday, September 7, 2013 1:31:22 PM UTC+1, the.u=
ltim...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br><=
blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddin=
g-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px;=
 border-left-style: solid;"><div dir=3D"ltr"><div>I can vouch that it makes=
 a difference. For frequent enough insertions, the cost comes not from misp=
redicted branches but the integer instructions to fetch and compare the cap=
acity pointer.<br><br>The workaround is to not use <span style=3D"font-fami=
ly: courier new,monospace;">push_back</span>, but IMHO it should be the rig=
ht tool for the job.<br></div></div></blockquote><div><br>And we're back at=
 the von Neumann bottleneck. Wouldn't a cleaner way to work around this be =
to leave the control flow of the filling to the vector itself?<br><br>My th=
ought on this isn't complete yet, but now that we can write function object=
s more easily, wouldn't the right approach be to generalize the following "=
fill" constructor:<br><br><div style=3D"border: 1px solid rgb(187, 187, 187=
); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code><div=
><span style=3D"color: rgb(0, 0, 0);">vector </span><span style=3D"color: r=
gb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 0);">size_type n<=
/span><span style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"color=
: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">const</span=
><span style=3D"color: rgb(0, 0, 0);"> value_type</span><span style=3D"colo=
r: rgb(102, 102, 0);">&amp;</span><span style=3D"color: rgb(0, 0, 0);"> val=
</span><span style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"colo=
r: rgb(0, 0, 0);"><br>&nbsp;</span><span style=3D"color: rgb(0, 0, 136);">c=
onst</span><span style=3D"color: rgb(0, 0, 0);"> allocator_type</span><span=
 style=3D"color: rgb(102, 102, 0);">&amp;</span><span style=3D"color: rgb(0=
, 0, 0);"> alloc </span><span style=3D"color: rgb(102, 102, 0);">=3D</span>=
<span style=3D"color: rgb(0, 0, 0);"> allocator_type</span><span style=3D"c=
olor: rgb(102, 102, 0);">());</span><span style=3D"color: rgb(0, 0, 0);"><b=
r></span></div></code></div><pre><span style=3D"font-family: arial,sans-ser=
if;"><br>Into</span>:<br><br></pre><div style=3D"border: 1px solid rgb(187,=
 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><=
code><div><span style=3D"color: rgb(0, 0, 136);">template</span><span style=
=3D"color: rgb(102, 102, 0);">&lt;</span><span style=3D"color: rgb(0, 0, 13=
6);">typename</span><span style=3D"color: rgb(0, 0, 0);"> </span><span styl=
e=3D"color: rgb(102, 0, 102);">Generator</span><span style=3D"color: rgb(10=
2, 102, 0);">&gt;</span><span style=3D"color: rgb(0, 0, 0);"><br>vector </s=
pan><span style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: =
rgb(0, 0, 0);">size_type n</span><span style=3D"color: rgb(102, 102, 0);">,=
</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: r=
gb(102, 0, 102);">Generator</span><span style=3D"color: rgb(0, 0, 0);"> gen=
</span><span style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"colo=
r: rgb(0, 0, 0);"><br>&nbsp;</span><span style=3D"color: rgb(0, 0, 136);">c=
onst</span><span style=3D"color: rgb(0, 0, 0);"> allocator_type</span><span=
 style=3D"color: rgb(102, 102, 0);">&amp;</span><span style=3D"color: rgb(0=
, 0, 0);"> alloc </span><span style=3D"color: rgb(102, 102, 0);">=3D</span>=
<span style=3D"color: rgb(0, 0, 0);"> allocator_type</span><span style=3D"c=
olor: rgb(102, 102, 0);">());</span><span style=3D"color: rgb(0, 0, 0);"><b=
r></span></div></code></div><span style=3D"font-family: arial,sans-serif;">=
<br></span><pre><span style=3D"font-family: arial,sans-serif;">If we then h=
ad a way to write the algorithm as a coroutine, the vector would determine =
its capacity only once and let the filling flow.</span><br></pre></div></di=
v></blockquote><div>&nbsp;</div><div>I believe this will not result in any =
speedup, as the generator will have&nbsp;internal state, and&nbsp;will need=
 extra calls (unless fully inlined). Moreover, it is less convinient to use=
 - there are generate and generate_n functions in &lt;algorithm&gt; which d=
o essentially the same, and in my experience they are rarely used.</div><di=
v>&nbsp;</div></div>

<p></p>

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

------=_Part_818_7857193.1378578381548--

.

------=_Part_624_25599971.1378578768267
Content-Type: text/plain; charset=ISO-8859-1


On Saturday, September 7, 2013 1:40:08 PM UTC+1, Maurice Bos wrote:
>
> Shouldn't this be a task of the compiler? (To inline push_back and
> optimize away the 'if (size == capacity)' check if it knows that 'size <
> capacity' because of a previous .reserve().)
>
>

As I said before, push_back is quite complicated, so unlikely to
be inlined. Even it it is, the compiler has to be very clever to find this
optimisation. In some situations, like inner loop or critical section, the
programmer would want to ensure that this optimisation has been applied.

--

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

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

<div dir=3D"ltr"><br>On Saturday, September 7, 2013 1:40:08 PM UTC+1, Mauri=
ce Bos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;"><div dir=3D"ltr">Shouldn't this b=
e a task of the compiler? (To inline push_back and optimize away the 'if (s=
ize =3D=3D capacity)' check if it knows that 'size &lt; capacity' because o=
f a previous .reserve().)<br>


&nbsp;</div></blockquote><div>&nbsp;</div><div>As I said before, push_back =
is&nbsp;quite complicated, so unlikely to be&nbsp;inlined. Even it it is, t=
he compiler has to be very clever to find this optimisation.&nbsp;In some s=
ituations, like inner loop or critical section, the programmer would want t=
o ensure that&nbsp;this optimisation&nbsp;has been applied.</div></div>

<p></p>

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

------=_Part_624_25599971.1378578768267--

.

------=_Part_625_6239224.1378578972351
Content-Type: text/plain; charset=ISO-8859-1


On Saturday, September 7, 2013 2:45:35 PM UTC+1, DeadMG wrote:
>
> You should refactor your loop into a range, and construct the vector
> directly from that. This would resolve the issue.
>

Or, much easier, allocate raw memory using malloc, and work with it.

--

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

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

<div dir=3D"ltr"><br>On Saturday, September 7, 2013 2:45:35 PM UTC+1, DeadM=
G wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8e=
x; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wi=
dth: 1px; border-left-style: solid;"><div dir=3D"ltr">You should refactor y=
our loop into a range, and construct the vector directly from that. This wo=
uld resolve the issue.</div></blockquote><div>&nbsp;</div><div>Or, much eas=
ier,&nbsp;allocate raw memory using malloc, and work with it.</div></div>

<p></p>

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

------=_Part_625_6239224.1378578972351--

.

------=_Part_722_31570288.1378579154071
Content-Type: text/plain; charset=ISO-8859-1

It would unfortunately be much easier because ranges are so irritating to
construct. This, however, is immaterial to the fact that the other
solutions are a disgusting hack which is only an approximation to the real
solution.

--

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

------=_Part_722_31570288.1378579154071
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">It would unfortunately be much easier because ranges are so irritating to construct. This, however, is immaterial to the fact that the other solutions are a disgusting hack which is only an approximation to the real solution.</div>

<p></p>

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

------=_Part_722_31570288.1378579154071--

.

On Sat, 2013-09-07 at 11:19 -0700, Victor.Khomenko@ncl.ac.uk wrote:
>
> On Saturday, September 7, 2013 12:10:25 PM UTC+1, David Krauss wrote:
>
>
>         On Saturday, September 7, 2013 4:59:45 PM UTC+8,
>         the.ultim...@gmail.com wrote:
>                 Hello Victor,
>
>                         vector::push_back() is inefficient, as every
>                         time it checks whether the vector has reached
>                         its full capacity and needs to allocate more
>                         memory. Such a check is often unnecessary,
>                         e.g. if reserve() was called, see the example
>                         below.
>
>                 I don't deny that there is a textual check at every
>                 push_back(). Do you have measurements on the acutal
>                 impact on execution? My theory is, if you reserved
>                 enough memory, the check should pass everytime and
>                 branch prediction would make your insertions throttle
>                 full speed.
>
>
>         I can vouch that it makes a difference. For frequent enough
>         insertions, the cost comes not from mispredicted branches but
>         the integer instructions to fetch and compare the capacity
>         pointer.
>
>
> Just to add: the implementation of push_back_() would be something
> like
>
> *ptr_end++=parameter;
>
> and so almost certainly inlined. In contrast, push_back() is unlikely
> to get inlined, as it does some complicated stuff, like reallocation
> and handling the ugly special case like v.push_back(v[i]).

I would expect the implementetion of push_back to be something along the
line of

inline void vector<T>::push_back(const T& parameter) {
  if (ptr_end == ptr_capacity)
    grow();
  allocator.construct(ptr_end, parameter);
  ++ptr_end;
}

where grow() grows the vector if needed. Here I don't expect grow() to
be fully inlined but I do not see why the rest couldn't be inlined.

Note that the your push_back_ also needs to do

  allocator.construct(ptr_end, parameter);
  ++ptr_end; // Increment after as construct could throw

since I expect the memory from ptr_end to ptr_capacity to be
uninitialized, so it really isn't that much simpler.

/MF


--

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

.

------=_Part_9_26435659.1378580595388
Content-Type: text/plain; charset=ISO-8859-1


On Saturday, September 7, 2013 12:57:45 PM UTC+1, Ville Voutilainen wrote:
>
>
> Well, if I don't want to resize the vector (and construct objects), I
> can't see what work-around would
> allow avoiding push_back. A vector of optionals would allow the resize
> without constructing
> the underlying objects, and then I could just use operator[].
>

Doesn't solve the problem: still many optionals are constructed, only to be
immediately overwritten.

--

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

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

<div dir=3D"ltr"><br>On Saturday, September 7, 2013 12:57:45 PM UTC+1, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div=
 class=3D"gmail_quote"><div><br>Well, if I don't want to resize the vector =
(and construct objects), I can't see what work-around would<br>allow avoidi=
ng push_back. A vector of optionals would allow the resize without construc=
ting<br>
the underlying objects, and then I could just use operator[]. <br></div></d=
iv></div></div></blockquote><div>&nbsp;</div><div>Doesn't solve&nbsp;the pr=
oblem: still&nbsp;many optionals are constructed, only to be immediately ov=
erwritten.</div></div>

<p></p>

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

------=_Part_9_26435659.1378580595388--

.

------=_Part_596_28731139.1378580987325
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, September 7, 2013 7:58:51 PM UTC+1, Magnus Fromreide wrote:

> On Sat, 2013-09-07 at 11:19 -0700, Victor....@ncl.ac.uk <javascript:>wrote:
> >
> > On Saturday, September 7, 2013 12:10:25 PM UTC+1, David Krauss wrote:
> >
> >
> >         On Saturday, September 7, 2013 4:59:45 PM UTC+8,
> >         the.ultim...@gmail.com wrote:
> >                 Hello Victor,
> >
> >                         vector::push_back() is inefficient, as every
> >                         time it checks whether the vector has reached
> >                         its full capacity and needs to allocate more
> >                         memory. Such a check is often unnecessary,
> >                         e.g. if reserve() was called, see the example
> >                         below.
> >
> >                 I don't deny that there is a textual check at every
> >                 push_back(). Do you have measurements on the acutal
> >                 impact on execution? My theory is, if you reserved
> >                 enough memory, the check should pass everytime and
> >                 branch prediction would make your insertions throttle
> >                 full speed.
> >
> >
> >         I can vouch that it makes a difference. For frequent enough
> >         insertions, the cost comes not from mispredicted branches but
> >         the integer instructions to fetch and compare the capacity
> >         pointer.
> >
> >
> > Just to add: the implementation of push_back_() would be something
> > like
> >
> > *ptr_end++=parameter;
> >
> > and so almost certainly inlined. In contrast, push_back() is unlikely
> > to get inlined, as it does some complicated stuff, like reallocation
> > and handling the ugly special case like v.push_back(v[i]).
>
> I would expect the implementetion of push_back to be something along the
> line of
>
> inline void vector<T>::push_back(const T& parameter) {
>   if (ptr_end == ptr_capacity)
>     grow();
>   allocator.construct(ptr_end, parameter);
>   ++ptr_end;
> }
>
> where grow() grows the vector if needed. Here I don't expect grow() to
> be fully inlined but I do not see why the rest couldn't be inlined.
>
> Note that the your push_back_ also needs to do
>
>   allocator.construct(ptr_end, parameter);
>   ++ptr_end; // Increment after as construct could throw
>
> since I expect the memory from ptr_end to ptr_capacity to be
> uninitialized, so it really isn't that much simpler.
>
> /MF
>
>

Ok, point taken about allocator.construct.

However, your implementation of puch_back has a subtle bug: it has
undefined behaviour for calls like v.push_back(v[0]) when v is full. Hence,
you need to add some code to handle this special case. This complicates the
implementation and makes it less likely to be inlined.

--

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

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

<div dir=3D"ltr"><div>On Saturday, September 7, 2013 7:58:51 PM UTC+1, Magn=
us Fromreide wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;">On Sat, 2013-09-07 at=
 11:19 -0700, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"-rZp1mYJTvAJ">Victor....@ncl.ac.uk</a> wrote:
<div>&gt;=20
</div><div>&gt; On Saturday, September 7, 2013 12:10:25 PM UTC+1, David Kra=
uss wrote:
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp;=20
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp;=20
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; On Saturday, September 7, 2013 =
4:59:45 PM UTC+8,
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; <a>the.ultim...@gmail.com</a> w=
rote:
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Hel=
lo Victor,
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp;
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; vector::push_back() is inefficient, as every
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; time it checks whether the vector has reached
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; its full capacity and needs to allocate more
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; memory. Such a check is often unnecessary,
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; e.g. if reserve() was called, see the example
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; below.=20
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=20
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; I d=
on't deny that there is a textual check at every
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; pus=
h_back(). Do you have measurements on the acutal
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; imp=
act on execution? My theory is, if you reserved
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; eno=
ugh memory, the check should pass everytime and
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; bra=
nch prediction would make your insertions throttle
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ful=
l speed.
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=20
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp;=20
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; I can vouch that it makes a dif=
ference. For frequent enough
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; insertions, the cost comes not =
from mispredicted branches but
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; the integer instructions to fet=
ch and compare the capacity
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp; pointer.
</div><div>&gt; &nbsp; &nbsp; &nbsp; &nbsp;=20
</div><div>&gt; &nbsp;
</div><div>&gt; Just to add: the implementation of push_back_() would be so=
mething
</div><div>&gt; like
</div><div>&gt; &nbsp;
</div><div>&gt; *ptr_end++=3Dparameter;
</div><div>&gt; &nbsp;
</div><div>&gt; and so almost certainly inlined. In contrast, push_back() i=
s unlikely
</div><div>&gt; to get inlined, as it does some complicated stuff, like rea=
llocation
</div><div>&gt; and handling the ugly special case like v.push_back(v[i]).
</div><div>
&nbsp;</div><div>I would expect the implementetion of push_back to be somet=
hing along the
</div><div>line of
</div><div>
&nbsp;</div><div>inline void vector&lt;T&gt;::push_back(const T&amp; parame=
ter) {
</div><div>&nbsp; if (ptr_end =3D=3D ptr_capacity)
</div><div>&nbsp; &nbsp; grow();
</div><div>&nbsp; allocator.construct(ptr_end, parameter);
</div><div>&nbsp; ++ptr_end;
</div><div>}
</div><div>
&nbsp;</div><div>where grow() grows the vector if needed. Here I don't expe=
ct grow() to
</div><div>be fully inlined but I do not see why the rest couldn't be inlin=
ed.
</div><div>
&nbsp;</div><div>Note that the your push_back_ also needs to do
</div><div>
&nbsp;</div><div>&nbsp; allocator.construct(ptr_end, parameter);
</div><div>&nbsp; ++ptr_end; // Increment after as construct could throw
</div><div>
&nbsp;</div><div>since I expect the memory from ptr_end to ptr_capacity to =
be
</div><div>uninitialized, so it really isn't that much simpler.
</div><div>
&nbsp;</div><div>/MF
</div><div>
&nbsp;</div></blockquote><div>&nbsp;</div><div>Ok, point taken about&nbsp;a=
llocator.construct.</div><div>&nbsp;</div><div>However, your implementation=
 of puch_back&nbsp;has a subtle bug: it has undefined behaviour&nbsp;for ca=
lls like v.push_back(v[0]) when v is full. Hence, you need to add some code=
 to handle this special case. This complicates the implementation and makes=
 it less likely to be inlined.</div></div>

<p></p>

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

------=_Part_596_28731139.1378580987325--

.

--089e013a215a216e2c04e5cff689
Content-Type: text/plain; charset=ISO-8859-1

On 7 September 2013 22:03, <Victor.Khomenko@ncl.ac.uk> wrote:

>
> On Saturday, September 7, 2013 12:57:45 PM UTC+1, Ville Voutilainen wrote:
>>
>>
>> Well, if I don't want to resize the vector (and construct objects), I
>> can't see what work-around would
>> allow avoiding push_back. A vector of optionals would allow the resize
>> without constructing
>> the underlying objects, and then I could just use operator[].
>>
>
> Doesn't solve the problem: still many optionals are constructed, only to
> be immediately overwritten.
>
>
>
>
Assuming that the Widgets in your original example are costly to construct
and overwrite,
the optional<Widget>s are not costly to construct.

--

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

--089e013a215a216e2c04e5cff689
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 7 September 2013 22:03,  <span dir=3D"ltr">&lt;<a href=3D"mailto=
:Victor.Khomenko@ncl.ac.uk" target=3D"_blank">Victor.Khomenko@ncl.ac.uk</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><br>On Sa=
turday, September 7, 2013 12:57:45 PM UTC+1, Ville Voutilainen wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:=
1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-st=
yle:solid">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br>Well, if I don&#3=
9;t want to resize the vector (and construct objects), I can&#39;t see what=
 work-around would<br>allow avoiding push_back. A vector of optionals would=
 allow the resize without constructing<br>

the underlying objects, and then I could just use operator[]. <br></div></d=
iv></div></div></blockquote><div>=A0</div></div><div>Doesn&#39;t solve=A0th=
e problem: still=A0many optionals are constructed, only to be immediately o=
verwritten.</div>
</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>Assuming that the Widg=
ets in your original example are costly to construct and overwrite,<br>the =
optional&lt;Widget&gt;s are not costly to construct. <br></div></div><br>
</div></div>

<p></p>

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

--089e013a215a216e2c04e5cff689--

.

On Sat, 2013-09-07 at 12:09 -0700, Victor.Khomenko@ncl.ac.uk wrote:
> On Saturday, September 7, 2013 7:58:51 PM UTC+1, Magnus Fromreide
> wrote:
>         On Sat, 2013-09-07 at 11:19 -0700, Victor....@ncl.ac.uk
>         wrote:
>         >
>
>         I would expect the implementetion of push_back to be something
>         along the
>         line of
>
>         inline void vector<T>::push_back(const T& parameter) {
>           if (ptr_end == ptr_capacity)
>             grow();
>           allocator.construct(ptr_end, parameter);
>           ++ptr_end;
>         }
>
>         where grow() grows the vector if needed. Here I don't expect
>         grow() to
>         be fully inlined but I do not see why the rest couldn't be
>         inlined.
>
>         Note that the your push_back_ also needs to do
>
>           allocator.construct(ptr_end, parameter);
>           ++ptr_end; // Increment after as construct could throw
>
>         since I expect the memory from ptr_end to ptr_capacity to be
>         uninitialized, so it really isn't that much simpler.
>
>         /MF
>
>
> Ok, point taken about allocator.construct.
>
> However, your implementation of puch_back has a subtle bug: it has
> undefined behaviour for calls like v.push_back(v[0]) when v is full.
> Hence, you need to add some code to handle this special case. This
> complicates the implementation and makes it less likely to be inlined.

Ok, point taken about the v[i] case, but the whole insertion in the
grow() case could be passed of to another method (grow(parameter)) since
that is a problem only when a reallocation happens so there still is no
reason this would prevent inlining of the non-growing case.

/MF

--

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

.

------=_Part_741_11350647.1378582888261
Content-Type: text/plain; charset=ISO-8859-1


On Saturday, September 7, 2013 8:21:58 PM UTC+1, Magnus Fromreide wrote:
>
> Ok, point taken about the v[i] case, but the whole insertion in the
> grow() case could be passed of to another method (grow(parameter)) since
> that is a problem only when a reallocation happens so there still is no
> reason this would prevent inlining of the non-growing case.
>
> /MF
>
>
Ok, maybe one can achieve inlining for push_bask, in principle at least.
Below is an actual implementation from VS2012. I find it difficult to
believe it's inlined...



void push_back(value_type&& _Val)
 { // insert by moving into element at end
 if (_Inside(_STD addressof(_Val)))
  { // push back an element
  size_type _Idx = _STD addressof(_Val) - this->_Myfirst;
  if (this->_Mylast == this->_Myend)
   _Reserve(1);
  _Orphan_range(this->_Mylast, this->_Mylast);
  this->_Getal().construct(this->_Mylast,
   _STD forward<value_type>(this->_Myfirst[_Idx]));
  ++this->_Mylast;
  }
 else
  { // push back a non-element
  if (this->_Mylast == this->_Myend)
   _Reserve(1);
  _Orphan_range(this->_Mylast, this->_Mylast);
  this->_Getal().construct(this->_Mylast,
   _STD forward<value_type>(_Val));
  ++this->_Mylast;
  }
 }







--

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

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

<div dir=3D"ltr"><br>On Saturday, September 7, 2013 8:21:58 PM UTC+1, Magnu=
s Fromreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;">

Ok, point taken about the v[i] case, but the whole insertion in the
<br>grow() case could be passed of to another method (grow(parameter)) sinc=
e
<br>that is a problem only when a reallocation happens so there still is no
<br>reason this would prevent inlining of the non-growing case.
<br>
<br>/MF
<br><br></blockquote><div>&nbsp;</div><div>Ok, maybe one can achieve inlini=
ng for push_bask, in principle at least. Below is an actual implementation =
from VS2012. I find it difficult to believe it's inlined...</div><font face=
=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D"2"><div><p>&nbsp;<=
p>void push_back(value_type&amp;&amp; _Val)<br>&nbsp;{&nbsp;// insert by mo=
ving into element at end<br>&nbsp;if (_Inside(_STD addressof(_Val)))<br>&nb=
sp;&nbsp;{&nbsp;// push back an element<br>&nbsp;&nbsp;size_type _Idx =3D _=
STD addressof(_Val) - this-&gt;_Myfirst;<br>&nbsp;&nbsp;if (this-&gt;_Mylas=
t =3D=3D this-&gt;_Myend)<br>&nbsp;&nbsp;&nbsp;_Reserve(1);<br>&nbsp;&nbsp;=
_Orphan_range(this-&gt;_Mylast, this-&gt;_Mylast);<br>&nbsp;&nbsp;this-&gt;=
_Getal().construct(this-&gt;_Mylast,<br>&nbsp;&nbsp;&nbsp;_STD forward&lt;v=
alue_type&gt;(this-&gt;_Myfirst[_Idx]));<br>&nbsp;&nbsp;++this-&gt;_Mylast;=
<br>&nbsp;&nbsp;}<br>&nbsp;else<br>&nbsp;&nbsp;{&nbsp;// push back a non-el=
ement<br>&nbsp;&nbsp;if (this-&gt;_Mylast =3D=3D this-&gt;_Myend)<br>&nbsp;=
&nbsp;&nbsp;_Reserve(1);<br>&nbsp;&nbsp;_Orphan_range(this-&gt;_Mylast, thi=
s-&gt;_Mylast);<br>&nbsp;&nbsp;this-&gt;_Getal().construct(this-&gt;_Mylast=
,<br>&nbsp;&nbsp;&nbsp;_STD forward&lt;value_type&gt;(_Val));<br>&nbsp;&nbs=
p;++this-&gt;_Mylast;<br>&nbsp;&nbsp;}<br>&nbsp;}</p></div></font><p><div>&=
nbsp;</div><p></p></font><p>&nbsp;<div>&nbsp;</div><div>&nbsp;</div></div>

<p></p>

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

------=_Part_741_11350647.1378582888261--

.

------=_Part_766_8466326.1378583433632
Content-Type: text/plain; charset=ISO-8859-1


On Saturday, September 7, 2013 8:14:17 PM UTC+1, Ville Voutilainen wrote:
>
>
> Assuming that the Widgets in your original example are costly to construct
> and overwrite,
> the optional<Widget>s are not costly to construct.
>

Sure - this can work in some circumstances. However, we are talking about
saving a couple of processor instructions here, so "costly" should be
viewed from this perspective. Also, that extra flag in optional<> can
increase the element size, spoil the alignment, and result in something
that's actually slower and takes more memory. The bottom line: occasionally
it works, but it's not a general solution to 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br>On Saturday, September 7, 2013 8:14:17 PM UTC+1, Ville=
 Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br>Assumi=
ng that the Widgets in your original example are costly to construct and ov=
erwrite,<br>the optional&lt;Widget&gt;s are not costly to construct. <br></=
div></blockquote><div>&nbsp;</div><div>Sure - this can work in some circums=
tances. However,&nbsp;we are&nbsp;talking about saving a couple of&nbsp;pro=
cessor instructions here, so "costly" should be viewed from this perspectiv=
e. Also, that extra flag in optional&lt;&gt; can increase the element size,=
 spoil the alignment, and result in something that's actually slower and ta=
kes more memory. The bottom line: occasionally it works, but it's not a gen=
eral solution to the problem.</div></div>

<p></p>

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

------=_Part_766_8466326.1378583433632--

.

On Fri, Sep 6, 2013 at 7:05 PM,  <Victor.Khomenko@ncl.ac.uk> wrote:
> [I suspect I am re-inventing the wheel, but a quick search of this forum
> didn't yield any similar proposal.]
>
> vector::push_back() is inefficient, as every time it checks whether the
> vector has reached its full capacity and needs to allocate more memory. Such
> a check is often unnecessary, e.g. if reserve() was called, see the example
> below. Hence, the proposal is to add vector::push_back_() which skips this
> check. Calling it for a full vector results in undefined behaviour
> (consistent with operator[] which does not check that the index is valid).
> Of course, an assertion checking the capacity should be used in push_back_()
> to simplify debugging, but the optimised code has no overhead.

I think a elegant solution for this (and a lot of other similar)
problem would be
something like this:

void foo(std::vector<char>& v)
{
  assume(v.reserve() > v.size());
  v.push_back('a'); // the compiler would do dead-code elimination and
then inline
}

[snip - example]

Regards,
--
Felipe Magno de Almeida

--

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

.

--047d7bfe97e07fe55c04e5d095a5
Content-Type: text/plain; charset=ISO-8859-1

On 7 September 2013 22:50, <Victor.Khomenko@ncl.ac.uk> wrote:

>
> On Saturday, September 7, 2013 8:14:17 PM UTC+1, Ville Voutilainen wrote:
>>
>>
>> Assuming that the Widgets in your original example are costly to
>> construct and overwrite,
>> the optional<Widget>s are not costly to construct.
>>
>
> Sure - this can work in some circumstances. However, we are talking about
> saving a couple of processor instructions here, so "costly" should be
> viewed from this perspective. Also, that extra flag in optional<> can
> increase the element size, spoil the alignment, and result in something
> that's actually slower and takes more memory. The bottom line: occasionally
> it works, but it's not a general solution to the problem.
>
>
>
>
True enough. I think this proposal has quite decent merit. I can't really
work around it otherwise than postponing
the construction with optional, so it looks like a change to vector is
what's necessary. If benchmarks show
that it's necessary, that is. ;)

--

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

--047d7bfe97e07fe55c04e5d095a5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 7 September 2013 22:50,  <span dir=3D"ltr">&lt;<a href=3D"mailto=
:Victor.Khomenko@ncl.ac.uk" target=3D"_blank">Victor.Khomenko@ncl.ac.uk</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><br>On Sa=
turday, September 7, 2013 8:14:17 PM UTC+1, Ville Voutilainen wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1=
ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-sty=
le:solid">
<div dir=3D"ltr"><br>Assuming that the Widgets in your original example are=
 costly to construct and overwrite,<br>the optional&lt;Widget&gt;s are not =
costly to construct. <br></div></blockquote><div>=A0</div></div><div>Sure -=
 this can work in some circumstances. However,=A0we are=A0talking about sav=
ing a couple of=A0processor instructions here, so &quot;costly&quot; should=
 be viewed from this perspective. Also, that extra flag in optional&lt;&gt;=
 can increase the element size, spoil the alignment, and result in somethin=
g that&#39;s actually slower and takes more memory. The bottom line: occasi=
onally it works, but it&#39;s not a general solution to the problem.</div>
</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>True enough. I think t=
his proposal has quite decent merit. I can&#39;t really work around it othe=
rwise than postponing<br>the construction with optional, so it looks like a=
 change to vector is what&#39;s necessary. If benchmarks show<br>
that it&#39;s necessary, that is. ;) <br></div></div><br></div></div>

<p></p>

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

--047d7bfe97e07fe55c04e5d095a5--

.

------=_Part_6_8820428.1378585696615
Content-Type: text/plain; charset=ISO-8859-1


On Saturday, September 7, 2013 8:54:30 PM UTC+1, Felipe Almeida wrote:
>
>
> I think a elegant solution for this (and a lot of other similar)
> problem would be
> something like this:
>
> void foo(std::vector<char>& v)
> {
>   assume(v.reserve() > v.size());
>   v.push_back('a'); // the compiler would do dead-code elimination and
> then inline
> }
>

This is an interesting idea, but not quite perfect:
 * in a critical section or a tight loop I'd positively want to make sure
that the optimisation has occured - but "assume" does not give any positive
guarantees
 * it would be non-trivial for the compiler to do this optimisation for the
following reasons:
    - the user can only refer to public methods like capacity() and size()
in the "assume" clause while the implementation of puch_back would probably
refer to private data directly, and the compiler will have to figure out
the relashionship between these.
    - there is a special case in push_back that is handled separately:
v.push_back(v[0]); you need to say to the compiler somehow that if the
allocation is not required then this case should not be treated as special.

--

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

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

<div dir=3D"ltr"><br>On Saturday, September 7, 2013 8:54:30 PM UTC+1, Felip=
e Almeida wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><br>I think a elegant solution=
 for this (and a lot of other similar)
<br>problem would be
<br>something like this:
<br>
<br>void foo(std::vector&lt;char&gt;&amp; v)
<br>{
<br>&nbsp; assume(v.reserve() &gt; v.size());
<br>&nbsp; v.push_back('a'); // the compiler would do dead-code elimination=
 and
<br>then inline
<br>}
<br></blockquote><div>&nbsp;</div><div>This is an interesting idea, but not=
 quite perfect:</div><div>&nbsp;* in a critical section or&nbsp;a tight loo=
p I'd positively want to make sure that the optimisation has occured - but =
"assume" does not give any positive guarantees</div><div>&nbsp;* it would b=
e non-trivial for the compiler to do this optimisation for the following re=
asons:</div><div>&nbsp;&nbsp;&nbsp; - the user can only refer to public met=
hods like capacity() and size() in the "assume" clause while the implementa=
tion of puch_back would probably refer to private data directly, and the co=
mpiler will have to figure out the relashionship between these.</div><div>&=
nbsp;&nbsp;&nbsp; - there is a special case in push_back that is handled se=
parately: v.push_back(v[0]); you need to say to the compiler somehow that i=
f the allocation is not required then this case should not be treated as sp=
ecial.</div></div>

<p></p>

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

------=_Part_6_8820428.1378585696615--

.

On Sat, 2013-09-07 at 12:41 -0700, Victor.Khomenko@ncl.ac.uk wrote:
>
> On Saturday, September 7, 2013 8:21:58 PM UTC+1, Magnus Fromreide
> wrote:
>         Ok, point taken about the v[i] case, but the whole insertion
>         in the
>         grow() case could be passed of to another method
>         (grow(parameter)) since
>         that is a problem only when a reallocation happens so there
>         still is no
>         reason this would prevent inlining of the non-growing case.
>
>         /MF
>
>
> Ok, maybe one can achieve inlining for push_bask, in principle at
> least. Below is an actual implementation from VS2012. I find it
> difficult to believe it's inlined...
>
>
> void push_back(value_type&& _Val)
>  { // insert by moving into element at end
>  if (_Inside(_STD addressof(_Val)))
>   { // push back an element
>   size_type _Idx = _STD addressof(_Val) - this->_Myfirst;
>   if (this->_Mylast == this->_Myend)
>    _Reserve(1);
>   _Orphan_range(this->_Mylast, this->_Mylast);
>   this->_Getal().construct(this->_Mylast,
>    _STD forward<value_type>(this->_Myfirst[_Idx]));
>   ++this->_Mylast;
>   }
>  else
>   { // push back a non-element
>   if (this->_Mylast == this->_Myend)
>    _Reserve(1);
>   _Orphan_range(this->_Mylast, this->_Mylast);
>   this->_Getal().construct(this->_Mylast,
>    _STD forward<value_type>(_Val));
>   ++this->_Mylast;
>   }
>  }
>
That is a quality of implementation issue but I would measure rather
than guess regarding optimizations of standard library functions since
optimizers can be surprisingly good.

If one looks at GCC instead the implementation is

void
push_back(value_type&& __x)
{ emplace_back(std::move(__x)); }

template<typename _Tp, typename _Alloc>
template<typename... _Args>
void
vector<_Tp, _Alloc>::
emplace_back(_Args&&... __args)
{
  if (this->_M_impl._M_finish != this->_M_impl._M_end_of_storage)
    {
      _Alloc_traits::construct(this->_M_impl, this->_M_impl._M_finish,
                               std::forward<_Args>(__args)...);
      ++this->_M_impl._M_finish;
    }
  else
    _M_emplace_back_aux(std::forward<_Args>(__args)...);
}



--

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

.

------=_Part_476_22425018.1378586468750
Content-Type: text/plain; charset=ISO-8859-1


On Saturday, September 7, 2013 7:39:14 PM UTC+1, DeadMG wrote:
>
> It would unfortunately be much easier because ranges are so irritating to
> construct. This, however, is immaterial to the fact that the other
> solutions are a disgusting hack which is only an approximation to the real
> solution.
>

By that logic, vector::operator[] is also a "disgusting hack" as it results
in indefined behaviour if the index is out of range, instead of throwing an
exception. However, the committee felt that efficiency was more important
here than protecting the user from shooting themselves in a foot. The C++
philosophy is not to protect programmers from themselves, but to offer a
choice - purists can still use the old good push_back. However, in some
situation I do want maximum efficiency.

As I said in the original posting, any reasonable STL implementation would
add an assertion to push_back_ to check that the assumption on the capacity
actually holds - this would make debugging such violations as easy as
debugging out-of[range problems.

--

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

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

<div dir=3D"ltr"><br>On Saturday, September 7, 2013 7:39:14 PM UTC+1, DeadM=
G wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8e=
x; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wi=
dth: 1px; border-left-style: solid;"><div dir=3D"ltr">It would unfortunatel=
y be much easier because ranges are so irritating to construct. This, howev=
er, is immaterial to the fact that the other solutions are a disgusting hac=
k which is only an approximation to the real solution.</div></blockquote><d=
iv>&nbsp;</div><div>By that logic, vector::operator[] is also a "disgusting=
 hack" as it results in indefined behaviour if the index is out of range, i=
nstead of throwing an exception. However, the committee felt that efficienc=
y was more important here than protecting the user from shooting themselves=
 in a foot. The C++ philosophy is not to protect programmers from themselve=
s, but to offer a choice - purists can still use the old good push_back. Ho=
wever, in some situation I do want&nbsp;maximum efficiency.</div><div>&nbsp=
;</div><div>As I said in the original posting, any reasonable STL implement=
ation would add an assertion to push_back_ to check that the assumption on =
the capacity actually holds - this would make debugging such violations as =
easy as debugging out-of[range problems.</div></div>

<p></p>

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

------=_Part_476_22425018.1378586468750--

.

Why is that check any cheaper than the check for push_back to see if
the vector should grow?

--
 Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (312) 623-5420

> On Sep 7, 2013, at 3:41 PM, "Victor.Khomenko@ncl.ac.uk" <Victor.Khomenko@ncl.ac.uk> wrote:
>
> As I said in the original posting, any reasonable STL implementation would add an assertion to push_back_ to check that the assumption on the capacity actually holds

--

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

.

On Sep 7, 2013, at 3:41 PM, Victor.Khomenko@ncl.ac.uk wrote:

> Ok, maybe one can achieve inlining for push_bask, in principle at least. =
Below is an actual implementation from VS2012. I find it difficult to belie=
ve it's inlined...
> =20
> void push_back(value_type&& _Val)
>  { // insert by moving into element at end
>  if (_Inside(_STD addressof(_Val)))
>   { // push back an element
>   size_type _Idx =3D _STD addressof(_Val) - this->_Myfirst;
>   if (this->_Mylast =3D=3D this->_Myend)
>    _Reserve(1);
>   _Orphan_range(this->_Mylast, this->_Mylast);
>   this->_Getal().construct(this->_Mylast,
>    _STD forward<value_type>(this->_Myfirst[_Idx]));
>   ++this->_Mylast;
>   }
>  else
>   { // push back a non-element
>   if (this->_Mylast =3D=3D this->_Myend)
>    _Reserve(1);
>   _Orphan_range(this->_Mylast, this->_Mylast);
>   this->_Getal().construct(this->_Mylast,
>    _STD forward<value_type>(_Val));
>   ++this->_Mylast;
>   }
>  }

I recommend you stick to quoting open sourced implementations.  Here's one =
where you won't get in trouble:

http://libcxx.llvm.org

template <class _Tp, class _Allocator>
_LIBCPP_INLINE_VISIBILITY inline
void
vector<_Tp, _Allocator>::push_back(const_reference __x)
{
    if (this->__end_ !=3D this->__end_cap())
    {
        __alloc_traits::construct(this->__alloc(),
                                  _VSTD::__to_raw_pointer(this->__end_), __=
x);
        ++this->__end_;
    }
    else
        __push_back_slow_path(__x);
}

As others have alluded to, if push_back, and reserve+push_back is too expen=
sive for you, then you are in to a specialty niche situation, and you shoul=
d be prepared to do some extra work.

1.  You need to tell the vector up front how many elements there are going =
to be.

2.  You need to create a Widget generator which the function can use to con=
struct widgets with.

3.  Cast the generator in the form of a random access iterator.  Random acc=
ess is important as that is how the vector will get your up-front size stat=
ement.  I strongly suspect you can safely ignore the requirement that a ran=
dom access iterator must return a Widget& from operator*().  vector doesn't=
 need or use that requirement.  And it is a dumb requirement anyway that we=
 should change.

Here's a sketch:

#include <vector>

class Widget
{
    int data_;
public:
    explicit Widget(int data) : data_(data) {}
};

class generator_Widget
{
    int count_;
    int state_;

public:
    typedef std::random_access_iterator_tag iterator_category;
    typedef Widget                          value_type;
    typedef std::ptrdiff_t                  difference_type;
    typedef const Widget*                   pointer;
    typedef Widget                          reference;

    explicit generator_Widget(int count, int state =3D 0)
        : count_(count), state_(state) {}

    reference operator*() const {return Widget(state_);}
    pointer operator->() const {return nullptr;}

    generator_Widget& operator++() {++count_; --state_; return *this;}
    generator_Widget operator++(int)
        {generator_Widget tmp(*this); ++(*this); return tmp;}

    generator_Widget& operator--() {--count_; ++state_; return *this;}
    generator_Widget operator--(int)
        {generator_Widget tmp(*this); --(*this); return tmp;}

    generator_Widget& operator+=3D(difference_type n) {count_ +=3D n; state=
_ -=3D n; return *this;}
    generator_Widget operator+(difference_type n) const
        {generator_Widget tmp(*this); tmp +=3D n; return tmp;}
    friend generator_Widget operator+(difference_type n, generator_Widget x=
)
        {x +=3D n; return x;}
    generator_Widget& operator-=3D(difference_type n) {return *this +=3D -n=
;}
    generator_Widget operator-(difference_type n) const
        {generator_Widget tmp(*this); tmp -=3D n; return tmp;}

    reference operator[](difference_type n) const {return *(*this + n);}

    friend
    bool
    operator=3D=3D(const generator_Widget& x, const generator_Widget& y)
        {return x.count_ =3D=3D y.count_;}

    friend
    bool
    operator!=3D(const generator_Widget& x, const generator_Widget& y)
        {return !(x =3D=3D y);}

    friend
    bool
    operator<(const generator_Widget& x, const generator_Widget& y)
        {return x.count_ < y.count_;}

    friend
    bool
    operator>(const generator_Widget& x, const generator_Widget& y)
        {return y < x;}

    friend
    bool
    operator<=3D(const generator_Widget& x, const generator_Widget& y)
        {return !(y < x);}

    friend
    bool
    operator>=3D(const generator_Widget& x, const generator_Widget& y)
        {return !(x < y);}

    friend
    difference_type
    operator-(const generator_Widget& x, const generator_Widget& y)
        {return x.count_ - y.count_;}

};

int
main()
{
    std::vector<Widget> v(generator_Widget(0, 10), generator_Widget(10));
}

Yes, its a pain to write all this boilerplate.  Maybe you can generalize th=
e iterator/generator so you only have to write it once.  Or maybe somebody =
(boost?) has already written it for you.  But it isn't going to get much fa=
ster than this.  The vector constructor will subtract the pair of random ac=
cess iterators in its constructor and allocate the right amount of memory. =
 And then it will iterate through the range constructing each Widget from t=
he dereferenced iterator.

Another technique you could use is to give the vector an allocator whose co=
nstruct member is a no-op:

   template <class U, class... Args>
       void
       construct(U* p, Args&&...)
       {
       }


Then construct your vector:

   vector<Widget, my_alloc<Widget>> v(N);  // allocate but don't construct =
the Widgets

And then loop through your vector and actually construct each Widget:

    for (auto& w : v)
       ::new(&w) Widget(...);

You'll need to watch out for exception safety on this one.  If any of your =
Widget constructors throws, then ~Widget() better be able to cope with an u=
nspecified Widget state.

Neither of these techniques is very elegant.  But they are both workable.  =
They seem to me a better approach than adding an extremely error-prone memb=
er function to vector.

If we're going to further increase the performance of vector, the next most=
 effective step to take is to teach allocators how to expand existing alloc=
ations in place (realloc without the possibility of an address change), and=
 teach containers how to use such allocators.  Doing this can produce as mu=
ch as a 2X performance improvement compared to an un-reserved push_back loo=
p.  However even this at-best-2X improvement was not sufficiently enticing =
for the committee in the past.  I have no reason to think it will be in the=
 future.

Howard

--=20

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

.

------=_Part_660_27285492.1378587572237
Content-Type: text/plain; charset=ISO-8859-1


On Saturday, September 7, 2013 9:49:20 PM UTC+1, Nevin ":-)" Liber wrote:
>
> Why is that check any cheaper than the check for push_back to see if
> the vector should grow?
>
Because assertion are only active in the debug mode, and are removed in the
release build.

--

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

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

<div dir=3D"ltr"><br>On Saturday, September 7, 2013 9:49:20 PM UTC+1, Nevin=
 ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">Why is that check any cheap=
er than the check for push_back to see if
<div>the vector should grow?
</div></blockquote><div>
</div><div>Because assertion&nbsp;are only active in the debug mode, and ar=
e removed in the release build.</div></div>

<p></p>

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

------=_Part_660_27285492.1378587572237--

.

------=_Part_410_9242747.1378588364925
Content-Type: text/plain; charset=ISO-8859-1


On Saturday, September 7, 2013 9:36:27 PM UTC+1, Magnus Fromreide wrote:
>
> That is a quality of implementation issue but I would measure rather
> than guess regarding optimizations of standard library functions since
> optimizers can be surprisingly good.
>
>

I wouldn't overestimate the intellect of optimisers, especially when
pointers are involved...

In any case, there is no positive assurance that the optimisation
is applied. This is also unstable - minor changes in the code can upset
it. Moreover, it is easy enought to confuse the optimiser in practice. E.g.
imagine several threads compute some good stuff and push their results into
a vector, protecting puch_back calls by a lock. The user knows the upper
bound on the total number of results, and so can reserve memory in advance.
However, the code executed by the threads is far away from the call to
reserve(), so the compiler is powerless to optimise the critical section.



> If one looks at GCC instead the implementation is
>

Ok, can actually be inlined if you're lucky with your STL vendor :-)

--

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

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

<div dir=3D"ltr"><br>On Saturday, September 7, 2013 9:36:27 PM UTC+1, Magnu=
s Fromreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;">
That is a quality of implementation issue but I would measure rather
<div>than guess regarding optimizations of standard library functions since
</div><div>optimizers can be surprisingly good.
</div><div>
&nbsp;</div></blockquote><div>&nbsp;</div><div>I wouldn't overestimate the =
intellect of optimisers, especially&nbsp;when pointers are involved...</div=
><div>&nbsp;</div><div>In any case, there is no positive assurance that the=
 optimisation is&nbsp;applied. This is also unstable - minor changes in the=
 code can upset it.&nbsp;Moreover, it is easy enought&nbsp;to confuse the o=
ptimiser in practice. E.g. imagine several threads compute some good stuff =
and push their results into a vector, protecting puch_back calls by a lock.=
 The user knows the upper bound on the total number of results, and so can&=
nbsp;reserve memory in advance. However, the code executed by the threads i=
s far away from the call to reserve(), so the compiler is powerless to opti=
mise&nbsp;the critical section.</div><div>&nbsp;</div><div>&nbsp;</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-l=
eft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bo=
rder-left-style: solid;"><div>If one looks at GCC instead the implementatio=
n is
</div></blockquote><div>&nbsp;</div><div>Ok, can&nbsp;actually be inlined i=
f you're lucky with your STL vendor :-)</div></div>

<p></p>

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

------=_Part_410_9242747.1378588364925--

.

------=_Part_189_9695219.1378589590403
Content-Type: text/plain; charset=ISO-8859-1


On Saturday, September 7, 2013 9:50:51 PM UTC+1, Howard Hinnant wrote:
>
> If we're going to further increase the performance of vector, the next
> most effective step to take is to teach allocators how to expand existing
> allocations in place (realloc without the possibility of an address
> change), and teach containers how to use such allocators.  Doing this can
> produce as much as a 2X performance improvement compared to an un-reserved
> push_back loop.  However even this at-best-2X improvement was not
> sufficiently enticing for the committee in the past.  I have no reason to
> think it will be in the future.
>
> Howard
>

The generator solution is unelegant, I think I'd rather use malloc and
manage memory myself than doing anything like this. It is also of limited
use compared to push_back_ - e.g. imagine several threads push their
results into a vector, protecting puch_back_ calls by a lock; this is
difficult to reformulate as generators.

The allocator solution is interesting, and would probably work, but I
believe it is no less "error-prone" than push_back_. Do you really want to
recommend it? I think push_back_ is no more difficult / error-prone than
operator[], so the users can cope with it.

--

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

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

<div dir=3D"ltr"><br>On Saturday, September 7, 2013 9:50:51 PM UTC+1, Howar=
d Hinnant wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;">If we're going to further incr=
ease the performance of vector, the next most effective step to take is to =
teach allocators how to expand existing allocations in place (realloc witho=
ut the possibility of an address change), and teach containers how to use s=
uch allocators. &nbsp;Doing this can produce as much as a 2X performance im=
provement compared to an un-reserved push_back loop. &nbsp;However even thi=
s at-best-2X improvement was not sufficiently enticing for the committee in=
 the past. &nbsp;I have no reason to think it will be in the future.
<br>
<br>Howard<br>
</blockquote><div>&nbsp;</div><div>The generator solution is unelegant, I t=
hink I'd rather use malloc and manage memory myself than doing anything lik=
e this. It is also&nbsp;of limited use compared to push_back_&nbsp;- e.g.&n=
bsp;imagine several threads&nbsp;push their results into a vector, protecti=
ng puch_back_ calls by a lock; this is difficult to reformulate as generato=
rs.</div><div>&nbsp;</div><div>The allocator solution is interesting, and w=
ould probably work, but I believe it is no less "error-prone" than push_bac=
k_. Do you really want to recommend it? I think push_back_ is no more diffi=
cult / error-prone than operator[], so the&nbsp;users can cope with it.</di=
v></div>

<p></p>

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

------=_Part_189_9695219.1378589590403--

.

On Sep 7, 2013, at 5:33 PM, Victor.Khomenko@ncl.ac.uk wrote:

> The generator solution is unelegant, I think I'd rather use malloc and ma=
nage memory myself than doing anything like this.=20

That is certainly another possibility.

> It is also of limited use compared to push_back_ - e.g. imagine several t=
hreads push their results into a vector, protecting puch_back_ calls by a l=
ock; this is difficult to reformulate as generators.

And the generator method would also be unnecessary.  The cost of the lock w=
ould put the cost of the one if-statement you're trying to avoid into the n=
oise.

> =20
> The allocator solution is interesting, and would probably work, but I bel=
ieve it is no less "error-prone" than push_back_. Do you really want to rec=
ommend it? I think push_back_ is no more difficult / error-prone than opera=
tor[], so the users can cope with it.

The no-construct allocator technique is very error prone.  The one advantag=
e it has over push_back_ is that it is in C++11 and later, and push_back_ i=
sn't.

Howard

--=20

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

.

On Sep 7, 2013, at 4:50 PM, Howard Hinnant <howard.hinnant@gmail.com> wrote=
:

> Here's a sketch:
>=20
> #include <vector>
>=20
> class Widget
> {
>    int data_;
> public:
>    explicit Widget(int data) : data_(data) {}
> };
>=20
> class generator_Widget
> {

Fwiw, I decided it was time to see some real code and real numbers so we kn=
ow what we're dealing with.  I'm using the cheapest Widget I can imagine - =
just wraps an int.  This emphasizes any performance gains as much as possib=
le.  As Widget becomes more expensive to construct, the performance gains o=
f one technique over the other will probably become negligible.

Here's the code I'm testing:

#include <iostream>
#include <chrono>
#include <vector>

class Widget
{
    int data_;
public:
    explicit Widget(int data) : data_(data) {}
};

class generator_Widget
{
    int count_;
    int state_;

public:
//    typedef std::input_iterator_tag iterator_category;
    typedef std::random_access_iterator_tag iterator_category;
    typedef Widget                          value_type;
    typedef std::ptrdiff_t                  difference_type;
    typedef const Widget*                   pointer;
    typedef Widget                          reference;

    explicit generator_Widget(int count, int state =3D 0)
        : count_(count), state_(state) {}

    reference operator*() const {return Widget(state_);}
    pointer operator->() const {return nullptr;}

    generator_Widget& operator++() {++count_; --state_; return *this;}
    generator_Widget operator++(int)
        {generator_Widget tmp(*this); ++(*this); return tmp;}

    generator_Widget& operator--() {--count_; ++state_; return *this;}
    generator_Widget operator--(int)
        {generator_Widget tmp(*this); --(*this); return tmp;}

    generator_Widget& operator+=3D(difference_type n) {count_ +=3D n; state=
_ -=3D n; return *this;}
    generator_Widget operator+(difference_type n) const
        {generator_Widget tmp(*this); tmp +=3D n; return tmp;}
    friend generator_Widget operator+(difference_type n, generator_Widget x=
)
        {x +=3D n; return x;}
    generator_Widget& operator-=3D(difference_type n) {return *this +=3D -n=
;}
    generator_Widget operator-(difference_type n) const
        {generator_Widget tmp(*this); tmp -=3D n; return tmp;}

    reference operator[](difference_type n) const {return *(*this + n);}

    friend
    bool
    operator=3D=3D(const generator_Widget& x, const generator_Widget& y)
        {return x.count_ =3D=3D y.count_;}

    friend
    bool
    operator!=3D(const generator_Widget& x, const generator_Widget& y)
        {return !(x =3D=3D y);}

    friend
    bool
    operator<(const generator_Widget& x, const generator_Widget& y)
        {return x.count_ < y.count_;}

    friend
    bool
    operator>(const generator_Widget& x, const generator_Widget& y)
        {return y < x;}

    friend
    bool
    operator<=3D(const generator_Widget& x, const generator_Widget& y)
        {return !(y < x);}

    friend
    bool
    operator>=3D(const generator_Widget& x, const generator_Widget& y)
        {return !(x < y);}

    friend
    difference_type
    operator-(const generator_Widget& x, const generator_Widget& y)
        {return x.count_ - y.count_;}

};

int
main()
{
    const unsigned N =3D 1000000;
    using namespace std::chrono;
    auto t0 =3D high_resolution_clock::now();
#if 1
    std::vector<Widget> v(generator_Widget(0, N), generator_Widget(N));
#else
    std::vector<Widget> v;
    int state =3D N;
    v.reserve(N);
    for (unsigned i =3D 0; i < N; ++i, --state)
        v.push_back(Widget(state));
#endif
    auto t1 =3D std::chrono::high_resolution_clock::now();
    std::cout << duration_cast<microseconds>(t1-t0).count() << "\xC2\xB5s\n=
";
}

I'm testing the above with clang++ -O3, tip-of-trunk libc++.  For me this o=
utputs:

$ a.out
2468=B5s
$ a.out
2431=B5s
$ a.out
2443=B5s
$ a.out
2709=B5s

If I change the above to use push_back():

#if 0

Then I get:

$ a.out
3848=B5s
$ a.out
3608=B5s
$ a.out
3635=B5s
$ a.out
3765=B5s

That's around a 40% performance hit, which is significant.

I also noted a generator/iterator adaptor in boost:

http://www.boost.org/doc/libs/1_54_0/libs/utility/generator_iterator.htm

However this adaptor is strictly conforming, and thus classifying itself as=
 an input_iterator.  This is a performance killer.  I modeled this with:

    typedef std::input_iterator_tag iterator_category;
//    typedef std::random_access_iterator_tag iterator_category;

and got:

$ a.out
5256=B5s
$ a.out
5426=B5s
$ a.out
5233=B5s
$ a.out
5388=B5s

Another 48% slower than the push_back loop.  The main reason for this is th=
at vector can't predict a-preori the final capacity it will need, and thus =
must grow its capacity geometrically during the iteration.  libc++ grows wi=
th a factor of 2.  This is also the approximate time I get with the push_ba=
ck() method if I remove the v.reserve(N).

I haven't bothered testing the allocator-no-op-constructor method.  I belie=
ve it will be no faster, and possibly slower than the random-access-iterato=
r-generator technique because it requires two passes over the elements, and=
 one of the passes might be optimized out.

Howard

--=20

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

.

--089e0158a92e0936d004e5d7ec38
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Note that you can use the generator even if you aren't constructing the
vector by calling assign or insert. While the generator solution is clunky
if someone has really really profiled their code, and really found that a
significant fraction is spent in push_back (which I think is *exceedingly*
unlikely), then they can use the generator solution.

> The no-construct allocator technique is very error prone.  The one
advantage it has over push_back_ is that it is in C++11 and later, and
push_back_ isn't.

It also has the advantage that the client can't "screw up" and go off the
end of the allocated region. The resulting program is perfectly safe, which
wouldn't happen with the proposed push_back_ solution. (Yes, the generator
is more complex, but the vast majority of bugs there will result in easy to
diagnose crashes or simply fail to compile)

The benchmark above neglects to mention that there is also a size
modification going on inside push_back -- writes are typically more
expensive than reads, such as the comparison against capacity. If the
vector has been reserved in advance, then the capacity check is going to be
predicted with high accuracy by any machine worth its salt, so it should
parallelize well.

However, writing the value of size in the above example changes on every
iteration of the loop, and causes cross loop body memory dependencies. It
also doubles or triples the amount of memory being written to, because each
int being written is causing a size_t to be written for the size update.

The push_back_ proposal doesn't remove the size modification, only the
capacity check. Are we sure that the capacity check is actually the cause
of that 40% difference?



Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sat, Sep 7, 2013 at 4:45 PM, Howard Hinnant <howard.hinnant@gmail.com>wr=
ote:

> On Sep 7, 2013, at 4:50 PM, Howard Hinnant <howard.hinnant@gmail.com>
> wrote:
>
> > Here's a sketch:
> >
> > #include <vector>
> >
> > class Widget
> > {
> >    int data_;
> > public:
> >    explicit Widget(int data) : data_(data) {}
> > };
> >
> > class generator_Widget
> > {
>
> Fwiw, I decided it was time to see some real code and real numbers so we
> know what we're dealing with.  I'm using the cheapest Widget I can imagin=
e
> - just wraps an int.  This emphasizes any performance gains as much as
> possible.  As Widget becomes more expensive to construct, the performance
> gains of one technique over the other will probably become negligible.
>
> Here's the code I'm testing:
>
> #include <iostream>
> #include <chrono>
> #include <vector>
>
> class Widget
> {
>     int data_;
> public:
>     explicit Widget(int data) : data_(data) {}
> };
>
> class generator_Widget
> {
>     int count_;
>     int state_;
>
> public:
> //    typedef std::input_iterator_tag iterator_category;
>     typedef std::random_access_iterator_tag iterator_category;
>     typedef Widget                          value_type;
>     typedef std::ptrdiff_t                  difference_type;
>     typedef const Widget*                   pointer;
>     typedef Widget                          reference;
>
>     explicit generator_Widget(int count, int state =3D 0)
>         : count_(count), state_(state) {}
>
>     reference operator*() const {return Widget(state_);}
>     pointer operator->() const {return nullptr;}
>
>     generator_Widget& operator++() {++count_; --state_; return *this;}
>     generator_Widget operator++(int)
>         {generator_Widget tmp(*this); ++(*this); return tmp;}
>
>     generator_Widget& operator--() {--count_; ++state_; return *this;}
>     generator_Widget operator--(int)
>         {generator_Widget tmp(*this); --(*this); return tmp;}
>
>     generator_Widget& operator+=3D(difference_type n) {count_ +=3D n; sta=
te_
> -=3D n; return *this;}
>     generator_Widget operator+(difference_type n) const
>         {generator_Widget tmp(*this); tmp +=3D n; return tmp;}
>     friend generator_Widget operator+(difference_type n, generator_Widget
> x)
>         {x +=3D n; return x;}
>     generator_Widget& operator-=3D(difference_type n) {return *this +=3D =
-n;}
>     generator_Widget operator-(difference_type n) const
>         {generator_Widget tmp(*this); tmp -=3D n; return tmp;}
>
>     reference operator[](difference_type n) const {return *(*this + n);}
>
>     friend
>     bool
>     operator=3D=3D(const generator_Widget& x, const generator_Widget& y)
>         {return x.count_ =3D=3D y.count_;}
>
>     friend
>     bool
>     operator!=3D(const generator_Widget& x, const generator_Widget& y)
>         {return !(x =3D=3D y);}
>
>     friend
>     bool
>     operator<(const generator_Widget& x, const generator_Widget& y)
>         {return x.count_ < y.count_;}
>
>     friend
>     bool
>     operator>(const generator_Widget& x, const generator_Widget& y)
>         {return y < x;}
>
>     friend
>     bool
>     operator<=3D(const generator_Widget& x, const generator_Widget& y)
>         {return !(y < x);}
>
>     friend
>     bool
>     operator>=3D(const generator_Widget& x, const generator_Widget& y)
>         {return !(x < y);}
>
>     friend
>     difference_type
>     operator-(const generator_Widget& x, const generator_Widget& y)
>         {return x.count_ - y.count_;}
>
> };
>
> int
> main()
> {
>     const unsigned N =3D 1000000;
>     using namespace std::chrono;
>     auto t0 =3D high_resolution_clock::now();
> #if 1
>     std::vector<Widget> v(generator_Widget(0, N), generator_Widget(N));
> #else
>     std::vector<Widget> v;
>     int state =3D N;
>     v.reserve(N);
>     for (unsigned i =3D 0; i < N; ++i, --state)
>         v.push_back(Widget(state));
> #endif
>     auto t1 =3D std::chrono::high_resolution_clock::now();
>     std::cout << duration_cast<microseconds>(t1-t0).count() <<
> "\xC2\xB5s\n";
> }
>
> I'm testing the above with clang++ -O3, tip-of-trunk libc++.  For me this
> outputs:
>
> $ a.out
> 2468=B5s
> $ a.out
> 2431=B5s
> $ a.out
> 2443=B5s
> $ a.out
> 2709=B5s
>
> If I change the above to use push_back():
>
> #if 0
>
> Then I get:
>
> $ a.out
> 3848=B5s
> $ a.out
> 3608=B5s
> $ a.out
> 3635=B5s
> $ a.out
> 3765=B5s
>
> That's around a 40% performance hit, which is significant.
>
> I also noted a generator/iterator adaptor in boost:
>
> http://www.boost.org/doc/libs/1_54_0/libs/utility/generator_iterator.htm
>
> However this adaptor is strictly conforming, and thus classifying itself
> as an input_iterator.  This is a performance killer.  I modeled this with=
:
>
>     typedef std::input_iterator_tag iterator_category;
> //    typedef std::random_access_iterator_tag iterator_category;
>
> and got:
>
> $ a.out
> 5256=B5s
> $ a.out
> 5426=B5s
> $ a.out
> 5233=B5s
> $ a.out
> 5388=B5s
>
> Another 48% slower than the push_back loop.  The main reason for this is
> that vector can't predict a-preori the final capacity it will need, and
> thus must grow its capacity geometrically during the iteration.  libc++
> grows with a factor of 2.  This is also the approximate time I get with t=
he
> push_back() method if I remove the v.reserve(N).
>
> I haven't bothered testing the allocator-no-op-constructor method.  I
> believe it will be no faster, and possibly slower than the
> random-access-iterator-generator technique because it requires two passes
> over the elements, and one of the passes might be optimized out.
>
> Howard
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

--089e0158a92e0936d004e5d7ec38
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Note that you can use the generator even if you aren&=
#39;t constructing the vector by calling assign or insert. While the genera=
tor solution is clunky if someone has really really profiled their code, an=
d really found that a significant fraction is spent in push_back (which I t=
hink is *exceedingly* unlikely), then they can use the generator solution.<=
/div>

<div><br>&gt; The no-construct allocator technique is very error prone. =A0=
The one advantage it has over push_back_ is that it is in C++11 and later, =
and push_back_ isn&#39;t.</div><div>=A0</div><div>It also has=A0the advanta=
ge that the client can&#39;t &quot;screw up&quot; and go off the end of the=
 allocated region. The resulting program is perfectly safe, which wouldn&#3=
9;t happen with the proposed push_back_ solution. (Yes, the generator is mo=
re complex, but the vast majority of bugs there will result in easy to diag=
nose crashes or simply fail to compile)</div>

<div>=A0</div><div>The benchmark above neglects to mention that there is al=
so a size modification going on inside push_back -- writes are typically mo=
re expensive than reads, such as the comparison against capacity. If the ve=
ctor has been reserved in advance, then the capacity check is going to be p=
redicted with high accuracy by any machine worth its salt, so it should par=
allelize well.</div>

<div>=A0</div><div>However, writing the value of size in the above example =
changes on every iteration of the loop, and causes cross loop body memory d=
ependencies. It also doubles or triples the amount of memory being written =
to, because each int being written is causing a size_t to be written for th=
e size update.</div>

<div>=A0</div><div>The push_back_ proposal doesn&#39;t remove the size modi=
fication, only the capacity check. Are we sure that the capacity check is a=
ctually the cause of that 40% difference?<br></div><div>=A0</div><div>=A0</=
div>

<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" targe=
t=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http:/=
/stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stacko=
verflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sat, Sep 7, 2013 at 4:45 PM, Howard H=
innant <span dir=3D"ltr">&lt;<a href=3D"mailto:howard.hinnant@gmail.com" ta=
rget=3D"_blank">howard.hinnant@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex=
;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style=
:solid">

<div class=3D"im">On Sep 7, 2013, at 4:50 PM, Howard Hinnant &lt;<a href=3D=
"mailto:howard.hinnant@gmail.com">howard.hinnant@gmail.com</a>&gt; wrote:<b=
r>
<br>
&gt; Here&#39;s a sketch:<br>
&gt;<br>
&gt; #include &lt;vector&gt;<br>
&gt;<br>
&gt; class Widget<br>
&gt; {<br>
&gt; =A0 =A0int data_;<br>
&gt; public:<br>
&gt; =A0 =A0explicit Widget(int data) : data_(data) {}<br>
&gt; };<br>
&gt;<br>
&gt; class generator_Widget<br>
&gt; {<br>
<br>
</div>Fwiw, I decided it was time to see some real code and real numbers so=
 we know what we&#39;re dealing with. =A0I&#39;m using the cheapest Widget =
I can imagine - just wraps an int. =A0This emphasizes any performance gains=
 as much as possible. =A0As Widget becomes more expensive to construct, the=
 performance gains of one technique over the other will probably become neg=
ligible.<br>


<br>
Here&#39;s the code I&#39;m testing:<br>
<br>
#include &lt;iostream&gt;<br>
#include &lt;chrono&gt;<br>
<div class=3D"im">#include &lt;vector&gt;<br>
<br>
class Widget<br>
{<br>
=A0 =A0 int data_;<br>
public:<br>
=A0 =A0 explicit Widget(int data) : data_(data) {}<br>
};<br>
<br>
class generator_Widget<br>
{<br>
=A0 =A0 int count_;<br>
=A0 =A0 int state_;<br>
<br>
public:<br>
</div>// =A0 =A0typedef std::input_iterator_tag iterator_category;<br>
<div><div class=3D"h5">=A0 =A0 typedef std::random_access_iterator_tag iter=
ator_category;<br>
=A0 =A0 typedef Widget =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0v=
alue_type;<br>
=A0 =A0 typedef std::ptrdiff_t =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0differenc=
e_type;<br>
=A0 =A0 typedef const Widget* =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pointer;<=
br>
=A0 =A0 typedef Widget =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0r=
eference;<br>
<br>
=A0 =A0 explicit generator_Widget(int count, int state =3D 0)<br>
=A0 =A0 =A0 =A0 : count_(count), state_(state) {}<br>
<br>
=A0 =A0 reference operator*() const {return Widget(state_);}<br>
=A0 =A0 pointer operator-&gt;() const {return nullptr;}<br>
<br>
=A0 =A0 generator_Widget&amp; operator++() {++count_; --state_; return *thi=
s;}<br>
=A0 =A0 generator_Widget operator++(int)<br>
=A0 =A0 =A0 =A0 {generator_Widget tmp(*this); ++(*this); return tmp;}<br>
<br>
=A0 =A0 generator_Widget&amp; operator--() {--count_; ++state_; return *thi=
s;}<br>
=A0 =A0 generator_Widget operator--(int)<br>
=A0 =A0 =A0 =A0 {generator_Widget tmp(*this); --(*this); return tmp;}<br>
<br>
=A0 =A0 generator_Widget&amp; operator+=3D(difference_type n) {count_ +=3D =
n; state_ -=3D n; return *this;}<br>
=A0 =A0 generator_Widget operator+(difference_type n) const<br>
=A0 =A0 =A0 =A0 {generator_Widget tmp(*this); tmp +=3D n; return tmp;}<br>
=A0 =A0 friend generator_Widget operator+(difference_type n, generator_Widg=
et x)<br>
=A0 =A0 =A0 =A0 {x +=3D n; return x;}<br>
=A0 =A0 generator_Widget&amp; operator-=3D(difference_type n) {return *this=
 +=3D -n;}<br>
=A0 =A0 generator_Widget operator-(difference_type n) const<br>
=A0 =A0 =A0 =A0 {generator_Widget tmp(*this); tmp -=3D n; return tmp;}<br>
<br>
=A0 =A0 reference operator[](difference_type n) const {return *(*this + n);=
}<br>
<br>
=A0 =A0 friend<br>
=A0 =A0 bool<br>
=A0 =A0 operator=3D=3D(const generator_Widget&amp; x, const generator_Widge=
t&amp; y)<br>
=A0 =A0 =A0 =A0 {return x.count_ =3D=3D y.count_;}<br>
<br>
=A0 =A0 friend<br>
=A0 =A0 bool<br>
=A0 =A0 operator!=3D(const generator_Widget&amp; x, const generator_Widget&=
amp; y)<br>
=A0 =A0 =A0 =A0 {return !(x =3D=3D y);}<br>
<br>
=A0 =A0 friend<br>
=A0 =A0 bool<br>
=A0 =A0 operator&lt;(const generator_Widget&amp; x, const generator_Widget&=
amp; y)<br>
=A0 =A0 =A0 =A0 {return x.count_ &lt; y.count_;}<br>
<br>
=A0 =A0 friend<br>
=A0 =A0 bool<br>
=A0 =A0 operator&gt;(const generator_Widget&amp; x, const generator_Widget&=
amp; y)<br>
=A0 =A0 =A0 =A0 {return y &lt; x;}<br>
<br>
=A0 =A0 friend<br>
=A0 =A0 bool<br>
=A0 =A0 operator&lt;=3D(const generator_Widget&amp; x, const generator_Widg=
et&amp; y)<br>
=A0 =A0 =A0 =A0 {return !(y &lt; x);}<br>
<br>
=A0 =A0 friend<br>
=A0 =A0 bool<br>
=A0 =A0 operator&gt;=3D(const generator_Widget&amp; x, const generator_Widg=
et&amp; y)<br>
=A0 =A0 =A0 =A0 {return !(x &lt; y);}<br>
<br>
=A0 =A0 friend<br>
=A0 =A0 difference_type<br>
=A0 =A0 operator-(const generator_Widget&amp; x, const generator_Widget&amp=
; y)<br>
=A0 =A0 =A0 =A0 {return x.count_ - y.count_;}<br>
<br>
};<br>
<br>
int<br>
main()<br>
{<br>
</div></div>=A0 =A0 const unsigned N =3D 1000000;<br>
=A0 =A0 using namespace std::chrono;<br>
=A0 =A0 auto t0 =3D high_resolution_clock::now();<br>
#if 1<br>
=A0 =A0 std::vector&lt;Widget&gt; v(generator_Widget(0, N), generator_Widge=
t(N));<br>
#else<br>
=A0 =A0 std::vector&lt;Widget&gt; v;<br>
=A0 =A0 int state =3D N;<br>
=A0 =A0 v.reserve(N);<br>
=A0 =A0 for (unsigned i =3D 0; i &lt; N; ++i, --state)<br>
=A0 =A0 =A0 =A0 v.push_back(Widget(state));<br>
#endif<br>
=A0 =A0 auto t1 =3D std::chrono::high_resolution_clock::now();<br>
=A0 =A0 std::cout &lt;&lt; duration_cast&lt;microseconds&gt;(t1-t0).count()=
 &lt;&lt; &quot;\xC2\xB5s\n&quot;;<br>
}<br>
<br>
I&#39;m testing the above with clang++ -O3, tip-of-trunk libc++. =A0For me =
this outputs:<br>
<br>
$ a.out<br>
2468=B5s<br>
$ a.out<br>
2431=B5s<br>
$ a.out<br>
2443=B5s<br>
$ a.out<br>
2709=B5s<br>
<br>
If I change the above to use push_back():<br>
<br>
#if 0<br>
<br>
Then I get:<br>
<br>
$ a.out<br>
3848=B5s<br>
$ a.out<br>
3608=B5s<br>
$ a.out<br>
3635=B5s<br>
$ a.out<br>
3765=B5s<br>
<br>
That&#39;s around a 40% performance hit, which is significant.<br>
<br>
I also noted a generator/iterator adaptor in boost:<br>
<br>
<a href=3D"http://www.boost.org/doc/libs/1_54_0/libs/utility/generator_iter=
ator.htm" target=3D"_blank">http://www.boost.org/doc/libs/1_54_0/libs/utili=
ty/generator_iterator.htm</a><br>
<br>
However this adaptor is strictly conforming, and thus classifying itself as=
 an input_iterator. =A0This is a performance killer. =A0I modeled this with=
:<br>
<br>
=A0 =A0 typedef std::input_iterator_tag iterator_category;<br>
// =A0 =A0typedef std::random_access_iterator_tag iterator_category;<br>
<br>
and got:<br>
<br>
$ a.out<br>
5256=B5s<br>
$ a.out<br>
5426=B5s<br>
$ a.out<br>
5233=B5s<br>
$ a.out<br>
5388=B5s<br>
<br>
Another 48% slower than the push_back loop. =A0The main reason for this is =
that vector can&#39;t predict a-preori the final capacity it will need, and=
 thus must grow its capacity geometrically during the iteration. =A0libc++ =
grows with a factor of 2. =A0This is also the approximate time I get with t=
he push_back() method if I remove the v.reserve(N).<br>


<br>
I haven&#39;t bothered testing the allocator-no-op-constructor method. =A0I=
 believe it will be no faster, and possibly slower than the random-access-i=
terator-generator technique because it requires two passes over the element=
s, and one of the passes might be optimized out.<br>


<div class=3D"HOEnZb"><div class=3D"h5"><br>
Howard<br>
<br>
--<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">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

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

--089e0158a92e0936d004e5d7ec38--

.

On Sat, 2013-09-07 at 21:43 -0700, Billy O'Neal wrote:
> Note that you can use the generator even if you aren't constructing
> the vector by calling assign or insert. While the generator solution
> is clunky if someone has really really profiled their code, and really
> found that a significant fraction is spent in push_back (which I think
> is *exceedingly* unlikely), then they can use the generator solution.
>
> > The no-construct allocator technique is very error prone.  The one
> advantage it has over push_back_ is that it is in C++11 and later, and
> push_back_ isn't.
>
> It also has the advantage that the client can't "screw up" and go off
> the end of the allocated region. The resulting program is perfectly
> safe, which wouldn't happen with the proposed push_back_ solution.
> (Yes, the generator is more complex, but the vast majority of bugs
> there will result in easy to diagnose crashes or simply fail to
> compile)
>
> The benchmark above neglects to mention that there is also a size
> modification going on inside push_back -- writes are typically more
> expensive than reads, such as the comparison against capacity. If the
> vector has been reserved in advance, then the capacity check is going
> to be predicted with high accuracy by any machine worth its salt, so
> it should parallelize well.
>
> However, writing the value of size in the above example changes on
> every iteration of the loop, and causes cross loop body memory
> dependencies. It also doubles or triples the amount of memory being
> written to, because each int being written is causing a size_t to be
> written for the size update.
>
> The push_back_ proposal doesn't remove the size modification, only the
> capacity check. Are we sure that the capacity check is actually the
> cause of that 40% difference?

I did some quick performance runs with Howard's code (gcc-3.9 20130903,
x86_64) but added two more cases

1 - generate_Widget
2 - reserve, push_back
3 - reserve, emplace_back
4 - reserve, push_back_

What I ended up with was that

* 1 and 4 resulted in the same code
* 3 is marginally faster than 2, but still in the same ballpark

Looking at the generated assembler it seems that the real killer is that
the ptr_end and ptr_capacity values are updated (written to memory) on
each lap through the code in case 3 and 4. (The state variable is also
spilled but forcing that into a register doesn't seem to affect the
performance)

/MF


--

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

.

--047d7bf18754531e9104e5da746d
Content-Type: text/plain; charset=ISO-8859-1

It seems like the implementation shouldn't be writing ptr_capacity if the
capacity is unchanged.... :/

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sat, Sep 7, 2013 at 11:25 PM, Magnus Fromreide <magfr@lysator.liu.se>wrote:

> On Sat, 2013-09-07 at 21:43 -0700, Billy O'Neal wrote:
> > Note that you can use the generator even if you aren't constructing
> > the vector by calling assign or insert. While the generator solution
> > is clunky if someone has really really profiled their code, and really
> > found that a significant fraction is spent in push_back (which I think
> > is *exceedingly* unlikely), then they can use the generator solution.
> >
> > > The no-construct allocator technique is very error prone.  The one
> > advantage it has over push_back_ is that it is in C++11 and later, and
> > push_back_ isn't.
> >
> > It also has the advantage that the client can't "screw up" and go off
> > the end of the allocated region. The resulting program is perfectly
> > safe, which wouldn't happen with the proposed push_back_ solution.
> > (Yes, the generator is more complex, but the vast majority of bugs
> > there will result in easy to diagnose crashes or simply fail to
> > compile)
> >
> > The benchmark above neglects to mention that there is also a size
> > modification going on inside push_back -- writes are typically more
> > expensive than reads, such as the comparison against capacity. If the
> > vector has been reserved in advance, then the capacity check is going
> > to be predicted with high accuracy by any machine worth its salt, so
> > it should parallelize well.
> >
> > However, writing the value of size in the above example changes on
> > every iteration of the loop, and causes cross loop body memory
> > dependencies. It also doubles or triples the amount of memory being
> > written to, because each int being written is causing a size_t to be
> > written for the size update.
> >
> > The push_back_ proposal doesn't remove the size modification, only the
> > capacity check. Are we sure that the capacity check is actually the
> > cause of that 40% difference?
>
> I did some quick performance runs with Howard's code (gcc-3.9 20130903,
> x86_64) but added two more cases
>
> 1 - generate_Widget
> 2 - reserve, push_back
> 3 - reserve, emplace_back
> 4 - reserve, push_back_
>
> What I ended up with was that
>
> * 1 and 4 resulted in the same code
> * 3 is marginally faster than 2, but still in the same ballpark
>
> Looking at the generated assembler it seems that the real killer is that
> the ptr_end and ptr_capacity values are updated (written to memory) on
> each lap through the code in case 3 and 4. (The state variable is also
> spilled but forcing that into a register doesn't seem to affect the
> performance)
>
> /MF
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--047d7bf18754531e9104e5da746d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It seems like the implementation shouldn&#39;t be writing =
ptr_capacity if the capacity is unchanged.... :/</div><div class=3D"gmail_e=
xtra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><d=
iv><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://=
github.com/BillyONeal/</a></div>

<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sat, Sep 7, 2013 at 11:25 PM, Magnus =
Fromreide <span dir=3D"ltr">&lt;<a href=3D"mailto:magfr@lysator.liu.se" tar=
get=3D"_blank">magfr@lysator.liu.se</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">

On Sat, 2013-09-07 at 21:43 -0700, Billy O&#39;Neal wrote:<br>
&gt; Note that you can use the generator even if you aren&#39;t constructin=
g<br>
&gt; the vector by calling assign or insert. While the generator solution<b=
r>
&gt; is clunky if someone has really really profiled their code, and really=
<br>
&gt; found that a significant fraction is spent in push_back (which I think=
<br>
&gt; is *exceedingly* unlikely), then they can use the generator solution.<=
br>
&gt;<br>
&gt; &gt; The no-construct allocator technique is very error prone. =A0The =
one<br>
&gt; advantage it has over push_back_ is that it is in C++11 and later, and=
<br>
&gt; push_back_ isn&#39;t.<br>
&gt;<br>
&gt; It also has the advantage that the client can&#39;t &quot;screw up&quo=
t; and go off<br>
&gt; the end of the allocated region. The resulting program is perfectly<br=
>
&gt; safe, which wouldn&#39;t happen with the proposed push_back_ solution.=
<br>
&gt; (Yes, the generator is more complex, but the vast majority of bugs<br>
&gt; there will result in easy to diagnose crashes or simply fail to<br>
&gt; compile)<br>
&gt;<br>
&gt; The benchmark above neglects to mention that there is also a size<br>
&gt; modification going on inside push_back -- writes are typically more<br=
>
&gt; expensive than reads, such as the comparison against capacity. If the<=
br>
&gt; vector has been reserved in advance, then the capacity check is going<=
br>
&gt; to be predicted with high accuracy by any machine worth its salt, so<b=
r>
&gt; it should parallelize well.<br>
&gt;<br>
&gt; However, writing the value of size in the above example changes on<br>
&gt; every iteration of the loop, and causes cross loop body memory<br>
&gt; dependencies. It also doubles or triples the amount of memory being<br=
>
&gt; written to, because each int being written is causing a size_t to be<b=
r>
&gt; written for the size update.<br>
&gt;<br>
&gt; The push_back_ proposal doesn&#39;t remove the size modification, only=
 the<br>
&gt; capacity check. Are we sure that the capacity check is actually the<br=
>
&gt; cause of that 40% difference?<br>
<br>
I did some quick performance runs with Howard&#39;s code (gcc-3.9 20130903,=
<br>
x86_64) but added two more cases<br>
<br>
1 - generate_Widget<br>
2 - reserve, push_back<br>
3 - reserve, emplace_back<br>
4 - reserve, push_back_<br>
<br>
What I ended up with was that<br>
<br>
* 1 and 4 resulted in the same code<br>
* 3 is marginally faster than 2, but still in the same ballpark<br>
<br>
Looking at the generated assembler it seems that the real killer is that<br=
>
the ptr_end and ptr_capacity values are updated (written to memory) on<br>
each lap through the code in case 3 and 4. (The state variable is also<br>
spilled but forcing that into a register doesn&#39;t seem to affect the<br>
performance)<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
/MF<br>
<br>
<br>
--<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">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--047d7bf18754531e9104e5da746d--

.

On Sun, 2013-09-08 at 00:44 -0700, Billy O'Neal wrote:
> It seems like the implementation shouldn't be writing ptr_capacity if
> the capacity is unchanged.... :/

It doesn't, but it reads it from memory every turn.

/MF


--

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

.

------=_Part_1_20395084.1378653537085
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

We could consider a totally different way to handle this, which also has=20
other uses. Admittedly, this can easily crash if misused (just as index out=
=20
of range or too many push_back_ calls). I will call this tentatively=20
uninitialized_resize(size_t sz). It just moves the end pointer and=20
reallocates as required, but leaves the new elements uninitialized. Then,=
=20
to initialize the elements, placement new is used. This avoids the=20
increments for each push_back_() call. The additional use is for=20
interfacing with legacy libraries and similar which construct an array of=
=20
objects at a specified "buffer" address. Today there is no way to use a=20
vector as such a buffer without extra initialization code running at=20
resize() or when constructing the vector with the size. Note that this is=
=20
true for basic types such as char and int too (in C++11), although I'm=20
uncertain if this is intended (see note below).

Example:

vector<Widget> v;
v.uninitialized_resize(10);

for (auto& i : v)
    new (&i) Widget;

// Get an image from a third party library into a vector:

vector<char> image;
image.uninitialized_resize(size.x*size.y);
GetImage(image.data());

The placement new usage could be somewhat problematic as it circumvents the=
=20
allocator. If Allocator::construct does someting else than what the default=
=20
allocator does a special method on vector may be warranted, for instance=20
initialize_element(i, args...), which basically forwards to=20
Allocator::construct.


Note: The rather complicated reason for not being able to set the size of=
=20
even a vector<char> without clearing the memory block is that the new=20
resize() and ctor overloads without the initializer element does not just=
=20
default construct the elements (which would be a nop for char) but rather=
=20
calls Allocator::construct which is now a variadic template function and=20
expanding the empty parameter pack creates a value construction rather than=
=20
a default constuction. To me it seems that this combination effect may not=
=20
have been desired. On the other hand this resize() overload replaces the=20
older =3D0 on the second argument of resize() so even in C++98 it was=20
impossible to construct a vector<char> without writing the elements.=20
Probably many programmers have used the feature that in contrast with a=20
plain char or array of char a vector of char has 0 in its elements.=20
uninitialized_resize() thus adds a new functionality to vector in addition=
=20
to what push_back_ would yield.


Den s=F6ndagen den 8:e september 2013 kl. 09:54:16 UTC+2 skrev Magnus=20
Fromreide:
>
> On Sun, 2013-09-08 at 00:44 -0700, Billy O'Neal wrote:=20
> > It seems like the implementation shouldn't be writing ptr_capacity if=
=20
> > the capacity is unchanged.... :/=20
>
> It doesn't, but it reads it from memory every turn.=20
>
> /MF=20
>
>
>

--=20

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

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

<div dir=3D"ltr">We could consider a totally different way to handle this, =
which also has other uses. Admittedly, this can easily crash if misused (ju=
st as index out of range or too many push_back_ calls). I will call this te=
ntatively uninitialized_resize(size_t sz). It just moves the end pointer an=
d reallocates as required, but leaves the new elements uninitialized. Then,=
 to initialize the elements, placement new is used. This avoids the increme=
nts for each push_back_() call. The additional use is for interfacing with =
legacy libraries and similar which construct an array of objects at a speci=
fied "buffer" address. Today there is no way to use a vector as such a buff=
er without extra initialization code running at resize() or when constructi=
ng the vector with the size. Note that this is true for basic types such as=
 char and int too (in C++11), although I'm uncertain if this is intended (s=
ee note below).<div><br></div><div>Example:</div><div><br></div><div>vector=
&lt;Widget&gt; v;</div><div>v.uninitialized_resize(10);</div><div><br></div=
><div>for (auto&amp; i : v)</div><div>&nbsp; &nbsp; new (&amp;i) Widget;</d=
iv><div><br></div><div>// Get an image from a third party library into a ve=
ctor:</div><div><br></div><div>vector&lt;char&gt; image;</div><div>image.un=
initialized_resize(size.x*size.y);</div><div>GetImage(image.data());</div><=
div><br></div><div><span style=3D"font-size: 13px;">The placement new usage=
 could be somewhat problematic as it circumvents the allocator. If Allocato=
r::construct does someting else than what the default allocator does a spec=
ial method on vector may be warranted, for instance initialize_element(i, a=
rgs...), which basically forwards to Allocator::construct.</span><br><br><b=
r><span style=3D"font-size: 13px;">Note: The rather complicated reason for =
not being able to set the size of even a vector&lt;char&gt; without clearin=
g the memory block is that the new resize() and ctor overloads without the =
initializer element does not just default construct the elements (which wou=
ld be a nop for char) but rather calls Allocator::construct which is now a =
variadic template function and expanding the empty parameter pack creates a=
 value construction rather than a default constuction. To me it seems that =
this combination effect may not have been desired. On the other hand this r=
esize() overload replaces the older =3D0 on the second argument of resize()=
 so even in C++98 it was impossible to construct a vector&lt;char&gt; witho=
ut writing the elements. Probably many programmers have used the feature th=
at in contrast with a plain char or array of char a vector of char has 0 in=
 its elements. uninitialized_resize() thus adds a new functionality to vect=
or in addition to what push_back_ would yield.</span><br><br><br>Den s=F6nd=
agen den 8:e september 2013 kl. 09:54:16 UTC+2 skrev Magnus Fromreide:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On Sun, 2013-09-08 at 00:44 -0700, =
Billy O'Neal wrote:
<br>&gt; It seems like the implementation shouldn't be writing ptr_capacity=
 if
<br>&gt; the capacity is unchanged.... :/
<br>
<br>It doesn't, but it reads it from memory every turn.
<br>
<br>/MF
<br>
<br>
<br></blockquote></div></div>

<p></p>

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

------=_Part_1_20395084.1378653537085--

.

--001a11c2a120fe585704e5e11b90
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

>Allocator::construct which is now a variadic template function and
expanding the empty parameter pack creates a value construction rather than
a default construction.

If your allocator::construct does nothing, then the memory will be
uninitialized. Every compiler on earth will inline a completely empty
function. std::allocator's default behavior is to zero initialize the
memory. If you want to use uninitialized behavior, just change out the
allocator to do that.

>The placement new usage could be somewhat problematic as it circumvents
the allocator. If Allocator::construct does someting else than what the
default allocator does a special method on vector may be warranted, for
instance initialize_element(i, args...), which basically forwards to
Allocator::construct.

If you allow this, how does vector know the number of elements to destroy
(call destructors on) in vector's destructor? Do you want to make it
undefined to allow the vector to be destroyed with uninitialized data?

How many cases are actually out there that need to avoid
zero-initialization of the memory that aren't met by unique_ptr<T[]>?

I remain unconvinced that any of this makes a measurable difference in real
applications; or even that if it did that the class allowing these
different behaviors should be called vector.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sun, Sep 8, 2013 at 8:18 AM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> We could consider a totally different way to handle this, which also has
> other uses. Admittedly, this can easily crash if misused (just as index o=
ut
> of range or too many push_back_ calls). I will call this tentatively
> uninitialized_resize(size_t sz). It just moves the end pointer and
> reallocates as required, but leaves the new elements uninitialized. Then,
> to initialize the elements, placement new is used. This avoids the
> increments for each push_back_() call. The additional use is for
> interfacing with legacy libraries and similar which construct an array of
> objects at a specified "buffer" address. Today there is no way to use a
> vector as such a buffer without extra initialization code running at
> resize() or when constructing the vector with the size. Note that this is
> true for basic types such as char and int too (in C++11), although I'm
> uncertain if this is intended (see note below).
>
> Example:
>
> vector<Widget> v;
> v.uninitialized_resize(10);
>
> for (auto& i : v)
>     new (&i) Widget;
>
> // Get an image from a third party library into a vector:
>
> vector<char> image;
> image.uninitialized_resize(size.x*size.y);
> GetImage(image.data());
>
> The placement new usage could be somewhat problematic as it circumvents
> the allocator. If Allocator::construct does someting else than what the
> default allocator does a special method on vector may be warranted, for
> instance initialize_element(i, args...), which basically forwards to
> Allocator::construct.
>
>
> Note: The rather complicated reason for not being able to set the size of
> even a vector<char> without clearing the memory block is that the new
> resize() and ctor overloads without the initializer element does not just
> default construct the elements (which would be a nop for char) but rather
> calls Allocator::construct which is now a variadic template function and
> expanding the empty parameter pack creates a value construction rather th=
an
> a default constuction. To me it seems that this combination effect may no=
t
> have been desired. On the other hand this resize() overload replaces the
> older =3D0 on the second argument of resize() so even in C++98 it was
> impossible to construct a vector<char> without writing the elements.
> Probably many programmers have used the feature that in contrast with a
> plain char or array of char a vector of char has 0 in its elements.
> uninitialized_resize() thus adds a new functionality to vector in additio=
n
> to what push_back_ would yield.
>
>
> Den s=F6ndagen den 8:e september 2013 kl. 09:54:16 UTC+2 skrev Magnus
> Fromreide:
>
>> On Sun, 2013-09-08 at 00:44 -0700, Billy O'Neal wrote:
>> > It seems like the implementation shouldn't be writing ptr_capacity if
>> > the capacity is unchanged.... :/
>>
>> It doesn't, but it reads it from memory every turn.
>>
>> /MF
>>
>>
>>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

--001a11c2a120fe585704e5e11b90
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt;Allocator::construct which is now a variadic temp=
late function and expanding the empty parameter pack creates a value constr=
uction rather than a default construction.</div><div>=A0</div><div>If your =
allocator::construct does nothing, then the memory will be uninitialized. E=
very compiler on earth will inline a completely empty function. std::alloca=
tor&#39;s default behavior is to zero initialize the memory. If you want to=
 use uninitialized behavior, just change out the allocator to do that.</div=
>

<div>=A0</div><div>&gt;<span style=3D"font-size:13px">The placement new usa=
ge could be somewhat problematic as it circumvents the allocator. If Alloca=
tor::construct does someting else than what the default allocator does a sp=
ecial method on vector may be warranted, for instance initialize_element(i,=
 args...), which basically forwards to Allocator::construct.</span></div>

<div>=A0</div><div>If you allow this, how does vector know the number of el=
ements to destroy (call destructors on) in vector&#39;s destructor? Do you =
want to make it undefined to allow the vector to be destroyed with uninitia=
lized data?</div>

<div>=A0</div><div>How many cases are actually out there that need to avoid=
 zero-initialization of the memory that aren&#39;t met by unique_ptr&lt;T[]=
&gt;?</div><div>=A0</div><div>I remain unconvinced that any of this makes a=
 measurable difference in real applications; or even that if it did that th=
e class allowing these different behaviors should be called vector.</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sun, Sep 8, 2013 at 8:18 AM, Bengt Gu=
stafsson <span dir=3D"ltr">&lt;<a href=3D"mailto:bengt.gustafsson@beamways.=
com" target=3D"_blank">bengt.gustafsson@beamways.com</a>&gt;</span> wrote:<=
br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">We could consider a totally=
 different way to handle this, which also has other uses. Admittedly, this =
can easily crash if misused (just as index out of range or too many push_ba=
ck_ calls). I will call this tentatively uninitialized_resize(size_t sz). I=
t just moves the end pointer and reallocates as required, but leaves the ne=
w elements uninitialized. Then, to initialize the elements, placement new i=
s used. This avoids the increments for each push_back_() call. The addition=
al use is for interfacing with legacy libraries and similar which construct=
 an array of objects at a specified &quot;buffer&quot; address. Today there=
 is no way to use a vector as such a buffer without extra initialization co=
de running at resize() or when constructing the vector with the size. Note =
that this is true for basic types such as char and int too (in C++11), alth=
ough I&#39;m uncertain if this is intended (see note below).<div>

<br></div><div>Example:</div><div><br></div><div>vector&lt;Widget&gt; v;</d=
iv><div>v.uninitialized_resize(10);</div><div><br></div><div>for (auto&amp;=
 i : v)</div><div>=A0 =A0 new (&amp;i) Widget;</div><div><br></div><div>// =
Get an image from a third party library into a vector:</div>

<div><br></div><div>vector&lt;char&gt; image;</div><div>image.uninitialized=
_resize(size.x*size.y);</div><div>GetImage(image.data());</div><div><br></d=
iv><div><span style=3D"font-size:13px">The placement new usage could be som=
ewhat problematic as it circumvents the allocator. If Allocator::construct =
does someting else than what the default allocator does a special method on=
 vector may be warranted, for instance initialize_element(i, args...), whic=
h basically forwards to Allocator::construct.</span><br>

<br><br><span style=3D"font-size:13px">Note: The rather complicated reason =
for not being able to set the size of even a vector&lt;char&gt; without cle=
aring the memory block is that the new resize() and ctor overloads without =
the initializer element does not just default construct the elements (which=
 would be a nop for char) but rather calls Allocator::construct which is no=
w a variadic template function and expanding the empty parameter pack creat=
es a value construction rather than a default constuction. To me it seems t=
hat this combination effect may not have been desired. On the other hand th=
is resize() overload replaces the older =3D0 on the second argument of resi=
ze() so even in C++98 it was impossible to construct a vector&lt;char&gt; w=
ithout writing the elements. Probably many programmers have used the featur=
e that in contrast with a plain char or array of char a vector of char has =
0 in its elements. uninitialized_resize() thus adds a new functionality to =
vector in addition to what push_back_ would yield.</span><br>

<br><br>Den s=F6ndagen den 8:e september 2013 kl. 09:54:16 UTC+2 skrev Magn=
us Fromreide:<div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">

On Sun, 2013-09-08 at 00:44 -0700, Billy O&#39;Neal wrote:
<br>&gt; It seems like the implementation shouldn&#39;t be writing ptr_capa=
city if
<br>&gt; the capacity is unchanged.... :/
<br>
<br>It doesn&#39;t, but it reads it from memory every turn.
<br>
<br>/MF
<br>
<br>
<br></blockquote></div></div></div></div><div class=3D"HOEnZb"><div class=
=3D"h5">

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11c2a120fe585704e5e11b90--

.

------=_Part_1202_29049875.1378665311418
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Den s=F6ndagen den 8:e september 2013 kl. 17:41:06 UTC+2 skrev Billy O'Neal=
:
>
> >Allocator::construct which is now a variadic template function and=20
> expanding the empty parameter pack creates a value construction rather th=
an=20
> a default construction.
> =20
> If your allocator::construct does nothing, then the memory will be=20
> uninitialized. Every compiler on earth will inline a completely empty=20
> function. std::allocator's default behavior is to zero initialize the=20
> memory. If you want to use uninitialized behavior, just change out the=20
> allocator to do that.
>
=20
Right, but as vectors with different allocators are different types you=20
can't subsequently send the vector as an argument to a non-template=20
function. Also, at least if the vector is a member of a class there may=20
well be other uses where you want the allocator to initialize the memory.

=20
> >The placement new usage could be somewhat problematic as it circumvents=
=20
> the allocator. If Allocator::construct does someting else than what the=
=20
> default allocator does a special method on vector may be warranted, for=
=20
> instance initialize_element(i, args...), which basically forwards to=20
> Allocator::construct.
> =20
> If you allow this, how does vector know the number of elements to destroy=
=20
> (call destructors on) in vector's destructor? Do you want to make it=20
> undefined to allow the vector to be destroyed with uninitialized data?
> =20
>
This is a main drawback if exceptions are possible. In many cases you don't=
=20
need to consider this, but especially for generic code you would have to be=
=20
careful and add a try block which sets the size back to where you were in=
=20
case you got an exception.
=20

> How many cases are actually out there that need to avoid=20
> zero-initialization of the memory that aren't met by unique_ptr<T[]>?
> =20
>
It is often a matter of trying to reconcile C libraries or legacy=20
libraries, other languages, device drivers etc. You want to work with the=
=20
convenient data structures such as vector, but especially when receiving=20
data from such external sources it can be a deterrant to have to either=20
copy the received data an extra time or clear the buffer before it is=20
overwritten. All just because there is no way to tell vector that "someone=
=20
else" has constructed the data.

=20

> I remain unconvinced that any of this makes a measurable difference in=20
> real applications; or even that if it did that the class allowing these=
=20
> different behaviors should be called vector.
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Sun, Sep 8, 2013 at 8:18 AM, Bengt Gustafsson <bengt.gu...@beamways.co=
m<javascript:>
> > wrote:
>
>> We could consider a totally different way to handle this, which also has=
=20
>> other uses. Admittedly, this can easily crash if misused (just as index =
out=20
>> of range or too many push_back_ calls). I will call this tentatively=20
>> uninitialized_resize(size_t sz). It just moves the end pointer and=20
>> reallocates as required, but leaves the new elements uninitialized. Then=
,=20
>> to initialize the elements, placement new is used. This avoids the=20
>> increments for each push_back_() call. The additional use is for=20
>> interfacing with legacy libraries and similar which construct an array o=
f=20
>> objects at a specified "buffer" address. Today there is no way to use a=
=20
>> vector as such a buffer without extra initialization code running at=20
>> resize() or when constructing the vector with the size. Note that this i=
s=20
>> true for basic types such as char and int too (in C++11), although I'm=
=20
>> uncertain if this is intended (see note below).
>>
>> Example:
>>
>> vector<Widget> v;
>> v.uninitialized_resize(10);
>>
>> for (auto& i : v)
>>     new (&i) Widget;
>>
>> // Get an image from a third party library into a vector:
>>
>> vector<char> image;
>> image.uninitialized_resize(size.x*size.y);
>> GetImage(image.data());
>>
>> The placement new usage could be somewhat problematic as it circumvents=
=20
>> the allocator. If Allocator::construct does someting else than what the=
=20
>> default allocator does a special method on vector may be warranted, for=
=20
>> instance initialize_element(i, args...), which basically forwards to=20
>> Allocator::construct.
>>
>>
>> Note: The rather complicated reason for not being able to set the size o=
f=20
>> even a vector<char> without clearing the memory block is that the new=20
>> resize() and ctor overloads without the initializer element does not jus=
t=20
>> default construct the elements (which would be a nop for char) but rathe=
r=20
>> calls Allocator::construct which is now a variadic template function and=
=20
>> expanding the empty parameter pack creates a value construction rather t=
han=20
>> a default constuction. To me it seems that this combination effect may n=
ot=20
>> have been desired. On the other hand this resize() overload replaces the=
=20
>> older =3D0 on the second argument of resize() so even in C++98 it was=20
>> impossible to construct a vector<char> without writing the elements.=20
>> Probably many programmers have used the feature that in contrast with a=
=20
>> plain char or array of char a vector of char has 0 in its elements.=20
>> uninitialized_resize() thus adds a new functionality to vector in additi=
on=20
>> to what push_back_ would yield.
>>
>>
>> Den s=F6ndagen den 8:e september 2013 kl. 09:54:16 UTC+2 skrev Magnus=20
>> Fromreide:
>>
>>> On Sun, 2013-09-08 at 00:44 -0700, Billy O'Neal wrote:=20
>>> > It seems like the implementation shouldn't be writing ptr_capacity if=
=20
>>> > the capacity is unchanged.... :/=20
>>>
>>> It doesn't, but it reads it from memory every turn.=20
>>>
>>> /MF=20
>>>
>>>
>>>  --=20
>> =20
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

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

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

<div dir=3D"ltr"><br><br>Den s=F6ndagen den 8:e september 2013 kl. 17:41:06=
 UTC+2 skrev Billy O'Neal:<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>&gt;Allocator::construct which is now a variadic template=
 function and expanding the empty parameter pack creates a value constructi=
on rather than a default construction.</div><div>&nbsp;</div><div>If your a=
llocator::construct does nothing, then the memory will be uninitialized. Ev=
ery compiler on earth will inline a completely empty function. std::allocat=
or's default behavior is to zero initialize the memory. If you want to use =
uninitialized behavior, just change out the allocator to do that.</div></di=
v></blockquote><div>&nbsp;</div><div>Right, but as vectors with different a=
llocators are different types you can't subsequently send the vector as an =
argument to a non-template function. Also, at least if the vector is a memb=
er of a class there may well be other uses where you want the allocator to =
initialize the memory.</div><div><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>&nbsp;</div><div>&gt;<span style=3D"font-size:13px">The placement new =
usage could be somewhat problematic as it circumvents the allocator. If All=
ocator::construct does someting else than what the default allocator does a=
 special method on vector may be warranted, for instance initialize_element=
(i, args...), which basically forwards to Allocator::construct.</span></div=
>

<div>&nbsp;</div><div>If you allow this, how does vector know the number of=
 elements to destroy (call destructors on) in vector's destructor? Do you w=
ant to make it undefined to allow the vector to be destroyed with uninitial=
ized data?</div>

<div>&nbsp;</div></div></blockquote><div>This is a main drawback if excepti=
ons are possible. In many cases you don't need to consider this, but especi=
ally for generic code you would have to be careful and add a try block whic=
h sets the size back to where you were in case you got an exception.</div><=
div>&nbsp;</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"lt=
r"><div>How many cases are actually out there that need to avoid zero-initi=
alization of the memory that aren't met by unique_ptr&lt;T[]&gt;?</div><div=
>&nbsp;</div></div></blockquote><div>It is often a matter of trying to reco=
ncile C libraries or legacy libraries, other languages, device drivers etc.=
 You want to work with the convenient data structures such as vector, but e=
specially when receiving data from such external sources it can be a deterr=
ant to have to either copy the received data an extra time or clear the buf=
fer before it is overwritten. All just because there is no way to tell vect=
or that "someone else" has constructed the data.</div><div><br></div><div>&=
nbsp;</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"><d=
iv>I remain unconvinced that any of this makes a measurable difference in r=
eal applications; or even that if it did that the class allowing these diff=
erent behaviors should be called vector.</div>

</div><div><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div><=
div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:/=
/github.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/u=
sers/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/<wbr>use=
rs/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sun, Sep 8, 2013 at 8:18 AM, Bengt Gu=
stafsson <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"xxvptPKA0UIJ">bengt.gu...@beamways.com</a><wbr>&gt;<=
/span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">We could consider a totally=
 different way to handle this, which also has other uses. Admittedly, this =
can easily crash if misused (just as index out of range or too many push_ba=
ck_ calls). I will call this tentatively uninitialized_resize(size_t sz). I=
t just moves the end pointer and reallocates as required, but leaves the ne=
w elements uninitialized. Then, to initialize the elements, placement new i=
s used. This avoids the increments for each push_back_() call. The addition=
al use is for interfacing with legacy libraries and similar which construct=
 an array of objects at a specified "buffer" address. Today there is no way=
 to use a vector as such a buffer without extra initialization code running=
 at resize() or when constructing the vector with the size. Note that this =
is true for basic types such as char and int too (in C++11), although I'm u=
ncertain if this is intended (see note below).<div>

<br></div><div>Example:</div><div><br></div><div>vector&lt;Widget&gt; v;</d=
iv><div>v.uninitialized_resize(10);</div><div><br></div><div>for (auto&amp;=
 i : v)</div><div>&nbsp; &nbsp; new (&amp;i) Widget;</div><div><br></div><d=
iv>// Get an image from a third party library into a vector:</div>

<div><br></div><div>vector&lt;char&gt; image;</div><div>image.uninitialized=
_resize(<wbr>size.x*size.y);</div><div>GetImage(image.data());</div><div><b=
r></div><div><span style=3D"font-size:13px">The placement new usage could b=
e somewhat problematic as it circumvents the allocator. If Allocator::const=
ruct does someting else than what the default allocator does a special meth=
od on vector may be warranted, for instance initialize_element(i, args...),=
 which basically forwards to Allocator::construct.</span><br>

<br><br><span style=3D"font-size:13px">Note: The rather complicated reason =
for not being able to set the size of even a vector&lt;char&gt; without cle=
aring the memory block is that the new resize() and ctor overloads without =
the initializer element does not just default construct the elements (which=
 would be a nop for char) but rather calls Allocator::construct which is no=
w a variadic template function and expanding the empty parameter pack creat=
es a value construction rather than a default constuction. To me it seems t=
hat this combination effect may not have been desired. On the other hand th=
is resize() overload replaces the older =3D0 on the second argument of resi=
ze() so even in C++98 it was impossible to construct a vector&lt;char&gt; w=
ithout writing the elements. Probably many programmers have used the featur=
e that in contrast with a plain char or array of char a vector of char has =
0 in its elements. uninitialized_resize() thus adds a new functionality to =
vector in addition to what push_back_ would yield.</span><br>

<br><br>Den s=F6ndagen den 8:e september 2013 kl. 09:54:16 UTC+2 skrev Magn=
us Fromreide:<div><div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-=
left-width:1px;border-left-style:solid">

On Sun, 2013-09-08 at 00:44 -0700, Billy O'Neal wrote:
<br>&gt; It seems like the implementation shouldn't be writing ptr_capacity=
 if
<br>&gt; the capacity is unchanged.... :/
<br>
<br>It doesn't, but it reads it from memory every turn.
<br>
<br>/MF
<br>
<br>
<br></blockquote></div></div></div></div><div><div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
xxvptPKA0UIJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"xxvptPKA0UIJ">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div>

<p></p>

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

------=_Part_1202_29049875.1378665311418--

.

------=_Part_199_31629889.1378667875016
Content-Type: text/plain; charset=ISO-8859-1


On Sunday, September 8, 2013 4:18:56 PM UTC+1, Bengt Gustafsson wrote:
>
> We could consider a totally different way to handle this, which also has
> other uses. Admittedly, this can easily crash if misused (just as index out
> of range or too many push_back_ calls). I will call this tentatively
> uninitialized_resize(size_t sz). It just moves the end pointer and
> reallocates as required, but leaves the new elements uninitialized.
>

I think this will never be adopted as vector no longer can enforce its
invariants. Example:
{
    vector<Widget> v;
    v.uninitialized_resize(10);
    // at this point the desctructors are called, resulting in a crash
}

--

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

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

<div dir=3D"ltr"><br>On Sunday, September 8, 2013 4:18:56 PM UTC+1, Bengt G=
ustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">We could cons=
ider a totally different way to handle this, which also has other uses. Adm=
ittedly, this can easily crash if misused (just as index out of range or to=
o many push_back_ calls). I will call this tentatively uninitialized_resize=
(size_t sz). It just moves the end pointer and reallocates as required, but=
 leaves the new elements uninitialized. <br></div></blockquote><div>&nbsp;<=
/div><div>I think this will never be adopted as vector no longer can enforc=
e its invariants. Example:</div><div>{</div><div><div>&nbsp;&nbsp;&nbsp; ve=
ctor&lt;Widget&gt; v;</div><div>&nbsp;&nbsp;&nbsp; v.uninitialized_resize(1=
0);</div><div>&nbsp;&nbsp;&nbsp; // at this point the desctructors are call=
ed, resulting in a crash</div>}</div></div>

<p></p>

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

------=_Part_199_31629889.1378667875016--

.

------=_Part_1403_7251206.1378668252579
Content-Type: text/plain; charset=ISO-8859-1


On Sunday, September 8, 2013 12:45:19 AM UTC+1, Howard Hinnant wrote:
>
> Fwiw, I decided it was time to see some real code and real numbers so we
> know what we're dealing with.
>
>
Many thanks, Howard, for your effort! I know it was my job to do the
experiments :-\

--

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

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

<div dir=3D"ltr"><br>On Sunday, September 8, 2013 12:45:19 AM UTC+1, Howard=
 Hinnant wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;">Fwiw, I decided it was time to =
see some real code and real numbers so we know what we're dealing with.<br>=
<br></blockquote><div>&nbsp;</div><div>Many thanks, Howard, for your effort=
! I know it was my job to do the experiments :-\</div></div>

<p></p>

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

------=_Part_1403_7251206.1378668252579--

.

------=_Part_1314_10721595.1378668681556
Content-Type: text/plain; charset=ISO-8859-1


On Sunday, September 8, 2013 7:25:38 AM UTC+1, Magnus Fromreide wrote:
>
> 1 - generate_Widget
> 2 - reserve, push_back
> 3 - reserve, emplace_back
> 4 - reserve, push_back_
>

Many thanks for the figures!



> What I ended up with was that
>
> * 1 and 4 resulted in the same code
>

do you mean the same assembly code or the same performance? (I'd expect the
code to be different, as 1 doesn't have to store ptr_end on each loop
iteration.)


>  Looking at the generated assembler it seems that the real killer is that
> the ptr_end and ptr_capacity values are updated (written to memory) on
> each lap through the code in case 3 and 4.



Did you mean 2 and 3?

If I'm interpreting your and Howard's results right, push_back_ and
generator have similar performance, which is 40% better than push_back.
Correct?


--

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

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

<div dir=3D"ltr"><br>On Sunday, September 8, 2013 7:25:38 AM UTC+1, Magnus =
Fromreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;">1 - generate_Widget
<br>2 - reserve, push_back
<br>3 - reserve, emplace_back
<br>4 - reserve, push_back_
<br>
</blockquote><div>&nbsp;</div><div>Many thanks for the figures!</div><div>&=
nbsp;</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;">What I ended up wi=
th was that=20
<br>
<br>* 1 and 4 resulted in the same code
<br></blockquote><div>&nbsp;</div><div>do you mean the same assembly code o=
r the same performance? (I'd expect the code to be different, as 1 doesn't =
have to store ptr_end on each loop iteration.)</div><div>&nbsp;</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;">&nbsp;Looking at the generated assembler it seems th=
at the real killer is that
<br>the ptr_end and ptr_capacity values are updated (written to memory) on
<br>each lap through the code in case 3 and 4.</blockquote><div>&nbsp;</div=
><div>&nbsp;</div><div>Did you mean 2 and 3?</div><div>&nbsp;</div><div>If =
I'm interpreting your and Howard's results right, push_back_ and generator =
have similar performance, which is 40% better than push_back. Correct?</div=
><div>&nbsp;</div></div>

<p></p>

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

------=_Part_1314_10721595.1378668681556--

.

On Sun, 2013-09-08 at 12:31 -0700, Victor.Khomenko@ncl.ac.uk wrote:
>
> On Sunday, September 8, 2013 7:25:38 AM UTC+1, Magnus Fromreide wrote:
>         1 - generate_Widget
>         2 - reserve, push_back
>         3 - reserve, emplace_back
>         4 - reserve, push_back_
>
> Many thanks for the figures!
>
>
>         What I ended up with was that
>
>         * 1 and 4 resulted in the same code
>
> do you mean the same assembly code or the same performance? (I'd
> expect the code to be different, as 1 doesn't have to store ptr_end on
> each loop iteration.)

The same assembly code between the calls to system_clock::now.
Down to the label names.
Yes, I was just as surprised as you.

I suppose the compiler figures out that nothing can disturb the sequence
of assignments so it can hoist the saving of ptr_end out of the loop
when Widget is this simple.

>          Looking at the generated assembler it seems that the real
>         killer is that
>         the ptr_end and ptr_capacity values are updated (written to
>         memory) on
>         each lap through the code in case 3 and 4.
>
>
> Did you mean 2 and 3?

Yes.

> If I'm interpreting your and Howard's results right, push_back_ and
> generator have similar performance, which is 40% better than
> push_back. Correct?

Yes.

/MF

--

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

.

------=_Part_110_20438365.1378694565318
Content-Type: text/plain; charset=ISO-8859-1



On Monday, September 9, 2013 4:29:30 AM UTC+8, Magnus Fromreide wrote:
>
> On Sun, 2013-09-08 at 12:31 -0700, Victor....@ncl.ac.uk <javascript:>wrote:
> >
> > If I'm interpreting your and Howard's results right, push_back_ and
> > generator have similar performance, which is 40% better than
> > push_back. Correct?
>
> Yes.
>

The problem is that generators are far less flexible. You can't
simultaneously insert into several containers. Inserting a
non-predetermined number of objects requires the generator to return a
status code as well as the result, which adds overhead in C++ (I don't
suppose it's even part of the Generator concept; haven't looked it up).

One use case with lots of containers is sorting a large number of objects
into bins, for example generating graph nodes with unknown but bounded
degree, given a list of edges.

I had a thought, that if conversions were allowed when propagating
allocators, you could use std::allocator (or whatever) to get memory for a
container, then convert to a dummy allocator which does not perform
additional allocations. Ideally the bounds-overflow check would become a
no-op and be removed by dead code elimination. But, looking at the actual
implementation of libstdc++-v3, that could be too difficult to arrange.

--

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

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

<div dir=3D"ltr"><br><br>On Monday, September 9, 2013 4:29:30 AM UTC+8, Mag=
nus Fromreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sun, 20=
13-09-08 at 12:31 -0700, <a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"HfdxOPo5B1EJ">Victor....@ncl.ac.uk</a> wrote:
<br>&gt;=20
<br>&gt; If I'm interpreting your and Howard's results right, push_back_ an=
d
<br>&gt; generator have similar performance, which is 40% better than
<br>&gt; push_back. Correct?
<br>
<br>Yes.
<br></blockquote><div><br>The problem is that generators are far less flexi=
ble. You can't simultaneously insert into several containers. Inserting a n=
on-predetermined number of objects requires the generator to return a statu=
s code as well as the result, which adds overhead in C++ (I don't suppose i=
t's even part of the Generator concept; haven't looked it up).<br><br>One u=
se case with lots of containers is sorting a large number of objects into b=
ins, for example generating graph nodes with unknown but bounded degree, gi=
ven a list of edges.<br><br>I had a thought, that if conversions were allow=
ed when propagating allocators, you could use <span style=3D"font-family: c=
ourier new,monospace;">std::allocator</span> (or whatever) to get memory fo=
r a container, then convert to a dummy allocator which does not perform add=
itional allocations. Ideally the bounds-overflow check would become a no-op=
 and be removed by dead code elimination. But, looking at the actual implem=
entation of libstdc++-v3, that could be too difficult to arrange.<br></div>=
</div>

<p></p>

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

------=_Part_110_20438365.1378694565318--

.

------=_Part_0_1378699654171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Have you profiled and found the capacity check significant in comparison to=
 choosing the container instance to push_back to?

Even if significant, are you sure the easily branch predicted capacity chec=
k is significant compared to updating size?

Sent from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: "David Krauss" <potswa@gmail.com>
To: <std-proposals@isocpp.org>
Subject: [std-proposals] proposal to add vector::push_back_()
Date: Sun, Sep 8, 2013 7:42 PM

On Monday, September 9, 2013 4:29:30 AM UTC+8, Magnus Fromreide wrote:On Su=
n, 2013-09-08 at 12:31 -0700, Victor....@ncl.ac.uk wrote:

>=20

> If I'm interpreting your and Howard's results right, push_back_ and

> generator have similar performance, which is 40% better than

> push_back. Correct?



Yes.


The problem is that generators are far less flexible. You can't simultaneou=
sly insert into several containers. Inserting a non-predetermined number of=
 objects requires the generator to return a status code as well as the resu=
lt, which adds overhead in C++ (I don't suppose it's even part of the Gener=
ator concept; haven't looked it up).

One use case with lots of containers is sorting a large number of objects i=
nto bins, for example generating graph nodes with unknown but bounded degre=
e, given a list of edges.

I had a thought, that if conversions were allowed when propagating allocato=
rs, you could use std::allocator (or whatever) to get memory for a containe=
r, then convert to a dummy allocator which does not perform additional allo=
cations. Ideally the bounds-overflow check would become a no-op and be remo=
ved by dead code elimination. But, looking at the actual implementation of =
libstdc++-v3, that could be too difficult to arrange.





--=20

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

--=20

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

------=_Part_0_1378699654171
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div style=3D"font-size: 12pt; font-family: Calibri,sans-serif;"><div>Have =
you profiled and found the capacity check significant in comparison to choo=
sing the container instance to push_back to?</div><div><br></div><div>Even =
if significant, are you sure the easily branch predicted capacity check is =
significant compared to updating size?</div><div><br></div><div>Sent from a=
 touchscreen. Please excuse the brevity and tpyos.</div><br><div id=3D"htc_=
header">----- Reply message -----<br>From: &quot;David Krauss&quot; &lt;pot=
swa@gmail.com&gt;<br>To: &lt;std-proposals@isocpp.org&gt;<br>Subject: [std-=
proposals] proposal to add vector::push_back_()<br>Date: Sun, Sep 8, 2013 7=
:42 PM</div></div><br><div dir=3D"ltr"><br><br>On Monday, September 9, 2013=
 4:29:30 AM UTC+8, Magnus Fromreide wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">On Sun, 2013-09-08 at 12:31 -0700, <a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"HfdxOPo5B1EJ">Victor....@ncl.ac.uk</=
a> wrote:
<br>&gt;=20
<br>&gt; If I'm interpreting your and Howard's results right, push_back_ an=
d
<br>&gt; generator have similar performance, which is 40% better than
<br>&gt; push_back. Correct?
<br>
<br>Yes.
<br></blockquote><div><br>The problem is that generators are far less flexi=
ble. You can't simultaneously insert into several containers. Inserting a n=
on-predetermined number of objects requires the generator to return a statu=
s code as well as the result, which adds overhead in C++ (I don't suppose i=
t's even part of the Generator concept; haven't looked it up).<br><br>One u=
se case with lots of containers is sorting a large number of objects into b=
ins, for example generating graph nodes with unknown but bounded degree, gi=
ven a list of edges.<br><br>I had a thought, that if conversions were allow=
ed when propagating allocators, you could use <span style=3D"font-family: c=
ourier new,monospace;">std::allocator</span> (or whatever) to get memory fo=
r a container, then convert to a dummy allocator which does not perform add=
itional allocations. Ideally the bounds-overflow check would become a no-op=
 and be removed by dead code elimination. But, looking at the actual implem=
entation of libstdc++-v3, that could be too difficult to arrange.<br></div>=
</div>

<p></p>

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

<p></p>

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

------=_Part_0_1378699654171--


.

------=_Part_13_23289961.1378707022545
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Monday, September 9, 2013 12:07:34 PM UTC+8, Billy O'Neal wrote:
>
> Have you profiled and found the capacity check significant in comparison=
=20
> to choosing the container instance to push_back to?
>
> Even if significant, are you sure the easily branch predicted capacity=20
> check is significant compared to updating size?
>

The specific case I mentioned was from years ago, and I don't know the=20
performance impact of push_back partly because I abandoned standard=20
containers and used a custom scheme (based on open hashing and circular=20
linked lists). Updating vector::size is deadly not only because it requires=
=20
extra instructions, but because the vector object and the data sequence are=
=20
on different cache lines, so you can easily double the memory write=20
bandwidth requirement.

Again, the topic here is what happens *after* branch prediction does its=20
job. The extra instructions still need to be retired.

Correct me if I'm wrong, but using a generator here requires

   1. The length of the sequence is predetermined before the elements are=
=20
   generated.
   2. The length of the sequence is not predetermined at compile time, or=
=20
   you'd just use an array instead.
   3. Consecutive elements from the generated sequence go into the same=20
   container.
  =20
It's not hard to find a case which is simple enough that the capacity check=
=20
has an impact, yet fails #1 and 3. Tokenizing a string requires the=20
sequence length to vary (although the length is usually unbounded, I'm just=
=20
going off the top of my head). Partitioning an input sequence into two=20
output containers would fail #3. The container selection could just be a=20
range check or modulus; such a thing could easily be a very tight inner=20
loop.

I wonder if any cases where construction by generator is applicable pass=20
requirement #2 =97 that it shouldn't be a fixed-size array.

As for exception safety and construction-destruction semantics in a=20
fixed-size array, I think the performant generic solution would be an RAII=
=20
array construction sentry. It's nice for the library to maintain a size=20
count, but redundant if the final size is fixed. But, I'm not sure how best=
=20
to prevent the full array destructor from running to allow such a sentry to=
=20
do its job, in the general case where the sentry lifetime is during=20
initialization but the array lifetime is longer. I guess it would require=
=20
union trickery and an explicit destructor call in the non-exceptional case.

Micro-optimization tends to get very esoteric very fast, and although I did=
=20
say this problem is valid, I don't know if it's really possible to address=
=20
such problems in a general fashion in the standard library. Boost has=20
plenty of tools for slightly-different data structures. Maybe that array=20
sentry would fit in nicely there. But we can't try to accommodate every=20
specific inner loop with a member function, or extrapolate too surely from=
=20
specific member functions to real-world application solutions.

Custom allocators could improve container performance if they were more=20
flexible. That's the best way to expand the library. The contract to obtain=
=20
memory is the real issue. There are fewer such contracts than specific=20
kinds of inner loops. Handling more memory allocation schemes would more=20
usefully expand the applicability of the container library than adding=20
canned inner loops. In this case, the user should meaningfully be able to=
=20
say they don't want more memory.

For what it's worth, the last time I was bit by something like this was in=
=20
a tokenizer, and the problem was malloc allocating the small strings, not=
=20
the size/end update or capacity check. A third-party arena allocator might=
=20
have solved my problem, but nothing included with GCC did the trick. I=20
ended up coding a custom subset of std::string functionality as a "drop-in=
=20
replacement."

--=20

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

------=_Part_13_23289961.1378707022545
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, September 9, 2013 12:07:34 PM UTC+8, Billy O'Ne=
al 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"font-si=
ze:12pt;font-family:Calibri,sans-serif"><div>Have you profiled and found th=
e capacity check significant in comparison to choosing the container instan=
ce to push_back to?</div><div><br></div><div>Even if significant, are you s=
ure the easily branch predicted capacity check is significant compared to u=
pdating size?</div></div></blockquote><br>The specific case I mentioned was=
 from years ago, and I don't know the performance impact of <span style=3D"=
font-family: courier new,monospace;">push_back</span>
 partly because I abandoned standard containers and used a custom scheme
 (based on open hashing and circular linked lists). Updating <span style=3D=
"font-family: courier new,monospace;">vector::size</span> is deadly not onl=
y because it requires extra instructions, but because the <span style=3D"fo=
nt-family: courier new,monospace;">vector</span> object and the data sequen=
ce are on different cache lines, so you can easily double the memory write =
bandwidth requirement.<br><br>Again, the topic here is what happens <i>afte=
r</i> branch prediction does its job. The extra instructions still need to =
be retired.<br><br>Correct me if I'm wrong, but using a generator here requ=
ires<br><ol><li>The length of the sequence is predetermined before the elem=
ents are generated.</li><li>The length of the sequence is not predetermined=
 at compile time, or you'd just use an array instead.</li><li>Consecutive e=
lements from the generated sequence go into the same container.<br></li></o=
l>It's
 not hard to find a case which is simple enough that the capacity check=20
has an impact, yet fails #1 and 3. Tokenizing a string requires the=20
sequence length to vary (although the length is usually unbounded, I'm=20
just going off the top of my head). Partitioning an input sequence into=20
two output containers would fail #3. The container selection could just=20
be a range check or modulus; such a thing could easily be a very tight=20
inner loop.<br><br>I wonder if any cases where construction by generator
 is applicable pass requirement #2 =97 that it shouldn't be a fixed-size=20
array.<br><br>As for exception safety and construction-destruction=20
semantics in a fixed-size array, I think the performant generic solution
 would be an RAII array construction sentry. It's nice for the library=20
to maintain a size count, but redundant if the final size is fixed. But,
 I'm not sure how best to prevent the full array destructor from running
 to allow such a sentry to do its job, in the general case where the=20
sentry lifetime is during initialization but the array lifetime is=20
longer. I guess it would require <span style=3D"font-family: courier new,mo=
nospace;">union</span> trickery and an explicit destructor call in the non-=
exceptional case.<br><br>Micro-optimization
 tends to get very esoteric very fast, and although I did say this=20
problem is valid, I don't know if it's really possible to address such=20
problems in a general fashion in the standard library. Boost has plenty=20
of tools for slightly-different data structures. Maybe that array sentry
 would fit in nicely there. But we can't try to accommodate every=20
specific inner loop with a member function, or extrapolate too surely=20
from specific member functions to real-world application solutions.<br><br>=
Custom
 allocators could improve container performance if they were more=20
flexible. That's the best way to expand the library. The contract to=20
obtain memory is the real issue. There are fewer such contracts than=20
specific kinds of inner loops. Handling more memory allocation schemes=20
would more usefully expand the applicability of the container library=20
than adding canned inner loops. In this case, the user should=20
meaningfully be able to say they don't want more memory.<br><br>For what it=
's worth, the last time I was bit by something like this was in a tokenizer=
, and the problem was <span style=3D"font-family: courier new,monospace;">m=
alloc</span> allocating the small strings, not the <span style=3D"font-fami=
ly: courier new,monospace;">size</span>/<span style=3D"font-family: courier=
 new,monospace;">end</span>
 update or capacity check. A third-party arena allocator might have=20
solved my problem, but nothing included with GCC did the trick. I ended=20
up coding a custom subset of <span style=3D"font-family: courier new,monosp=
ace;">std::string</span> functionality as a "drop-in replacement."</div>

<p></p>

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

------=_Part_13_23289961.1378707022545--

.

------=_Part_116_32266319.1378738775759
Content-Type: text/plain; charset=ISO-8859-1

Has noone mentioned that the name is abysmal?  OK, I'll do it: push_back_
is a terrible, terrible name.  I prefer the uninitialized_resize()
suggestion if only because the name at least gives a clue that it's
dangerous if you use it wrong.

I agree with Howard's first mail that this is a pretty specialized request
and so I'm not keen on adding it to the standard because you don't want to
write some extra code for your specialized scenario.  std::vector doesn't
need to be ideal for every possible use case.

--

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

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

<div dir=3D"ltr">Has noone mentioned that the name is abysmal?&nbsp; OK, I'=
ll do it: push_back_ is a terrible, terrible name.&nbsp; I prefer the unini=
tialized_resize() suggestion if only because the name at least gives a clue=
 that it's dangerous if you use it wrong.<br><br>I agree with Howard's firs=
t mail that this is a pretty specialized request and so I'm not keen on add=
ing it to the standard because you don't want to write some extra code for =
your specialized scenario.&nbsp; std::vector doesn't need to be ideal for e=
very possible use case.<br></div>

<p></p>

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

------=_Part_116_32266319.1378738775759--

.

--001a11c2bcceec435704e5f4df66
Content-Type: text/plain; charset=ISO-8859-1

On 9 September 2013 09:59, Jonathan Wakely <cxx@kayari.org> wrote:

> Has noone mentioned that the name is abysmal?  OK, I'll do it: push_back_
> is a terrible, terrible name.  I prefer the uninitialized_resize()
> suggestion if only because the name at least gives a clue that it's
> dangerous if you use it wrong.
>

I prefer buffer_overrun(), since that is what this will be enabling.


> I agree with Howard's first mail that this is a pretty specialized request
> and so I'm not keen on adding it to the standard because you don't want to
> write some extra code for your specialized scenario.  std::vector doesn't
> need to be ideal for every possible use case.
>

+1
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c2bcceec435704e5f4df66
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 9 September 2013 09:59, Jona=
than Wakely <span dir=3D"ltr">&lt;<a href=3D"mailto:cxx@kayari.org" target=
=3D"_blank">cxx@kayari.org</a>&gt;</span> wrote:<br><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">Has noone mentioned that the name is abysmal?=A0 OK, I&#39=
;ll do it: push_back_ is a terrible, terrible name.=A0 I prefer the uniniti=
alized_resize() suggestion if only because the name at least gives a clue t=
hat it&#39;s dangerous if you use it wrong.<br>

</div></blockquote><div><br></div><div>I prefer buffer_overrun(), since tha=
t is what this will be enabling.</div><div>=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">

<div dir=3D"ltr">I agree with Howard&#39;s first mail that this is a pretty=
 specialized request and so I&#39;m not keen on adding it to the standard b=
ecause you don&#39;t want to write some extra code for your specialized sce=
nario.=A0 std::vector doesn&#39;t need to be ideal for every possible use c=
ase.<br>

</div></blockquote><div><br></div><div>+1</div></div>-- <br>=A0Nevin &quot;=
:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" tar=
get=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404
</div></div>

<p></p>

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

--001a11c2bcceec435704e5f4df66--

.

El 09/09/2013 17:15, Nevin Liber escribi=F3:
>     Has noone mentioned that the name is abysmal?  OK, I'll do it:
>     push_back_ is a terrible, terrible name.  I prefer the
>     uninitialized_resize() suggestion if only because the name at least
>     gives a clue that it's dangerous if you use it wrong.

What about "unchecked_push_back()" ?

Resizing without constructing some elements (as the vector could store=20
some already constructed elements) breaks vector invariants. For=20
non-trivial types the user should construct the data using the same=20
allocator as vector::allocator_type and it should implement the=20
allocator_traits dispatching logic to be consistent with what vector=20
currently does.

"unchecked_push_back" just tells the vector that it should add a new=20
element without any boundary checking, just like we have operator[] vs at()=
..

To use std::vector<POD> as a buffer to store data raw data to be filled=20
by an external function without paying for zero initialization of POD,=20
shouldn't something like this do the trick?

vector.resize(N, std::default_init);
receive_network_packet
   (vector.data(), vector.size(), /*out*/ received_bytes);
vector.resize(received_bytes);

vector calls allocator_traits::construct(alloc, p, std::default_init)=20
for each element if the allocator does not define such function. The=20
default implementation for "allocator_traits::construct(p,=20
std::default_init)" would be "::new (p) T". I guess the compiler could=20
inline the call to allocator_traits::construct and see ::new(p) T does=20
nothing, simplifying the initialization loop to nothing. Otherwise, a=20
compiler traits is needed to detect trivially default-initializable types.

Best,

Ion

--=20

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

.

--047d7bdcabe2f7c02904e5f5f235
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 9 September 2013 11:07, Ion Gazta=F1aga <igaztanaga@gmail.com> wrote:

> To use std::vector<POD> as a buffer to store data raw data to be filled b=
y
> an external function without paying for zero initialization of POD,


That case can already be solved with allocators.

This proposal is purely to allow optimizing libraries the flexibility to
remove one if check.

std::default_init is (a) not proposed (I didn't see it in the papers for
Chicago) and (b) a whole different can of worms, as it either requires
revising allocators (since allocators, not containers, are currently
responsible for construction of objects inside containers) and/or
moving/sharing responsibility of construction from the allocator to the
container.  If you want to discuss that again, please start a new thread or
resurrect one of the previous discussions on it.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

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

--047d7bdcabe2f7c02904e5f5f235
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 9 September 2013 11:07, Ion =
Gazta=F1aga <span dir=3D"ltr">&lt;<a href=3D"mailto:igaztanaga@gmail.com" t=
arget=3D"_blank">igaztanaga@gmail.com</a>&gt;</span> wrote:<br><div class=
=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">To use std::vector&lt;POD&gt; as a buffer to=
 store data raw data to be filled by an external function without paying fo=
r zero initialization of POD,</blockquote>

<div><br></div><div>That case can already be solved with allocators.</div><=
div><br></div><div>This proposal is purely to allow optimizing libraries th=
e flexibility to remove one if check.</div><div><br></div><div>std::default=
_init is (a) not proposed (I didn&#39;t see it in the papers for Chicago) a=
nd (b) a whole different can of worms, as it either requires revising alloc=
ators (since allocators, not containers, are currently responsible for cons=
truction of objects inside containers) and/or moving/sharing responsibility=
 of construction from the allocator to the container. =A0If you want to dis=
cuss that again, please start a new thread or resurrect one of the previous=
 discussions on it.</div>

</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 (847) 691-1404
</div></div>

<p></p>

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

--047d7bdcabe2f7c02904e5f5f235--

.

--001a11c2570eb9976d04e5f66a02
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> Updating vector::size is deadly not only because it requires extra
instructions, but because the vector object and the data sequence are on
different cache lines, so you can easily double the memory write bandwidth
requirement

Ok, well the push_back_ proposal doesn't get rid of the size modifications.
Which was my whole point. The extra 1 or 2 instructions for the capacity
check are negligible in comparison.

I don't think the cache line thing is going to be a big deal because the
cache line containing size already needs to be accessed to get the pointer
to vector's allocated buffer.

> I prefer the uninitialized_resize() suggestion if only because the name
at least gives a clue that it's dangerous if you use it wrong.
Ok, but that's a different proposal, which is going to be difficult because
it breaks semantics of vector's destructor. I think if you want to restrict
this to POD types that don't need destructor calls, then there's no reason
someone can't write a container with the desired semantics and contains
static_asserts that T be a POD type.

> This proposal is purely to allow optimizing libraries the flexibility to
remove one if check.

Have you shown that this comparison is at all significant in a real world
use case? The size update is the expensive portion, and this proposal
doesn't remove the size update.


Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Mon, Sep 9, 2013 at 9:32 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 9 September 2013 11:07, Ion Gazta=F1aga <igaztanaga@gmail.com> wrote:
>
>> To use std::vector<POD> as a buffer to store data raw data to be filled
>> by an external function without paying for zero initialization of POD,
>
>
> That case can already be solved with allocators.
>
> This proposal is purely to allow optimizing libraries the flexibility to
> remove one if check.
>
> std::default_init is (a) not proposed (I didn't see it in the papers for
> Chicago) and (b) a whole different can of worms, as it either requires
> revising allocators (since allocators, not containers, are currently
> responsible for construction of objects inside containers) and/or
> moving/sharing responsibility of construction from the allocator to the
> container.  If you want to discuss that again, please start a new thread =
or
> resurrect one of the previous discussions on it.
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

--001a11c2570eb9976d04e5f66a02
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt; Updating <span style=3D"font-family:courier new,=
monospace">vector::size</span> is deadly not only because it requires extra=
 instructions, but because the <span style=3D"font-family:courier new,monos=
pace">vector</span> object and the data sequence are on different cache lin=
es, so you can easily double the memory write bandwidth requirement</div>

<div>=A0</div><div>Ok, well the push_back_ proposal doesn&#39;t get rid of =
the size modifications. Which was my whole point. The extra 1 or 2 instruct=
ions for the capacity check are negligible in comparison.</div><div>=A0</di=
v>

<div>I don&#39;t think the cache line thing is going to be a big deal becau=
se the cache line containing size already needs to be accessed to get the p=
ointer to vector&#39;s allocated buffer.</div><div>=A0</div><div>&gt; I pre=
fer the uninitialized_resize() suggestion if only because the name at least=
 gives a clue that it&#39;s dangerous if you use it wrong.<br>

</div><div>Ok, but that&#39;s a different proposal, which is going to be di=
fficult because it breaks semantics of vector&#39;s destructor. I think if =
you want to restrict this to POD types that don&#39;t need destructor calls=
, then there&#39;s no reason someone can&#39;t write a container with the d=
esired semantics and contains static_asserts that T be a POD type.</div>

<div>=A0</div><div>&gt; This proposal is purely to allow optimizing librari=
es the flexibility to remove one if check.</div><div>=A0</div><div>Have you=
 shown that this comparison is at all significant in a real world use case?=
 The size update is the expensive portion, and this proposal doesn&#39;t re=
move the size update.</div>

<div>=A0</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div =
dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.or=
g/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</a></div><d=
iv><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_=
blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Sep 9, 2013 at 9:32 AM, Nevin Li=
ber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"im">On 9 Septembe=
r 2013 11:07, Ion Gazta=F1aga <span dir=3D"ltr">&lt;<a href=3D"mailto:igazt=
anaga@gmail.com" target=3D"_blank">igaztanaga@gmail.com</a>&gt;</span> wrot=
e:<br></div>

<div class=3D"gmail_quote"><div class=3D"im">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">To use std::vector&lt;POD&gt; as a buffer to store data ra=
w data to be filled by an external function without paying for zero initial=
ization of POD,</blockquote>



<div><br></div></div><div>That case can already be solved with allocators.<=
/div><div><br></div><div>This proposal is purely to allow optimizing librar=
ies the flexibility to remove one if check.</div><div><br></div><div>std::d=
efault_init is (a) not proposed (I didn&#39;t see it in the papers for Chic=
ago) and (b) a whole different can of worms, as it either requires revising=
 allocators (since allocators, not containers, are currently responsible fo=
r construction of objects inside containers) and/or moving/sharing responsi=
bility of construction from the allocator to the container. =A0If you want =
to discuss that again, please start a new thread or resurrect one of the pr=
evious discussions on it.</div>



</div><div class=3D"im">-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto=
:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilover=
lord.com</a>&gt;=A0 <a href=3D"tel:%28847%29%20691-1404" target=3D"_blank" =
value=3D"+18476911404">(847) 691-1404</a>
</div></div></div>

<p></p>

-- <br><div class=3D"HOEnZb"><div class=3D"h5">
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11c2570eb9976d04e5f66a02--

.

------=_Part_488_27127797.1378751331583
Content-Type: text/plain; charset=ISO-8859-1


On Monday, September 9, 2013 3:59:35 PM UTC+1, Jonathan Wakely wrote:
>
> Has noone mentioned that the name is abysmal?  OK, I'll do it: push_back_
> is a terrible, terrible name.  I prefer the uninitialized_resize()
> suggestion if only because the name at least gives a clue that it's
> dangerous if you use it wrong.
>

That trailing unserscore is a common convention. In any case, the proposal
is not about the name, I'm quite flexible to change it. E.g.
unchecked_push_back suggested by Ion is perfectly fine with me.



> I agree with Howard's first mail that this is a pretty specialized request
> and so I'm not keen on adding it to the standard because you don't want to
> write some extra code for your specialized scenario.  std::vector doesn't
> need to be ideal for every possible use case.
>

The problem is that no STL container is good enough for this particular use
case. It looks like falling back to malloc is the most natural approach
here. (While I like the generating iterators methods, it's far from natural
- how many programmers would invent it?)


--

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

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

<div dir=3D"ltr"><br>On Monday, September 9, 2013 3:59:35 PM UTC+1, Jonatha=
n Wakely wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">Has noone ment=
ioned that the name is abysmal?&nbsp; OK, I'll do it: push_back_ is a terri=
ble, terrible name.&nbsp; I prefer the uninitialized_resize() suggestion if=
 only because the name at least gives a clue that it's dangerous if you use=
 it wrong.<br></div></blockquote><div>&nbsp;</div><div>That trailing unsers=
core is a common convention. In any case, the proposal is not about the nam=
e, I'm quite flexible to change it. E.g. unchecked_push_back suggested by I=
on is perfectly fine with me.</div><div>&nbsp;</div><div>&nbsp;</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;"><div dir=3D"ltr">I agree with Howard's first mail th=
at this is a pretty specialized request and so I'm not keen on adding it to=
 the standard because you don't want to write some extra code for your spec=
ialized scenario.&nbsp; std::vector doesn't need to be ideal for every poss=
ible use case.<br></div></blockquote><div>&nbsp;</div><div>The problem is t=
hat no STL container is good enough for this particular use case. It looks =
like falling back to malloc is the most natural approach here. (While I lik=
e the generating iterators methods, it's far from natural - how many progra=
mmers would invent it?)</div><div>&nbsp;</div></div>

<p></p>

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

------=_Part_488_27127797.1378751331583--

.

------=_Part_341_18192109.1378751398143
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Monday, September 9, 2013 5:07:26 PM UTC+1, Ion Gazta=F1aga wrote:
>
>
> What about "unchecked_push_back()" ?
>
=20
Fine with me.=20

--=20

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

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

<div dir=3D"ltr"><br>On Monday, September 9, 2013 5:07:26 PM UTC+1, Ion Gaz=
ta=F1aga wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;"><br>What about "unchecked_push_=
back()" ?<br></blockquote><div>&nbsp;</div><div>Fine with me.&nbsp;</div></=
div>

<p></p>

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

------=_Part_341_18192109.1378751398143--

.

------=_Part_351_24184759.1378751898045
Content-Type: text/plain; charset=ISO-8859-1


On Monday, September 9, 2013 6:06:21 PM UTC+1, Billy O'Neal wrote:
>
> Ok, well the push_back_ proposal doesn't get rid of the size
> modifications. Which was my whole point. The extra 1 or 2 instructions for
> the capacity check are negligible in comparison.
>

In Magnus' experiments the compiler was clever enough to remove these
stores. I'd expect it to be easy to spot for the optimiser: on each
iteration it loads and stores this value, and no one else modifies it, so
the store instruction can be postponed to the very end.



>
> Have you shown that this comparison is at all significant in a real world
> use case? The size update is the expensive portion, and this proposal
> doesn't remove the size update.
>

So far there are only small benchmarks by Howard and Magnus showing 40%
speedup.

--

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

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

<div dir=3D"ltr"><br>On Monday, September 9, 2013 6:06:21 PM UTC+1, Billy O=
'Neal wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>Ok, well the=
 push_back_ proposal doesn't get rid of the size modifications. Which was m=
y whole point. The extra 1 or 2 instructions for the capacity check are neg=
ligible in comparison.</div><div></div></div></blockquote><div>&nbsp;</div>=
<div>In Magnus' experiments the compiler was clever enough to remove these =
stores. I'd expect it to&nbsp;be easy to spot for the optimiser: on each it=
eration it loads and stores this value, and no one else modifies it, so the=
 store instruction can be postponed to the very end.</div><div>&nbsp;</div>=
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>&nbsp;<=
/div><div>Have you shown that this comparison is at all significant in a re=
al world use case? The size update is the expensive portion, and this propo=
sal doesn't remove the size update.<br></div></div></blockquote><div>&nbsp;=
</div><div>So far&nbsp;there are only small benchmarks by Howard and Magnus=
 showing 40% speedup.</div></div>

<p></p>

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

------=_Part_351_24184759.1378751898045--

.

--nextPart11730859.OGIsClQiob
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On segunda-feira, 9 de setembro de 2013 11:28:51, Victor.Khomenko@ncl.ac.uk
wrote:
> That trailing unserscore is a common convention.

Can you point to examples in the Standard Library public API?

I can see examples of that in the private code in libstdc++-v3:

bits/stl_set.h:      { return _M_t._M_insert_unique_(__position, __x); }
bits/stl_tree.h:    _M_insert_(_Const_Base_ptr __x, _Const_Base_ptr __p,
_Arg&& __v)
ext/pb_ds/detail/unordered_iterator/iterator.hpp:  iterator_()

In libc++ I can't find a single function ending in underscore, only internal
macros and variable names.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--nextPart11730859.OGIsClQiob
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iD8DBQBSLiFTM/XwBW70U1gRArwaAJ9oATJmK+d05MmmN+4Y6BFZ7qKG2wCfWHfM
YlqubpQAGCMbsFq4jZd7NcY=
=t8l5
-----END PGP SIGNATURE-----

--nextPart11730859.OGIsClQiob--


.

------=_Part_1779_26328312.1378760606388
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I also think that the uninitialized_resize() I suggested would not be=20
accepted due to the problems with the destruction of the maybe-constructed=
=20
elements. However, I still think that there are practical uses for this,=20
and as sadly enough not all vectors are equal, if you change the allocator=
=20
you change the type and the vector is useless in non-template APIs written=
=20
for regular vectors. While such APIs may be deemed as bad practize now that=
=20
template oriented programming is prevalent it is very common in real world=
=20
applications and in some cases necessary, such as when the called method is=
=20
virtual. Due to this I'm willing to give it another try. I think that from=
=20
the standpoint of understandability this one is worse, but from the point=
=20
of view of keeping the vector promises it may be better.

Instead of an uninitialized_resize() this involves another ugly method,=20
which we could tentatively call just_set_the_end_pointer(). The usage=20
scenario is this:

vector.reserve(n);
int actual_count =3D socket.read(vector.data(), n);
vector.just_set_the_end_pointer(actual_count);

There is actually not much difference here, except that if the element type=
=20
has a dtor it would be the socket or whatever functionality is messing=20
around in the memory area that is responsible for handling destruction in=
=20
case of a problem. As far as the vector is concerned there's still nothing=
=20
there. Only when the just_set_the_end_pointer() method is called the vector=
=20
takes responsiblity and at this time there is no problem in doing so. Some=
=20
quite obvious nothrow guarantee must be placed on just_set_the_end_pointer(=
)=20
I guess, but as it just sets the end pointer that would not be a problem.=
=20
The case that the initializing functionality is overstepping the buffer=20
bounds is no worse than if the buffer was an array, a heap block or=20
whatever.

The function name of course has to be given serious thought so that it=20
really conveys what is going on. I would be quite happy to enable_if this=
=20
function for POD elements only but I think the original poster proposing=20
push_back_() would not. Also it is kind of falling into the vector<bool>=20
trap again, although not as seriously.

Den m=E5ndagen den 9:e september 2013 kl. 21:28:13 UTC+2 skrev Thiago=20
Macieira:
>
> On segunda-feira, 9 de setembro de 2013 11:28:51, Victor....@ncl.ac.uk<ja=
vascript:>=20
> wrote:=20
> > That trailing unserscore is a common convention.=20
>
> Can you point to examples in the Standard Library public API?=20
>
> I can see examples of that in the private code in libstdc++-v3:=20
>
> bits/stl_set.h:      { return _M_t._M_insert_unique_(__position, __x); }=
=20
> bits/stl_tree.h:    _M_insert_(_Const_Base_ptr __x, _Const_Base_ptr __p,=
=20
> _Arg&& __v)=20
> ext/pb_ds/detail/unordered_iterator/iterator.hpp:  iterator_()=20
>
> In libc++ I can't find a single function ending in underscore, only=20
> internal=20
> macros and variable names.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>

--=20

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

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

<div dir=3D"ltr">I also think that the uninitialized_resize() I suggested w=
ould not be accepted due to the problems with the destruction of the maybe-=
constructed elements. However, I still think that there are practical uses =
for this, and as sadly enough not all vectors are equal, if you change the =
allocator you change the type and the vector is useless in non-template API=
s written for regular vectors. While such APIs may be deemed as bad practiz=
e now that template oriented programming is prevalent it is very common in =
real world applications and in some cases necessary, such as when the calle=
d method is virtual. Due to this I'm willing to give it another try. I thin=
k that from the standpoint of understandability this one is worse, but from=
 the point of view of keeping the vector promises it may be better.<div><br=
></div><div>Instead of an uninitialized_resize() this involves another ugly=
 method, which we could tentatively call just_set_the_end_pointer(). The us=
age scenario is this:</div><div><br></div><div>vector.reserve(n);</div><div=
>int actual_count =3D socket.read(vector.data(), n);</div><div>vector.just_=
set_the_end_pointer(<span style=3D"font-size: 13px;">actual_count</span><sp=
an style=3D"font-size: 13px;">);</span></div><div><span style=3D"font-size:=
 13px;"><br></span></div><div><span style=3D"font-size: 13px;">There is act=
ually not much difference here, except that if the element type has a dtor =
it would be the socket or whatever functionality is messing around in the m=
emory area that is responsible for handling destruction in case of a proble=
m. As far as the vector is concerned there's still nothing there. Only when=
 the&nbsp;</span><span style=3D"font-size: 13px;">just_set_the_end_pointer(=
) method is called the vector takes responsiblity and at this time there is=
 no problem in doing so. Some quite obvious nothrow guarantee must be place=
d on&nbsp;</span><span style=3D"font-size: 13px;">just_set_the_end_pointer(=
) I guess, but as it just sets the end pointer that would not be a problem.=
 The case that the initializing functionality is overstepping the buffer bo=
unds is no worse than if the buffer was an array, a heap block or whatever.=
</span></div><div><span style=3D"font-size: 13px;"><br></span></div><div><s=
pan style=3D"font-size: 13px;">The function name of course has to be given =
serious thought so that it really conveys what is going on. I would be quit=
e happy to enable_if this function for POD elements only but I think the or=
iginal poster proposing push_back_() would not. Also it is kind of falling =
into the vector&lt;bool&gt; trap again, although not as seriously.</span></=
div><div><br>Den m=E5ndagen den 9:e september 2013 kl. 21:28:13 UTC+2 skrev=
 Thiago Macieira:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On segunda-fe=
ira, 9 de setembro de 2013 11:28:51, <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"AXlPBXRWs-YJ">Victor....@ncl.ac.uk</a>=20
<br>wrote:
<br>&gt; That trailing unserscore is a common convention.
<br>
<br>Can you point to examples in the Standard Library public API?
<br>
<br>I can see examples of that in the private code in libstdc++-v3:
<br>
<br>bits/stl_set.h: &nbsp; &nbsp; &nbsp;{ return _M_t._M_insert_unique_(__<=
wbr>position, __x); }
<br>bits/stl_tree.h: &nbsp; &nbsp;_M_insert_(_Const_Base_ptr __x, _Const_Ba=
se_ptr __p,=20
<br>_Arg&amp;&amp; __v)
<br>ext/pb_ds/detail/unordered_<wbr>iterator/iterator.hpp: &nbsp;iterator_(=
)
<br>
<br>In libc++ I can't find a single function ending in underscore, only int=
ernal=20
<br>macros and variable names.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br></blockquote></div></div>

<p></p>

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

------=_Part_1779_26328312.1378760606388--

.

--047d7bdcabe20f8c5a04e5f9f4e3
Content-Type: text/plain; charset=ISO-8859-1

On 9 September 2013 16:03, Bengt Gustafsson
<bengt.gustafsson@beamways.com>wrote:

>
> Instead of an uninitialized_resize() this involves another ugly method,
> which we could tentatively call just_set_the_end_pointer(). The usage
> scenario is this:
>

-1.  Classes have invariants; we should not be providing easy methods to
break those invariants.

I really don't see why any of this has to be shoehorned into std::vector.
If people can change their code to use the new methods you propose, they
can also change their implementations to use more appropriate data
structures.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bdcabe20f8c5a04e5f9f4e3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 9 September 2013 16:03, Beng=
t Gustafsson <span dir=3D"ltr">&lt;<a href=3D"mailto:bengt.gustafsson@beamw=
ays.com" target=3D"_blank">bengt.gustafsson@beamways.com</a>&gt;</span> wro=
te:<br>


<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div><br></div><div>Instead of an uninitialized_resize() this involves anot=
her ugly method, which we could tentatively call just_set_the_end_pointer()=
.. The usage scenario is this:</div>


</div></blockquote><div><br></div><div>-1. =A0Classes have invariants; we s=
hould not be providing easy methods to break those invariants.=A0</div><div=
><br></div><div>I really don&#39;t see why any of this has to be shoehorned=
 into std::vector. =A0 If people can change their code to use the new metho=
ds you propose, they can also change their implementations to use more appr=
opriate data structures.</div>


</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_=
blank">(847) 691-1404</a>
</div></div>

<p></p>

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

--047d7bdcabe20f8c5a04e5f9f4e3--

.

El 09/09/2013 18:32, Nevin Liber escribi=F3:
>     To use std::vector<POD> as a buffer to store data raw data to be
>     filled by an external function without paying for zero
>     initialization of POD,
>
> That case can already be solved with allocators.
> This proposal is purely to allow optimizing libraries the flexibility to
> remove one if check.
>
> std::default_init is (a) not proposed (I didn't see it in the papers for
> Chicago) and (b) a whole different can of worms, as it either requires
> revising allocators (since allocators, not containers, are currently
> responsible for construction of objects inside containers) and/or
> moving/sharing responsibility of construction from the allocator to the
> container.  If you want to discuss that again, please start a new thread
> or resurrect one of the previous discussions on it.

Sorry but I don't understand your response. I'm just giving an=20
alternative to some proposals in this thread like the one proposed by Bengt=
:

   vector.reserve(n);
   int actual_count =3D socket.read(vector.data(), n);
   vector.just_set_the_end_pointer(actual_count);

and other posts talking about the cost of zero-initialization when=20
dealing with C libraries.

Writing a custom allocator just to avoid the value-initialization=20
overhead is not a trivial task and you are changing the type of the=20
vector, which is not very convenient to maintain ABI compatibility, and=20
you miss move semantics with other classes holding std::allocator-based=20
vectors. In this case, the socket is writing to uninitialized memory,=20
constructing objects without passing through allocator_traits protocol.=20
If value_type has no trivial destructor then resources will be leaked.

I know that std::default_init is not in any proposal, it's was a quick=20
example to show how default initialization for all allocators could be=20
achieved (just like in C++11 variadic construct functions for emplace=20
were added). allocator_traits is the proxy object that dispatches object=20
construction for containers between allocators' "construct" methods and=20
default implementations based on placement new. Currently, with=20
allocator_traits+std::allocator you can obtain these placement calls:

::new (p) T() //value initialization for DefaultInsertable types
::new (p) T(a) //1 arg constructor for EmplaceInsertable types
::new (p) T(a, b) //2 arg, etc.. for EmplaceInsertable types

but there is no equivalent to:
::new (p) T //default initialization for DefaultInsertable types

I consider this a (tiny) hole in the specification. If default=20
initialization is a good idea in the language, then it should be there=20
also for collections. The typical use cases is avoiding more costly=20
value initializations for types that will be shortly externally assigned=20
(socket, IPC, etc.).

We can add a new function to allocator_traits requesting "default=20
initialization" when constructing an DefaultInsertable object, just like=20
it offers variadic constructors while C++03 allocators only provide a=20
copy construction based "construct" member. Changing allocator_traits=20
does not require changing user defined allocators, just like we didn't=20
need to update our C++03 allocators with C++11 containers.

I agree that this is off-topic in a "push_back()_" titled thread, sorry=20
for any inconvenience this might have caused.

Best,

Ion

--=20

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

.

------=_Part_917_14996831.1378765831022
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, September 10, 2013 5:03:26 AM UTC+8, Bengt Gustafsson wrote:
>
> However, I still think that there are practical uses for this, and as
> sadly enough not all vectors are equal, if you change the allocator you
> change the type and the vector is useless in non-template APIs written for
> regular vectors. While such APIs may be deemed as bad practize now that
> template oriented programming is prevalent it is very common in real world
> applications and in some cases necessary, such as when the called method is
> virtual.
>

Since we're already in micro-optimization land, legacy code and especially
virtual dispatches essentially don't exist. The present motivation is to
stop users from abandoning the Standard Library entirely in favor of
malloc, or a user-defined end pointer within the vector. Such user
tendencies result in reliability and security traded off for performance.

There's no sense in opening a potential correctness hole for the sake of
keeping std::allocator in use.

--

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

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

<div dir=3D"ltr"><br><br>On Tuesday, September 10, 2013 5:03:26 AM UTC+8, B=
engt Gustafsson 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">However, I still think that there are practical uses for this, and=
 as sadly enough not all vectors are equal, if you change the allocator you=
 change the type and the vector is useless in non-template APIs written for=
 regular vectors. While such APIs may be deemed as bad practize now that te=
mplate oriented programming is prevalent it is very common in real world ap=
plications and in some cases necessary, such as when the called method is v=
irtual.</div></blockquote><div><br>Since we're already in micro-optimizatio=
n land, legacy code and especially virtual dispatches essentially don't exi=
st. The present motivation is to stop users from abandoning the Standard Li=
brary entirely in favor of malloc, or a user-defined end pointer within the=
 vector. Such user tendencies result in reliability and security traded off=
 for performance.<br><br>There's no sense in opening a potential correctnes=
s hole for the sake of keeping std::allocator in use.<br></div></div>

<p></p>

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

------=_Part_917_14996831.1378765831022--

.

--001a11c2d5449a527a04e5fb002f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 9 September 2013 17:19, Ion Gazta=F1aga <igaztanaga@gmail.com> wrote:

> Sorry but I don't understand your response. I'm just giving an alternativ=
e
> to some proposals in this thread like the one proposed by Bengt:
>
>
>   vector.reserve(n);
>   int actual_count =3D socket.read(vector.data(), n);
>   vector.just_set_the_end_**pointer(actual_count);
>
> and other posts talking about the cost of zero-initialization when dealin=
g
> with C libraries.
>
> Writing a custom allocator just to avoid the value-initialization overhea=
d
> is not a trivial task


1)  It isn't that hard in C++11.  Which part of writing the allocator are
you finding tricky?

2)  I would strongly support someone proposing such an allocator for C++17.


> and you are changing the type of the vector, which is not very convenient
> to maintain ABI compatibility,


And changing the standard is *more* convenient, for a feature you cannot
count on having for at least half a decade?


> and you miss move semantics with other classes holding
> std::allocator-based vectors.


So we should shoehorn *everything* into std::vector<T, std::allocator<T>>
because some people are unwilling to change their interfaces?


> I know that std::default_init is not in any proposal, it's was a quick
> example to show how default initialization for all allocators could be
> achieved (just like in C++11 variadic construct functions for emplace wer=
e
> added). allocator_traits is the proxy object that dispatches object
> construction for containers between allocators' "construct" methods and
> default implementations based on placement new. Currently, with
> allocator_traits+std::**allocator you can obtain these placement calls:
>
> ::new (p) T() //value initialization for DefaultInsertable types
> ::new (p) T(a) //1 arg constructor for EmplaceInsertable types
> ::new (p) T(a, b) //2 arg, etc.. for EmplaceInsertable types
>
> but there is no equivalent to:
> ::new (p) T //default initialization for DefaultInsertable types
>

There is also no equivalent to:

:: new (p) T{}
:: new (p) T{a}
:: new (p) T{a, b}

or

:: new (p) T
:: new (p) T{a}
:: new (p) T{a, b}

People desire lots of combinations of things.

While it isn't great that allocators have two responsibilities
(getting/freeing storage and constructing/destroying objects), that is the
customization point for it.

--=20
>
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

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

--001a11c2d5449a527a04e5fb002f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 9 September 2013 17:19, Ion =
Gazta=F1aga <span dir=3D"ltr">&lt;<a href=3D"mailto:igaztanaga@gmail.com" t=
arget=3D"_blank">igaztanaga@gmail.com</a>&gt;</span> wrote:<br><div class=
=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Sorry but I don&#39;t understand your respon=
se. I&#39;m just giving an alternative to some proposals in this thread lik=
e the one proposed by Bengt:<div class=3D"im">

<br>
<br>
=A0 vector.reserve(n);<br>
=A0 int actual_count =3D socket.read(vector.data(), n);<br>
=A0 vector.just_set_the_end_<u></u>pointer(actual_count);<br>
<br></div>
and other posts talking about the cost of zero-initialization when dealing =
with C libraries.<br>
<br>
Writing a custom allocator just to avoid the value-initialization overhead =
is not a trivial task </blockquote><div><br></div><div>1) =A0It isn&#39;t t=
hat hard in C++11. =A0Which part of writing the allocator are you finding t=
ricky?</div>

<div><br></div><div>2) =A0I would strongly support someone proposing such a=
n allocator for C++17.</div><div>=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">an=
d you are changing the type of the vector, which is not very convenient to =
maintain ABI compatibility,</blockquote>

<div><br></div><div>And changing the standard is *more* convenient, for a f=
eature you cannot count on having for at least half a decade?</div><div>=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">

 and you miss move semantics with other classes holding std::allocator-base=
d vectors. </blockquote><div><br></div><div>So we should shoehorn *everythi=
ng* into std::vector&lt;T, std::allocator&lt;T&gt;&gt; because some people =
are unwilling to change their interfaces?</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">I know that std::default_init =
is not in any proposal, it&#39;s was a quick example to show how default in=
itialization for all allocators could be achieved (just like in C++11 varia=
dic construct functions for emplace were added). allocator_traits is the pr=
oxy object that dispatches object construction for containers between alloc=
ators&#39; &quot;construct&quot; methods and default implementations based =
on placement new. Currently, with allocator_traits+std::<u></u>allocator yo=
u can obtain these placement calls:<br>


<br>
::new (p) T() //value initialization for DefaultInsertable types<br>
::new (p) T(a) //1 arg constructor for EmplaceInsertable types<br>
::new (p) T(a, b) //2 arg, etc.. for EmplaceInsertable types<br>
<br>
but there is no equivalent to:<br>
::new (p) T //default initialization for DefaultInsertable types<br></block=
quote><div><br></div><div>There is also no equivalent to:</div><div><br></d=
iv>:: new (p) T{}=A0<br>:: new (p) T{a}=A0<br><div><div>:: new (p) T{a, b}=
=A0</div>

</div><div><br></div><div>or=A0</div><div><br></div><div>:: new (p) T<br>::=
 new (p) T{a}=A0<br><div><div>:: new (p) T{a, b}=A0</div></div><div><br></d=
iv><div>People desire lots of combinations of things.</div><div><br></div><=
div>

While it isn&#39;t great that allocators have two responsibilities (getting=
/freeing storage and constructing/destroying objects), that is the customiz=
ation point for it.</div></div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">

<div>--=A0<br></div></blockquote></div>=A0Nevin &quot;:-)&quot; Liber=A0 &l=
t;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@=
eviloverlord.com</a>&gt;=A0 (847) 691-1404
</div></div>

<p></p>

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

--001a11c2d5449a527a04e5fb002f--

.

------=_Part_2210_29800438.1378807117831
Content-Type: text/plain; charset=ISO-8859-1



On Monday, September 9, 2013 7:28:51 PM UTC+1, Victor....@ncl.ac.uk wrote:
>
>
> On Monday, September 9, 2013 3:59:35 PM UTC+1, Jonathan Wakely wrote:
>>
>> Has noone mentioned that the name is abysmal?  OK, I'll do it: push_back_
>> is a terrible, terrible name.  I prefer the uninitialized_resize()
>> suggestion if only because the name at least gives a clue that it's
>> dangerous if you use it wrong.
>>
>
> That trailing unserscore is a common convention.
>

Where else is it used in the standard library?


> In any case, the proposal is not about the name, I'm quite flexible to
> change it. E.g. unchecked_push_back suggested by Ion is perfectly fine with
> me.
>
>
>
>> I agree with Howard's first mail that this is a pretty specialized
>> request and so I'm not keen on adding it to the standard because you don't
>> want to write some extra code for your specialized scenario.  std::vector
>> doesn't need to be ideal for every possible use case.
>>
>
> The problem is that no STL container is good enough for this particular
> use case. It looks like falling back to malloc is the most natural approach
> here. (While I like the generating iterators methods, it's far from natural
> - how many programmers would invent it?)
>

So write your own container, the STL containers were never meant to be all
things to all men, they are examples of data structures that follow the STL
interface, which is about iterators and algorithms, not containers.

Specialized use cases deserve specialized containers.

--

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

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

<div dir=3D"ltr"><br><br>On Monday, September 9, 2013 7:28:51 PM UTC+1, Vic=
tor....@ncl.ac.uk wrote:<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>On Monday, September 9, 2013 3:59:35 PM UTC+1, Jonathan Wake=
ly wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid"><div dir=3D"ltr">Has noone mentioned that the nam=
e is abysmal?&nbsp; OK, I'll do it: push_back_ is a terrible, terrible name=
..&nbsp; I prefer the uninitialized_resize() suggestion if only because the =
name at least gives a clue that it's dangerous if you use it wrong.<br></di=
v></blockquote><div>&nbsp;</div><div>That trailing unserscore is a common c=
onvention.</div></div></blockquote><div><br>Where else is it used in the st=
andard library?<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div> In any case, the proposal is not about the name, I'=
m quite flexible to change it. E.g. unchecked_push_back suggested by Ion is=
 perfectly fine with me.</div><div>&nbsp;</div><div>&nbsp;</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;b=
order-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:s=
olid"><div dir=3D"ltr">I agree with Howard's first mail that this is a pret=
ty specialized request and so I'm not keen on adding it to the standard bec=
ause you don't want to write some extra code for your specialized scenario.=
&nbsp; std::vector doesn't need to be ideal for every possible use case.<br=
></div></blockquote><div>&nbsp;</div><div>The problem is that no STL contai=
ner is good enough for this particular use case. It looks like falling back=
 to malloc is the most natural approach here. (While I like the generating =
iterators methods, it's far from natural - how many programmers would inven=
t it?)</div></div></blockquote><div><br>So write your own container, the ST=
L containers were never meant to be all things to all men, they are example=
s of data structures that follow the STL interface, which is about iterator=
s and algorithms, not containers.<br>&nbsp;<br>Specialized use cases deserv=
e specialized containers.<br><br></div></div>

<p></p>

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

------=_Part_2210_29800438.1378807117831--

.

------=_Part_397_29556721.1378842826673
Content-Type: text/plain; charset=ISO-8859-1


On Monday, September 9, 2013 8:28:13 PM UTC+1, Thiago Macieira wrote:
>
> On segunda-feira, 9 de setembro de 2013 11:28:51, Victor....@ncl.ac.uk<javascript:>
> wrote:
> > That trailing unserscore is a common convention.
>
> Can you point to examples in the Standard Library public API?
>

Ok, this is a good argument, let's go with Ion's suggestion then
(unchecked_push_back).

--

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

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

<div dir=3D"ltr"><br>On Monday, September 9, 2013 8:28:13 PM UTC+1, Thiago =
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;">On segunda-feira, 9 de setembro=
 de 2013 11:28:51, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"AXlPBXRWs-YJ">Victor....@ncl.ac.uk</a>=20
<br>wrote:
<br>&gt; That trailing unserscore is a common convention.
<br>
<br>Can you point to examples in the Standard Library public API?
<br></blockquote><div>&nbsp;</div><div>Ok, this is a&nbsp;good argument, le=
t's go with Ion's suggestion then (unchecked_push_back).&nbsp;</div></div>

<p></p>

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

------=_Part_397_29556721.1378842826673--

.

------=_Part_54_7466274.1378931745611
Content-Type: text/plain; charset=ISO-8859-1

I'd prefer push_back_unchecked because it allows for better code completion.

--

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

------=_Part_54_7466274.1378931745611
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">I'd prefer push_back_unchecked because it allows for better code completion.<br></div>

<p></p>

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

------=_Part_54_7466274.1378931745611--

.

------=_Part_7_22945010.1378927647943
Content-Type: text/plain; charset=ISO-8859-1

Hi,
I haven't read all the comments, but it seems to me that your are finding
really complicated solution to a simple problem.
The problem is that we are doing the check every time when adding multiple
values?
When the we don't we provide a method wich will be able to add mutiple
values directly and do the check only one?
something like:
template< class RandomIt >
void push_back( RandomIt first, RandomIt last );
RandomIt should be a RandomAccessIterator, so that we can compute the
difference between first and last to do the check.
Note that in the case where the allocated memory isn't suffisent and a
reallocation happen, things could also be optimized because we already know
how much space will be necessary in order to do all the insertion.
The code will then become :

vector<Widget> vw;
vector<Widget> others;
//vw.reserve(...); commented out since the extra allocation will be done in
one pass below, so adding this won't changes a lot of things.
vw.push_back(others.begin(), others.end()); // efficient because the
capacity checks will be done only once.


Note that this solution is probably not the best in term of pure
efficiency, but I do believe it is good compromise between efficiency and
code savety.

On Saturday, September 7, 2013 12:05:03 AM UTC+2, Victor....@ncl.ac.uk
wrote:
>
> [I suspect I am re-inventing the wheel, but a quick search of this forum
> didn't yield any similar proposal.]
>
> vector::push_back() is inefficient, as every time it checks whether
> the vector has reached its full capacity and needs to allocate more memory.
> Such a check is often unnecessary, e.g. if reserve() was called, see the
> example below. Hence, the proposal is to add vector::push_back_() which
> skips this check. Calling it for a full vector results in undefined
> behaviour (consistent with operator[] which does not check that the index
> is valid). Of course, an assertion checking the capacity should be used in
> push_back_() to simplify debugging, but the optimised code has no overhead.
>
> ---------
> Example: The vector class is often used like this:
>
> vector<Widget> vw;
> vw.reserve(...);
> for(...){
>     vw.push_back(...); // inefficient due to unnecessary capacity checks;
> push_back_() should be used instead
> }
>
> The capacity check is unnecessary in this example and leads to loss of
> performance (code like this is likely to be in a tight internal
> loop). Furthermore, unnecessary overhead cannot be removed, e.g. replacing
> this code by
>
> vector<Widget> vw(...);
> for(...){
>     vw[...]=...;
> }
>
> does not solve the problem, as now the default constructor of Widget is
> called many times, only for the created objects to be immediately
> overwritten in the loop.
> ---------
>
> Of course, the same argument works for emplace_back_(). One might also
> consider adding back_inserter_ to further exploit the new functionality,
> e.g.:
>
> vector<Widget> vw;
> vw.reserve(...);
> transform(...,back_inserter_(vw),...);
>
>
>

--

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

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

<div dir=3D"ltr">Hi,<br>I haven't read all the comments, but it seems to me=
 that your are finding really complicated solution to a simple problem. <br=
>The problem is that we are doing the check every time when adding multiple=
 values?<br>When the we don't we provide a method wich will be able to add =
mutiple values directly and do the check only one?<br>something like:<br>te=
mplate&lt; class RandomIt &gt;<br>void push_back( RandomIt first, RandomIt =
last );<br>RandomIt should be a RandomAccessIterator, so that we can comput=
e the difference between first and last to do the check.<br>Note that in th=
e case where the allocated memory isn't suffisent and a reallocation happen=
, things could also be optimized because we already know how much space wil=
l be necessary in order to do all the insertion.<br>The code will then beco=
me :<div><br></div><div style=3D"background-color: #FAFAFA; border-color: #=
BBB; border-style: solid; border-width: 1px; word-wrap: break-word;" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Widget</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> vw</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>vector</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Widget</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> others</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">//vw.reser=
ve(...); commented out since the extra allocation will be done in one pass =
below, so adding this won't changes a lot of things.</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>vw</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">push_back</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">others</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">.</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">begin</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> other=
s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">end</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">());</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
800;" class=3D"styled-by-prettify">// efficient because the capacity checks=
 will be done only once.</span></div></code></div><br><br>Note that this so=
lution is probably not the best in term of pure efficiency, but I do believ=
e it is good compromise between efficiency and code savety.<br><br>On Satur=
day, September 7, 2013 12:05:03 AM UTC+2, Victor....@ncl.ac.uk wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>[I suspect I a=
m re-inventing the wheel, but&nbsp;a quick search of this forum didn't yiel=
d any similar proposal.]</div><div>&nbsp;</div><div>vector::push_back() is =
inefficient, as&nbsp;every time it checks whether the&nbsp;vector has&nbsp;=
reached its full capacity and needs to allocate more memory. Such a check i=
s often unnecessary, e.g. if reserve() was called, see the example below. H=
ence, the proposal is to add&nbsp;vector::push_back_() which skips this che=
ck.&nbsp;Calling it for a full vector results in undefined behaviour (consi=
stent with operator[] which does not check that the index is valid). Of cou=
rse, an assertion checking the capacity should be used&nbsp;in push_back_()=
 to simplify debugging, but&nbsp;the optimised code has no overhead.</div><=
div>&nbsp;</div><div>---------</div><div>Example: The vector class is often=
 used like this:</div><div>&nbsp;</div><div>vector&lt;Widget&gt; vw;</div><=
div>vw.reserve(...);</div><div>for(...){</div><div>&nbsp;&nbsp;&nbsp; vw.pu=
sh_back(...); //&nbsp;inefficient due to unnecessary capacity checks; push_=
back_() should be used instead</div><div>}</div><div>&nbsp;</div><div>The c=
apacity&nbsp;check is unnecessary in this example and leads&nbsp;to&nbsp;lo=
ss of performance (code like this is likely to be in a tight internal loop)=
..&nbsp;Furthermore, unnecessary overhead cannot be removed, e.g. replacing =
this code by</div><div>&nbsp;</div><div><div>vector&lt;Widget&gt; vw(...);<=
/div><div>for(...){</div><div>&nbsp;&nbsp;&nbsp; vw[...]=3D...;</div><div>}=
</div><div>&nbsp;</div><div>does not solve the problem, as now the default =
constructor of Widget is called many times, only for&nbsp;the created objec=
ts to be immediately overwritten in the loop.</div><div>---------</div><div=
>&nbsp;</div><div><div>Of course, the same argument works for&nbsp;emplace_=
back_(). One might also consider adding back_inserter_ to further&nbsp;expl=
oit the new functionality, e.g.:</div><div>&nbsp;</div></div><div><div>vect=
or&lt;Widget&gt; vw;</div><div>vw.reserve(...);</div><div>transform(...,bac=
k_inserter_(vw),...);</div></div><div>&nbsp;</div><div>&nbsp;</div></div></=
div></blockquote></div>

<p></p>

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

------=_Part_7_22945010.1378927647943--

.

--089e01176cf7c52a9104e6224ce1
Content-Type: text/plain; charset=ISO-8859-1

That already exists, the member function is called insert.

vw.insert(vw.begin(), others.begin(), others.end()); //C++98/03

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Wed, Sep 11, 2013 at 12:27 PM, <masse.nicolas@gmail.com> wrote:

> Hi,
> I haven't read all the comments, but it seems to me that your are finding
> really complicated solution to a simple problem.
> The problem is that we are doing the check every time when adding multiple
> values?
> When the we don't we provide a method wich will be able to add mutiple
> values directly and do the check only one?
> something like:
> template< class RandomIt >
> void push_back( RandomIt first, RandomIt last );
> RandomIt should be a RandomAccessIterator, so that we can compute the
> difference between first and last to do the check.
> Note that in the case where the allocated memory isn't suffisent and a
> reallocation happen, things could also be optimized because we already know
> how much space will be necessary in order to do all the insertion.
> The code will then become :
>
> vector<Widget> vw;
> vector<Widget> others;
> //vw.reserve(...); commented out since the extra allocation will be done
> in one pass below, so adding this won't changes a lot of things.
> vw.push_back(others.begin(), others.end()); // efficient because the
> capacity checks will be done only once.
>
>
> Note that this solution is probably not the best in term of pure
> efficiency, but I do believe it is good compromise between efficiency and
> code savety.
>
> On Saturday, September 7, 2013 12:05:03 AM UTC+2, Victor....@ncl.ac.ukwrote:
>>
>> [I suspect I am re-inventing the wheel, but a quick search of this forum
>> didn't yield any similar proposal.]
>>
>> vector::push_back() is inefficient, as every time it checks whether
>> the vector has reached its full capacity and needs to allocate more memory.
>> Such a check is often unnecessary, e.g. if reserve() was called, see the
>> example below. Hence, the proposal is to add vector::push_back_() which
>> skips this check. Calling it for a full vector results in undefined
>> behaviour (consistent with operator[] which does not check that the index
>> is valid). Of course, an assertion checking the capacity should be used in
>> push_back_() to simplify debugging, but the optimised code has no overhead.
>>
>> ---------
>> Example: The vector class is often used like this:
>>
>> vector<Widget> vw;
>> vw.reserve(...);
>> for(...){
>>     vw.push_back(...); // inefficient due to unnecessary capacity checks;
>> push_back_() should be used instead
>> }
>>
>> The capacity check is unnecessary in this example and leads to loss of
>> performance (code like this is likely to be in a tight internal
>> loop). Furthermore, unnecessary overhead cannot be removed, e.g. replacing
>> this code by
>>
>> vector<Widget> vw(...);
>> for(...){
>>     vw[...]=...;
>> }
>>
>> does not solve the problem, as now the default constructor of Widget is
>> called many times, only for the created objects to be immediately
>> overwritten in the loop.
>> ---------
>>
>> Of course, the same argument works for emplace_back_(). One might also
>> consider adding back_inserter_ to further exploit the new functionality,
>> e.g.:
>>
>> vector<Widget> vw;
>> vw.reserve(...);
>> transform(...,back_inserter_(vw),...);
>>
>>
>>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--089e01176cf7c52a9104e6224ce1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>That already exists, the member function is called in=
sert.</div><div>=A0</div><div>vw<span style=3D"color:rgb(102,102,0)">.</spa=
n><span>insert</span><span style=3D"color:rgb(102,102,0)">(vw.begin(), </sp=
an><span>others</span><span style=3D"color:rgb(102,102,0)">.</span><span st=
yle=3D"color:rgb(0,0,136)">begin</span><span style=3D"color:rgb(102,102,0)"=
>(),</span><span> others</span><span style=3D"color:rgb(102,102,0)">.</span=
><span style=3D"color:rgb(0,0,136)">end</span><span style=3D"color:rgb(102,=
102,0)">()); //C++98/03</span></div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Sep 11, 2013 at 12:27 PM,  <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:masse.nicolas@gmail.com" target=3D"_blan=
k">masse.nicolas@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">

<div dir=3D"ltr">Hi,<br>I haven&#39;t read all the comments, but it seems t=
o me that your are finding really complicated solution to a simple problem.=
 <br>The problem is that we are doing the check every time when adding mult=
iple values?<br>

When the we don&#39;t we provide a method wich will be able to add mutiple =
values directly and do the check only one?<br>something like:<br>template&l=
t; class RandomIt &gt;<br>void push_back( RandomIt first, RandomIt last );<=
br>

RandomIt should be a RandomAccessIterator, so that we can compute the diffe=
rence between first and last to do the check.<br>Note that in the case wher=
e the allocated memory isn&#39;t suffisent and a reallocation happen, thing=
s could also be optimized because we already know how much space will be ne=
cessary in order to do all the insertion.<br>

The code will then become :<div><br></div><div style=3D"border:1px solid rg=
b(187,187,187);background-color:rgb(250,250,250)"><code><div><span>vector</=
span><span style=3D"color:rgb(102,102,0)">&lt;</span><span style=3D"color:r=
gb(102,0,102)">Widget</span><span style=3D"color:rgb(102,102,0)">&gt;</span=
><span> vw</span><span style=3D"color:rgb(102,102,0)">;</span><span><br>

vector</span><span style=3D"color:rgb(102,102,0)">&lt;</span><span style=3D=
"color:rgb(102,0,102)">Widget</span><span style=3D"color:rgb(102,102,0)">&g=
t;</span><span> others</span><span style=3D"color:rgb(102,102,0)">;</span><=
span><br>

</span><span style=3D"color:rgb(136,0,0)">//vw.reserve(...); commented out =
since the extra allocation will be done in one pass below, so adding this w=
on&#39;t changes a lot of things.</span><span><br>vw</span><span style=3D"c=
olor:rgb(102,102,0)">.</span><span>push_back</span><span style=3D"color:rgb=
(102,102,0)">(</span><span>others</span><span style=3D"color:rgb(102,102,0)=
">.</span><span style=3D"color:rgb(0,0,136)">begin</span><span style=3D"col=
or:rgb(102,102,0)">(),</span><span> others</span><span style=3D"color:rgb(1=
02,102,0)">.</span><span style=3D"color:rgb(0,0,136)">end</span><span style=
=3D"color:rgb(102,102,0)">());</span><span> </span><span style=3D"color:rgb=
(136,0,0)">// efficient because the capacity checks will be done only once.=
</span></div>

</code></div><br><br>Note that this solution is probably not the best in te=
rm of pure efficiency, but I do believe it is good compromise between effic=
iency and code savety.<br><br>On Saturday, September 7, 2013 12:05:03 AM UT=
C+2, <a href=3D"mailto:Victor....@ncl.ac.uk" target=3D"_blank">Victor....@n=
cl.ac.uk</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left=
-width:1px;border-left-style:solid">

<div dir=3D"ltr"><div>[I suspect I am re-inventing the wheel, but=A0a quick=
 search of this forum didn&#39;t yield any similar proposal.]</div><div>=A0=
</div><div>vector::push_back() is inefficient, as=A0every time it checks wh=
ether the=A0vector has=A0reached its full capacity and needs to allocate mo=
re memory. Such a check is often unnecessary, e.g. if reserve() was called,=
 see the example below. Hence, the proposal is to add=A0vector::push_back_(=
) which skips this check.=A0Calling it for a full vector results in undefin=
ed behaviour (consistent with operator[] which does not check that the inde=
x is valid). Of course, an assertion checking the capacity should be used=
=A0in push_back_() to simplify debugging, but=A0the optimised code has no o=
verhead.</div>

<div>=A0</div><div>---------</div><div>Example: The vector class is often u=
sed like this:</div><div>=A0</div><div>vector&lt;Widget&gt; vw;</div><div>v=
w.reserve(...);</div><div>for(...){</div><div>=A0=A0=A0 vw.push_back(...); =
//=A0inefficient due to unnecessary capacity checks; push_back_() should be=
 used instead</div>

<div>}</div><div>=A0</div><div>The capacity=A0check is unnecessary in this =
example and leads=A0to=A0loss of performance (code like this is likely to b=
e in a tight internal loop).=A0Furthermore, unnecessary overhead cannot be =
removed, e.g. replacing this code by</div>

<div>=A0</div><div><div>vector&lt;Widget&gt; vw(...);</div><div>for(...){</=
div><div>=A0=A0=A0 vw[...]=3D...;</div><div>}</div><div>=A0</div><div>does =
not solve the problem, as now the default constructor of Widget is called m=
any times, only for=A0the created objects to be immediately overwritten in =
the loop.</div>

<div>---------</div><div>=A0</div><div><div>Of course, the same argument wo=
rks for=A0emplace_back_(). One might also consider adding back_inserter_ to=
 further=A0exploit the new functionality, e.g.:</div><div>=A0</div></div><d=
iv>
<div>
vector&lt;Widget&gt; vw;</div><div>vw.reserve(...);</div><div>transform(...=
,back_inserter_(vw),...);</div></div><div>=A0</div><div>=A0</div></div></di=
v></blockquote></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--089e01176cf7c52a9104e6224ce1--

.

------=_Part_643_5443833.1379001994791
Content-Type: text/plain; charset=ISO-8859-1


On Wednesday, September 11, 2013 9:35:45 PM UTC+1, stackm...@hotmail.com
wrote:
>
> I'd prefer push_back_unchecked because it allows for better code
> completion.
>

This would be somewhat misleading, as one can read it, "push back an
unchecked Widget".

Victor.

--

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

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

<div dir=3D"ltr"><br>On Wednesday, September 11, 2013 9:35:45 PM UTC+1, sta=
ckm...@hotmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">I'd =
prefer push_back_unchecked because it allows for better code completion.<br=
></div></blockquote><div>&nbsp;</div><div>This would be somewhat misleading=
, as&nbsp;one can read it,&nbsp;"push back an unchecked Widget".</div><div>=
&nbsp;</div><div>Victor.</div></div>

<p></p>

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

------=_Part_643_5443833.1379001994791--

.

------=_Part_394_5010711.1379005973453
Content-Type: text/plain; charset=ISO-8859-1

Dear all,

I think it would be appropriate to provide a (somewhat biased) summary of
the discussion so far.

 * Name:

It was pointed by several posters that the original name push_back_ has no
analogs in the STL. This is a strong argument, and I'm quite happy to
change it. A couple of  alternatives were suggested, my current favourite
is unchecked_push_back suggested by Ion. Any other suggestions?

 * Performance:

The independent (from me) experiments by Howard and Magnus showed 40%
improvement over push_back. The loop code was included into the
measurments, so the "pure" performance gain of unchecked_push_back over
push_back must be higher. However, it would be difficult to disentangle it
from the optimised code, and maybe the end user would be more interested in
the performance of the whole loop anyway.

Hence the conclusion: the performance of a tight loop can be improved by
40% by replacing push_back by unchecked_push_back. Looks like a good bate!

* Alternatives to unchecked_push_back:

Several alternatives have been suggested how to improve the performance
without dragging unchecked_push_back into the standard (I tried to make a
complete list, but apologies if I missed anything).

1. Use malloc and manage memory yourself. (Ok, unique_ptr with a deleter
calling free() would simplify the task.) This is probably a solution an
average programmer would come up with.

Advantages: good performance, easy

Disadvantages: repulsive for C++ programmers, unsafe, difficult to
interface with the rest of the C++ code

2. Generating iterators suggested by Howard: use the range constructor of
vector, but give it an iterator that would compute a new Widget when
dereferenced.

Advantages: safe, uses what already exists in the library, in experiments
it peformed as well as unchecked_push_back.

Disadvantages: mixing iterators with generators; "pain to write all this
boilerplate" - to quote Howard.

In principle, the idea of a generating iterator could make a proposal of
its own, but that would require amending the standard anyway.

3.  Filling constructor: add a vector constructor accepting a generator.
Advantages: safe, potentially can peform as well as unchecked_push_back.

Disadvantages: still requires addition to the library. (Afterthought: is
this at all possible in a natural way? vector already has templated
constructors with two parameters. But still can be done somehow, e.g. with
a fake parameter.)

4.  The "assume" trick suggested by Felipe.

Advantages: simple, does not require additions to the standard

Disadvantages: no positive assurance that the optimisation is actually
applied; non-trivial for the compiler to deduce the optimisation;
non-standard extension

5. uninitialized_resize suggested by Bengt.

Advantages: simple and efficient

Disadvantages: require additions to the standard, exceedingly unsafe
(breaks vector's invariants); if fact Bengt dropped this suggestion in
favour of the next one.

6. just_set_the_end_pointer suggested by Bengt.

Advantages: simple and efficient

Disadvantages: require additions to the standard, quite unsafe (gives the
user direct write access to vector's end pointer).

7. Custom allocators suggested by several posters. The idea is, roughly, to
pass a custom allocator to a vector, such that when the vector's
constructor taking the size is called, the memory would be left
uninitialised. Then placement-new can be used to create Widgets.

Advantages: uses what already exists in the library; might achieve the same
performance as unchecked_push_back, but this was not tested.

Disadvantages: exceedingly unsafe: might call the destructor of an
uninitialised Widget, e.g. in case of an exception; might break the "usual"
invariants expected of the vector.

* Safety: When discussing safety, we should bare in mind that vector was
primeraly designed for efficiency and interface with C code [Meyers]. As
such, it has several unsafe features, such as data() returing descriptors
of internal data, unchecked operator[], the possibility of the pointer
returned by data() and iterators to become invalid (the latter are very,
very difficult to check by assertions), etc. In view of these,
unchecked_push_back looks rather benign: it has a simple pre-condition
which is easy to check by an assertion.

--

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

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

<div dir=3D"ltr"><div>Dear all,</div><div>&nbsp;</div><div>I think it would=
 be appropriate to provide&nbsp;a (somewhat biased) summary of the discussi=
on so far.</div><div>&nbsp;</div><div>&nbsp;* Name:</div><div>&nbsp;</div><=
div>It was pointed by several posters that the original name push_back_ has=
 no analogs in the STL. This is a strong argument, and I'm quite happy to c=
hange it. A couple of&nbsp; alternatives were suggested, my current favouri=
te is unchecked_push_back suggested by Ion. Any other suggestions?</div><di=
v>&nbsp;</div><div>&nbsp;* Performance:</div><div>&nbsp;</div><div>The inde=
pendent (from me) experiments by Howard and Magnus showed 40% improvement o=
ver push_back. The&nbsp;loop code was included into the measurments,&nbsp;s=
o the "pure" performance gain of unchecked_push_back over push_back must be=
 higher. However, it would be difficult to disentangle it from the optimise=
d code, and maybe the end user would be more interested in the performance =
of the whole loop anyway. </div><div>&nbsp;</div><div>Hence the conclusion:=
 the performance of a tight loop can be improved by 40% by replacing push_b=
ack by&nbsp;unchecked_push_back. Looks like a good bate!</div><div>&nbsp;</=
div><div>* Alternatives to unchecked_push_back:</div><div>&nbsp;</div><div>=
Several alternatives have been suggested how to improve the performance wit=
hout dragging unchecked_push_back into the standard (I tried to make a comp=
lete list, but apologies if I missed anything).</div><div>&nbsp;</div><div>=
1. Use malloc and manage memory yourself. (Ok, unique_ptr with a deleter ca=
lling free() would simplify the task.) This is probably a solution an avera=
ge programmer would come up with.</div><div>&nbsp;</div><div>Advantages: go=
od performance, easy</div><div>&nbsp;</div><div>Disadvantages: repulsive fo=
r C++ programmers, unsafe, difficult to interface with the rest of the C++ =
code</div><div>&nbsp;</div><div>2. Generating iterators suggested by Howard=
:&nbsp;use the range constructor of vector, but give it an iterator that wo=
uld compute a new Widget when dereferenced.</div><div>&nbsp;</div><div>Adva=
ntages: safe, uses what already exists in the library,&nbsp;in experiments =
it peformed as well as unchecked_push_back.</div><div>&nbsp;</div><div>Disa=
dvantages: mixing iterators with generators; "pain to write all this boiler=
plate" - to quote Howard.</div><div>&nbsp;</div><div>In principle, the idea=
 of a generating iterator could make a proposal of its own, but that&nbsp;w=
ould require amending the standard anyway.</div><div>&nbsp;</div><div>3.&nb=
sp; Filling constructor:&nbsp;add a vector&nbsp;constructor accepting a gen=
erator.<br></div><div><div>Advantages: safe,&nbsp;potentially can&nbsp;pefo=
rm as well as unchecked_push_back.</div><div>&nbsp;</div><div>Disadvantages=
: still requires addition to the library. (Afterthought: is this at all pos=
sible in a natural way? vector already has templated constructors with two =
parameters. But still can be done somehow, e.g. with a fake parameter.)</di=
v><div>&nbsp;</div><div>4.&nbsp; The "assume" trick&nbsp;suggested by Felip=
e.</div><div>&nbsp;</div><div>Advantages: simple, does not require addition=
s to the standard</div><div>&nbsp;</div><div>Disadvantages: no positive ass=
urance that the optimisation is actually applied; non-trivial for the compi=
ler to deduce the optimisation; non-standard extension</div><div>&nbsp;</di=
v><div>5. uninitialized_resize suggested by Bengt.</div><div>&nbsp;</div><d=
iv><div>Advantages: simple and efficient</div><div>&nbsp;</div><div>Disadva=
ntages: require additions to the standard,&nbsp;exceedingly unsafe (breaks =
vector's invariants); if fact Bengt dropped this suggestion in favour of th=
e next one.</div><div>&nbsp;</div><div>6. just_set_the_end_<wbr>pointer sug=
gested by Bengt.</div><div>&nbsp;</div><div><div>Advantages: simple and eff=
icient</div><div>&nbsp;</div><div>Disadvantages: require additions to the s=
tandard, quite unsafe (gives the user direct write access to vector's end p=
ointer).</div></div></div><div>&nbsp;</div><div><font size=3D"2">7. Custom =
allocators suggested by several posters. The idea is, roughly,&nbsp;to pass=
 a custom allocator to a vector, such that when the vector's constructor ta=
king the size is called, the memory would be left uninitialised. Then place=
ment-new can be used to create Widgets.</font></div></div><div align=3D"lef=
t">&nbsp;</div><div>Advantages: uses what already exists in the library; mi=
ght achieve the same performance as unchecked_push_back, but this was not t=
ested.</div><div>&nbsp;</div><div>Disadvantages: exceedingly unsafe: might =
call the destructor of an uninitialised Widget, e.g. in case of an exceptio=
n; might break the "usual" invariants expected of the vector.</div><div>&nb=
sp;</div><div>* Safety: When discussing safety, we should bare in mind that=
 vector was primeraly designed for efficiency and interface with C code [Me=
yers]. As such, it has several unsafe features, such as data() returing des=
criptors of internal data, unchecked operator[], the possibility of the poi=
nter returned by data() and&nbsp;iterators to become invalid (the latter&nb=
sp;are very, very difficult to check by assertions), etc. In view of these,=
 unchecked_push_back looks rather benign: it has a simple pre-condition whi=
ch is easy to check by an assertion.</div></div>

<p></p>

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

------=_Part_394_5010711.1379005973453--

.

--001a11330a00e8495704e632f951
Content-Type: text/plain; charset=ISO-8859-1

[quote]
Hence the conclusion: the performance of a tight loop can be improved by
40% by replacing push_back by unchecked_push_back. Looks like a good bate!
[/quote]
At the expense of completely destroying all of vector's safety guarantees.
It is easy to be fast if you don't have to be correct.

Note again that we have to distinguish the behavior of not checking
capacity (which was the original proposal) from not updating size. If you
are proposing the capacity check being removed, I doubt that was a
significant part of that 40%. If you are removing the size check, then
using vector without causing undefined behavior is pretty much impossible.

If you want uninitialized semantics, then the container should not be
called vector. You want something else. That is a specialized use case for
which the existing containers are not a good fit.


Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Thu, Sep 12, 2013 at 10:12 AM, <Victor.Khomenko@ncl.ac.uk> wrote:

> Dear all,
>
> I think it would be appropriate to provide a (somewhat biased) summary of
> the discussion so far.
>
>  * Name:
>
> It was pointed by several posters that the original name push_back_ has no
> analogs in the STL. This is a strong argument, and I'm quite happy to
> change it. A couple of  alternatives were suggested, my current favourite
> is unchecked_push_back suggested by Ion. Any other suggestions?
>
>  * Performance:
>
> The independent (from me) experiments by Howard and Magnus showed 40%
> improvement over push_back. The loop code was included into the
> measurments, so the "pure" performance gain of unchecked_push_back over
> push_back must be higher. However, it would be difficult to disentangle it
> from the optimised code, and maybe the end user would be more interested in
> the performance of the whole loop anyway.
>
> Hence the conclusion: the performance of a tight loop can be improved by
> 40% by replacing push_back by unchecked_push_back. Looks like a good bate!
>
> * Alternatives to unchecked_push_back:
>
> Several alternatives have been suggested how to improve the performance
> without dragging unchecked_push_back into the standard (I tried to make a
> complete list, but apologies if I missed anything).
>
> 1. Use malloc and manage memory yourself. (Ok, unique_ptr with a deleter
> calling free() would simplify the task.) This is probably a solution an
> average programmer would come up with.
>
> Advantages: good performance, easy
>
> Disadvantages: repulsive for C++ programmers, unsafe, difficult to
> interface with the rest of the C++ code
>
> 2. Generating iterators suggested by Howard: use the range constructor of
> vector, but give it an iterator that would compute a new Widget when
> dereferenced.
>
> Advantages: safe, uses what already exists in the library, in experiments
> it peformed as well as unchecked_push_back.
>
> Disadvantages: mixing iterators with generators; "pain to write all this
> boilerplate" - to quote Howard.
>
> In principle, the idea of a generating iterator could make a proposal of
> its own, but that would require amending the standard anyway.
>
> 3.  Filling constructor: add a vector constructor accepting a generator.
> Advantages: safe, potentially can peform as well as unchecked_push_back.
>
> Disadvantages: still requires addition to the library. (Afterthought: is
> this at all possible in a natural way? vector already has templated
> constructors with two parameters. But still can be done somehow, e.g. with
> a fake parameter.)
>
> 4.  The "assume" trick suggested by Felipe.
>
> Advantages: simple, does not require additions to the standard
>
> Disadvantages: no positive assurance that the optimisation is actually
> applied; non-trivial for the compiler to deduce the optimisation;
> non-standard extension
>
> 5. uninitialized_resize suggested by Bengt.
>
> Advantages: simple and efficient
>
> Disadvantages: require additions to the standard, exceedingly unsafe
> (breaks vector's invariants); if fact Bengt dropped this suggestion in
> favour of the next one.
>
> 6. just_set_the_end_**pointer suggested by Bengt.
>
> Advantages: simple and efficient
>
> Disadvantages: require additions to the standard, quite unsafe (gives the
> user direct write access to vector's end pointer).
>
> 7. Custom allocators suggested by several posters. The idea is,
> roughly, to pass a custom allocator to a vector, such that when the
> vector's constructor taking the size is called, the memory would be left
> uninitialised. Then placement-new can be used to create Widgets.
>
> Advantages: uses what already exists in the library; might achieve the
> same performance as unchecked_push_back, but this was not tested.
>
> Disadvantages: exceedingly unsafe: might call the destructor of an
> uninitialised Widget, e.g. in case of an exception; might break the "usual"
> invariants expected of the vector.
>
> * Safety: When discussing safety, we should bare in mind that vector was
> primeraly designed for efficiency and interface with C code [Meyers]. As
> such, it has several unsafe features, such as data() returing descriptors
> of internal data, unchecked operator[], the possibility of the pointer
> returned by data() and iterators to become invalid (the latter are very,
> very difficult to check by assertions), etc. In view of these,
> unchecked_push_back looks rather benign: it has a simple pre-condition
> which is easy to check by an assertion.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--001a11330a00e8495704e632f951
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>[quote]</div><div><div>Hence the conclusion: the perf=
ormance of a tight loop can be improved by 40% by replacing push_back by=A0=
unchecked_push_back. Looks like a good bate!</div><div>[/quote]</div><div>A=
t the expense of completely destroying all of vector&#39;s safety guarantee=
s. It is easy to be fast if you don&#39;t have to be correct.</div>

<div>=A0</div><div>Note again that we have to distinguish the behavior of n=
ot checking capacity (which was the original proposal) from not updating si=
ze. If you are proposing the capacity check being removed, I doubt that was=
 a significant part of that 40%. If you are removing the size check, then u=
sing vector without causing undefined behavior is pretty much impossible.</=
div>

<div>=A0</div><div>If you want uninitialized semantics, then the container =
should not be called vector. You want something else. That is a specialized=
 use case for which the=A0existing containers=A0are not a good fit.</div><d=
iv>

=A0</div></div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div=
 dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.o=
rg/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</a></div><=
div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"=
_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Thu, Sep 12, 2013 at 10:12 AM,  <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:Victor.Khomenko@ncl.ac.uk" target=3D"_bl=
ank">Victor.Khomenko@ncl.ac.uk</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div dir=3D"ltr"><div>Dear all,</div><div>=A0</div><div>I think it would be=
 appropriate to provide=A0a (somewhat biased) summary of the discussion so =
far.</div><div>=A0</div><div>=A0* Name:</div><div>=A0</div><div>It was poin=
ted by several posters that the original name push_back_ has no analogs in =
the STL. This is a strong argument, and I&#39;m quite happy to change it. A=
 couple of=A0 alternatives were suggested, my current favourite is unchecke=
d_push_back suggested by Ion. Any other suggestions?</div>

<div>=A0</div><div>=A0* Performance:</div><div>=A0</div><div>The independen=
t (from me) experiments by Howard and Magnus showed 40% improvement over pu=
sh_back. The=A0loop code was included into the measurments,=A0so the &quot;=
pure&quot; performance gain of unchecked_push_back over push_back must be h=
igher. However, it would be difficult to disentangle it from the optimised =
code, and maybe the end user would be more interested in the performance of=
 the whole loop anyway. </div>

<div>=A0</div><div>Hence the conclusion: the performance of a tight loop ca=
n be improved by 40% by replacing push_back by=A0unchecked_push_back. Looks=
 like a good bate!</div><div>=A0</div><div>* Alternatives to unchecked_push=
_back:</div>

<div>=A0</div><div>Several alternatives have been suggested how to improve =
the performance without dragging unchecked_push_back into the standard (I t=
ried to make a complete list, but apologies if I missed anything).</div>
<div>
=A0</div><div>1. Use malloc and manage memory yourself. (Ok, unique_ptr wit=
h a deleter calling free() would simplify the task.) This is probably a sol=
ution an average programmer would come up with.</div><div>=A0</div><div>Adv=
antages: good performance, easy</div>

<div>=A0</div><div>Disadvantages: repulsive for C++ programmers, unsafe, di=
fficult to interface with the rest of the C++ code</div><div>=A0</div><div>=
2. Generating iterators suggested by Howard:=A0use the range constructor of=
 vector, but give it an iterator that would compute a new Widget when deref=
erenced.</div>

<div>=A0</div><div>Advantages: safe, uses what already exists in the librar=
y,=A0in experiments it peformed as well as unchecked_push_back.</div><div>=
=A0</div><div>Disadvantages: mixing iterators with generators; &quot;pain t=
o write all this boilerplate&quot; - to quote Howard.</div>

<div>=A0</div><div>In principle, the idea of a generating iterator could ma=
ke a proposal of its own, but that=A0would require amending the standard an=
yway.</div><div>=A0</div><div>3.=A0 Filling constructor:=A0add a vector=A0c=
onstructor accepting a generator.<br>

</div><div><div>Advantages: safe,=A0potentially can=A0peform as well as unc=
hecked_push_back.</div><div>=A0</div><div>Disadvantages: still requires add=
ition to the library. (Afterthought: is this at all possible in a natural w=
ay? vector already has templated constructors with two parameters. But stil=
l can be done somehow, e.g. with a fake parameter.)</div>

<div>=A0</div><div>4.=A0 The &quot;assume&quot; trick=A0suggested by Felipe=
..</div><div>=A0</div><div>Advantages: simple, does not require additions to=
 the standard</div><div>=A0</div><div>Disadvantages: no positive assurance =
that the optimisation is actually applied; non-trivial for the compiler to =
deduce the optimisation; non-standard extension</div>

<div>=A0</div><div>5. uninitialized_resize suggested by Bengt.</div><div>=
=A0</div><div><div>Advantages: simple and efficient</div><div>=A0</div><div=
>Disadvantages: require additions to the standard,=A0exceedingly unsafe (br=
eaks vector&#39;s invariants); if fact Bengt dropped this suggestion in fav=
our of the next one.</div>

<div>=A0</div><div>6. just_set_the_end_<u></u>pointer suggested by Bengt.</=
div><div>=A0</div><div><div>Advantages: simple and efficient</div><div>=A0<=
/div><div>Disadvantages: require additions to the standard, quite unsafe (g=
ives the user direct write access to vector&#39;s end pointer).</div>

</div></div><div>=A0</div><div><font>7. Custom allocators suggested by seve=
ral posters. The idea is, roughly,=A0to pass a custom allocator to a vector=
, such that when the vector&#39;s constructor taking the size is called, th=
e memory would be left uninitialised. Then placement-new can be used to cre=
ate Widgets.</font></div>

</div><div align=3D"left">=A0</div><div>Advantages: uses what already exist=
s in the library; might achieve the same performance as unchecked_push_back=
, but this was not tested.</div><div>=A0</div><div>Disadvantages: exceeding=
ly unsafe: might call the destructor of an uninitialised Widget, e.g. in ca=
se of an exception; might break the &quot;usual&quot; invariants expected o=
f the vector.</div>

<div>=A0</div><div>* Safety: When discussing safety, we should bare in mind=
 that vector was primeraly designed for efficiency and interface with C cod=
e [Meyers]. As such, it has several unsafe features, such as data() returin=
g descriptors of internal data, unchecked operator[], the possibility of th=
e pointer returned by data() and=A0iterators to become invalid (the latter=
=A0are very, very difficult to check by assertions), etc. In view of these,=
 unchecked_push_back looks rather benign: it has a simple pre-condition whi=
ch is easy to check by an assertion.</div>

</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11330a00e8495704e632f951--

.

--047d7b62249a6dd36604e63359ed
Content-Type: text/plain; charset=ISO-8859-1

On 12 September 2013 12:21, Billy O'Neal <billy.oneal@gmail.com> wrote:

> [quote]
> Hence the conclusion: the performance of a tight loop can be improved by
> 40% by replacing push_back by unchecked_push_back. Looks like a good bate!
> [/quote]
> At the expense of completely destroying all of vector's safety guarantees.
> It is easy to be fast if you don't have to be correct.
>
> Note again that we have to distinguish the behavior of not checking
> capacity (which was the original proposal) from not updating size. If you
> are proposing the capacity check being removed, I doubt that was a
> significant part of that 40%. If you are removing the size check, then
> using vector without causing undefined behavior is pretty much impossible.
>

push_back normally does three things in the non-growing case:

1.  pointer comparison (capacity check)
2.  placement new (object construction)
3.  pointer increment (size correction)

Howard's benchmark minimized the cost of (2).  I can very easily believe if
all your code does is a pointer comparison and pointer increment, you can
get a 40% increase if you eliminate the pointer comparison.  I'm betting if
you eliminate (3) instead of (1) while still minimizing (2), you'll also
get a double digit percentage increase.

For most real uses of vector, (2) dominates, putting (1) and (3) in the
noise.

I'm sticking with my name of buffer_overrun() for this misfeature.  Please
add it (or potential_buffer_overrun(), if it makes the OP feel better) to
the list if the OP intends to go through with this proposal.


>  If you want uninitialized semantics, then the container should not be
> called vector.
>

+100.


> You want something else. That is a specialized use case for which
> the existing containers are not a good fit.
>

The motivation of needing this performance in an organization where it is
impossible to change interfaces to get that performance is unconvincing to
me.  That's a problem for the OP's company to fix and not for the standard
to address.

Oh, and (7) is about adding an allocator which does default initialization
instead of a value initialization on its object when passed no constructor
parameters.  There is nothing unsafe about doing so, and I would be
strongly in favor of adding such an allocator.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b62249a6dd36604e63359ed
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 12 September 2013 12:21, Billy O&#39;Neal <span dir=3D"=
ltr">&lt;<a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.o=
neal@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:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>[quote]</div><div><div=
><div>Hence the conclusion: the performance of a tight loop can be improved=
 by 40% by replacing push_back by=A0unchecked_push_back. Looks like a good =
bate!</div>


</div><div>[/quote]</div><div>At the expense of completely destroying all o=
f vector&#39;s safety guarantees. It is easy to be fast if you don&#39;t ha=
ve to be correct.</div>

<div>=A0</div><div>Note again that we have to distinguish the behavior of n=
ot checking capacity (which was the original proposal) from not updating si=
ze. If you are proposing the capacity check being removed, I doubt that was=
 a significant part of that 40%. If you are removing the size check, then u=
sing vector without causing undefined behavior is pretty much impossible.</=
div>


</div></div></blockquote><div><br></div><div>push_back normally does three =
things in the non-growing case:<br><br></div><div>1.=A0 pointer comparison =
(capacity check)<br></div><div>2.=A0 placement new (object construction)<br=
>


</div><div>3.=A0 pointer increment (size correction)<br><br></div><div>Howa=
rd&#39;s benchmark minimized the cost of (2).=A0 I can very easily believe =
if all your code does is a pointer comparison and pointer increment, you ca=
n get a 40% increase if you eliminate the pointer comparison.=A0 I&#39;m be=
tting if you eliminate (3) instead of (1) while still minimizing (2), you&#=
39;ll also get a double digit percentage increase.<br>


<br></div><div>For most real uses of vector, (2) dominates, putting (1) and=
 (3) in the noise.<br><br></div><div>I&#39;m sticking with my name of buffe=
r_overrun() for this misfeature.=A0 Please add it (or potential_buffer_over=
run(), if it makes the OP feel better) to the list if the OP intends to go =
through with this proposal.<br>


</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>

<div>=A0If you want uninitialized semantics, then the container should not =
be called vector. </div></div></div></blockquote><div><br>+100.<br>=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div><div>You want something else. That is a specialized u=
se case for which the=A0existing containers=A0are not a good fit.</div></di=
v></div></blockquote>
<div><br></div><div>The motivation of needing this performance in an organi=
zation where it is impossible to change interfaces to get that performance =
is unconvincing to me.=A0 That&#39;s a problem for the OP&#39;s company to =
fix and not for the standard to address.<br>

<br></div><div>Oh, and (7) is about adding an allocator which does default =
initialization instead of a value initialization on its object when passed =
no constructor parameters.=A0 There is nothing unsafe about doing so, and I=
 would be strongly in favor of adding such an allocator.<br clear=3D"all">


</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=
=3D"_blank">(847) 691-1404</a>
</div></div>

<p></p>

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

--047d7b62249a6dd36604e63359ed--

.

On Sep 12, 2013, at 1:48 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> Howard's benchmark minimized the cost of (2).

Thank you Nevin, I was beginning to wonder if anyone recalled that.

On Sep 7, 2013, at 7:45 PM, Howard Hinnant <howard.hinnant@gmail.com> wrote=
:

> I'm using the cheapest Widget I can imagine - just wraps an int.  This em=
phasizes any performance gains as much as possible.  As Widget becomes more=
 expensive to construct, the performance gains of one technique over the ot=
her will probably become negligible.

Since I'm seeing statements like:

On Sep 12, 2013, at 1:12 PM, Victor.Khomenko@ncl.ac.uk wrote:

> The independent (from me) experiments by Howard and Magnus showed 40% imp=
rovement over push_back. The loop code was included into the measurments, s=
o the "pure" performance gain of unchecked_push_back over push_back must be=
 higher.=20

I think it is time to reign in the excitement just a notch or two.  Here is=
 a very slightly modified test that puts a std::string in Widget instead of=
 an int:

#include <iostream>
#include <chrono>
#include <vector>
#include <string>

class Widget
{
    std::string data_;
public:
    explicit Widget(int data) : data_(data, '\0') {}
};

class generator_Widget
{
    int count_;
    int state_;

public:
    typedef std::input_iterator_tag iterator_category;
//    typedef std::random_access_iterator_tag iterator_category;
    typedef Widget                          value_type;
    typedef std::ptrdiff_t                  difference_type;
    typedef const Widget*                   pointer;
    typedef Widget                          reference;

    explicit generator_Widget(int count, int state =3D 0)
        : count_(count), state_(state) {}

    reference operator*() const {return Widget(state_);}
    pointer operator->() const {return nullptr;}

    generator_Widget& operator++() {++count_; --state_; return *this;}
    generator_Widget operator++(int)
        {generator_Widget tmp(*this); ++(*this); return tmp;}

    generator_Widget& operator--() {--count_; ++state_; return *this;}
    generator_Widget operator--(int)
        {generator_Widget tmp(*this); --(*this); return tmp;}

    generator_Widget& operator+=3D(difference_type n) {count_ +=3D n; state=
_ -=3D n; return *this;}
    generator_Widget operator+(difference_type n) const
        {generator_Widget tmp(*this); tmp +=3D n; return tmp;}
    friend generator_Widget operator+(difference_type n, generator_Widget x=
)
        {x +=3D n; return x;}
    generator_Widget& operator-=3D(difference_type n) {return *this +=3D -n=
;}
    generator_Widget operator-(difference_type n) const
        {generator_Widget tmp(*this); tmp -=3D n; return tmp;}

    reference operator[](difference_type n) const {return *(*this + n);}

    friend
    bool
    operator=3D=3D(const generator_Widget& x, const generator_Widget& y)
        {return x.count_ =3D=3D y.count_;}

    friend
    bool
    operator!=3D(const generator_Widget& x, const generator_Widget& y)
        {return !(x =3D=3D y);}

    friend
    bool
    operator<(const generator_Widget& x, const generator_Widget& y)
        {return x.count_ < y.count_;}

    friend
    bool
    operator>(const generator_Widget& x, const generator_Widget& y)
        {return y < x;}

    friend
    bool
    operator<=3D(const generator_Widget& x, const generator_Widget& y)
        {return !(y < x);}

    friend
    bool
    operator>=3D(const generator_Widget& x, const generator_Widget& y)
        {return !(x < y);}

    friend
    difference_type
    operator-(const generator_Widget& x, const generator_Widget& y)
        {return x.count_ - y.count_;}

};

int
main()
{
    const unsigned N =3D 100000;
    using namespace std::chrono;
    auto t0 =3D high_resolution_clock::now();
#if 1
    std::vector<Widget> v(generator_Widget(0, N), generator_Widget(N));
#else
    std::vector<Widget> v;
    int state =3D N;
    v.reserve(N);
    for (unsigned i =3D 0; i < N; ++i, --state)
        v.push_back(Widget(state));
#endif
    auto t1 =3D std::chrono::high_resolution_clock::now();
    std::cout << duration_cast<milliseconds>(t1-t0).count() << "ms\n";
}

Comparing the iterator construction technique with just doing reserve+push_=
back now gives:

$ clang++ -O3 -std=3Dc++11 test.cpp
$ a.out
1902ms
$ a.out
1955ms
$ a.out
1892ms
$ clang++ -O3 -std=3Dc++11 test.cpp
$ a.out
1944ms
$ a.out
1896ms
$ a.out
1893ms

Question:  For the above test, did I run #if 1 or #if 0 first?

Answer:  It doesn't matter.  They are the same speed.

Summary:

Under the best of circumstances, with the cheapest of Widgets, you might se=
e up to a 40% gain.  However it would not be unexpected to see no gain at a=
ll, even with just a moderately expensive Widget (e.g. contains a single st=
d::string that gets constructed beyond the short string buffer).

Howard

--=20

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

.

On Thu, 2013-09-12 at 10:12 -0700, Victor.Khomenko@ncl.ac.uk wrote:
> Dear all,
>
> I think it would be appropriate to provide a (somewhat biased) summary
> of the discussion so far.
>
>  * Name:
>
> It was pointed by several posters that the original name push_back_
> has no analogs in the STL. This is a strong argument, and I'm quite
> happy to change it. A couple of  alternatives were suggested, my
> current favourite is unchecked_push_back suggested by Ion. Any other
> suggestions?
>
>  * Performance:
>
> The independent (from me) experiments by Howard and Magnus showed 40%
> improvement over push_back. The loop code was included into the
> measurments, so the "pure" performance gain of unchecked_push_back
> over push_back must be higher. However, it would be difficult to
> disentangle it from the optimised code, and maybe the end user would
> be more interested in the performance of the whole loop anyway.
>
> Hence the conclusion: the performance of a tight loop can be improved
> by 40% by replacing push_back by unchecked_push_back. Looks like a
> good bate!

Here I should probably mention that I did some inspection of the
generated assembly and found that if one could teach the optimizer to
only store the end_ptr when it needs to expand the storage or when the
loop ends and not on each lap then the gain from unchecked_push_back is
pretty low.

I still think it would be a better idea for you to work on improving the
optimizers.

/MF

--

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

.

------=_Part_768_22014457.1379025335055
Content-Type: text/plain; charset=ISO-8859-1



On Friday, September 13, 2013 1:12:53 AM UTC+8, Victor....@ncl.ac.uk wrote:
>
>
> 7. Custom allocators suggested by several posters. The idea is,
> roughly, to pass a custom allocator to a vector, such that when the
> vector's constructor taking the size is called, the memory would be left
> uninitialised. Then placement-new can be used to create Widgets.
>

I don't think anyone suggested that, although I could be wrong.

My suggestion about custom allocators was to extend the library to allow
allocator (and sequence storage) propagation in cases where the allocator
is of different, but convertible type. This is a very general improvement,
allowing any kind of change to a container's "memory contract." For the
problem at hand, the implementation should also ensure that if
allocator::allocate cannot allocate anything (according to some criteria),
that no capacity check occurs.

You would reserve space inside the vector, then move it to a non-allocating
vector of different specialization, then everything else would be as usual
except incurring another allocation would be UB.

--

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

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

<div dir=3D"ltr"><br><br>On Friday, September 13, 2013 1:12:53 AM UTC+8, Vi=
ctor....@ncl.ac.uk 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"><br><div><font size=3D"2">7. Custom allocators suggested by sev=
eral posters. The idea is, roughly,&nbsp;to pass a custom allocator to a ve=
ctor, such that when the vector's constructor taking the size is called, th=
e memory would be left uninitialised. Then placement-new can be used to cre=
ate Widgets.</font></div></div></blockquote><div><br>I don't think anyone s=
uggested that, although I could be wrong.<br><br>My suggestion about custom=
 allocators was to extend the library to allow allocator (and sequence stor=
age) propagation in cases where the allocator is of different, but converti=
ble type. This is a very general improvement, allowing any kind of change t=
o a container's "memory contract." For the problem at hand, the implementat=
ion should also ensure that if allocator::allocate cannot allocate anything=
 (according to some criteria), that no capacity check occurs.<br><br>You wo=
uld reserve space inside the vector, then move it to a non-allocating vecto=
r of different specialization, then everything else would be as usual excep=
t incurring another allocation would be UB.<br></div></div>

<p></p>

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

------=_Part_768_22014457.1379025335055--

.

------=_Part_189_31334366.1379075506984
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, September 12, 2013 7:07:58 PM UTC+1, Howard Hinnant wrote:
>
> On Sep 12, 2013, at 1:48 PM, Nevin Liber <ne...@eviloverlord.com<javascript:>>
> wrote:
>
> > Howard's benchmark minimized the cost of (2).
>
> Thank you Nevin, I was beginning to wonder if anyone recalled that.
>

I think those who don't want to add std::vector::buffer_overrun() recalled
that your test "emphasizes any performance gains as much as possible" and
those who do want to add std::vector::buffer_overrun() recalled only the
performance gains :-)




--

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

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

<div dir=3D"ltr">On Thursday, September 12, 2013 7:07:58 PM UTC+1, Howard H=
innant wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sep 12, 2013, =
at 1:48 PM, Nevin Liber &lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"ok-7VySq5qwJ">ne...@eviloverlord.com</a>&gt; wrote:
<br>
<br>&gt; Howard's benchmark minimized the cost of (2).
<br>
<br>Thank you Nevin, I was beginning to wonder if anyone recalled that.
<br></blockquote><div><br>I think those who don't want to add std::vector::=
buffer_overrun() recalled that your test "emphasizes any performance gains =
as much as possible" and those who do want to add std::vector::buffer_overr=
un() recalled only the performance gains :-)<br><br><br>&nbsp;</div></div>

<p></p>

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

------=_Part_189_31334366.1379075506984--

.

------=_Part_1694_28903247.1379166908746
Content-Type: text/plain; charset=ISO-8859-1


On Thursday, September 12, 2013 6:21:21 PM UTC+1, Billy O'Neal wrote:
>
> [quote]
> Hence the conclusion: the performance of a tight loop can be improved by
> 40% by replacing push_back by unchecked_push_back. Looks like a good bate!
> [/quote]
> At the expense of completely destroying all of vector's safety guarantees.
> It is easy to be fast if you don't have to be correct.
>

As I wrote, the so called "vector's safety guarantees" are a bad joke if
you have data(), operator[] and iterators that can become invalid. My
argument was that unchecked_push_back is quite in line with those "safety
guarantees", maybe even on the safer side of them.



>  Note again that we have to distinguish the behavior of not checking
> capacity (which was the original proposal) from not updating size. If you
> are proposing the capacity check being removed, I doubt that was a
> significant part of that 40%. If you are removing the size check, then
> using vector without causing undefined behavior is pretty much impossible.
>
>

There is some confusion here. I never proposed removing the size update,
and 40% figure was for the original proposal. However, the compiler managed
to detect that size update was unnecessary and optimised the code. For
push_back it would be impossible or at least very difficult for the
compiler, as size update in each loop iteration would be necessary in case
the vector has to grow on the next iteration (which it won't, but the
compiler cannot work it out).



> If you want uninitialized semantics, then the container should not be
> called vector. You want something else. That is a specialized use case for
> which the existing containers are not a good fit.
>
>

I don't want uninitialized semantics.


--

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

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

<div dir=3D"ltr"><br>On Thursday, September 12, 2013 6:21:21 PM UTC+1, Bill=
y O'Neal wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>[quote]</=
div><div><div>Hence the conclusion: the performance of a tight loop can be =
improved by 40% by replacing push_back by&nbsp;unchecked_push_back. Looks l=
ike a good bate!</div><div>[/quote]</div><div>At the expense of completely =
destroying all of vector's safety guarantees. It is easy to be fast if you =
don't have to be correct.</div>

<div></div></div></div></blockquote><div>&nbsp;</div><div>As I wrote, the s=
o called "vector's safety guarantees" are a bad joke if you have data(), op=
erator[] and iterators that can become invalid. My argument was that unchec=
ked_push_back is quite in line with those "safety guarantees", maybe even o=
n the safer side of them.</div><div>&nbsp;</div><div>&nbsp;</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1=
ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-l=
eft-style: solid;"><div dir=3D"ltr"><div><div>&nbsp;Note again that we have=
 to distinguish the behavior of not checking capacity (which was the origin=
al proposal) from not updating size. If you are proposing the capacity chec=
k being removed, I doubt that was a significant part of that 40%. If you ar=
e removing the size check, then using vector without causing undefined beha=
vior is pretty much impossible.</div>

<div>&nbsp;</div></div></div></blockquote><div>&nbsp;</div><div>There is so=
me confusion here. I never proposed removing the size update, and 40% figur=
e was for the original proposal. However, the compiler managed to detect th=
at size update was unnecessary and optimised the code. For push_back it wou=
ld be impossible or at least very difficult for the compiler, as size updat=
e in each loop iteration would be necessary in case the vector has to grow =
on the next iteration (which it won't, but the compiler cannot work it out)=
.. </div><div>&nbsp;</div><div>&nbsp;</div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: =
rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div=
 dir=3D"ltr"><div><div>If you want uninitialized semantics, then the contai=
ner should not be called vector. You want something else. That is a special=
ized use case for which the&nbsp;existing containers&nbsp;are not a good fi=
t.</div><div>

&nbsp;</div></div></div></blockquote><div>&nbsp;</div><div>I don't want uni=
nitialized semantics.</div><div>&nbsp;</div></div>

<p></p>

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

------=_Part_1694_28903247.1379166908746--

.

------=_Part_100_12099445.1379167255900
Content-Type: text/plain; charset=ISO-8859-1


On Thursday, September 12, 2013 6:48:03 PM UTC+1, Nevin ":-)" Liber wrote:
>
>
> Oh, and (7) is about adding an allocator which does default initialization
> instead of a value initialization on its object when passed no constructor
> parameters.  There is nothing unsafe about doing so, and I would be
> strongly in favor of adding such an allocator.
>

It would be unsafe if Widget has non-trivial destructor. E.g. it can wrap a
pointer, which should be initialised to nullptr. If left uninitialised
and ~Widget deletes it, you have undefined behaviour.

--

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

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

<div dir=3D"ltr"><br>On Thursday, September 12, 2013 6:48:03 PM UTC+1, Nevi=
n ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div=
 class=3D"gmail_quote"><div>&nbsp;</div><div>Oh, and (7) is about adding an=
 allocator which does default initialization instead of a value initializat=
ion on its object when passed no constructor parameters.&nbsp; There is not=
hing unsafe about doing so, and I would be strongly in favor of adding such=
 an allocator.<br clear=3D"all">


</div></div></div></div></blockquote><div>&nbsp;</div><div>It would be unsa=
fe if Widget has non-trivial destructor. E.g. it can wrap a pointer, which&=
nbsp;should&nbsp;be initialised to nullptr. If left uninitialised and&nbsp;=
~Widget deletes it, you have undefined behaviour.</div></div>

<p></p>

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

------=_Part_100_12099445.1379167255900--

.

------=_Part_65_17079983.1379167786168
Content-Type: text/plain; charset=ISO-8859-1


On Thursday, September 12, 2013 7:07:58 PM UTC+1, Howard Hinnant wrote:
>
>
> I think it is time to reign in the excitement just a notch or two.  Here
> is a very slightly modified test that puts a std::string in Widget instead
> of an int:
> [...]
>     explicit Widget(int data) : data_(data, '\0') {}
>

This creates a new loop nested in the one we are trying to optimise, and
the total work grows from O(n) to O(n^2). Very slight modification indeed!



> Under the best of circumstances, with the cheapest of Widgets, you might
> see up to a 40% gain.  However it would not be unexpected to see no gain at
> all, even with just a moderately expensive Widget (e.g. contains a single
> std::string that gets constructed beyond the short string buffer).
>

Sure, as push_back is no longer in the innermost loop.

In any case, I agee that the intended use cases are when Widgets are small,
e.g. wrap int or pointer.

--

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

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

<div dir=3D"ltr"><br>On Thursday, September 12, 2013 7:07:58 PM UTC+1, Howa=
rd Hinnant wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><br>I think it is time to rei=
gn in the excitement just a notch or two. &nbsp;Here is a very slightly mod=
ified test that puts a std::string in Widget instead of an int:
<br>
[...]<br>&nbsp;&nbsp;&nbsp; explicit Widget(int data) : data_(data, '\0') {=
}
<br></blockquote><div>&nbsp;</div><div>This&nbsp;creates a new loop nested =
in the one we are trying to optimise, and the total work&nbsp;grows from O(=
n) to O(n^2). Very slight modification indeed!</div><div>&nbsp;</div><div>&=
nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;">Under the best of circumstances, wi=
th the cheapest of Widgets, you might see up to a 40% gain. &nbsp;However i=
t would not be unexpected to see no gain at all, even with just a moderatel=
y expensive Widget (e.g. contains a single std::string that gets constructe=
d beyond the short string buffer).
<br></blockquote><div>&nbsp;</div><div>Sure, as&nbsp;push_back is no longer=
 in the innermost loop.</div><div>&nbsp;</div><div>In any case, I agee that=
 the intended use cases are when&nbsp;Widgets are small, e.g. wrap int or p=
ointer.&nbsp; </div></div>

<p></p>

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

------=_Part_65_17079983.1379167786168--

.

------=_Part_71_23914592.1379168149393
Content-Type: text/plain; charset=ISO-8859-1


On Thursday, September 12, 2013 7:39:37 PM UTC+1, Magnus Fromreide wrote:
>
> Here I should probably mention that I did some inspection of the
> generated assembly and found that if one could teach the optimizer to
> only store the end_ptr when it needs to expand the storage or when the
> loop ends and not on each lap then the gain from unchecked_push_back is
> pretty low.
>


In the case of push_back, you cannot eliminate that nasty store from the
loop, as grow() needs it to be set properly. What one can do is to put it
to the other branch of "if". However, it is difficult to do for the
compiler, as it needs to work out that this other branch is rarely/never
used, i.e. in effect it should be clever enough to work out that push_back
can be replaced by unchecked_push_back. Ok, in some situations the
compiler can be just lucky or use profile-guided optimisation.

--

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

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

<div dir=3D"ltr"><br>On Thursday, September 12, 2013 7:39:37 PM UTC+1, Magn=
us Fromreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">Here I should probably ment=
ion that I did some inspection of the
<br>generated assembly and found that if one could teach the optimizer to
<br>only store the end_ptr when it needs to expand the storage or when the
<br>loop ends and not on each lap then the gain from unchecked_push_back is
<br>pretty low.
<br>
&nbsp;</blockquote><div>&nbsp;</div><div>In the case of push_back, you cann=
ot eliminate that nasty store from the loop, as grow() needs it to be set p=
roperly. What&nbsp;one can&nbsp;do is to put it to the other branch of "if"=
.. However, it is difficult to do for the compiler, as it needs to work out =
that this other branch is rarely/never used, i.e. in&nbsp;effect it should =
be clever enough to work out that push_back can be replaced by&nbsp;uncheck=
ed_push_back. Ok, in some situations&nbsp;the compiler&nbsp;can be just luc=
ky or use profile-guided optimisation.</div></div>

<p></p>

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

------=_Part_71_23914592.1379168149393--

.

------=_Part_1624_22106.1379168342306
Content-Type: text/plain; charset=ISO-8859-1


On Thursday, September 12, 2013 11:35:35 PM UTC+1, David Krauss wrote:
>
>
> I don't think anyone suggested that, although I could be wrong.
>

Howard did.


> My suggestion about custom allocators was to extend the library to allow
> allocator (and sequence storage) propagation in cases where the allocator
> is of different, but convertible type. This is a very general improvement,
> allowing any kind of change to a container's "memory contract." For the
> problem at hand, the implementation should also ensure that if
> allocator::allocate cannot allocate anything (according to some criteria),
> that no capacity check occurs.
>
> You would reserve space inside the vector, then move it to a
> non-allocating vector of different specialization, then everything else
> would be as usual except incurring another allocation would be UB.
>

Apologies, this is quite a different idea and should have been included
into the list. It is much safer, but will be a breaking change, e.g. the
stateless allocators can no longer be optimised out.


--

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

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

<div dir=3D"ltr"><br>On Thursday, September 12, 2013 11:35:35 PM UTC+1, Dav=
id Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br>I don't t=
hink anyone suggested that, although I could be wrong.<br></div></blockquot=
e><div>&nbsp;</div><div>Howard did.</div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div dir=3D"ltr">My suggestion about custom allocators was to e=
xtend the library to allow allocator (and sequence storage) propagation in =
cases where the allocator is of different, but convertible type. This is a =
very general improvement, allowing any kind of change to a container's "mem=
ory contract." For the problem at hand, the implementation should also ensu=
re that if allocator::allocate cannot allocate anything (according to some =
criteria), that no capacity check occurs.<br><br>You would reserve space in=
side the vector, then move it to a non-allocating vector of different speci=
alization, then everything else would be as usual except incurring another =
allocation would be UB.<br></div></blockquote><div>&nbsp;</div><div>Apologi=
es, this is quite a different idea and should have been included into the l=
ist. It is much safer, but will be a breaking change, e.g. the stateless al=
locators can no longer be optimised out.</div><div>&nbsp;</div></div>

<p></p>

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

------=_Part_1624_22106.1379168342306--

.

------=_Part_1722_18309811.1379168423444
Content-Type: text/plain; charset=ISO-8859-1


On Friday, September 13, 2013 1:31:46 PM UTC+1, Jonathan Wakely wrote:
>
>
> I think those who don't want to add std::vector::buffer_overrun() recalled
> that your test "emphasizes any performance gains as much as possible" and
> those who do want to add std::vector::buffer_overrun() recalled only the
> performance gains :-)
>

What a surprise! :-)

--

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

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

<div dir=3D"ltr"><br>On Friday, September 13, 2013 1:31:46 PM UTC+1, Jonath=
an Wakely wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br>I th=
ink those who don't want to add std::vector::buffer_overrun() recalled that=
 your test "emphasizes any performance gains as much as possible" and those=
 who do want to add std::vector::buffer_overrun() recalled only the perform=
ance gains :-)<br></div></div></blockquote><div>&nbsp;</div><div>What a sur=
prise! :-)&nbsp;</div></div>

<p></p>

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

------=_Part_1722_18309811.1379168423444--

.

------=_Part_1629_5555687.1379168976984
Content-Type: text/plain; charset=ISO-8859-1


On Thursday, September 12, 2013 6:48:03 PM UTC+1, Nevin ":-)" Liber wrote:
>
>
> Please add it (or potential_buffer_overrun(), if it makes the OP feel
> better) to the list if the OP intends to go through with this proposal.
>

At the moment I don't see enought support here, so no intention to make a
formal proposal. This might change if there is a sudden surge of support.

--

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

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

<div dir=3D"ltr"><br>On Thursday, September 12, 2013 6:48:03 PM UTC+1, Nevi=
n ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div=
 class=3D"gmail_quote"><div><br>Please add it (or potential_buffer_overrun(=
), if it makes the OP feel better) to the list if the OP intends to go thro=
ugh with this proposal.<br>


</div></div></div></div></blockquote><div>&nbsp;</div><div>At the moment&nb=
sp;I don't see enought support here, so no intention&nbsp;to&nbsp;make a fo=
rmal proposal. This might change if there is a&nbsp;sudden&nbsp;surge of su=
pport.</div></div>

<p></p>

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

------=_Part_1629_5555687.1379168976984--

.

------=_Part_255_26660215.1379183214678
Content-Type: text/plain; charset=ISO-8859-1



On Saturday, September 14, 2013 3:55:08 PM UTC+2, Victor....@ncl.ac.uk
wrote:
>
>
> On Thursday, September 12, 2013 6:21:21 PM UTC+1, Billy O'Neal wrote:
>>
>> [quote]
>> Hence the conclusion: the performance of a tight loop can be improved by
>> 40% by replacing push_back by unchecked_push_back. Looks like a good bate!
>> [/quote]
>> At the expense of completely destroying all of vector's safety
>> guarantees. It is easy to be fast if you don't have to be correct.
>>
>
> As I wrote, the so called "vector's safety guarantees" are a bad joke if
> you have data(), operator[] and iterators that can become invalid. My
> argument was that unchecked_push_back is quite in line with those "safety
> guarantees", maybe even on the safer side of them.
>
>
 Is bit difference between making some pointer and iterators invalid and
permanently breaking vector. every exception during `unchecked_push_back`
will break program.

--

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

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

<div dir=3D"ltr"><br><br>On Saturday, September 14, 2013 3:55:08 PM UTC+2, =
Victor....@ncl.ac.uk wrote:<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"><br>On Thursday, September 12, 2013 6:21:21 PM UTC+1, Billy O=
'Neal wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:=
1px;border-left-style:solid"><div dir=3D"ltr"><div>[quote]</div><div><div>H=
ence the conclusion: the performance of a tight loop can be improved by 40%=
 by replacing push_back by&nbsp;unchecked_push_back. Looks like a good bate=
!</div><div>[/quote]</div><div>At the expense of completely destroying all =
of vector's safety guarantees. It is easy to be fast if you don't have to b=
e correct.</div>

<div></div></div></div></blockquote><div>&nbsp;</div><div>As I wrote, the s=
o called "vector's safety guarantees" are a bad joke if you have data(), op=
erator[] and iterators that can become invalid. My argument was that unchec=
ked_push_back is quite in line with those "safety guarantees", maybe even o=
n the safer side of them.</div><div>&nbsp;</div></div></blockquote><div>&nb=
sp;Is bit difference between making some pointer and iterators invalid and =
permanently breaking vector. every exception during `unchecked_push_back` w=
ill break program.<br></div></div>

<p></p>

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

------=_Part_255_26660215.1379183214678--

.

------=_Part_1747_7281775.1379186677507
Content-Type: text/plain; charset=ISO-8859-1


On Saturday, September 14, 2013 7:26:54 PM UTC+1, inkwizyt...@gmail.com
wrote:
>
>
>>
>  Is bit difference between making some pointer and iterators invalid and
> permanently breaking vector. every exception during `unchecked_push_back`
> will break program.
>

This is just not true. (If it were, push_back would also be broken.)

--

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

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

<div dir=3D"ltr"><br>On Saturday, September 14, 2013 7:26:54 PM UTC+1, inkw=
izyt...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-le=
ft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bor=
der-left-style: solid;"><div dir=3D"ltr"><div>&nbsp;</div></div></blockquot=
e><div>&nbsp;Is bit difference between making some pointer and iterators in=
valid and permanently breaking vector. every exception during `unchecked_pu=
sh_back` will break program.<br></div></div></blockquote><div>&nbsp;</div><=
div>This is just not true.&nbsp;(If it were,&nbsp;push_back would also be b=
roken.)</div></div>

<p></p>

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

------=_Part_1747_7281775.1379186677507--

.

------=_Part_1799_19865305.1379188515972
Content-Type: text/plain; charset=ISO-8859-1



On Saturday, September 14, 2013 9:24:37 PM UTC+2, Victor....@ncl.ac.uk
wrote:
>
>
> On Saturday, September 14, 2013 7:26:54 PM UTC+1, inkwizyt...@gmail.comwrote:
>>
>>
>>>
>>  Is bit difference between making some pointer and iterators invalid and
>> permanently breaking vector. every exception during `unchecked_push_back`
>> will break program.
>>
>
> This is just not true. (If it were, push_back would also be broken.)
>
Right, I mix it with `uninitialized_resize()` that have that property
(Billy O'Neal probably said this about `uninitialized_resize()` too).

--

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

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

<div dir=3D"ltr"><br><br>On Saturday, September 14, 2013 9:24:37 PM UTC+2, =
Victor....@ncl.ac.uk wrote:<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"><br>On Saturday, September 14, 2013 7:26:54 PM UTC+1, <a>inkw=
izyt...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bo=
rder-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bor=
der-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:sol=
id"><div dir=3D"ltr"><div>&nbsp;</div></div></blockquote><div>&nbsp;Is bit =
difference between making some pointer and iterators invalid and permanentl=
y breaking vector. every exception during `unchecked_push_back` will break =
program.<br></div></div></blockquote><div>&nbsp;</div><div>This is just not=
 true.&nbsp;(If it were,&nbsp;push_back would also be broken.)</div></div><=
/blockquote><div>Right, I mix it with `uninitialized_resize()` that have th=
at property (Billy O'Neal probably said this about `uninitialized_resize()`=
 too).<br><br></div></div>

<p></p>

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

------=_Part_1799_19865305.1379188515972--

.

------=_Part_46_19452948.1379263978889
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This discussion is being muddled by the fact that two suggestions with=20
different goals are mixed. I admit to being the culprit here as I thought=
=20
that the push_back_ suggestion was a subset of the uninitialized_resize()=
=20
suggestion I had. In fact, due to the destruction at exception issue the=20
issues are basically separate.

1. The original issue, which is for types that have a destructor which must=
=20
be run in the case of an unwind.

Here typically complex objects are moved or copied to the vector and the=20
test for the resize is probably negligable. In many cases the introduction=
=20
of emplace_back as a complement to push_back() in C++11 has a much higher=
=20
potential for speed up.

2. My other issue which is for filling vectors which initially act as=20
buffers for some legacy function etc.

My initial suggestion uninitialized_resize() does the job but is dangeous=
=20
if applied to types with a destructor. Later a suggestion to add a "tag" to=
=20
the sizing constructor to instruct the allocator to use default=20
construction instead of value construction solved this problem as there is=
=20
no difference between these constructions except for the basic types and=20
pointers. In complement with this constructor there would also naturally=20
exist a resize() overload taking the same tag.

Note that this is now safe as only types without a destructor get an=20
uninitialized construction:

struct default_construct_t {
} default_construct;

vector::vector(size_t sz, default_construct_t);
vector::resize(size_t sz, default_construct_t);



Den l=F6rdagen den 14:e september 2013 kl. 21:55:15 UTC+2 skrev=20
inkwizyt...@gmail.com:
>
>
>
> On Saturday, September 14, 2013 9:24:37 PM UTC+2, Victor....@ncl.ac.ukwro=
te:
>>
>>
>> On Saturday, September 14, 2013 7:26:54 PM UTC+1, inkwizyt...@gmail.comw=
rote:
>>>
>>> =20
>>>>
>>>  Is bit difference between making some pointer and iterators invalid an=
d=20
>>> permanently breaking vector. every exception during `unchecked_push_bac=
k`=20
>>> will break program.
>>>
>> =20
>> This is just not true. (If it were, push_back would also be broken.)
>>
> Right, I mix it with `uninitialized_resize()` that have that property=20
> (Billy O'Neal probably said this about `uninitialized_resize()` too).
>
>

--=20

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

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

<div dir=3D"ltr">This discussion is being muddled by the fact that two sugg=
estions with different goals are mixed. I admit to being the culprit here a=
s I thought that the push_back_ suggestion was a subset of the uninitialize=
d_resize() suggestion I had. In fact, due to the destruction at exception i=
ssue the issues are basically separate.<div><br></div><div>1. The original =
issue, which is for types that have a destructor which must be run in the c=
ase of an unwind.</div><div><br></div><div>Here typically complex objects a=
re moved or copied to the vector and the test for the resize is probably ne=
gligable. In many cases the introduction of emplace_back as a complement to=
 push_back() in C++11 has a much higher potential for speed up.</div><div><=
br></div><div>2. My other issue which is for filling vectors which initiall=
y act as buffers for some legacy function etc.</div><div><br></div><div>My =
initial suggestion uninitialized_resize() does the job but is dangeous if a=
pplied to types with a destructor. Later a suggestion to add a "tag" to the=
 sizing constructor to instruct the allocator to use default construction i=
nstead of value construction solved this problem as there is no difference =
between these constructions except for the basic types and pointers. In com=
plement with this constructor there would also naturally exist a resize() o=
verload taking the same tag.</div><div><br></div><div>Note that this is now=
 safe as only types without a destructor get an uninitialized construction:=
</div><div><br></div><div>struct default_construct_t {</div><div>} default_=
construct;</div><div><br></div><div>vector::vector(size_t sz, default_const=
ruct_t);<br>vector::resize(size_t sz, default_construct_t);</div><div><br><=
/div><div><br><br>Den l=F6rdagen den 14:e september 2013 kl. 21:55:15 UTC+2=
 skrev inkwizyt...@gmail.com:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><br><br>On Saturday, September 14, 2013 9:24:37 PM UTC+2, <=
a>Victor....@ncl.ac.uk</a> wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><br>On Saturday, September 14, 2013 7:26:54 PM UTC+1, <a>ink=
wizyt...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);b=
order-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bo=
rder-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:so=
lid"><div dir=3D"ltr"><div>&nbsp;</div></div></blockquote><div>&nbsp;Is bit=
 difference between making some pointer and iterators invalid and permanent=
ly breaking vector. every exception during `unchecked_push_back` will break=
 program.<br></div></div></blockquote><div>&nbsp;</div><div>This is just no=
t true.&nbsp;(If it were,&nbsp;push_back would also be broken.)</div></div>=
</blockquote><div>Right, I mix it with `uninitialized_resize()` that have t=
hat property (Billy O'Neal probably said this about `uninitialized_resize()=
` too).<br><br></div></div></blockquote></div></div>

<p></p>

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

------=_Part_46_19452948.1379263978889--

.

--001a11c2e7c6ef262604e6705e9b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 15 September 2013 11:52, Bengt Gustafsson
<bengt.gustafsson@beamways.com>wrote:

>
> 2. My other issue which is for filling vectors which initially act as
> buffers for some legacy function etc.
>

I've addressed this.  Twice.  Here goes a third time:

It can be done safely today (and heck, even in C++03) by writing an
allocator which does a default initialization instead of value
initialization when calling construct() (with no parameters).  Ion
Gazta=F1aga stated it was hard to write such an allocator; but that has not
been my experience in C++11.  He has yet to respond as to why he finds
writing such an allocator difficult (I'd like to know, as that difficulty
may be something the standard should address).

To go further, I'd be strongly in favor of adding such an allocator to the
standard, were someone to propose it.  Unlike the other proposals, this is
just an additional independent library and does not require modification of
containers or allocators to implement.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

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

--001a11c2e7c6ef262604e6705e9b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 15 September 2013 11:52, Ben=
gt Gustafsson <span dir=3D"ltr">&lt;<a href=3D"mailto:bengt.gustafsson@beam=
ways.com" target=3D"_blank">bengt.gustafsson@beamways.com</a>&gt;</span> wr=
ote:<br>

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">

<div dir=3D"ltr"><br></div></blockquote><blockquote class=3D"gmail_quote" s=
tyle=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex=
;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style=
:solid;padding-left:1ex">

<div dir=3D"ltr"><div>2. My other issue which is for filling vectors which =
initially act as buffers for some legacy function etc.<br></div></div></blo=
ckquote><div><br></div><div>I&#39;ve addressed this. =A0Twice. =A0Here goes=
 a third time:</div>

<div><br></div><div>It can be done safely today (and heck, even in C++03) b=
y writing an allocator which does a default initialization instead of value=
 initialization when calling construct() (with no parameters). =A0<span cla=
ss=3D"" style=3D"border-collapse:collapse;color:rgb(80,0,80);font-family:ar=
ial,sans-serif;font-size:13px">Ion Gazta=F1aga=A0</span>stated it was hard =
to write such an allocator; but that has not been my experience in C++11. =
=A0He has yet to respond as to why he finds writing such an allocator diffi=
cult (I&#39;d like to know, as that difficulty may be something the standar=
d should address).</div>

<div><br></div><div>To go further, I&#39;d be strongly in favor of adding s=
uch an allocator to the standard, were someone to propose it. =A0Unlike the=
 other proposals, this is just an additional independent library and does n=
ot require modification of containers or allocators to implement.</div>

</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 (847) 691-1404
</div></div>

<p></p>

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

--001a11c2e7c6ef262604e6705e9b--

.

------=_Part_378_30149301.1379278628468
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I can't see that a special allocator solves the problem, as vectors with=20
different allocators are different types. Even with the invention of  some=
=20
sort of assignable allocator suggested earlier in this thread and=20
provisions in all classes that use allocators so that you can move and swap=
=20
the vector with the special allocator with a vector with the standard=20
allocator it results in rather convoluted code compared to an extra ctor=20
parameter or special resize method.=20

A problem with the assignable allocator solution is that it uses allocators=
=20
to differentiate something that is completely different from setting a=20
policy on from where memory is allocated, which is what allocators are=20
designed for. With assignable allocators the writer of the new allocator=20
class is promising that as these allocators can be assigned to each other=
=20
they are equivalent when it comes to doing their work,=20
allocation/deallocation, and the only difference is that they do something=
=20
else, i.e. construction, in different ways. To me this is not a very clean=
=20
design. Also the amount of changes in the standard is much larger as all=20
users of allocators are affected (to implement the actual assignment/copy=
=20
construction which must now be templated on the allocator type).  Each new =
allocation=20
scheme will now need a parallel non_initializing_allocator class for=20
orthogonality.=20

Alternatively an allocator could have a bool member which is inpected in=20
each construct to see if value or default construction is required. Maybe=
=20
easier but now construct() performance is reduced which does not sit well=
=20
with this performance directed improvement, and it is still not the default=
=20
allocator. Each construction of the vector needs to get a parameter which=
=20
is a an allocator constructed with true or false value. This value can't be=
=20
changed between allocations as you can't get a non-const reference to the=
=20
allocator from the vector, only a copy. Even if you could it would not be=
=20
very safe as you need to set/reset the flag between calls.

The counter argument will be that "then change all those vectors to be=20
vectors with the special allocator". This is bad design as now all uses of=
=20
this vector, which is typically a class member, are changed. What is needed=
=20
is a per-site possibility to define if zero initiation is to be done, even=
=20
if the data member is the same. A resize_default_constructed() is a quite=
=20
nice solution to this problem as it does not need a special tag class and=
=20
it doesn't compromize safety for classes with non-trivial destructors. The=
=20
only drawback I can see is that it needs a new default_construct() method=
=20
on the allocator, but this method is of course needed only if the method is=
=20
called, i.e. almost only on the default allocator type.

Note the difference from the previously suggested uninitialized_resize(),=
=20
in that this method calls the default constructor for the elements. It so=
=20
happens that the default constructor for basic types and pointers do=20
nothing and so the entire loop containing the placement new and=20
incrementing the index etc. will very likely be optimized away. Not so for=
=20
non-pod types, where it works exactly as the normal resize, as default and=
=20
value construction are the same.

Example:

templat<typename T, ...> class allocator {
    void default_construct(void* at) { new(at) T; }
};
template<...> class vector {
    ...
    void resize_default_constructed(size_t newsize);
};

// Fill data from a socket without clearing the bytes first.
vector<char> myBuffer;
myBuffer.resize_default_constructed(1000);
socket.read(myBuffer.data(), 1000);


Not being able to construct the vector directly with a specified number of=
=20
default constructed members is a minor annoyance, which I don't think=20
warrants the tag-class trick previously suggested.

Den s=F6ndagen den 15:e september 2013 kl. 20:36:10 UTC+2 skrev Nevin ":-)"=
=20
Liber:
>
> On 15 September 2013 11:52, Bengt Gustafsson <bengt.gu...@beamways.com<ja=
vascript:>
> > wrote:
>
>>
>> 2. My other issue which is for filling vectors which initially act as=20
>> buffers for some legacy function etc.
>>
>
> I've addressed this.  Twice.  Here goes a third time:
>
> It can be done safely today (and heck, even in C++03) by writing an=20
> allocator which does a default initialization instead of value=20
> initialization when calling construct() (with no parameters).  Ion=20
> Gazta=F1aga stated it was hard to write such an allocator; but that has n=
ot=20
> been my experience in C++11.  He has yet to respond as to why he finds=20
> writing such an allocator difficult (I'd like to know, as that difficulty=
=20
> may be something the standard should address).
>
> To go further, I'd be strongly in favor of adding such an allocator to th=
e=20
> standard, were someone to propose it.  Unlike the other proposals, this i=
s=20
> just an additional independent library and does not require modification =
of=20
> containers or allocators to implement.
> --=20
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)=
=20
> 691-1404=20
>

--=20

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

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

<div dir=3D"ltr">I can't see that a special allocator solves the problem, a=
s vectors with different allocators are different types. Even with the inve=
ntion of &nbsp;some sort of assignable allocator suggested earlier in this =
thread and provisions in all classes that use allocators so that you can mo=
ve and swap the vector with the special allocator with a vector with the st=
andard allocator it results in rather convoluted code compared to an extra =
ctor parameter or special resize method.&nbsp;<div><br></div><div>A problem=
 with the assignable allocator solution is that it uses allocators to diffe=
rentiate something that is completely different from setting a policy on fr=
om where memory is allocated, which is what allocators are designed for. Wi=
th assignable allocators the writer of the new allocator class is promising=
 that as these allocators can be assigned to each other they are equivalent=
 when it comes to doing their work, allocation/deallocation, and the only d=
ifference is that they do something else, i.e. construction, in different w=
ays. To me this is not a very clean design. Also the amount of changes in t=
he standard is much larger as all users of allocators are affected (to impl=
ement the actual assignment/copy construction which must now be templated o=
n the allocator type).&nbsp;<span style=3D"font-size: 13px;">&nbsp;</span><=
span style=3D"font-size: 13px;">Each new&nbsp;</span><span style=3D"font-si=
ze: 13px;">allocation scheme will now need a parallel non_initializing_allo=
cator class for orthogonality.&nbsp;</span></div><div><span style=3D"font-s=
ize: 13px;"><br></span></div><div><span style=3D"font-size: 13px;">Alternat=
ively an allocator could have a bool member which is inpected in each const=
ruct to see if value or default construction is required. Maybe easier but =
now construct() performance is reduced which does not sit well with this pe=
rformance directed improvement, and it is still not the default allocator. =
Each construction of the vector needs to get a parameter which is a an allo=
cator constructed with true or false value. This value can't be changed bet=
ween allocations as you can't get a non-const reference to the allocator fr=
om the vector, only a copy. Even if you could it would not be very safe as =
you need to set/reset the flag between calls.</span></div><div><div><br></d=
iv><div>The counter argument will be that "then change all those vectors to=
 be vectors with the special allocator". This is bad design as now all uses=
 of this vector, which is typically a class member, are changed. What is ne=
eded is a per-site possibility to define if zero initiation is to be done, =
even if the data member is the same. A resize_<span style=3D"font-size: 13p=
x;">default_constructed</span><span style=3D"font-size: 13px;">() is a quit=
e nice solution to this problem as it does not need a special tag class and=
 it doesn't compromize safety for classes with non-trivial destructors. The=
 only drawback I can see is that it needs a new default_construct() method =
on the allocator, but this method is of course needed only if the method is=
 called, i.e. almost only on the default allocator type.</span></div><div><=
br></div><div>Note the difference from the previously suggested uninitializ=
ed_resize(), in that this method calls the default constructor for the elem=
ents. It so happens that the default constructor for basic types and pointe=
rs do nothing and so the entire loop containing the placement new and incre=
menting the index etc. will very likely be optimized away. Not so for non-p=
od types, where it works exactly as the normal resize, as default and value=
 construction are the same.</div><div><br></div><div>Example:</div><div><br=
></div><div>templat&lt;typename T, ...&gt; class allocator {</div><div>&nbs=
p; &nbsp; void default_construct(void* at) { new(at) T; }</div><div>};</div=
><div>template&lt;...&gt; class vector {</div><div>&nbsp; &nbsp; ...</div><=
div>&nbsp; &nbsp; void resize_default_constructed(size_t newsize);</div><di=
v>};</div><div><br></div><div>// Fill data from a socket without clearing t=
he bytes first.</div><div>vector&lt;char&gt; myBuffer;</div><div>myBuffer.r=
esize_default_constructed(1000);</div><div>socket.read(myBuffer.data(), 100=
0);</div><div><br></div><div><br></div><div>Not being able to construct the=
 vector directly with a specified number of default constructed members is =
a minor annoyance, which I don't think warrants the tag-class trick previou=
sly suggested.<br><br>Den s=F6ndagen den 15:e september 2013 kl. 20:36:10 U=
TC+2 skrev Nevin ":-)" Liber:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div>On 15 September 2013 11:52, Bengt Gustafsson <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"xNvWRiGZgBoJ">bengt.gu...@beamways.com</a><wbr>&gt;</span> wrote:<br>

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">

<div dir=3D"ltr"><br></div></blockquote><blockquote class=3D"gmail_quote" s=
tyle=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex=
;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style=
:solid;padding-left:1ex">

<div dir=3D"ltr"><div>2. My other issue which is for filling vectors which =
initially act as buffers for some legacy function etc.<br></div></div></blo=
ckquote><div><br></div><div>I've addressed this. &nbsp;Twice. &nbsp;Here go=
es a third time:</div>

<div><br></div><div>It can be done safely today (and heck, even in C++03) b=
y writing an allocator which does a default initialization instead of value=
 initialization when calling construct() (with no parameters). &nbsp;<span =
style=3D"border-collapse:collapse;color:rgb(80,0,80);font-family:arial,sans=
-serif;font-size:13px">Ion Gazta=F1aga&nbsp;</span>stated it was hard to wr=
ite such an allocator; but that has not been my experience in C++11. &nbsp;=
He has yet to respond as to why he finds writing such an allocator difficul=
t (I'd like to know, as that difficulty may be something the standard shoul=
d address).</div>

<div><br></div><div>To go further, I'd be strongly in favor of adding such =
an allocator to the standard, were someone to propose it. &nbsp;Unlike the =
other proposals, this is just an additional independent library and does no=
t require modification of containers or allocators to implement.</div>

</div>-- <br>&nbsp;Nevin ":-)" Liber&nbsp; &lt;mailto:<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"xNvWRiGZgBoJ">ne...@eviloverl=
ord.com</a><wbr>&gt;&nbsp; (847) 691-1404
</div></div>
</blockquote></div></div></div>

<p></p>

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

------=_Part_378_30149301.1379278628468--

.

--089e01183066dc977a04e6727fc7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

[quote]
I can't see that a special allocator solves the problem, as vectors with
different allocators are different types.
[/quote]
I see this as a *good* thing. Vector currently maintains the invariant that
no accessible portion of the vector is ever uninitialized. If you want a
routine to allow uninitialized data, then that routine should declare that
it is capable of dealing with that.

[quote]
The counter argument will be that "then change all those vectors to be
vectors with the special allocator". This is bad design as now all uses of
this vector, which is typically a class member, are changed.
[/quote]
You are changing vector's semantics everywhere. It follows that code
changing everywhere is a reasonable result of that.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sun, Sep 15, 2013 at 1:57 PM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> I can't see that a special allocator solves the problem, as vectors with
> different allocators are different types. Even with the invention of  som=
e
> sort of assignable allocator suggested earlier in this thread and
> provisions in all classes that use allocators so that you can move and sw=
ap
> the vector with the special allocator with a vector with the standard
> allocator it results in rather convoluted code compared to an extra ctor
> parameter or special resize method.
>
> A problem with the assignable allocator solution is that it uses
> allocators to differentiate something that is completely different from
> setting a policy on from where memory is allocated, which is what
> allocators are designed for. With assignable allocators the writer of the
> new allocator class is promising that as these allocators can be assigned
> to each other they are equivalent when it comes to doing their work,
> allocation/deallocation, and the only difference is that they do somethin=
g
> else, i.e. construction, in different ways. To me this is not a very clea=
n
> design. Also the amount of changes in the standard is much larger as all
> users of allocators are affected (to implement the actual assignment/copy
> construction which must now be templated on the allocator type).  Each
> new allocation scheme will now need a parallel non_initializing_allocator
> class for orthogonality.
>
> Alternatively an allocator could have a bool member which is inpected in
> each construct to see if value or default construction is required. Maybe
> easier but now construct() performance is reduced which does not sit well
> with this performance directed improvement, and it is still not the defau=
lt
> allocator. Each construction of the vector needs to get a parameter which
> is a an allocator constructed with true or false value. This value can't =
be
> changed between allocations as you can't get a non-const reference to the
> allocator from the vector, only a copy. Even if you could it would not be
> very safe as you need to set/reset the flag between calls.
>
> The counter argument will be that "then change all those vectors to be
> vectors with the special allocator". This is bad design as now all uses o=
f
> this vector, which is typically a class member, are changed. What is need=
ed
> is a per-site possibility to define if zero initiation is to be done, eve=
n
> if the data member is the same. A resize_default_constructed() is a quite
> nice solution to this problem as it does not need a special tag class and
> it doesn't compromize safety for classes with non-trivial destructors. Th=
e
> only drawback I can see is that it needs a new default_construct() method
> on the allocator, but this method is of course needed only if the method =
is
> called, i.e. almost only on the default allocator type.
>
> Note the difference from the previously suggested uninitialized_resize(),
> in that this method calls the default constructor for the elements. It so
> happens that the default constructor for basic types and pointers do
> nothing and so the entire loop containing the placement new and
> incrementing the index etc. will very likely be optimized away. Not so fo=
r
> non-pod types, where it works exactly as the normal resize, as default an=
d
> value construction are the same.
>
> Example:
>
> templat<typename T, ...> class allocator {
>     void default_construct(void* at) { new(at) T; }
> };
> template<...> class vector {
>     ...
>     void resize_default_constructed(size_t newsize);
> };
>
> // Fill data from a socket without clearing the bytes first.
> vector<char> myBuffer;
> myBuffer.resize_default_constructed(1000);
> socket.read(myBuffer.data(), 1000);
>
>
> Not being able to construct the vector directly with a specified number o=
f
> default constructed members is a minor annoyance, which I don't think
> warrants the tag-class trick previously suggested.
>
> Den s=F6ndagen den 15:e september 2013 kl. 20:36:10 UTC+2 skrev Nevin ":-=
)"
> Liber:
>>
>> On 15 September 2013 11:52, Bengt Gustafsson <bengt.gu...@beamways.com**=
>wrote:
>>
>>>
>>> 2. My other issue which is for filling vectors which initially act as
>>> buffers for some legacy function etc.
>>>
>>
>> I've addressed this.  Twice.  Here goes a third time:
>>
>> It can be done safely today (and heck, even in C++03) by writing an
>> allocator which does a default initialization instead of value
>> initialization when calling construct() (with no parameters).  Ion
>> Gazta=F1aga stated it was hard to write such an allocator; but that has
>> not been my experience in C++11.  He has yet to respond as to why he fin=
ds
>> writing such an allocator difficult (I'd like to know, as that difficult=
y
>> may be something the standard should address).
>>
>> To go further, I'd be strongly in favor of adding such an allocator to
>> the standard, were someone to propose it.  Unlike the other proposals, t=
his
>> is just an additional independent library and does not require modificat=
ion
>> of containers or allocators to implement.
>>  --
>>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com**>  (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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

--089e01183066dc977a04e6727fc7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>[quote]</div><div>I can&#39;t see that a special allo=
cator solves the problem, as vectors with different allocators are differen=
t types. </div><div>[/quote]</div><div>I see this as a *good* thing. Vector=
 currently maintains the invariant that no accessible portion of the vector=
 is ever uninitialized. If you want a routine to allow uninitialized data, =
then that routine should declare that it is capable of dealing with that.</=
div>

<div>=A0</div><div>[quote]</div><div>The counter argument will be that &quo=
t;then change all those vectors to be vectors with the special allocator&qu=
ot;. This is bad design as now all uses of this vector, which is typically =
a class member, are changed.</div>

<div>[/quote]</div><div>You are changing vector&#39;s semantics everywhere.=
 It follows that code changing everywhere is a reasonable result of that.</=
div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr=
">

<div>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal=
/" target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=
=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">htt=
p://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sun, Sep 15, 2013 at 1:57 PM, Bengt G=
ustafsson <span dir=3D"ltr">&lt;<a href=3D"mailto:bengt.gustafsson@beamways=
..com" target=3D"_blank">bengt.gustafsson@beamways.com</a>&gt;</span> wrote:=
<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I can&#39;t see that a spec=
ial allocator solves the problem, as vectors with different allocators are =
different types. Even with the invention of =A0some sort of assignable allo=
cator suggested earlier in this thread and provisions in all classes that u=
se allocators so that you can move and swap the vector with the special all=
ocator with a vector with the standard allocator it results in rather convo=
luted code compared to an extra ctor parameter or special resize method.=A0=
<div>

<br></div><div>A problem with the assignable allocator solution is that it =
uses allocators to differentiate something that is completely different fro=
m setting a policy on from where memory is allocated, which is what allocat=
ors are designed for. With assignable allocators the writer of the new allo=
cator class is promising that as these allocators can be assigned to each o=
ther they are equivalent when it comes to doing their work, allocation/deal=
location, and the only difference is that they do something else, i.e. cons=
truction, in different ways. To me this is not a very clean design. Also th=
e amount of changes in the standard is much larger as all users of allocato=
rs are affected (to implement the actual assignment/copy construction which=
 must now be templated on the allocator type).=A0<span style=3D"font-size:1=
3px">=A0</span><span style=3D"font-size:13px">Each new=A0</span><span style=
=3D"font-size:13px">allocation scheme will now need a parallel non_initiali=
zing_allocator class for orthogonality.=A0</span></div>

<div><span style=3D"font-size:13px"><br></span></div><div><span style=3D"fo=
nt-size:13px">Alternatively an allocator could have a bool member which is =
inpected in each construct to see if value or default construction is requi=
red. Maybe easier but now construct() performance is reduced which does not=
 sit well with this performance directed improvement, and it is still not t=
he default allocator. Each construction of the vector needs to get a parame=
ter which is a an allocator constructed with true or false value. This valu=
e can&#39;t be changed between allocations as you can&#39;t get a non-const=
 reference to the allocator from the vector, only a copy. Even if you could=
 it would not be very safe as you need to set/reset the flag between calls.=
</span></div>

<div><div><br></div><div>The counter argument will be that &quot;then chang=
e all those vectors to be vectors with the special allocator&quot;. This is=
 bad design as now all uses of this vector, which is typically a class memb=
er, are changed. What is needed is a per-site possibility to define if zero=
 initiation is to be done, even if the data member is the same. A resize_<s=
pan style=3D"font-size:13px">default_constructed</span><span style=3D"font-=
size:13px">() is a quite nice solution to this problem as it does not need =
a special tag class and it doesn&#39;t compromize safety for classes with n=
on-trivial destructors. The only drawback I can see is that it needs a new =
default_construct() method on the allocator, but this method is of course n=
eeded only if the method is called, i.e. almost only on the default allocat=
or type.</span></div>

<div><br></div><div>Note the difference from the previously suggested unini=
tialized_resize(), in that this method calls the default constructor for th=
e elements. It so happens that the default constructor for basic types and =
pointers do nothing and so the entire loop containing the placement new and=
 incrementing the index etc. will very likely be optimized away. Not so for=
 non-pod types, where it works exactly as the normal resize, as default and=
 value construction are the same.</div>

<div><br></div><div>Example:</div><div><br></div><div>templat&lt;typename T=
, ...&gt; class allocator {</div><div>=A0 =A0 void default_construct(void* =
at) { new(at) T; }</div><div>};</div><div>template&lt;...&gt; class vector =
{</div>

<div>=A0 =A0 ...</div><div>=A0 =A0 void resize_default_constructed(size_t n=
ewsize);</div><div>};</div><div><br></div><div>// Fill data from a socket w=
ithout clearing the bytes first.</div><div>vector&lt;char&gt; myBuffer;</di=
v><div>

myBuffer.resize_default_constructed(1000);</div><div>socket.read(myBuffer.d=
ata(), 1000);</div><div><br></div><div><br></div><div>Not being able to con=
struct the vector directly with a specified number of default constructed m=
embers is a minor annoyance, which I don&#39;t think warrants the tag-class=
 trick previously suggested.<br>

<br>Den s=F6ndagen den 15:e september 2013 kl. 20:36:10 UTC+2 skrev Nevin &=
quot;:-)&quot; Liber:<blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-le=
ft-width:1px;border-left-style:solid">

<div dir=3D"ltr"><div>On 15 September 2013 11:52, Bengt Gustafsson <span di=
r=3D"ltr">&lt;<a>bengt.gu...@beamways.com</a><u></u>&gt;</span> wrote:<br>

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);bor=
der-left-width:1px;border-left-style:solid">

<div dir=3D"ltr"><br></div></blockquote><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204=
,204,204);border-left-width:1px;border-left-style:solid">

<div dir=3D"ltr"><div>2. My other issue which is for filling vectors which =
initially act as buffers for some legacy function etc.<br></div></div></blo=
ckquote><div><br></div><div>I&#39;ve addressed this. =A0Twice. =A0Here goes=
 a third time:</div>



<div><br></div><div>It can be done safely today (and heck, even in C++03) b=
y writing an allocator which does a default initialization instead of value=
 initialization when calling construct() (with no parameters). =A0<span sty=
le=3D"color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px;border=
-collapse:collapse">Ion Gazta=F1aga=A0</span>stated it was hard to write su=
ch an allocator; but that has not been my experience in C++11. =A0He has ye=
t to respond as to why he finds writing such an allocator difficult (I&#39;=
d like to know, as that difficulty may be something the standard should add=
ress).</div>



<div><br></div><div>To go further, I&#39;d be strongly in favor of adding s=
uch an allocator to the standard, were someone to propose it. =A0Unlike the=
 other proposals, this is just an additional independent library and does n=
ot require modification of containers or allocators to implement.</div>

<span class=3D"HOEnZb"><font color=3D"#888888">

</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">-- <br>=
=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a>ne...@eviloverlord.com</a><=
u></u>&gt;=A0 <a href=3D"tel:%28847%29%20691-1404" target=3D"_blank" value=
=3D"+18476911404">(847) 691-1404</a>
</font></span></div></div><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></blockquote></div></div></div><span class=3D"HOEnZb"><font c=
olor=3D"#888888">

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--089e01183066dc977a04e6727fc7--

.

--001a11c1cee6fb3b7a04e674316d
Content-Type: text/plain; charset=ISO-8859-1

On 15 September 2013 15:57, Bengt Gustafsson
<bengt.gustafsson@beamways.com>wrote:

> I can't see that a special allocator solves the problem, as vectors with
> different allocators are different types.
>

So??  Not everything needs to be shoehorned into std::vector<T,
std::allocator<T>>.

The argument of:

1.  You need better performance than vector<T, allocator<T>> gives me today.
2.  You are unwilling to change any interfaces from using vector<T,
allocator<T>> to get better performance.
3.  You are willing to chance pushing through an intrusive change to the
standard library to get better performance.
4.  You are willing to wait five or more years before you can get this
better performance.

can be reduced to:

You really don't need better performance than vector<T, allocator<T>>.



>  A problem with the assignable allocator solution
>

I don't know what you mean by "assignable allocator".

As I wrote it in <
http://stackoverflow.com/questions/15097783/value-initialized-objects-in-c11-and-stdvector-constructor/15119665#15119665>,
I'm talking about using a different allocator which implements something
like:

template<typename T>struct DefaultInitAllocator {
    template<typename U>
    void construct(U* p)
    { ::new (static_cast<void*>(p)) U; }

    template<typename U, typename... Args>
    void construct(U* p, Args&&... args)
    { ::new (static_cast<void*>(p)) U(std::forward<Args>(args)...); }

    // ... rest of the allocator interface};



>  is that it uses allocators to differentiate something that is completely
> different from setting a policy on from where memory is allocated, which is
> what allocators are designed for.
>

*shrug*  I guess we'll have to agree to disagree.  Last I checked, standard
library containers construct/destroy objects by calling functions in their
allocator.

Even with the invention of  some sort of assignable allocator suggested
> earlier in this thread and provisions in all classes that use allocators so
> that you can move and swap the vector with the special allocator with a
> vector with the standard allocator it results in rather convoluted code
> compared to an extra ctor parameter or special resize method.
>

If you think it is easier to push through an intrusive change to both
containers and allocators just to handle this very specialized use case,
it's probably time for me to bow out of this discussion and wish you good
luck with writing up and presenting your proposal.

--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c1cee6fb3b7a04e674316d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 15 September 2013 15:57, Ben=
gt Gustafsson <span dir=3D"ltr">&lt;<a href=3D"mailto:bengt.gustafsson@beam=
ways.com" target=3D"_blank">bengt.gustafsson@beamways.com</a>&gt;</span> wr=
ote:<br>

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">

<div dir=3D"ltr">I can&#39;t see that a special allocator solves the proble=
m, as vectors with different allocators are different types.</div></blockqu=
ote><div><br></div><div>So?? =A0Not everything needs to be shoehorned into =
std::vector&lt;T, std::allocator&lt;T&gt;&gt;.</div>

<div><br></div><div>The argument of:</div><div><br></div><div>1. =A0You nee=
d better performance than vector&lt;T, allocator&lt;T&gt;&gt; gives me toda=
y.</div><div>2. =A0You are unwilling to change any interfaces from using ve=
ctor&lt;T, allocator&lt;T&gt;&gt; to get better performance.</div>

<div>3. =A0You are willing to chance pushing through an intrusive change to=
 the standard library to get better performance.</div><div>4. =A0You are wi=
lling to wait five or more years before you can get this better performance=
..</div>

<div><br></div><div>can be reduced to:</div><div><br></div><div>You really =
don&#39;t need better performance than vector&lt;T, allocator&lt;T&gt;&gt;.=
</div><div><br></div><div>=A0<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;=
border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:=
solid;padding-left:1ex">

<div dir=3D"ltr">=A0A problem with the assignable allocator solution</div><=
/blockquote><div><br></div><div>I don&#39;t know what you mean by &quot;ass=
ignable allocator&quot;.</div><div><br></div><div>As I wrote it in &lt;<a h=
ref=3D"http://stackoverflow.com/questions/15097783/value-initialized-object=
s-in-c11-and-stdvector-constructor/15119665#15119665">http://stackoverflow.=
com/questions/15097783/value-initialized-objects-in-c11-and-stdvector-const=
ructor/15119665#15119665</a>&gt;, I&#39;m talking about using a different a=
llocator which implements something like:</div>

<div><br></div><div><span class=3D"" style=3D"border-collapse:collapse;font=
-family:Arial,&#39;Liberation Sans&#39;,&#39;DejaVu Sans&#39;,sans-serif;fo=
nt-size:14px;line-height:18px;color:rgb(0,0,0)"><pre class=3D"" style=3D"ma=
rgin-top:0px;margin-right:0px;margin-bottom:10px;margin-left:0px;padding-to=
p:5px;padding-right:5px;padding-bottom:5px;padding-left:5px;border-top-widt=
h:0px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;=
border-style:initial;border-color:initial;font-size:14px;vertical-align:bas=
eline;background-image:initial;background-color:rgb(238,238,238);font-famil=
y:Consolas,Menlo,Monaco,&#39;Lucida Console&#39;,&#39;Liberation Mono&#39;,=
&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans Mono&#39;,&#39;Courier =
New&#39;,monospace,serif;width:auto;max-height:600px">

<code style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-lef=
t:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px=
;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;border=
-left-width:0px;border-style:initial;border-color:initial;font-size:14px;ve=
rtical-align:baseline;background-image:initial;background-color:rgb(238,238=
,238);font-family:Consolas,Menlo,Monaco,&#39;Lucida Console&#39;,&#39;Liber=
ation Mono&#39;,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans Mono&#3=
9;,&#39;Courier New&#39;,monospace,serif"><span class=3D"" style=3D"margin-=
top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;=
padding-right:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;=
border-right-width:0px;border-bottom-width:0px;border-left-width:0px;border=
-style:initial;border-color:initial;font-size:14px;vertical-align:baseline;=
background-image:initial;background-color:transparent;color:rgb(0,0,139)">t=
emplate</span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;mar=
gin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bo=
ttom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;borde=
r-bottom-width:0px;border-left-width:0px;border-style:initial;border-color:=
initial;font-size:14px;vertical-align:baseline;background-image:initial;bac=
kground-color:transparent;color:rgb(0,0,0)">&lt;</span><span class=3D"" sty=
le=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;pad=
ding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-t=
op-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-wid=
th:0px;border-style:initial;border-color:initial;font-size:14px;vertical-al=
ign:baseline;background-image:initial;background-color:transparent;color:rg=
b(0,0,139)">typename</span><span class=3D"" style=3D"margin-top:0px;margin-=
right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0=
px;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-wi=
dth:0px;border-bottom-width:0px;border-left-width:0px;border-style:initial;=
border-color:initial;font-size:14px;vertical-align:baseline;background-imag=
e:initial;background-color:transparent;color:rgb(0,0,0)"> T</span><span cla=
ss=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-l=
eft:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0=
px;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;bord=
er-left-width:0px;border-style:initial;border-color:initial;font-size:14px;=
vertical-align:baseline;background-image:initial;background-color:transpare=
nt;color:rgb(0,0,0)">&gt;</span><span class=3D"" style=3D"margin-top:0px;ma=
rgin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-ri=
ght:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-rig=
ht-width:0px;border-bottom-width:0px;border-left-width:0px;border-style:ini=
tial;border-color:initial;font-size:14px;vertical-align:baseline;background=
-image:initial;background-color:transparent;color:rgb(0,0,0)">
</span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bot=
tom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0p=
x;padding-left:0px;border-top-width:0px;border-right-width:0px;border-botto=
m-width:0px;border-left-width:0px;border-style:initial;border-color:initial=
;font-size:14px;vertical-align:baseline;background-image:initial;background=
-color:transparent;color:rgb(0,0,139)">struct</span><span class=3D"" style=
=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;paddi=
ng-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top=
-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-width=
:0px;border-style:initial;border-color:initial;font-size:14px;vertical-alig=
n:baseline;background-image:initial;background-color:transparent;color:rgb(=
0,0,0)"> </span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;m=
argin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-=
bottom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;bor=
der-bottom-width:0px;border-left-width:0px;border-style:initial;border-colo=
r:initial;font-size:14px;vertical-align:baseline;background-image:initial;b=
ackground-color:transparent;color:rgb(43,145,175)">DefaultInitAllocator</sp=
an><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:=
0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;pa=
dding-left:0px;border-top-width:0px;border-right-width:0px;border-bottom-wi=
dth:0px;border-left-width:0px;border-style:initial;border-color:initial;fon=
t-size:14px;vertical-align:baseline;background-image:initial;background-col=
or:transparent;color:rgb(0,0,0)"> </span><span class=3D"" style=3D"margin-t=
op:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;p=
adding-right:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;b=
order-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-=
style:initial;border-color:initial;font-size:14px;vertical-align:baseline;b=
ackground-image:initial;background-color:transparent;color:rgb(0,0,0)">{</s=
pan><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom=
:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;p=
adding-left:0px;border-top-width:0px;border-right-width:0px;border-bottom-w=
idth:0px;border-left-width:0px;border-style:initial;border-color:initial;fo=
nt-size:14px;vertical-align:baseline;background-image:initial;background-co=
lor:transparent;color:rgb(0,0,0)">
    </span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin=
-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-botto=
m:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-b=
ottom-width:0px;border-left-width:0px;border-style:initial;border-color:ini=
tial;font-size:14px;vertical-align:baseline;background-image:initial;backgr=
ound-color:transparent;color:rgb(0,0,139)">template</span><span class=3D"" =
style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;=
padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;borde=
r-top-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-=
width:0px;border-style:initial;border-color:initial;font-size:14px;vertical=
-align:baseline;background-image:initial;background-color:transparent;color=
:rgb(0,0,0)">&lt;</span><span class=3D"" style=3D"margin-top:0px;margin-rig=
ht:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;=
padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-width=
:0px;border-bottom-width:0px;border-left-width:0px;border-style:initial;bor=
der-color:initial;font-size:14px;vertical-align:baseline;background-image:i=
nitial;background-color:transparent;color:rgb(0,0,139)">typename</span><spa=
n class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;mar=
gin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-l=
eft:0px;border-top-width:0px;border-right-width:0px;border-bottom-width:0px=
;border-left-width:0px;border-style:initial;border-color:initial;font-size:=
14px;vertical-align:baseline;background-image:initial;background-color:tran=
sparent;color:rgb(0,0,0)"> U</span><span class=3D"" style=3D"margin-top:0px=
;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding=
-right:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-=
right-width:0px;border-bottom-width:0px;border-left-width:0px;border-style:=
initial;border-color:initial;font-size:14px;vertical-align:baseline;backgro=
und-image:initial;background-color:transparent;color:rgb(0,0,0)">&gt;</span=
><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0p=
x;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padd=
ing-left:0px;border-top-width:0px;border-right-width:0px;border-bottom-widt=
h:0px;border-left-width:0px;border-style:initial;border-color:initial;font-=
size:14px;vertical-align:baseline;background-image:initial;background-color=
:transparent;color:rgb(0,0,0)">
    </span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin=
-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-botto=
m:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-b=
ottom-width:0px;border-left-width:0px;border-style:initial;border-color:ini=
tial;font-size:14px;vertical-align:baseline;background-image:initial;backgr=
ound-color:transparent;color:rgb(0,0,139)">void</span><span class=3D"" styl=
e=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padd=
ing-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-to=
p-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-widt=
h:0px;border-style:initial;border-color:initial;font-size:14px;vertical-ali=
gn:baseline;background-image:initial;background-color:transparent;color:rgb=
(0,0,0)"> construct</span><span class=3D"" style=3D"margin-top:0px;margin-r=
ight:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0p=
x;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-wid=
th:0px;border-bottom-width:0px;border-left-width:0px;border-style:initial;b=
order-color:initial;font-size:14px;vertical-align:baseline;background-image=
:initial;background-color:transparent;color:rgb(0,0,0)">(</span><span class=
=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-lef=
t:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px=
;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;border=
-left-width:0px;border-style:initial;border-color:initial;font-size:14px;ve=
rtical-align:baseline;background-image:initial;background-color:transparent=
;color:rgb(0,0,0)">U</span><span class=3D"" style=3D"margin-top:0px;margin-=
right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0=
px;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-wi=
dth:0px;border-bottom-width:0px;border-left-width:0px;border-style:initial;=
border-color:initial;font-size:14px;vertical-align:baseline;background-imag=
e:initial;background-color:transparent;color:rgb(0,0,0)">*</span><span clas=
s=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-le=
ft:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0p=
x;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;borde=
r-left-width:0px;border-style:initial;border-color:initial;font-size:14px;v=
ertical-align:baseline;background-image:initial;background-color:transparen=
t;color:rgb(0,0,0)"> p</span><span class=3D"" style=3D"margin-top:0px;margi=
n-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right=
:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-=
width:0px;border-bottom-width:0px;border-left-width:0px;border-style:initia=
l;border-color:initial;font-size:14px;vertical-align:baseline;background-im=
age:initial;background-color:transparent;color:rgb(0,0,0)">)</span><span cl=
ass=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-=
left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:=
0px;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;bor=
der-left-width:0px;border-style:initial;border-color:initial;font-size:14px=
;vertical-align:baseline;background-image:initial;background-color:transpar=
ent;color:rgb(0,0,0)">
    </span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin=
-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-botto=
m:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-b=
ottom-width:0px;border-left-width:0px;border-style:initial;border-color:ini=
tial;font-size:14px;vertical-align:baseline;background-image:initial;backgr=
ound-color:transparent;color:rgb(0,0,0)">{</span><span class=3D"" style=3D"=
margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-t=
op:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top-wid=
th:0px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px=
;border-style:initial;border-color:initial;font-size:14px;vertical-align:ba=
seline;background-image:initial;background-color:transparent;color:rgb(0,0,=
0)"> </span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margi=
n-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bott=
om:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-=
bottom-width:0px;border-left-width:0px;border-style:initial;border-color:in=
itial;font-size:14px;vertical-align:baseline;background-image:initial;backg=
round-color:transparent;color:rgb(0,0,0)">::</span><span class=3D"" style=
=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;paddi=
ng-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top=
-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-width=
:0px;border-style:initial;border-color:initial;font-size:14px;vertical-alig=
n:baseline;background-image:initial;background-color:transparent;color:rgb(=
0,0,139)">new</span><span class=3D"" style=3D"margin-top:0px;margin-right:0=
px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padd=
ing-bottom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px=
;border-bottom-width:0px;border-left-width:0px;border-style:initial;border-=
color:initial;font-size:14px;vertical-align:baseline;background-image:initi=
al;background-color:transparent;color:rgb(0,0,0)"> </span><span class=3D"" =
style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;=
padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;borde=
r-top-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-=
width:0px;border-style:initial;border-color:initial;font-size:14px;vertical=
-align:baseline;background-image:initial;background-color:transparent;color=
:rgb(0,0,0)">(</span><span class=3D"" style=3D"margin-top:0px;margin-right:=
0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;pad=
ding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-width:0p=
x;border-bottom-width:0px;border-left-width:0px;border-style:initial;border=
-color:initial;font-size:14px;vertical-align:baseline;background-image:init=
ial;background-color:transparent;color:rgb(0,0,139)">static_cast</span><spa=
n class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;mar=
gin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-l=
eft:0px;border-top-width:0px;border-right-width:0px;border-bottom-width:0px=
;border-left-width:0px;border-style:initial;border-color:initial;font-size:=
14px;vertical-align:baseline;background-image:initial;background-color:tran=
sparent;color:rgb(0,0,0)">&lt;</span><span class=3D"" style=3D"margin-top:0=
px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;paddi=
ng-right:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;borde=
r-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-styl=
e:initial;border-color:initial;font-size:14px;vertical-align:baseline;backg=
round-image:initial;background-color:transparent;color:rgb(0,0,139)">void</=
span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-botto=
m:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;=
padding-left:0px;border-top-width:0px;border-right-width:0px;border-bottom-=
width:0px;border-left-width:0px;border-style:initial;border-color:initial;f=
ont-size:14px;vertical-align:baseline;background-image:initial;background-c=
olor:transparent;color:rgb(0,0,0)">*&gt;(</span><span class=3D"" style=3D"m=
argin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-to=
p:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top-widt=
h:0px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;=
border-style:initial;border-color:initial;font-size:14px;vertical-align:bas=
eline;background-image:initial;background-color:transparent;color:rgb(0,0,0=
)">p</span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin=
-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-botto=
m:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-b=
ottom-width:0px;border-left-width:0px;border-style:initial;border-color:ini=
tial;font-size:14px;vertical-align:baseline;background-image:initial;backgr=
ound-color:transparent;color:rgb(0,0,0)">))</span><span class=3D"" style=3D=
"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-=
top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top-wi=
dth:0px;border-right-width:0px;border-bottom-width:0px;border-left-width:0p=
x;border-style:initial;border-color:initial;font-size:14px;vertical-align:b=
aseline;background-image:initial;background-color:transparent;color:rgb(0,0=
,0)"> U</span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;mar=
gin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bo=
ttom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;borde=
r-bottom-width:0px;border-left-width:0px;border-style:initial;border-color:=
initial;font-size:14px;vertical-align:baseline;background-image:initial;bac=
kground-color:transparent;color:rgb(0,0,0)">;</span><span class=3D"" style=
=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;paddi=
ng-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top=
-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-width=
:0px;border-style:initial;border-color:initial;font-size:14px;vertical-alig=
n:baseline;background-image:initial;background-color:transparent;color:rgb(=
0,0,0)"> </span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;m=
argin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-=
bottom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;bor=
der-bottom-width:0px;border-left-width:0px;border-style:initial;border-colo=
r:initial;font-size:14px;vertical-align:baseline;background-image:initial;b=
ackground-color:transparent;color:rgb(0,0,0)">}</span><span class=3D"" styl=
e=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padd=
ing-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-to=
p-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-widt=
h:0px;border-style:initial;border-color:initial;font-size:14px;vertical-ali=
gn:baseline;background-image:initial;background-color:transparent;color:rgb=
(0,0,0)">

    </span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin=
-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-botto=
m:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-b=
ottom-width:0px;border-left-width:0px;border-style:initial;border-color:ini=
tial;font-size:14px;vertical-align:baseline;background-image:initial;backgr=
ound-color:transparent;color:rgb(0,0,139)">template</span><span class=3D"" =
style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;=
padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;borde=
r-top-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-=
width:0px;border-style:initial;border-color:initial;font-size:14px;vertical=
-align:baseline;background-image:initial;background-color:transparent;color=
:rgb(0,0,0)">&lt;</span><span class=3D"" style=3D"margin-top:0px;margin-rig=
ht:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;=
padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-width=
:0px;border-bottom-width:0px;border-left-width:0px;border-style:initial;bor=
der-color:initial;font-size:14px;vertical-align:baseline;background-image:i=
nitial;background-color:transparent;color:rgb(0,0,139)">typename</span><spa=
n class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;mar=
gin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-l=
eft:0px;border-top-width:0px;border-right-width:0px;border-bottom-width:0px=
;border-left-width:0px;border-style:initial;border-color:initial;font-size:=
14px;vertical-align:baseline;background-image:initial;background-color:tran=
sparent;color:rgb(0,0,0)"> U</span><span class=3D"" style=3D"margin-top:0px=
;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding=
-right:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-=
right-width:0px;border-bottom-width:0px;border-left-width:0px;border-style:=
initial;border-color:initial;font-size:14px;vertical-align:baseline;backgro=
und-image:initial;background-color:transparent;color:rgb(0,0,0)">,</span><s=
pan class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;m=
argin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding=
-left:0px;border-top-width:0px;border-right-width:0px;border-bottom-width:0=
px;border-left-width:0px;border-style:initial;border-color:initial;font-siz=
e:14px;vertical-align:baseline;background-image:initial;background-color:tr=
ansparent;color:rgb(0,0,0)"> </span><span class=3D"" style=3D"margin-top:0p=
x;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;paddin=
g-right:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;border=
-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-style=
:initial;border-color:initial;font-size:14px;vertical-align:baseline;backgr=
ound-image:initial;background-color:transparent;color:rgb(0,0,139)">typenam=
e</span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bo=
ttom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0=
px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-bott=
om-width:0px;border-left-width:0px;border-style:initial;border-color:initia=
l;font-size:14px;vertical-align:baseline;background-image:initial;backgroun=
d-color:transparent;color:rgb(0,0,0)">...</span><span class=3D"" style=3D"m=
argin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-to=
p:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top-widt=
h:0px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;=
border-style:initial;border-color:initial;font-size:14px;vertical-align:bas=
eline;background-image:initial;background-color:transparent;color:rgb(0,0,0=
)"> </span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin=
-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-botto=
m:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-b=
ottom-width:0px;border-left-width:0px;border-style:initial;border-color:ini=
tial;font-size:14px;vertical-align:baseline;background-image:initial;backgr=
ound-color:transparent;color:rgb(43,145,175)">Args</span><span class=3D"" s=
tyle=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;p=
adding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border=
-top-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-w=
idth:0px;border-style:initial;border-color:initial;font-size:14px;vertical-=
align:baseline;background-image:initial;background-color:transparent;color:=
rgb(0,0,0)">&gt;</span><span class=3D"" style=3D"margin-top:0px;margin-righ=
t:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;p=
adding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-width:=
0px;border-bottom-width:0px;border-left-width:0px;border-style:initial;bord=
er-color:initial;font-size:14px;vertical-align:baseline;background-image:in=
itial;background-color:transparent;color:rgb(0,0,0)">
    </span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin=
-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-botto=
m:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-b=
ottom-width:0px;border-left-width:0px;border-style:initial;border-color:ini=
tial;font-size:14px;vertical-align:baseline;background-image:initial;backgr=
ound-color:transparent;color:rgb(0,0,139)">void</span><span class=3D"" styl=
e=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padd=
ing-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-to=
p-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-widt=
h:0px;border-style:initial;border-color:initial;font-size:14px;vertical-ali=
gn:baseline;background-image:initial;background-color:transparent;color:rgb=
(0,0,0)"> construct</span><span class=3D"" style=3D"margin-top:0px;margin-r=
ight:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0p=
x;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-wid=
th:0px;border-bottom-width:0px;border-left-width:0px;border-style:initial;b=
order-color:initial;font-size:14px;vertical-align:baseline;background-image=
:initial;background-color:transparent;color:rgb(0,0,0)">(</span><span class=
=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-lef=
t:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px=
;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;border=
-left-width:0px;border-style:initial;border-color:initial;font-size:14px;ve=
rtical-align:baseline;background-image:initial;background-color:transparent=
;color:rgb(0,0,0)">U</span><span class=3D"" style=3D"margin-top:0px;margin-=
right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0=
px;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-wi=
dth:0px;border-bottom-width:0px;border-left-width:0px;border-style:initial;=
border-color:initial;font-size:14px;vertical-align:baseline;background-imag=
e:initial;background-color:transparent;color:rgb(0,0,0)">*</span><span clas=
s=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-le=
ft:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0p=
x;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;borde=
r-left-width:0px;border-style:initial;border-color:initial;font-size:14px;v=
ertical-align:baseline;background-image:initial;background-color:transparen=
t;color:rgb(0,0,0)"> p</span><span class=3D"" style=3D"margin-top:0px;margi=
n-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right=
:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-=
width:0px;border-bottom-width:0px;border-left-width:0px;border-style:initia=
l;border-color:initial;font-size:14px;vertical-align:baseline;background-im=
age:initial;background-color:transparent;color:rgb(0,0,0)">,</span><span cl=
ass=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-=
left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:=
0px;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;bor=
der-left-width:0px;border-style:initial;border-color:initial;font-size:14px=
;vertical-align:baseline;background-image:initial;background-color:transpar=
ent;color:rgb(0,0,0)"> </span><span class=3D"" style=3D"margin-top:0px;marg=
in-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-righ=
t:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right=
-width:0px;border-bottom-width:0px;border-left-width:0px;border-style:initi=
al;border-color:initial;font-size:14px;vertical-align:baseline;background-i=
mage:initial;background-color:transparent;color:rgb(43,145,175)">Args</span=
><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0p=
x;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padd=
ing-left:0px;border-top-width:0px;border-right-width:0px;border-bottom-widt=
h:0px;border-left-width:0px;border-style:initial;border-color:initial;font-=
size:14px;vertical-align:baseline;background-image:initial;background-color=
:transparent;color:rgb(0,0,0)">&amp;&amp;...</span><span class=3D"" style=
=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;paddi=
ng-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top=
-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-width=
:0px;border-style:initial;border-color:initial;font-size:14px;vertical-alig=
n:baseline;background-image:initial;background-color:transparent;color:rgb(=
0,0,0)"> args</span><span class=3D"" style=3D"margin-top:0px;margin-right:0=
px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padd=
ing-bottom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px=
;border-bottom-width:0px;border-left-width:0px;border-style:initial;border-=
color:initial;font-size:14px;vertical-align:baseline;background-image:initi=
al;background-color:transparent;color:rgb(0,0,0)">)</span><span class=3D"" =
style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;=
padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;borde=
r-top-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-=
width:0px;border-style:initial;border-color:initial;font-size:14px;vertical=
-align:baseline;background-image:initial;background-color:transparent;color=
:rgb(0,0,0)">
    </span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin=
-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-botto=
m:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-b=
ottom-width:0px;border-left-width:0px;border-style:initial;border-color:ini=
tial;font-size:14px;vertical-align:baseline;background-image:initial;backgr=
ound-color:transparent;color:rgb(0,0,0)">{</span><span class=3D"" style=3D"=
margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-t=
op:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top-wid=
th:0px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px=
;border-style:initial;border-color:initial;font-size:14px;vertical-align:ba=
seline;background-image:initial;background-color:transparent;color:rgb(0,0,=
0)"> </span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margi=
n-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bott=
om:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-=
bottom-width:0px;border-left-width:0px;border-style:initial;border-color:in=
itial;font-size:14px;vertical-align:baseline;background-image:initial;backg=
round-color:transparent;color:rgb(0,0,0)">::</span><span class=3D"" style=
=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;paddi=
ng-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top=
-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-width=
:0px;border-style:initial;border-color:initial;font-size:14px;vertical-alig=
n:baseline;background-image:initial;background-color:transparent;color:rgb(=
0,0,139)">new</span><span class=3D"" style=3D"margin-top:0px;margin-right:0=
px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padd=
ing-bottom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px=
;border-bottom-width:0px;border-left-width:0px;border-style:initial;border-=
color:initial;font-size:14px;vertical-align:baseline;background-image:initi=
al;background-color:transparent;color:rgb(0,0,0)"> </span><span class=3D"" =
style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;=
padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;borde=
r-top-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-=
width:0px;border-style:initial;border-color:initial;font-size:14px;vertical=
-align:baseline;background-image:initial;background-color:transparent;color=
:rgb(0,0,0)">(</span><span class=3D"" style=3D"margin-top:0px;margin-right:=
0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;pad=
ding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-width:0p=
x;border-bottom-width:0px;border-left-width:0px;border-style:initial;border=
-color:initial;font-size:14px;vertical-align:baseline;background-image:init=
ial;background-color:transparent;color:rgb(0,0,139)">static_cast</span><spa=
n class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;mar=
gin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-l=
eft:0px;border-top-width:0px;border-right-width:0px;border-bottom-width:0px=
;border-left-width:0px;border-style:initial;border-color:initial;font-size:=
14px;vertical-align:baseline;background-image:initial;background-color:tran=
sparent;color:rgb(0,0,0)">&lt;</span><span class=3D"" style=3D"margin-top:0=
px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;paddi=
ng-right:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;borde=
r-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-styl=
e:initial;border-color:initial;font-size:14px;vertical-align:baseline;backg=
round-image:initial;background-color:transparent;color:rgb(0,0,139)">void</=
span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-botto=
m:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;=
padding-left:0px;border-top-width:0px;border-right-width:0px;border-bottom-=
width:0px;border-left-width:0px;border-style:initial;border-color:initial;f=
ont-size:14px;vertical-align:baseline;background-image:initial;background-c=
olor:transparent;color:rgb(0,0,0)">*&gt;(</span><span class=3D"" style=3D"m=
argin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-to=
p:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top-widt=
h:0px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;=
border-style:initial;border-color:initial;font-size:14px;vertical-align:bas=
eline;background-image:initial;background-color:transparent;color:rgb(0,0,0=
)">p</span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin=
-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-botto=
m:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-b=
ottom-width:0px;border-left-width:0px;border-style:initial;border-color:ini=
tial;font-size:14px;vertical-align:baseline;background-image:initial;backgr=
ound-color:transparent;color:rgb(0,0,0)">))</span><span class=3D"" style=3D=
"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-=
top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top-wi=
dth:0px;border-right-width:0px;border-bottom-width:0px;border-left-width:0p=
x;border-style:initial;border-color:initial;font-size:14px;vertical-align:b=
aseline;background-image:initial;background-color:transparent;color:rgb(0,0=
,0)"> U</span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;mar=
gin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bo=
ttom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;borde=
r-bottom-width:0px;border-left-width:0px;border-style:initial;border-color:=
initial;font-size:14px;vertical-align:baseline;background-image:initial;bac=
kground-color:transparent;color:rgb(0,0,0)">(</span><span class=3D"" style=
=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;paddi=
ng-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top=
-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-width=
:0px;border-style:initial;border-color:initial;font-size:14px;vertical-alig=
n:baseline;background-image:initial;background-color:transparent;color:rgb(=
0,0,0)">std</span><span class=3D"" style=3D"margin-top:0px;margin-right:0px=
;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;paddin=
g-bottom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;b=
order-bottom-width:0px;border-left-width:0px;border-style:initial;border-co=
lor:initial;font-size:14px;vertical-align:baseline;background-image:initial=
;background-color:transparent;color:rgb(0,0,0)">::</span><span class=3D"" s=
tyle=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;p=
adding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border=
-top-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-w=
idth:0px;border-style:initial;border-color:initial;font-size:14px;vertical-=
align:baseline;background-image:initial;background-color:transparent;color:=
rgb(0,0,0)">forward</span><span class=3D"" style=3D"margin-top:0px;margin-r=
ight:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0p=
x;padding-bottom:0px;padding-left:0px;border-top-width:0px;border-right-wid=
th:0px;border-bottom-width:0px;border-left-width:0px;border-style:initial;b=
order-color:initial;font-size:14px;vertical-align:baseline;background-image=
:initial;background-color:transparent;color:rgb(0,0,0)">&lt;</span><span cl=
ass=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-=
left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:=
0px;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;bor=
der-left-width:0px;border-style:initial;border-color:initial;font-size:14px=
;vertical-align:baseline;background-image:initial;background-color:transpar=
ent;color:rgb(43,145,175)">Args</span><span class=3D"" style=3D"margin-top:=
0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padd=
ing-right:0px;padding-bottom:0px;padding-left:0px;border-top-width:0px;bord=
er-right-width:0px;border-bottom-width:0px;border-left-width:0px;border-sty=
le:initial;border-color:initial;font-size:14px;vertical-align:baseline;back=
ground-image:initial;background-color:transparent;color:rgb(0,0,0)">&gt;(</=
span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-botto=
m:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;=
padding-left:0px;border-top-width:0px;border-right-width:0px;border-bottom-=
width:0px;border-left-width:0px;border-style:initial;border-color:initial;f=
ont-size:14px;vertical-align:baseline;background-image:initial;background-c=
olor:transparent;color:rgb(0,0,0)">args</span><span class=3D"" style=3D"mar=
gin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:=
0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top-width:=
0px;border-right-width:0px;border-bottom-width:0px;border-left-width:0px;bo=
rder-style:initial;border-color:initial;font-size:14px;vertical-align:basel=
ine;background-image:initial;background-color:transparent;color:rgb(0,0,0)"=
>)...);</span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;mar=
gin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bo=
ttom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;borde=
r-bottom-width:0px;border-left-width:0px;border-style:initial;border-color:=
initial;font-size:14px;vertical-align:baseline;background-image:initial;bac=
kground-color:transparent;color:rgb(0,0,0)"> </span><span class=3D"" style=
=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;paddi=
ng-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;border-top=
-width:0px;border-right-width:0px;border-bottom-width:0px;border-left-width=
:0px;border-style:initial;border-color:initial;font-size:14px;vertical-alig=
n:baseline;background-image:initial;background-color:transparent;color:rgb(=
0,0,0)">}</span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;m=
argin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-=
bottom:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;bor=
der-bottom-width:0px;border-left-width:0px;border-style:initial;border-colo=
r:initial;font-size:14px;vertical-align:baseline;background-image:initial;b=
ackground-color:transparent;color:rgb(0,0,0)">

    </span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin=
-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-botto=
m:0px;padding-left:0px;border-top-width:0px;border-right-width:0px;border-b=
ottom-width:0px;border-left-width:0px;border-style:initial;border-color:ini=
tial;font-size:14px;vertical-align:baseline;background-image:initial;backgr=
ound-color:transparent;color:gray">// ... rest of the allocator interface</=
span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-botto=
m:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;=
padding-left:0px;border-top-width:0px;border-right-width:0px;border-bottom-=
width:0px;border-left-width:0px;border-style:initial;border-color:initial;f=
ont-size:14px;vertical-align:baseline;background-image:initial;background-c=
olor:transparent;color:rgb(0,0,0)">
</span><span class=3D"" style=3D"margin-top:0px;margin-right:0px;margin-bot=
tom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0p=
x;padding-left:0px;border-top-width:0px;border-right-width:0px;border-botto=
m-width:0px;border-left-width:0px;border-style:initial;border-color:initial=
;font-size:14px;vertical-align:baseline;background-image:initial;background=
-color:transparent;color:rgb(0,0,0)">};</span></code></pre>

</span></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">

<div dir=3D"ltr"> is that it uses allocators to differentiate something tha=
t is completely different from setting a policy on from where memory is all=
ocated, which is what allocators are designed for.</div></blockquote><div>

<br></div><div>*shrug* =A0I guess we&#39;ll have to agree to disagree. =A0L=
ast I checked, standard library containers construct/destroy objects by cal=
ling functions in their allocator.</div><div><br></div><div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0=
px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex">

<div dir=3D"ltr">Even with the invention of =A0some sort of assignable allo=
cator suggested earlier in this thread and provisions in all classes that u=
se allocators so that you can move and swap the vector with the special all=
ocator with a vector with the standard allocator it results in rather convo=
luted code compared to an extra ctor parameter or special resize method.=A0=
</div>

</blockquote><div><br></div><div>If you think it is easier to push through =
an intrusive change to both containers and allocators just to handle this v=
ery specialized use case, it&#39;s probably time for me to bow out of this =
discussion and wish you good luck with writing up and presenting your propo=
sal.</div>

</div><div><br></div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mai=
lto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilo=
verlord.com</a>&gt;=A0 (847) 691-1404
</div></div>

<p></p>

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

--001a11c1cee6fb3b7a04e674316d--

.

------=_Part_603_18277979.1379296545576
Content-Type: text/plain; charset=ISO-8859-1



On Monday, September 16, 2013 4:57:08 AM UTC+8, Bengt Gustafsson wrote:
>
> I can't see that a special allocator solves the problem, as vectors with
> different allocators are different types. Even with the invention of  some
> sort of assignable allocator suggested earlier in this thread and
> provisions in all classes that use allocators so that you can move and swap
> the vector with the special allocator with a vector with the standard
> allocator it results in rather convoluted code compared to an extra ctor
> parameter or special resize method.
>

vector< int > q;
q.reserve( 30 );
vector< int, other_allocator > r( std::move( q ) ); // Now r has whatever
special semantics.

Is this so convoluted?

This sort of code attaches invariants to an object using the type system,
allowing appropriate functions to be selected automatically. Adding special
members requires manual selection of functions, so the user has to work to
refactor code and verify that such refactoring remains valid.


> A problem with the assignable allocator solution is that it uses
> allocators to differentiate something that is completely different from
> setting a policy on from where memory is allocated, which is what
> allocators are designed for. With assignable allocators the writer of the
> new allocator class is promising that as these allocators can be assigned
> to each other they are equivalent when it comes to doing their work,
> allocation/deallocation, and the only difference is that they do something
> else, i.e. construction, in different ways. To me this is not a very clean
> design.
>

If by assignable allocators you mean my suggestion, *no*, I suggested to
assign an allocator that cannot perform any allocation but performs
construction as normal.

It seems there are at least 2-3 mutually exclusive allocator suggestions
here.

- No-initialize allocator
- Default-initialize allocator
- No-allocate allocator


> Alternatively an allocator could have a bool member which is inpected in
> each construct to see if value or default construction is required.
>

Adding state adds overhead. If one code path doesn't want two different
allocator behaviors, then the runtime state also means a static invariant
isn't getting checked by the type system as it should.

Applying and checking these invariants which vary from place to place, but
apply to the same thing, is what assignable allocators would solve.


> Maybe easier but now construct() performance is reduced which does not sit
> well with this performance directed improvement, and it is still not the
> default allocator.
>

If the special allocator assigns to and from the default allocator, then
you can use the default allocator wherever you wish. Am I mistaking what
you refer to by "assignable"?

But a default allocator vector and a special allocator vector cannot hold
the same sequence at the same time. Move semantics would be needed to
switch between them. Doesn't seem to be a problem as vector doesn't allow
concurrent reading and resizing anyway.

--

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

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

<div dir=3D"ltr"><br><br>On Monday, September 16, 2013 4:57:08 AM UTC+8, Be=
ngt Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">I can't see that a special allocator solves the problem, as vector=
s with different allocators are different types. Even with the invention of=
 &nbsp;some sort of assignable allocator suggested earlier in this thread a=
nd provisions in all classes that use allocators so that you can move and s=
wap the vector with the special allocator with a vector with the standard a=
llocator it results in rather convoluted code compared to an extra ctor par=
ameter or special resize method.&nbsp;</div></blockquote><div><br><div clas=
s=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> q</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
q</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">reserve</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">30</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>vector</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">in=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> other_allocator <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> r</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">move</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> q </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// Now r has whatever specia=
l semantics.</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span></div></code></div><br>Is this so convoluted?<br><br>This sort=
 of code attaches invariants to an object using the type system, allowing a=
ppropriate functions to be selected automatically. Adding special members r=
equires manual selection of functions, so the user has to work to refactor =
code and verify that such refactoring remains valid.<br>&nbsp;</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>A problem with =
the assignable allocator solution is that it uses allocators to differentia=
te something that is completely different from setting a policy on from whe=
re memory is allocated, which is what allocators are designed for. With ass=
ignable allocators the writer of the new allocator class is promising that =
as these allocators can be assigned to each other they are equivalent when =
it comes to doing their work, allocation/deallocation, and the only differe=
nce is that they do something else, i.e. construction, in different ways. T=
o me this is not a very clean design.</div></div></blockquote><div><br>If b=
y assignable allocators you mean my suggestion, <i>no</i>, I suggested to a=
ssign an allocator that cannot perform any allocation but performs construc=
tion as normal.<br><br>It seems there are at least 2-3 mutually exclusive a=
llocator suggestions here.<br><br>- No-initialize allocator<br>- Default-in=
itialize allocator<br>- No-allocate allocator<br>&nbsp;</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><span style=3D"font-size:13=
px">Alternatively an allocator could have a bool member which is inpected i=
n each construct to see if value or default construction is required.</span=
></div></blockquote><div><br>Adding state adds overhead. If one code path d=
oesn't want two different allocator behaviors, then the runtime state also =
means a static invariant isn't getting checked by the type system as it sho=
uld.<br><br>Applying and checking these invariants which vary from place to=
 place, but apply to the same thing, is what assignable allocators would so=
lve.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><span style=3D"font-size:13px"> Maybe easier but now construct() p=
erformance is reduced which does not sit well with this performance directe=
d improvement, and it is still not the default allocator.</span></div></blo=
ckquote><div><br>If the special allocator assigns to and from the default a=
llocator, then you can use the default allocator wherever you wish. Am I mi=
staking what you refer to by "assignable"?<br><br>But a default allocator v=
ector and a special allocator vector cannot hold the same sequence at the s=
ame time. Move semantics would be needed to switch between them. Doesn't se=
em to be a problem as vector doesn't allow concurrent reading and resizing =
anyway. <br></div></div>

<p></p>

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

------=_Part_603_18277979.1379296545576--

.

------=_Part_78_672203.1379408894307
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This is getting ever more confusing. since my last post yesterday I have=20
gotten two replies.

One from Nevin who correctly pointed out that getting an "assignable=20
allocator" idea through the committe. But this was not my suggestion, what=
=20
I wrote was a similar reaction to (now apparently) David's suggestion.

The other was from David who didn't think that his code was convoluted. I=
=20
can agree to that, as it can be wrapped into a function or something.=20
However, this solution is what needs the five years of committe work, isn't=
=20
it? Or do you mean that you can move construct vectors with different=20
allocators from each other in the current standard? I have checked both the=
=20
current standard and the C++14 draft and could not find such a=20
constructor... maybe I'm just blind.

By comparison I think that my suggestion of adding one (1) trivial method=
=20
to vector and one even more trivial method to allocator should be easier to=
=20
handle in the committe work.

By the way, David's code is a bit backwards as written. To do what I want=
=20
you first have a vector with the special no-init construct() and then call=
=20
resize() (not reserve()) on it, and finally move() it into a regular vector=
=20
which is what you need for the rest of the program:

vector<int, other_allocator> q;  // default constructing construct() on=20
this allocator.
q.resize( 30 );                  // A nop apart from moving the end pointer
vector<int> r( std::move( q ) ); // Now r has standard allocator and=20
default constructed elements, ready to be filled from some function.




Den m=E5ndagen den 16:e september 2013 kl. 03:55:45 UTC+2 skrev David Kraus=
s:
>
>
>
> On Monday, September 16, 2013 4:57:08 AM UTC+8, Bengt Gustafsson wrote:
>>
>> I can't see that a special allocator solves the problem, as vectors with=
=20
>> different allocators are different types. Even with the invention of  so=
me=20
>> sort of assignable allocator suggested earlier in this thread and=20
>> provisions in all classes that use allocators so that you can move and s=
wap=20
>> the vector with the special allocator with a vector with the standard=20
>> allocator it results in rather convoluted code compared to an extra ctor=
=20
>> parameter or special resize method.=20
>>
>
> vector< int > q;
> q.reserve( 30 );
> vector< int, other_allocator > r( std::move( q ) ); // Now r has whatever=
=20
> special semantics.
>
> Is this so convoluted?
>
> This sort of code attaches invariants to an object using the type system,=
=20
> allowing appropriate functions to be selected automatically. Adding speci=
al=20
> members requires manual selection of functions, so the user has to work t=
o=20
> refactor code and verify that such refactoring remains valid.
> =20
>
>> A problem with the assignable allocator solution is that it uses=20
>> allocators to differentiate something that is completely different from=
=20
>> setting a policy on from where memory is allocated, which is what=20
>> allocators are designed for. With assignable allocators the writer of th=
e=20
>> new allocator class is promising that as these allocators can be assigne=
d=20
>> to each other they are equivalent when it comes to doing their work,=20
>> allocation/deallocation, and the only difference is that they do somethi=
ng=20
>> else, i.e. construction, in different ways. To me this is not a very cle=
an=20
>> design.
>>
>
> If by assignable allocators you mean my suggestion, *no*, I suggested to=
=20
> assign an allocator that cannot perform any allocation but performs=20
> construction as normal.
>
> It seems there are at least 2-3 mutually exclusive allocator suggestions=
=20
> here.
>
> - No-initialize allocator
> - Default-initialize allocator
> - No-allocate allocator
> =20
>
>> Alternatively an allocator could have a bool member which is inpected in=
=20
>> each construct to see if value or default construction is required.
>>
>
> Adding state adds overhead. If one code path doesn't want two different=
=20
> allocator behaviors, then the runtime state also means a static invariant=
=20
> isn't getting checked by the type system as it should.
>
> Applying and checking these invariants which vary from place to place, bu=
t=20
> apply to the same thing, is what assignable allocators would solve.
> =20
>
>> Maybe easier but now construct() performance is reduced which does not=
=20
>> sit well with this performance directed improvement, and it is still not=
=20
>> the default allocator.
>>
>
> If the special allocator assigns to and from the default allocator, then=
=20
> you can use the default allocator wherever you wish. Am I mistaking what=
=20
> you refer to by "assignable"?
>
> But a default allocator vector and a special allocator vector cannot hold=
=20
> the same sequence at the same time. Move semantics would be needed to=20
> switch between them. Doesn't seem to be a problem as vector doesn't allow=
=20
> concurrent reading and resizing anyway.=20
>

--=20

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

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

<div dir=3D"ltr">This is getting ever more confusing. since my last post ye=
sterday I have gotten two replies.<div><br></div><div>One from Nevin who co=
rrectly pointed out that getting an "assignable allocator" idea through the=
 committe. But this was not my suggestion, what I wrote was a similar react=
ion to (now apparently) David's suggestion.</div><div><br></div><div>The ot=
her was from David who didn't think that his code was convoluted. I can agr=
ee to that, as it can be wrapped into a function or something. However, thi=
s solution is what needs the five years of committe work, isn't it? Or do y=
ou mean that you can move construct vectors with different allocators from =
each other in the current standard? I have checked both the current standar=
d and the C++14 draft and could not find such a constructor... maybe I'm ju=
st blind.</div><div><br></div><div>By comparison I think that my suggestion=
 of adding one (1) trivial method to vector and one even more trivial metho=
d to allocator should be easier to handle in the committe work.<br><br>By t=
he way, David's code is a bit backwards as written. To do what I want you f=
irst have a vector with the special no-init construct() and then call resiz=
e() (not reserve()) on it, and finally move() it into a regular vector whic=
h is what you need for the rest of the program:</div><div><br></div><div><s=
pan style=3D"font-family: monospace; background-color: rgb(250, 250, 250); =
color: rgb(0, 0, 0);">vector</span><span style=3D"font-family: monospace; b=
ackground-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">&lt;</span><=
span style=3D"font-family: monospace; background-color: rgb(250, 250, 250);=
 color: rgb(0, 0, 136);">int</span><span style=3D"font-family: monospace; b=
ackground-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">,</span><spa=
n style=3D"font-family: monospace; background-color: rgb(250, 250, 250); co=
lor: rgb(0, 0, 0);">&nbsp;other_allocator</span><span style=3D"font-family:=
 monospace; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);"=
>&gt;</span><span style=3D"font-family: monospace; background-color: rgb(25=
0, 250, 250); color: rgb(0, 0, 0);">&nbsp;q</span><span style=3D"font-famil=
y: monospace; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0)=
;">; &nbsp;// default constructing construct() on this allocator.</span></d=
iv><div><span style=3D"font-family: monospace; background-color: rgb(250, 2=
50, 250); color: rgb(0, 0, 0);">q</span><span style=3D"font-family: monospa=
ce; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">.</span=
><span style=3D"font-family: monospace; background-color: rgb(250, 250, 250=
); color: rgb(0, 0, 0);">resize</span><span style=3D"font-family: monospace=
; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">(</span><=
span style=3D"font-family: monospace; background-color: rgb(250, 250, 250);=
 color: rgb(0, 0, 0);">&nbsp;</span><span style=3D"font-family: monospace; =
background-color: rgb(250, 250, 250); color: rgb(0, 102, 102);">30</span><s=
pan style=3D"font-family: monospace; background-color: rgb(250, 250, 250); =
color: rgb(0, 0, 0);">&nbsp;</span><span style=3D"font-family: monospace; b=
ackground-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">); &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// A nop apart from mo=
ving the end pointer</span><span style=3D"font-family: monospace; backgroun=
d-color: rgb(250, 250, 250); color: rgb(0, 0, 0);"><br>vector</span><span s=
tyle=3D"font-family: monospace; background-color: rgb(250, 250, 250); color=
: rgb(102, 102, 0);">&lt;</span><span style=3D"font-family: monospace; back=
ground-color: rgb(250, 250, 250); color: rgb(0, 0, 136);">int</span><span s=
tyle=3D"font-family: monospace; background-color: rgb(250, 250, 250); color=
: rgb(102, 102, 0);">&gt;</span><span style=3D"font-family: monospace; back=
ground-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">&nbsp;r</span><span=
 style=3D"font-family: monospace; background-color: rgb(250, 250, 250); col=
or: rgb(102, 102, 0);">(</span><span style=3D"font-family: monospace; backg=
round-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">&nbsp;std</span><spa=
n style=3D"font-family: monospace; background-color: rgb(250, 250, 250); co=
lor: rgb(102, 102, 0);">::</span><span style=3D"font-family: monospace; bac=
kground-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">move</span><span s=
tyle=3D"font-family: monospace; background-color: rgb(250, 250, 250); color=
: rgb(102, 102, 0);">(</span><span style=3D"font-family: monospace; backgro=
und-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">&nbsp;q&nbsp;</span><s=
pan style=3D"font-family: monospace; background-color: rgb(250, 250, 250); =
color: rgb(102, 102, 0);">)</span><span style=3D"font-family: monospace; ba=
ckground-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">&nbsp;</span><spa=
n style=3D"font-family: monospace; background-color: rgb(250, 250, 250); co=
lor: rgb(102, 102, 0);">);</span><span style=3D"font-family: monospace; bac=
kground-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">&nbsp;</span><span=
 style=3D"font-family: monospace; background-color: rgb(250, 250, 250); col=
or: rgb(136, 0, 0);">// Now r has standard allocator and default constructe=
d elements, ready to be filled from some function.</span><span style=3D"fon=
t-family: monospace; background-color: rgb(250, 250, 250); color: rgb(0, 0,=
 0);"><br></span></div><div><span style=3D"font-family: monospace; backgrou=
nd-color: rgb(250, 250, 250); color: rgb(136, 0, 0);"><br></span></div><div=
><br></div><div><span style=3D"font-family: monospace; background-color: rg=
b(250, 250, 250); color: rgb(136, 0, 0);"><br></span></div><div><br>Den m=
=E5ndagen den 16:e september 2013 kl. 03:55:45 UTC+2 skrev David Krauss:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>On Monda=
y, September 16, 2013 4:57:08 AM UTC+8, Bengt Gustafsson 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">I can't see that a special all=
ocator solves the problem, as vectors with different allocators are differe=
nt types. Even with the invention of &nbsp;some sort of assignable allocato=
r suggested earlier in this thread and provisions in all classes that use a=
llocators so that you can move and swap the vector with the special allocat=
or with a vector with the standard allocator it results in rather convolute=
d code compared to an extra ctor parameter or special resize method.&nbsp;<=
/div></blockquote><div><br><div style=3D"background-color:rgb(250,250,250);=
border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap=
:break-word"><code><div><span style=3D"color:#000">vector</span><span style=
=3D"color:#660">&lt;</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">int</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">&gt;</span><span style=3D"color:#000"> q</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"><br>q</span><span style=3D"c=
olor:#660">.</span><span style=3D"color:#000">reserve</span><span style=3D"=
color:#660">(</span><span style=3D"color:#000"> </span><span style=3D"color=
:#066">30</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">);</span><span style=3D"color:#000"><br>vector</span><span style=3D"colo=
r:#660">&lt;</span><span style=3D"color:#000"> </span><span style=3D"color:=
#008">int</span><span style=3D"color:#660">,</span><span style=3D"color:#00=
0"> other_allocator </span><span style=3D"color:#660">&gt;</span><span styl=
e=3D"color:#000"> r</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">move</span><span style=3D"color:#660">(</span><span style=3D"co=
lor:#000"> q </span><span style=3D"color:#660">)</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">);</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#800">// Now r has whatever special semanti=
cs.</span><span style=3D"color:#000"><br></span></div></code></div><br>Is t=
his so convoluted?<br><br>This sort of code attaches invariants to an objec=
t using the type system, allowing appropriate functions to be selected auto=
matically. Adding special members requires manual selection of functions, s=
o the user has to work to refactor code and verify that such refactoring re=
mains valid.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>A problem with the assignable allocator solution is that it =
uses allocators to differentiate something that is completely different fro=
m setting a policy on from where memory is allocated, which is what allocat=
ors are designed for. With assignable allocators the writer of the new allo=
cator class is promising that as these allocators can be assigned to each o=
ther they are equivalent when it comes to doing their work, allocation/deal=
location, and the only difference is that they do something else, i.e. cons=
truction, in different ways. To me this is not a very clean design.</div></=
div></blockquote><div><br>If by assignable allocators you mean my suggestio=
n, <i>no</i>, I suggested to assign an allocator that cannot perform any al=
location but performs construction as normal.<br><br>It seems there are at =
least 2-3 mutually exclusive allocator suggestions here.<br><br>- No-initia=
lize allocator<br>- Default-initialize allocator<br>- No-allocate allocator=
<br>&nbsp;</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"><s=
pan style=3D"font-size:13px">Alternatively an allocator could have a bool m=
ember which is inpected in each construct to see if value or default constr=
uction is required.</span></div></blockquote><div><br>Adding state adds ove=
rhead. If one code path doesn't want two different allocator behaviors, the=
n the runtime state also means a static invariant isn't getting checked by =
the type system as it should.<br><br>Applying and checking these invariants=
 which vary from place to place, but apply to the same thing, is what assig=
nable allocators would solve.<br>&nbsp;</div><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"><span style=3D"font-size:13px"> Maybe easier but=
 now construct() performance is reduced which does not sit well with this p=
erformance directed improvement, and it is still not the default allocator.=
</span></div></blockquote><div><br>If the special allocator assigns to and =
from the default allocator, then you can use the default allocator wherever=
 you wish. Am I mistaking what you refer to by "assignable"?<br><br>But a d=
efault allocator vector and a special allocator vector cannot hold the same=
 sequence at the same time. Move semantics would be needed to switch betwee=
n them. Doesn't seem to be a problem as vector doesn't allow concurrent rea=
ding and resizing anyway. <br></div></div></blockquote></div></div>

<p></p>

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

------=_Part_78_672203.1379408894307--

.

--047d7bd767ae9c201604e6957c38
Content-Type: text/plain; charset=ISO-8859-1

On 15 September 2013 20:55, David Krauss <potswa@gmail.com> wrote:

> vector< int > q;
> q.reserve( 30 );
> vector< int, other_allocator > r( std::move( q ) ); // Now r has whatever
> special semantics.
>
> Is this so convoluted?


Yes.

In the above example, you are saying that std::allocator is responsible for
allocating space while other_allocator is responsible for deallocating that
space.  Ugh.

I don't see how such a thing is workable in general, other than as a hack
between two allocators that intimately know about each other.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bd767ae9c201604e6957c38
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 15 September 2013 20:55, David Krauss <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> w=
rote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"background-color:rgb(250,250,2=
50);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-=
wrap:break-word">

<code><div><span style>vector</span><span style=3D"color:#660">&lt;</span><=
span style> </span><span style=3D"color:#008">int</span><span style> </span=
><span style=3D"color:#660">&gt;</span><span style> q</span><span style=3D"=
color:#660">;</span><span style><br>

q</span><span style=3D"color:#660">.</span><span style>reserve</span><span =
style=3D"color:#660">(</span><span style> </span><span style=3D"color:#066"=
>30</span><span style> </span><span style=3D"color:#660">);</span><span sty=
le><br>

vector</span><span style=3D"color:#660">&lt;</span><span style> </span><spa=
n style=3D"color:#008">int</span><span style=3D"color:#660">,</span><span s=
tyle> other_allocator </span><span style=3D"color:#660">&gt;</span><span st=
yle> r</span><span style=3D"color:#660">(</span><span style> std</span><spa=
n style=3D"color:#660">::</span><span style>move</span><span style=3D"color=
:#660">(</span><span style> q </span><span style=3D"color:#660">)</span><sp=
an style> </span><span style=3D"color:#660">);</span><span style> </span><s=
pan style=3D"color:#800">// Now r has whatever special semantics.</span><sp=
an style><br>

</span></div></code></div><br>Is this so convoluted?</blockquote></div><br>=
</div><div class=3D"gmail_extra">Yes.<br><br>In the above example, you are =
saying that std::allocator is responsible for allocating space while other_=
allocator is responsible for deallocating that space.=A0 Ugh.<br>

</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I don=
&#39;t see how such a thing is workable in general, other than as a hack be=
tween two allocators that intimately know about each other.</div><div class=
=3D"gmail_extra">

-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847=
) 691-1404
</div></div>

<p></p>

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

--047d7bd767ae9c201604e6957c38--

.

--089e0117601f15866804e696e850
Content-Type: text/plain; charset=ISO-8859-1

Of course, presumably you would want to use resize rather than reserve.

Billy3

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Sep 17, 2013 at 7:53 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

>
> On 15 September 2013 20:55, David Krauss <potswa@gmail.com> wrote:
>
>> vector< int > q;
>> q.reserve( 30 );
>> vector< int, other_allocator > r( std::move( q ) ); // Now r has
>> whatever special semantics.
>>
>> Is this so convoluted?
>
>
> Yes.
>
> In the above example, you are saying that std::allocator is responsible
> for allocating space while other_allocator is responsible for deallocating
> that space.  Ugh.
>
> I don't see how such a thing is workable in general, other than as a hack
> between two allocators that intimately know about each other.
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--089e0117601f15866804e696e850
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Of course, presumably you would want to use resize ra=
ther than reserve.</div><div>=A0</div><div>Billy3</div></div><div class=3D"=
gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal<=
/div><div>

<a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://git=
hub.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users=
/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/=
billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Sep 17, 2013 at 7:53 AM, Nevin L=
iber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">

<div dir=3D"ltr"><div class=3D"im"><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On 15 September 2013 20:55, David Krauss <span dir=3D"ltr=
">&lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.co=
m</a>&gt;</span> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div style=3D"border:1px solid rgb(187,187,187);background=
-color:rgb(250,250,250)">



<code><div><span>vector</span><span style=3D"color:rgb(102,102,0)">&lt;</sp=
an><span> </span><span style=3D"color:rgb(0,0,136)">int</span><span> </span=
><span style=3D"color:rgb(102,102,0)">&gt;</span><span> q</span><span style=
=3D"color:rgb(102,102,0)">;</span><span><br>



q</span><span style=3D"color:rgb(102,102,0)">.</span><span>reserve</span><s=
pan style=3D"color:rgb(102,102,0)">(</span><span> </span><span style=3D"col=
or:rgb(0,102,102)">30</span><span> </span><span style=3D"color:rgb(102,102,=
0)">);</span><span><br>



vector</span><span style=3D"color:rgb(102,102,0)">&lt;</span><span> </span>=
<span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(102,1=
02,0)">,</span><span> other_allocator </span><span style=3D"color:rgb(102,1=
02,0)">&gt;</span><span> r</span><span style=3D"color:rgb(102,102,0)">(</sp=
an><span> std</span><span style=3D"color:rgb(102,102,0)">::</span><span>mov=
e</span><span style=3D"color:rgb(102,102,0)">(</span><span> q </span><span =
style=3D"color:rgb(102,102,0)">)</span><span> </span><span style=3D"color:r=
gb(102,102,0)">);</span><span> </span><span style=3D"color:rgb(136,0,0)">//=
 Now r has whatever special semantics.</span><span><br>



</span></div></code></div><br>Is this so convoluted?</blockquote></div><br>=
</div></div><div class=3D"gmail_extra">Yes.<br><br>In the above example, yo=
u are saying that std::allocator is responsible for allocating space while =
other_allocator is responsible for deallocating that space.=A0 Ugh.<br>



</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I don=
&#39;t see how such a thing is workable in general, other than as a hack be=
tween two allocators that intimately know about each other.</div><span clas=
s=3D"HOEnZb"><font color=3D"#888888"><div class=3D"gmail_extra">



-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 <a h=
ref=3D"tel:%28847%29%20691-1404" target=3D"_blank" value=3D"+18476911404">(=
847) 691-1404</a>
</div></font></span></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--089e0117601f15866804e696e850--

.

--047d7b5daca01950a704e69742c5
Content-Type: text/plain; charset=ISO-8859-1

On 17 September 2013 11:34, Billy O'Neal <billy.oneal@gmail.com> wrote:

> Of course, presumably you would want to use resize rather than reserve.
>

That's even more convoluted, as you now have *both* allocators used for
constructing objects in the same container while only other_allocator is
used for destroying objects.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b5daca01950a704e69742c5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 17 September 2013 11:34, Bil=
ly O&#39;Neal <span dir=3D"ltr">&lt;<a href=3D"mailto:billy.oneal@gmail.com=
" target=3D"_blank">billy.oneal@gmail.com</a>&gt;</span> wrote:<br><div cla=
ss=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Of course, presumably =
you would want to use resize rather than reserve.</div></div></blockquote><=
div>

<br></div><div>That&#39;s even more convoluted, as you now have *both* allo=
cators used for constructing objects in the same container while only other=
_allocator is used for destroying objects.</div></div>-- <br>=A0Nevin &quot=
;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" ta=
rget=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404
</div></div>

<p></p>

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

--047d7b5daca01950a704e69742c5--

.

--001a1133458e73227d04e6994ba6
Content-Type: text/plain; charset=ISO-8859-1

That's true -- but calling reserve here doesn't change the size of the
vector -- it isn't legal to store anything there. Reserve never calls
allocator::construct() or anything like that. If that's what you want, you
can already do that today.

If you actually want to make it valid to store things in the vector,
however, then you're going to have to resize it.

In terms of powering this, I don't see any reason we can't have a

template<typename U, typename V>
struct allocator_can_be_assigned : public std::false_type {};

template<>
struct allocator_can_be_assigned<std::allocator, my_no_construct_allocator>
: public std::true_type {};

or similar. Any pair of allocators of course would have to deal with any of
these cases correctly if they declare they support this pattern.

There is precedent for allocators declaring support for things like this;
e.g. the existing
std::allocator_traits<T>::propagate_on_container_copy_assignment and
friends.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Sep 17, 2013 at 9:59 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 17 September 2013 11:34, Billy O'Neal <billy.oneal@gmail.com> wrote:
>
>> Of course, presumably you would want to use resize rather than reserve.
>>
>
> That's even more convoluted, as you now have *both* allocators used for
> constructing objects in the same container while only other_allocator is
> used for destroying objects.
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--001a1133458e73227d04e6994ba6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>That&#39;s true -- but calling reserve here doesn&#39=
;t change the size of the vector -- it isn&#39;t legal to store anything th=
ere. Reserve never calls allocator::construct() or anything like that. If t=
hat&#39;s what you want, you can already do that today.</div>

<div>=A0</div><div>If you actually want to make it valid to store things in=
 the vector, however, then you&#39;re going to have to resize it.</div><div=
>=A0</div><div>In terms of powering this, I don&#39;t see any reason we can=
&#39;t have a</div>

<div>=A0</div><div>template&lt;typename U, typename V&gt;</div><div>struct =
allocator_can_be_assigned : public std::false_type {};</div><div>=A0</div><=
div>template&lt;&gt;</div><div>struct allocator_can_be_assigned&lt;std::all=
ocator, my_no_construct_allocator&gt; : public std::true_type {};</div>

<div>=A0</div><div>or similar. Any pair of allocators of course would have =
to deal with any of these cases correctly if they declare they support this=
 pattern.</div><div>=A0</div><div>There is precedent for allocators declari=
ng support for things like this; e.g. the existing std::allocator_traits&lt=
;T&gt;::propagate_on_container_copy_assignment and friends.</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Sep 17, 2013 at 9:59 AM, Nevin L=
iber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"im">On 17 Septemb=
er 2013 11:34, Billy O&#39;Neal <span dir=3D"ltr">&lt;<a href=3D"mailto:bil=
ly.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail.com</a>&gt;</span> =
wrote:<br>

</div><div class=3D"gmail_quote"><div class=3D"im">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><div>Of course, presumably you would want=
 to use resize rather than reserve.</div>

</div></blockquote><div>

<br></div></div><div>That&#39;s even more convoluted, as you now have *both=
* allocators used for constructing objects in the same container while only=
 other_allocator is used for destroying objects.</div></div><div class=3D"i=
m">

-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 <a h=
ref=3D"tel:%28847%29%20691-1404" target=3D"_blank" value=3D"+18476911404">(=
847) 691-1404</a>
</div></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a1133458e73227d04e6994ba6--

.

------=_Part_62_9606858.1379448305005
Content-Type: text/plain; charset=ISO-8859-1

Yesterday I updated David's code so that it does the intended function, but
you still discuss the shortcomings of the original version. Here's the
updated version again:

vector<int, other_allocator> q;  // default constructing construct() on
this allocator.
q.resize( 30 );                  // A nop apart from moving the end pointer
vector<int> r( std::move( q ) ); // Now r has standard allocator and
default constructed elements, ready to be filled from some function.

This is not to say that I like this solution as it is a bigger change to
the library and will require a long standardization process. On the other
hand allocator_can_be_assigned will have more uses than this example which
may be worth fighting for, which could boost the use of allocators. I don't
think that there are that many allocator classes being made out there
today, which in part is due to the fact that each allocator creates a
completely new set of containers which don't interplay in non-template code.

The vector::resize_default_constructed() method by comparison is a very
small and local change. As no one has commented on this last version of
special resize methods I don't know if you still consider it unsafe. If so,
please explain how.

Den tisdagen den 17:e september 2013 kl. 21:25:36 UTC+2 skrev Billy O'Neal:
>
> That's true -- but calling reserve here doesn't change the size of the
> vector -- it isn't legal to store anything there. Reserve never calls
> allocator::construct() or anything like that. If that's what you want, you
> can already do that today.
>
> If you actually want to make it valid to store things in the vector,
> however, then you're going to have to resize it.
>
> In terms of powering this, I don't see any reason we can't have a
>
> template<typename U, typename V>
> struct allocator_can_be_assigned : public std::false_type {};
>
> template<>
> struct allocator_can_be_assigned<std::allocator,
> my_no_construct_allocator> : public std::true_type {};
>
> or similar. Any pair of allocators of course would have to deal with any
> of these cases correctly if they declare they support this pattern.
>
> There is precedent for allocators declaring support for things like this;
> e.g. the existing
> std::allocator_traits<T>::propagate_on_container_copy_assignment and
> friends.
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Tue, Sep 17, 2013 at 9:59 AM, Nevin Liber <ne...@eviloverlord.com<javascript:>
> > wrote:
>
>> On 17 September 2013 11:34, Billy O'Neal <billy...@gmail.com<javascript:>
>> > wrote:
>>
>>> Of course, presumably you would want to use resize rather than reserve.
>>>
>>
>> That's even more convoluted, as you now have *both* allocators used for
>> constructing objects in the same container while only other_allocator is
>> used for destroying objects.
>> --
>>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--

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

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

<div dir=3D"ltr">Yesterday I updated David's code so that it does the inten=
ded function, but you still discuss the shortcomings of the original versio=
n. Here's the updated version again:<div><br></div><div><div><span style=3D=
"font-family: monospace; background-color: rgb(250, 250, 250); color: rgb(0=
, 0, 0);">vector</span><span style=3D"font-family: monospace; background-co=
lor: rgb(250, 250, 250); color: rgb(102, 102, 0);">&lt;</span><span style=
=3D"font-family: monospace; background-color: rgb(250, 250, 250); color: rg=
b(0, 0, 136);">int</span><span style=3D"font-family: monospace; background-=
color: rgb(250, 250, 250); color: rgb(102, 102, 0);">,</span><span style=3D=
"font-family: monospace; background-color: rgb(250, 250, 250); color: rgb(0=
, 0, 0);">&nbsp;other_allocator</span><span style=3D"font-family: monospace=
; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">&gt;</spa=
n><span style=3D"font-family: monospace; background-color: rgb(250, 250, 25=
0); color: rgb(0, 0, 0);">&nbsp;q</span><span style=3D"font-family: monospa=
ce; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);"><wbr>; =
&nbsp;// default constructing construct() on this allocator.</span></div><d=
iv><span style=3D"font-family: monospace; background-color: rgb(250, 250, 2=
50); color: rgb(0, 0, 0);">q</span><span style=3D"font-family: monospace; b=
ackground-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">.</span><spa=
n style=3D"font-family: monospace; background-color: rgb(250, 250, 250); co=
lor: rgb(0, 0, 0);">resize</span><span style=3D"font-family: monospace; bac=
kground-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">(</span><span =
style=3D"font-family: monospace; background-color: rgb(250, 250, 250); colo=
r: rgb(0, 0, 0);">&nbsp;</span><span style=3D"font-family: monospace; backg=
round-color: rgb(250, 250, 250); color: rgb(0, 102, 102);">30</span><span s=
tyle=3D"font-family: monospace; background-color: rgb(250, 250, 250); color=
: rgb(0, 0, 0);">&nbsp;</span><span style=3D"font-family: monospace; backgr=
ound-color: rgb(250, 250, 250); color: rgb(102, 102, 0);">); &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// A nop apart from moving =
the end pointer</span><span style=3D"font-family: monospace; background-col=
or: rgb(250, 250, 250); color: rgb(0, 0, 0);"><br>vector</span><span style=
=3D"font-family: monospace; background-color: rgb(250, 250, 250); color: rg=
b(102, 102, 0);">&lt;</span><span style=3D"font-family: monospace; backgrou=
nd-color: rgb(250, 250, 250); color: rgb(0, 0, 136);">int</span><span style=
=3D"font-family: monospace; background-color: rgb(250, 250, 250); color: rg=
b(102, 102, 0);">&gt;</span><span style=3D"font-family: monospace; backgrou=
nd-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">&nbsp;r</span><span sty=
le=3D"font-family: monospace; background-color: rgb(250, 250, 250); color: =
rgb(102, 102, 0);">(</span><span style=3D"font-family: monospace; backgroun=
d-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">&nbsp;std</span><span st=
yle=3D"font-family: monospace; background-color: rgb(250, 250, 250); color:=
 rgb(102, 102, 0);">::</span><span style=3D"font-family: monospace; backgro=
und-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">move</span><span style=
=3D"font-family: monospace; background-color: rgb(250, 250, 250); color: rg=
b(102, 102, 0);">(</span><span style=3D"font-family: monospace; background-=
color: rgb(250, 250, 250); color: rgb(0, 0, 0);">&nbsp;q&nbsp;</span><span =
style=3D"font-family: monospace; background-color: rgb(250, 250, 250); colo=
r: rgb(102, 102, 0);">)</span><span style=3D"font-family: monospace; backgr=
ound-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">&nbsp;</span><span st=
yle=3D"font-family: monospace; background-color: rgb(250, 250, 250); color:=
 rgb(102, 102, 0);"><wbr>);</span><span style=3D"font-family: monospace; ba=
ckground-color: rgb(250, 250, 250); color: rgb(0, 0, 0);">&nbsp;</span><spa=
n style=3D"font-family: monospace; background-color: rgb(250, 250, 250); co=
lor: rgb(136, 0, 0);">// Now r has standard allocator and default construct=
ed elements, ready to be filled from some function.</span><span style=3D"fo=
nt-family: monospace; background-color: rgb(250, 250, 250); color: rgb(0, 0=
, 0);"><br></span></div><div><span style=3D"font-family: monospace; backgro=
und-color: rgb(250, 250, 250); color: rgb(136, 0, 0);"><br></span></div><di=
v><font face=3D"arial, sans-serif"><span style=3D"background-color: rgb(250=
, 250, 250); color: rgb(136, 0, 0);">This is not to say that I like this so=
lution as it is a bigger change to the library and will require a long stan=
dardization process. On the other hand&nbsp;</span>allocator_can_be_assigne=
d will have more uses than this example which may be worth fighting for<fon=
t color=3D"#880000">, which could boost the use of allocators. I don't thin=
k that there are that many allocator classes being made out there today, wh=
ich in part is due to the fact that each allocator creates a completely new=
 set of containers which don't interplay in non-template code.</font></font=
></div><div><font face=3D"arial, sans-serif"><font color=3D"#880000"><br></=
font></font></div><div><font face=3D"arial, sans-serif"><font color=3D"#880=
000">The vector::resize_default_constructed() method by comparison is a ver=
y small and local change. As no one has commented on this last version of s=
pecial resize methods I don't know if you still consider it unsafe. If so, =
please explain how.</font></font></div><div><font face=3D"arial, sans-serif=
"><font color=3D"#880000"><br></font></font></div>Den tisdagen den 17:e sep=
tember 2013 kl. 21:25:36 UTC+2 skrev Billy O'Neal:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div>That's true -- but calling reserv=
e here doesn't change the size of the vector -- it isn't legal to store any=
thing there. Reserve never calls allocator::construct() or anything like th=
at. If that's what you want, you can already do that today.</div>

<div>&nbsp;</div><div>If you actually want to make it valid to store things=
 in the vector, however, then you're going to have to resize it.</div><div>=
&nbsp;</div><div>In terms of powering this, I don't see any reason we can't=
 have a</div>

<div>&nbsp;</div><div>template&lt;typename U, typename V&gt;</div><div>stru=
ct allocator_can_be_assigned : public std::false_type {};</div><div>&nbsp;<=
/div><div>template&lt;&gt;</div><div>struct allocator_can_be_assigned&lt;st=
d:<wbr>:allocator, my_no_construct_allocator&gt; : public std::true_type {}=
;</div>

<div>&nbsp;</div><div>or similar. Any pair of allocators of course would ha=
ve to deal with any of these cases correctly if they declare they support t=
his pattern.</div><div>&nbsp;</div><div>There is precedent for allocators d=
eclaring support for things like this; e.g. the existing std::allocator_tra=
its&lt;T&gt;::<wbr>propagate_on_container_copy_<wbr>assignment and friends.=
</div>

</div><div><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div><=
div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:/=
/github.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/u=
sers/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/<wbr>use=
rs/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Sep 17, 2013 at 9:59 AM, Nevin L=
iber <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"0MOcTQ-OZ8oJ">ne...@eviloverlord.com</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div><div>On 17 September 2013 11:34, Billy O'Neal <span d=
ir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"0MOcTQ-OZ8oJ">billy...@gmail.com</a>&gt;</span> wrote:<br>

</div><div class=3D"gmail_quote"><div>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><div>Of course, presumably you would want=
 to use resize rather than reserve.</div>

</div></blockquote><div>

<br></div></div><div>That's even more convoluted, as you now have *both* al=
locators used for constructing objects in the same container while only oth=
er_allocator is used for destroying objects.</div></div><div>

-- <br>&nbsp;Nevin ":-)" Liber&nbsp; &lt;mailto:<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"0MOcTQ-OZ8oJ">ne...@eviloverlord.co=
m</a><wbr>&gt;&nbsp; <a value=3D"+18476911404">(847) 691-1404</a>
</div></div></div><div><div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
0MOcTQ-OZ8oJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"0MOcTQ-OZ8oJ">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></div>

<p></p>

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

------=_Part_62_9606858.1379448305005--

.

--089e01160706f38d9304e69a0b49
Content-Type: text/plain; charset=ISO-8859-1

resize() already default constructs elements. I don't understand your
proposal. If you really meant resize_uninitialized or something like that
then you have to solve the hairy problem to define what happens in the
vector if elements are uninitialized when the vector is destroyed.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Sep 17, 2013 at 1:05 PM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> Yesterday I updated David's code so that it does the intended function,
> but you still discuss the shortcomings of the original version. Here's the
> updated version again:
>
> vector<int, other_allocator> q**;  // default constructing construct() on
> this allocator.
> q.resize( 30 );                  // A nop apart from moving the end
> pointer
> vector<int> r( std::move( q ) **); // Now r has standard allocator and
> default constructed elements, ready to be filled from some function.
>
> This is not to say that I like this solution as it is a bigger change to
> the library and will require a long standardization process. On the other
> hand allocator_can_be_assigned will have more uses than this example
> which may be worth fighting for, which could boost the use of allocators.
> I don't think that there are that many allocator classes being made out
> there today, which in part is due to the fact that each allocator creates a
> completely new set of containers which don't interplay in non-template code.
>
> The vector::resize_default_constructed() method by comparison is a very
> small and local change. As no one has commented on this last version of
> special resize methods I don't know if you still consider it unsafe. If so,
> please explain how.
>
> Den tisdagen den 17:e september 2013 kl. 21:25:36 UTC+2 skrev Billy O'Neal:
>>
>> That's true -- but calling reserve here doesn't change the size of the
>> vector -- it isn't legal to store anything there. Reserve never calls
>> allocator::construct() or anything like that. If that's what you want, you
>> can already do that today.
>>
>> If you actually want to make it valid to store things in the vector,
>> however, then you're going to have to resize it.
>>
>> In terms of powering this, I don't see any reason we can't have a
>>
>> template<typename U, typename V>
>> struct allocator_can_be_assigned : public std::false_type {};
>>
>> template<>
>> struct allocator_can_be_assigned<std:**:allocator,
>> my_no_construct_allocator> : public std::true_type {};
>>
>> or similar. Any pair of allocators of course would have to deal with any
>> of these cases correctly if they declare they support this pattern.
>>
>> There is precedent for allocators declaring support for things like this;
>> e.g. the existing std::allocator_traits<T>::**
>> propagate_on_container_copy_**assignment and friends.
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/**users/82320/billy-oneal<http://stackoverflow.com/users/82320/billy-oneal>
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Tue, Sep 17, 2013 at 9:59 AM, Nevin Liber <ne...@eviloverlord.com>wrote:
>>
>>> On 17 September 2013 11:34, Billy O'Neal <billy...@gmail.com> wrote:
>>>
>>>> Of course, presumably you would want to use resize rather than reserve.
>>>>
>>>
>>> That's even more convoluted, as you now have *both* allocators used for
>>> constructing objects in the same container while only other_allocator is
>>> used for destroying objects.
>>> --
>>>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com**>  (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-proposal...@**isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>>
>>> Visit this group at http://groups.google.com/a/**isocpp.org/group/std-**
>>> proposals/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>.
>>>
>>
>>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--089e01160706f38d9304e69a0b49
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>resize() already default constructs elements. I don&#=
39;t understand your proposal. If you really meant resize_uninitialized or =
something like that then you have to solve the hairy problem to define what=
 happens in the vector if elements are uninitialized when the vector is des=
troyed.</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Sep 17, 2013 at 1:05 PM, Bengt G=
ustafsson <span dir=3D"ltr">&lt;<a href=3D"mailto:bengt.gustafsson@beamways=
..com" target=3D"_blank">bengt.gustafsson@beamways.com</a>&gt;</span> wrote:=
<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Yesterday I updated David&#=
39;s code so that it does the intended function, but you still discuss the =
shortcomings of the original version. Here&#39;s the updated version again:=
<div>

<br></div><div><div class=3D"im"><div><span style=3D"font-family:monospace;=
background-color:rgb(250,250,250)">vector</span><span style=3D"color:rgb(10=
2,102,0);font-family:monospace;background-color:rgb(250,250,250)">&lt;</spa=
n><span style=3D"color:rgb(0,0,136);font-family:monospace;background-color:=
rgb(250,250,250)">int</span><span style=3D"color:rgb(102,102,0);font-family=
:monospace;background-color:rgb(250,250,250)">,</span><span style=3D"font-f=
amily:monospace;background-color:rgb(250,250,250)">=A0other_allocator</span=
><span style=3D"color:rgb(102,102,0);font-family:monospace;background-color=
:rgb(250,250,250)">&gt;</span><span style=3D"font-family:monospace;backgrou=
nd-color:rgb(250,250,250)">=A0q</span><span style=3D"color:rgb(102,102,0);f=
ont-family:monospace;background-color:rgb(250,250,250)"><u></u>; =A0// defa=
ult constructing construct() on this allocator.</span></div>

<div><span style=3D"font-family:monospace;background-color:rgb(250,250,250)=
">q</span><span style=3D"color:rgb(102,102,0);font-family:monospace;backgro=
und-color:rgb(250,250,250)">.</span><span style=3D"font-family:monospace;ba=
ckground-color:rgb(250,250,250)">resize</span><span style=3D"color:rgb(102,=
102,0);font-family:monospace;background-color:rgb(250,250,250)">(</span><sp=
an style=3D"font-family:monospace;background-color:rgb(250,250,250)">=A0</s=
pan><span style=3D"color:rgb(0,102,102);font-family:monospace;background-co=
lor:rgb(250,250,250)">30</span><span style=3D"font-family:monospace;backgro=
und-color:rgb(250,250,250)">=A0</span><span style=3D"color:rgb(102,102,0);f=
ont-family:monospace;background-color:rgb(250,250,250)">); =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0// A nop apart from moving the end pointer</span><span s=
tyle=3D"font-family:monospace;background-color:rgb(250,250,250)"><br>

vector</span><span style=3D"color:rgb(102,102,0);font-family:monospace;back=
ground-color:rgb(250,250,250)">&lt;</span><span style=3D"color:rgb(0,0,136)=
;font-family:monospace;background-color:rgb(250,250,250)">int</span><span s=
tyle=3D"color:rgb(102,102,0);font-family:monospace;background-color:rgb(250=
,250,250)">&gt;</span><span style=3D"font-family:monospace;background-color=
:rgb(250,250,250)">=A0r</span><span style=3D"color:rgb(102,102,0);font-fami=
ly:monospace;background-color:rgb(250,250,250)">(</span><span style=3D"font=
-family:monospace;background-color:rgb(250,250,250)">=A0std</span><span sty=
le=3D"color:rgb(102,102,0);font-family:monospace;background-color:rgb(250,2=
50,250)">::</span><span style=3D"font-family:monospace;background-color:rgb=
(250,250,250)">move</span><span style=3D"color:rgb(102,102,0);font-family:m=
onospace;background-color:rgb(250,250,250)">(</span><span style=3D"font-fam=
ily:monospace;background-color:rgb(250,250,250)">=A0q=A0</span><span style=
=3D"color:rgb(102,102,0);font-family:monospace;background-color:rgb(250,250=
,250)">)</span><span style=3D"font-family:monospace;background-color:rgb(25=
0,250,250)">=A0</span><span style=3D"color:rgb(102,102,0);font-family:monos=
pace;background-color:rgb(250,250,250)"><u></u>);</span><span style=3D"font=
-family:monospace;background-color:rgb(250,250,250)">=A0</span><span style=
=3D"color:rgb(136,0,0);font-family:monospace;background-color:rgb(250,250,2=
50)">// Now r has standard allocator and default constructed elements, read=
y to be filled from some function.</span><span style=3D"font-family:monospa=
ce;background-color:rgb(250,250,250)"><br>

</span></div><div><span style=3D"color:rgb(136,0,0);font-family:monospace;b=
ackground-color:rgb(250,250,250)"><br></span></div></div><div><font face=3D=
"arial, sans-serif"><span style=3D"color:rgb(136,0,0);background-color:rgb(=
250,250,250)">This is not to say that I like this solution as it is a bigge=
r change to the library and will require a long standardization process. On=
 the other hand=A0</span>allocator_can_be_assigned will have more uses than=
 this example which may be worth fighting for<font color=3D"#880000">, whic=
h could boost the use of allocators. I don&#39;t think that there are that =
many allocator classes being made out there today, which in part is due to =
the fact that each allocator creates a completely new set of containers whi=
ch don&#39;t interplay in non-template code.</font></font></div>

<div><font face=3D"arial, sans-serif"><font color=3D"#880000"><br></font></=
font></div><div><font face=3D"arial, sans-serif"><font color=3D"#880000">Th=
e vector::resize_default_constructed() method by comparison is a very small=
 and local change. As no one has commented on this last version of special =
resize methods I don&#39;t know if you still consider it unsafe. If so, ple=
ase explain how.</font></font></div>

<div><font face=3D"arial, sans-serif"><font color=3D"#880000"><br></font></=
font></div>Den tisdagen den 17:e september 2013 kl. 21:25:36 UTC+2 skrev Bi=
lly O&#39;Neal:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wid=
th:1px;border-left-style:solid">

<div class=3D"im"><div dir=3D"ltr"><div>That&#39;s true -- but calling rese=
rve here doesn&#39;t change the size of the vector -- it isn&#39;t legal to=
 store anything there. Reserve never calls allocator::construct() or anythi=
ng like that. If that&#39;s what you want, you can already do that today.</=
div>



<div>=A0</div><div>If you actually want to make it valid to store things in=
 the vector, however, then you&#39;re going to have to resize it.</div><div=
>=A0</div><div>In terms of powering this, I don&#39;t see any reason we can=
&#39;t have a</div>



<div>=A0</div><div>template&lt;typename U, typename V&gt;</div><div>struct =
allocator_can_be_assigned : public std::false_type {};</div><div>=A0</div><=
div>template&lt;&gt;</div><div>struct allocator_can_be_assigned&lt;std:<u><=
/u>:allocator, my_no_construct_allocator&gt; : public std::true_type {};</d=
iv>



<div>=A0</div><div>or similar. Any pair of allocators of course would have =
to deal with any of these cases correctly if they declare they support this=
 pattern.</div><div>=A0</div><div>There is precedent for allocators declari=
ng support for things like this; e.g. the existing std::allocator_traits&lt=
;T&gt;::<u></u>propagate_on_container_copy_<u></u>assignment and friends.</=
div>



</div></div><div><div class=3D"im"><br clear=3D"all"><div><div dir=3D"ltr">=
<div>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal=
/" target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=
=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">htt=
p://stackoverflow.com/<u></u>users/82320/billy-oneal</a></div>



<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br></div><div class=3D"gmail_quote">On Tue, Sep 17, 2013 at 9:59 AM, N=
evin Liber <span dir=3D"ltr">&lt;<a>ne...@eviloverlord.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid">



<div dir=3D"ltr"><div><div class=3D"im"><div>On 17 September 2013 11:34, Bi=
lly O&#39;Neal <span dir=3D"ltr">&lt;<a>billy...@gmail.com</a>&gt;</span> w=
rote:<br>

</div><div class=3D"gmail_quote"><div>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><div>Of course, presumably you would want=
 to use resize rather than reserve.</div>



</div></blockquote><div>

<br></div></div><div>That&#39;s even more convoluted, as you now have *both=
* allocators used for constructing objects in the same container while only=
 other_allocator is used for destroying objects.</div></div></div><div>



-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a>ne...@eviloverlord.c=
om</a><u></u>&gt;=A0 <a value=3D"+18476911404">(847) 691-1404</a>
</div></div></div><div><div><div class=3D"im">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div class=
=3D"im"><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></div></blockquote></div><br></div>
</blockquote></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--089e01160706f38d9304e69a0b49--

.

------=_Part_3971_4574791.1379478658263
Content-Type: text/plain; charset=ISO-8859-1

No it doesn't, it value-constructs the elements, which means that basic
types and pointers are zeroed out. What I'm proposing is a way to fill a
vector of such types with "garbage" instead, i.e. do nothing. This saves
time when you use the vector for instance to receive data from a legacy
function or I/O library that expects buffers of simple types such as char.
For types with constructors there is no difference.

Den tisdagen den 17:e september 2013 kl. 22:19:26 UTC+2 skrev Billy O'Neal:
>
> resize() already default constructs elements. I don't understand your
> proposal. If you really meant resize_uninitialized or something like that
> then you have to solve the hairy problem to define what happens in the
> vector if elements are uninitialized when the vector is destroyed.
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Tue, Sep 17, 2013 at 1:05 PM, Bengt Gustafsson <
> bengt.gu...@beamways.com <javascript:>> wrote:
>
>> Yesterday I updated David's code so that it does the intended function,
>> but you still discuss the shortcomings of the original version. Here's the
>> updated version again:
>>
>> vector<int, other_allocator> q**;  // default constructing construct()
>> on this allocator.
>> q.resize( 30 );                  // A nop apart from moving the end
>> pointer
>> vector<int> r( std::move( q ) **); // Now r has standard allocator and
>> default constructed elements, ready to be filled from some function.
>>
>> This is not to say that I like this solution as it is a bigger change to
>> the library and will require a long standardization process. On the other
>> hand allocator_can_be_assigned will have more uses than this example
>> which may be worth fighting for, which could boost the use of
>> allocators. I don't think that there are that many allocator classes being
>> made out there today, which in part is due to the fact that each allocator
>> creates a completely new set of containers which don't interplay in
>> non-template code.
>>
>> The vector::resize_default_constructed() method by comparison is a very
>> small and local change. As no one has commented on this last version of
>> special resize methods I don't know if you still consider it unsafe. If so,
>> please explain how.
>>
>> Den tisdagen den 17:e september 2013 kl. 21:25:36 UTC+2 skrev Billy
>> O'Neal:
>>>
>>> That's true -- but calling reserve here doesn't change the size of the
>>> vector -- it isn't legal to store anything there. Reserve never calls
>>> allocator::construct() or anything like that. If that's what you want, you
>>> can already do that today.
>>>
>>> If you actually want to make it valid to store things in the vector,
>>> however, then you're going to have to resize it.
>>>
>>> In terms of powering this, I don't see any reason we can't have a
>>>
>>> template<typename U, typename V>
>>> struct allocator_can_be_assigned : public std::false_type {};
>>>
>>> template<>
>>> struct allocator_can_be_assigned<std:**:allocator,
>>> my_no_construct_allocator> : public std::true_type {};
>>>
>>> or similar. Any pair of allocators of course would have to deal with any
>>> of these cases correctly if they declare they support this pattern.
>>>
>>> There is precedent for allocators declaring support for things like
>>> this; e.g. the existing std::allocator_traits<T>::**
>>> propagate_on_container_copy_**assignment and friends.
>>>
>>> Billy O'Neal
>>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>>> http://stackoverflow.com/**users/82320/billy-oneal<http://stackoverflow.com/users/82320/billy-oneal>
>>> Malware Response Instructor - BleepingComputer.com
>>>
>>>
>>> On Tue, Sep 17, 2013 at 9:59 AM, Nevin Liber <ne...@eviloverlord.com>wrote:
>>>
>>>> On 17 September 2013 11:34, Billy O'Neal <billy...@gmail.com> wrote:
>>>>
>>>>> Of course, presumably you would want to use resize rather than reserve.
>>>>>
>>>>
>>>> That's even more convoluted, as you now have *both* allocators used for
>>>> constructing objects in the same container while only other_allocator is
>>>> used for destroying objects.
>>>> --
>>>>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com**>  (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-proposal...@**isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>
>>>> Visit this group at http://groups.google.com/a/**isocpp.org/group/std-*
>>>> *proposals/<http://groups.google.com/a/isocpp.org/group/std-proposals/>
>>>> .
>>>>
>>>
>>>  --
>>
>> ---
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--

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

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

<div dir=3D"ltr">No it doesn't, it value-constructs the elements, which mea=
ns that basic types and pointers are zeroed out. What I'm proposing is a wa=
y to fill a vector of such types with "garbage" instead, i.e. do nothing. T=
his saves time when you use the vector for instance to receive data from a =
legacy function or I/O library that expects buffers of simple types such as=
 char. For types with constructors there is no difference.<br><br>Den tisda=
gen den 17:e september 2013 kl. 22:19:26 UTC+2 skrev Billy O'Neal:<blockquo=
te 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>resize() already =
default constructs elements. I don't understand your proposal. If you reall=
y meant resize_uninitialized or something like that then you have to solve =
the hairy problem to define what happens in the vector if elements are unin=
itialized when the vector is destroyed.</div>

</div><div><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div><=
div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:/=
/github.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/u=
sers/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/<wbr>use=
rs/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Sep 17, 2013 at 1:05 PM, Bengt G=
ustafsson <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"WlVQpYSi4SUJ">bengt.gu...@beamways.com</a><wbr>&gt;=
</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Yesterday I updated David's=
 code so that it does the intended function, but you still discuss the shor=
tcomings of the original version. Here's the updated version again:<div>

<br></div><div><div><div><span style=3D"font-family:monospace;background-co=
lor:rgb(250,250,250)">vector</span><span style=3D"color:rgb(102,102,0);font=
-family:monospace;background-color:rgb(250,250,250)">&lt;</span><span style=
=3D"color:rgb(0,0,136);font-family:monospace;background-color:rgb(250,250,2=
50)">int</span><span style=3D"color:rgb(102,102,0);font-family:monospace;ba=
ckground-color:rgb(250,250,250)">,</span><span style=3D"font-family:monospa=
ce;background-color:rgb(250,250,250)">&nbsp;other_allocator</span><span sty=
le=3D"color:rgb(102,102,0);font-family:monospace;background-color:rgb(250,2=
50,250)">&gt;</span><span style=3D"font-family:monospace;background-color:r=
gb(250,250,250)">&nbsp;q</span><span style=3D"color:rgb(102,102,0);font-fam=
ily:monospace;background-color:rgb(250,250,250)"><u></u><wbr>; &nbsp;// def=
ault constructing construct() on this allocator.</span></div>

<div><span style=3D"font-family:monospace;background-color:rgb(250,250,250)=
">q</span><span style=3D"color:rgb(102,102,0);font-family:monospace;backgro=
und-color:rgb(250,250,250)">.</span><span style=3D"font-family:monospace;ba=
ckground-color:rgb(250,250,250)">resize</span><span style=3D"color:rgb(102,=
102,0);font-family:monospace;background-color:rgb(250,250,250)">(</span><sp=
an style=3D"font-family:monospace;background-color:rgb(250,250,250)">&nbsp;=
</span><span style=3D"color:rgb(0,102,102);font-family:monospace;background=
-color:rgb(250,250,250)">30</span><span style=3D"font-family:monospace;back=
ground-color:rgb(250,250,250)">&nbsp;</span><span style=3D"color:rgb(102,10=
2,0);font-family:monospace;background-color:rgb(250,250,250)">); &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// A nop apart from mov=
ing the end pointer</span><span style=3D"font-family:monospace;background-c=
olor:rgb(250,250,250)"><br>

vector</span><span style=3D"color:rgb(102,102,0);font-family:monospace;back=
ground-color:rgb(250,250,250)">&lt;</span><span style=3D"color:rgb(0,0,136)=
;font-family:monospace;background-color:rgb(250,250,250)">int</span><span s=
tyle=3D"color:rgb(102,102,0);font-family:monospace;background-color:rgb(250=
,250,250)">&gt;</span><span style=3D"font-family:monospace;background-color=
:rgb(250,250,250)">&nbsp;r</span><span style=3D"color:rgb(102,102,0);font-f=
amily:monospace;background-color:rgb(250,250,250)">(</span><span style=3D"f=
ont-family:monospace;background-color:rgb(250,250,250)">&nbsp;std</span><sp=
an style=3D"color:rgb(102,102,0);font-family:monospace;background-color:rgb=
(250,250,250)">::</span><span style=3D"font-family:monospace;background-col=
or:rgb(250,250,250)">move</span><span style=3D"color:rgb(102,102,0);font-fa=
mily:monospace;background-color:rgb(250,250,250)">(</span><span style=3D"fo=
nt-family:monospace;background-color:rgb(250,250,250)">&nbsp;q&nbsp;</span>=
<span style=3D"color:rgb(102,102,0);font-family:monospace;background-color:=
rgb(250,250,250)">)</span><span style=3D"font-family:monospace;background-c=
olor:rgb(250,250,250)">&nbsp;</span><span style=3D"color:rgb(102,102,0);fon=
t-family:monospace;background-color:rgb(250,250,250)"><u></u><wbr>);</span>=
<span style=3D"font-family:monospace;background-color:rgb(250,250,250)">&nb=
sp;</span><span style=3D"color:rgb(136,0,0);font-family:monospace;backgroun=
d-color:rgb(250,250,250)">// Now r has standard allocator and default const=
ructed elements, ready to be filled from some function.</span><span style=
=3D"font-family:monospace;background-color:rgb(250,250,250)"><br>

</span></div><div><span style=3D"color:rgb(136,0,0);font-family:monospace;b=
ackground-color:rgb(250,250,250)"><br></span></div></div><div><font face=3D=
"arial, sans-serif"><span style=3D"color:rgb(136,0,0);background-color:rgb(=
250,250,250)">This is not to say that I like this solution as it is a bigge=
r change to the library and will require a long standardization process. On=
 the other hand&nbsp;</span>allocator_can_be_assigned will have more uses t=
han this example which may be worth fighting for<font color=3D"#880000">, w=
hich could boost the use of allocators. I don't think that there are that m=
any allocator classes being made out there today, which in part is due to t=
he fact that each allocator creates a completely new set of containers whic=
h don't interplay in non-template code.</font></font></div>

<div><font face=3D"arial, sans-serif"><font color=3D"#880000"><br></font></=
font></div><div><font face=3D"arial, sans-serif"><font color=3D"#880000">Th=
e vector::resize_default_<wbr>constructed() method by comparison is a very =
small and local change. As no one has commented on this last version of spe=
cial resize methods I don't know if you still consider it unsafe. If so, pl=
ease explain how.</font></font></div>

<div><font face=3D"arial, sans-serif"><font color=3D"#880000"><br></font></=
font></div>Den tisdagen den 17:e september 2013 kl. 21:25:36 UTC+2 skrev Bi=
lly O'Neal:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1=
px;border-left-style:solid">

<div><div dir=3D"ltr"><div>That's true -- but calling reserve here doesn't =
change the size of the vector -- it isn't legal to store anything there. Re=
serve never calls allocator::construct() or anything like that. If that's w=
hat you want, you can already do that today.</div>



<div>&nbsp;</div><div>If you actually want to make it valid to store things=
 in the vector, however, then you're going to have to resize it.</div><div>=
&nbsp;</div><div>In terms of powering this, I don't see any reason we can't=
 have a</div>



<div>&nbsp;</div><div>template&lt;typename U, typename V&gt;</div><div>stru=
ct allocator_can_be_assigned : public std::false_type {};</div><div>&nbsp;<=
/div><div>template&lt;&gt;</div><div>struct allocator_can_be_assigned&lt;st=
d:<u></u><wbr>:allocator, my_no_construct_allocator&gt; : public std::true_=
type {};</div>



<div>&nbsp;</div><div>or similar. Any pair of allocators of course would ha=
ve to deal with any of these cases correctly if they declare they support t=
his pattern.</div><div>&nbsp;</div><div>There is precedent for allocators d=
eclaring support for things like this; e.g. the existing std::allocator_tra=
its&lt;T&gt;::<u></u>prop<wbr>agate_on_container_copy_<u></u>assign<wbr>men=
t and friends.</div>



</div></div><div><div><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O'=
Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_bla=
nk">https://github.com/BillyONeal/</a></div><div><a href=3D"http://stackove=
rflow.com/users/82320/billy-oneal" target=3D"_blank">http://stackoverflow.c=
om/<u></u>users<wbr>/82320/billy-oneal</a></div>



<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br></div><div class=3D"gmail_quote">On Tue, Sep 17, 2013 at 9:59 AM, N=
evin Liber <span dir=3D"ltr">&lt;<a>ne...@eviloverlord.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid">



<div dir=3D"ltr"><div><div><div>On 17 September 2013 11:34, Billy O'Neal <s=
pan dir=3D"ltr">&lt;<a>billy...@gmail.com</a>&gt;</span> wrote:<br>

</div><div class=3D"gmail_quote"><div>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><div>Of course, presumably you would want=
 to use resize rather than reserve.</div>



</div></blockquote><div>

<br></div></div><div>That's even more convoluted, as you now have *both* al=
locators used for constructing objects in the same container while only oth=
er_allocator is used for destroying objects.</div></div></div><div>



-- <br>&nbsp;Nevin ":-)" Liber&nbsp; &lt;mailto:<a>ne...@eviloverlord.com</=
a><u></u><wbr>&gt;&nbsp; <a value=3D"+18476911404">(847) 691-1404</a>
</div></div></div><div><div><div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>iso<wbr=
>cpp.org/group/std-<u></u>proposals/</a>.<br>
</div></div></div></blockquote></div><br></div>
</blockquote></div></div><div><div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
WlVQpYSi4SUJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"WlVQpYSi4SUJ">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div>

<p></p>

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

------=_Part_3971_4574791.1379478658263--

.

--047d7b5d33d496eda004e6aa6900
Content-Type: text/plain; charset=ISO-8859-1

There is some ambiguity here -- the "default constructor" of a built in
value, e.g. that the user requests by doing "new int[42]()" (note the extra
parens) zero initializes the object.  In fact, N3691 23.3.7.3
[vector.capacity]/12 (emphasis mine) says:

*void resize(size_type sz);*
Effects: If sz <= size(), equivalent to calling pop_back() size() - sz
times. If size() < sz, *appends sz - size() default-inserted elements* to
the sequence.

I can't find anywhere in the standard where "default construct" is a
concept. The closest thing I can find is "default initialize", N3691 8.5
[dcl.init]/7.

How about something like:

class default_initialized_t {} default_initialized;

// in vector
void resize(size_type sz, default_initialized_t);

// use
vector<int> contains_trivial_type;
contains_trivial_type.resize(123, default_initialized);

Of course, this proposal has absolutely nothing to do with getting rid of
the capacity check originally proposed in this thread.


Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Sep 17, 2013 at 9:30 PM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> No it doesn't, it value-constructs the elements, which means that basic
> types and pointers are zeroed out. What I'm proposing is a way to fill a
> vector of such types with "garbage" instead, i.e. do nothing. This saves
> time when you use the vector for instance to receive data from a legacy
> function or I/O library that expects buffers of simple types such as char.
> For types with constructors there is no difference.
>
> Den tisdagen den 17:e september 2013 kl. 22:19:26 UTC+2 skrev Billy O'Neal:
>>
>> resize() already default constructs elements. I don't understand your
>> proposal. If you really meant resize_uninitialized or something like that
>> then you have to solve the hairy problem to define what happens in the
>> vector if elements are uninitialized when the vector is destroyed.
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/**users/82320/billy-oneal<http://stackoverflow.com/users/82320/billy-oneal>
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Tue, Sep 17, 2013 at 1:05 PM, Bengt Gustafsson <
>> bengt.gu...@beamways.com**> wrote:
>>
>>> Yesterday I updated David's code so that it does the intended function,
>>> but you still discuss the shortcomings of the original version. Here's the
>>> updated version again:
>>>
>>> vector<int, other_allocator> q****;  // default constructing
>>> construct() on this allocator.
>>> q.resize( 30 );                  // A nop apart from moving the end
>>> pointer
>>> vector<int> r( std::move( q ) ****); // Now r has standard allocator
>>> and default constructed elements, ready to be filled from some function.
>>>
>>> This is not to say that I like this solution as it is a bigger change to
>>> the library and will require a long standardization process. On the other
>>> hand allocator_can_be_assigned will have more uses than this example
>>> which may be worth fighting for, which could boost the use of
>>> allocators. I don't think that there are that many allocator classes being
>>> made out there today, which in part is due to the fact that each allocator
>>> creates a completely new set of containers which don't interplay in
>>> non-template code.
>>>
>>> The vector::resize_default_**constructed() method by comparison is a
>>> very small and local change. As no one has commented on this last version
>>> of special resize methods I don't know if you still consider it unsafe. If
>>> so, please explain how.
>>>
>>> Den tisdagen den 17:e september 2013 kl. 21:25:36 UTC+2 skrev Billy
>>> O'Neal:
>>>>
>>>> That's true -- but calling reserve here doesn't change the size of the
>>>> vector -- it isn't legal to store anything there. Reserve never calls
>>>> allocator::construct() or anything like that. If that's what you want, you
>>>> can already do that today.
>>>>
>>>> If you actually want to make it valid to store things in the vector,
>>>> however, then you're going to have to resize it.
>>>>
>>>> In terms of powering this, I don't see any reason we can't have a
>>>>
>>>> template<typename U, typename V>
>>>> struct allocator_can_be_assigned : public std::false_type {};
>>>>
>>>> template<>
>>>> struct allocator_can_be_assigned<std:****:allocator,
>>>> my_no_construct_allocator> : public std::true_type {};
>>>>
>>>> or similar. Any pair of allocators of course would have to deal with
>>>> any of these cases correctly if they declare they support this pattern.
>>>>
>>>> There is precedent for allocators declaring support for things like
>>>> this; e.g. the existing std::allocator_traits<T>::**prop**
>>>> agate_on_container_copy_**assign**ment and friends.
>>>>
>>>> Billy O'Neal
>>>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>>>> http://stackoverflow.com/**users**/82320/billy-oneal<http://stackoverflow.com/users/82320/billy-oneal>
>>>> Malware Response Instructor - BleepingComputer.com
>>>>
>>>>
>>>> On Tue, Sep 17, 2013 at 9:59 AM, Nevin Liber <ne...@eviloverlord.com>wrote:
>>>>
>>>>> On 17 September 2013 11:34, Billy O'Neal <billy...@gmail.com> wrote:
>>>>>
>>>>>> Of course, presumably you would want to use resize rather than
>>>>>> reserve.
>>>>>>
>>>>>
>>>>> That's even more convoluted, as you now have *both* allocators used
>>>>> for constructing objects in the same container while only other_allocator
>>>>> is used for destroying objects.
>>>>> --
>>>>>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com****>  (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-proposal...@**isocpp.org.
>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>>
>>>>> Visit this group at http://groups.google.com/a/**iso**
>>>>> cpp.org/group/std-**proposals/<http://groups.google.com/a/isocpp.org/group/std-proposals/>
>>>>> .
>>>>>
>>>>
>>>>  --
>>>
>>> ---
>>> 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-proposal...@**isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at http://groups.google.com/a/**isocpp.org/group/std-**
>>> proposals/ <http://groups.google.com/a/isocpp.org/group/std-proposals/>.
>>>
>>
>>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--047d7b5d33d496eda004e6aa6900
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>There is some ambiguity here -- the &quot;default con=
structor&quot; of a built in value, e.g. that the user requests by doing &q=
uot;new int[42]()&quot; (note the extra parens) zero initializes the object=
..=A0 In fact, N3691 23.3.7.3 [vector.capacity]/12 (emphasis mine) says:</di=
v>

<div>=A0</div><div><strong>void resize(size_type sz);</strong><br>Effects: =
If sz &lt;=3D size(), equivalent to calling pop_back() size() - sz times. I=
f size() &lt; sz, <strong>appends sz - size() default-inserted elements</st=
rong> to the sequence.=A0</div>

<div>=A0</div><div>I can&#39;t find anywhere in the standard where &quot;de=
fault construct&quot; is a concept. The closest thing I can find is &quot;d=
efault initialize&quot;, N3691 8.5 [dcl.init]/7.</div><div>=A0</div><div>Ho=
w about something like:</div>

<div>=A0</div><div><font face=3D"courier new,monospace">class default_initi=
alized_t {} default_initialized;</font></div><div><font face=3D"courier new=
,monospace">=A0</font></div><div><font face=3D"courier new,monospace">// in=
 vector</font></div>

<div><font face=3D"courier new,monospace">void resize(size_type sz, default=
_initialized_t);</font></div><div><font face=3D"courier new,monospace"></fo=
nt>=A0</div><div><font face=3D"courier new,monospace">// use</font></div><d=
iv>
<font face=3D"courier new,monospace">vector&lt;int&gt; contains_trivial_typ=
e;</font></div>
<div><font face=3D"courier new,monospace">contains_trivial_type.resize(123,=
 default_initialized);</font></div><div>=A0</div><div>Of course, this propo=
sal has absolutely nothing to do with getting rid of the capacity check ori=
ginally proposed in this thread.</div>

<div>=A0</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div =
dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.or=
g/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</a></div><d=
iv><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_=
blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Sep 17, 2013 at 9:30 PM, Bengt G=
ustafsson <span dir=3D"ltr">&lt;<a href=3D"mailto:bengt.gustafsson@beamways=
..com" target=3D"_blank">bengt.gustafsson@beamways.com</a>&gt;</span> wrote:=
<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">No it doesn&#39;t, it value=
-constructs the elements, which means that basic types and pointers are zer=
oed out. What I&#39;m proposing is a way to fill a vector of such types wit=
h &quot;garbage&quot; instead, i.e. do nothing. This saves time when you us=
e the vector for instance to receive data from a legacy function or I/O lib=
rary that expects buffers of simple types such as char. For types with cons=
tructors there is no difference.<br>

<br>Den tisdagen den 17:e september 2013 kl. 22:19:26 UTC+2 skrev Billy O&#=
39;Neal:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;=
border-left-style:solid">

<div class=3D"im"><div dir=3D"ltr"><div>resize() already default constructs=
 elements. I don&#39;t understand your proposal. If you really meant resize=
_uninitialized or something like that then you have to solve the hairy prob=
lem to define what happens in the vector if elements are uninitialized when=
 the vector is destroyed.</div>



</div></div><div><div class=3D"im"><br clear=3D"all"><div><div dir=3D"ltr">=
<div>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal=
/" target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=
=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">htt=
p://stackoverflow.com/<u></u>users/82320/billy-oneal</a></div>



<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br></div><div><div class=3D"h5"><div class=3D"gmail_quote">On Tue, Sep=
 17, 2013 at 1:05 PM, Bengt Gustafsson <span dir=3D"ltr">&lt;<a>bengt.gu...=
@beamways.com</a><u></u>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">Yesterday I updated David&#39;s code so t=
hat it does the intended function, but you still discuss the shortcomings o=
f the original version. Here&#39;s the updated version again:<div>



<br></div><div><div><div><span style=3D"font-family:monospace;background-co=
lor:rgb(250,250,250)">vector</span><span style=3D"color:rgb(102,102,0);font=
-family:monospace;background-color:rgb(250,250,250)">&lt;</span><span style=
=3D"color:rgb(0,0,136);font-family:monospace;background-color:rgb(250,250,2=
50)">int</span><span style=3D"color:rgb(102,102,0);font-family:monospace;ba=
ckground-color:rgb(250,250,250)">,</span><span style=3D"font-family:monospa=
ce;background-color:rgb(250,250,250)">=A0other_allocator</span><span style=
=3D"color:rgb(102,102,0);font-family:monospace;background-color:rgb(250,250=
,250)">&gt;</span><span style=3D"font-family:monospace;background-color:rgb=
(250,250,250)">=A0q</span><span style=3D"color:rgb(102,102,0);font-family:m=
onospace;background-color:rgb(250,250,250)"><u></u><u></u>; =A0// default c=
onstructing construct() on this allocator.</span></div>



<div><span style=3D"font-family:monospace;background-color:rgb(250,250,250)=
">q</span><span style=3D"color:rgb(102,102,0);font-family:monospace;backgro=
und-color:rgb(250,250,250)">.</span><span style=3D"font-family:monospace;ba=
ckground-color:rgb(250,250,250)">resize</span><span style=3D"color:rgb(102,=
102,0);font-family:monospace;background-color:rgb(250,250,250)">(</span><sp=
an style=3D"font-family:monospace;background-color:rgb(250,250,250)">=A0</s=
pan><span style=3D"color:rgb(0,102,102);font-family:monospace;background-co=
lor:rgb(250,250,250)">30</span><span style=3D"font-family:monospace;backgro=
und-color:rgb(250,250,250)">=A0</span><span style=3D"color:rgb(102,102,0);f=
ont-family:monospace;background-color:rgb(250,250,250)">); =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0// A nop apart from moving the end pointer</span><span s=
tyle=3D"font-family:monospace;background-color:rgb(250,250,250)"><br>



vector</span><span style=3D"color:rgb(102,102,0);font-family:monospace;back=
ground-color:rgb(250,250,250)">&lt;</span><span style=3D"color:rgb(0,0,136)=
;font-family:monospace;background-color:rgb(250,250,250)">int</span><span s=
tyle=3D"color:rgb(102,102,0);font-family:monospace;background-color:rgb(250=
,250,250)">&gt;</span><span style=3D"font-family:monospace;background-color=
:rgb(250,250,250)">=A0r</span><span style=3D"color:rgb(102,102,0);font-fami=
ly:monospace;background-color:rgb(250,250,250)">(</span><span style=3D"font=
-family:monospace;background-color:rgb(250,250,250)">=A0std</span><span sty=
le=3D"color:rgb(102,102,0);font-family:monospace;background-color:rgb(250,2=
50,250)">::</span><span style=3D"font-family:monospace;background-color:rgb=
(250,250,250)">move</span><span style=3D"color:rgb(102,102,0);font-family:m=
onospace;background-color:rgb(250,250,250)">(</span><span style=3D"font-fam=
ily:monospace;background-color:rgb(250,250,250)">=A0q=A0</span><span style=
=3D"color:rgb(102,102,0);font-family:monospace;background-color:rgb(250,250=
,250)">)</span><span style=3D"font-family:monospace;background-color:rgb(25=
0,250,250)">=A0</span><span style=3D"color:rgb(102,102,0);font-family:monos=
pace;background-color:rgb(250,250,250)"><u></u><u></u>);</span><span style=
=3D"font-family:monospace;background-color:rgb(250,250,250)">=A0</span><spa=
n style=3D"color:rgb(136,0,0);font-family:monospace;background-color:rgb(25=
0,250,250)">// Now r has standard allocator and default constructed element=
s, ready to be filled from some function.</span><span style=3D"font-family:=
monospace;background-color:rgb(250,250,250)"><br>



</span></div><div><span style=3D"color:rgb(136,0,0);font-family:monospace;b=
ackground-color:rgb(250,250,250)"><br></span></div></div><div><font face=3D=
"arial, sans-serif"><span style=3D"color:rgb(136,0,0);background-color:rgb(=
250,250,250)">This is not to say that I like this solution as it is a bigge=
r change to the library and will require a long standardization process. On=
 the other hand=A0</span>allocator_can_be_assigned will have more uses than=
 this example which may be worth fighting for<font color=3D"#880000">, whic=
h could boost the use of allocators. I don&#39;t think that there are that =
many allocator classes being made out there today, which in part is due to =
the fact that each allocator creates a completely new set of containers whi=
ch don&#39;t interplay in non-template code.</font></font></div>



<div><font face=3D"arial, sans-serif"><font color=3D"#880000"><br></font></=
font></div><div><font face=3D"arial, sans-serif"><font color=3D"#880000">Th=
e vector::resize_default_<u></u>constructed() method by comparison is a ver=
y small and local change. As no one has commented on this last version of s=
pecial resize methods I don&#39;t know if you still consider it unsafe. If =
so, please explain how.</font></font></div>



<div><font face=3D"arial, sans-serif"><font color=3D"#880000"><br></font></=
font></div>Den tisdagen den 17:e september 2013 kl. 21:25:36 UTC+2 skrev Bi=
lly O&#39;Neal:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wid=
th:1px;border-left-style:solid">



<div><div dir=3D"ltr"><div>That&#39;s true -- but calling reserve here does=
n&#39;t change the size of the vector -- it isn&#39;t legal to store anythi=
ng there. Reserve never calls allocator::construct() or anything like that.=
 If that&#39;s what you want, you can already do that today.</div>





<div>=A0</div><div>If you actually want to make it valid to store things in=
 the vector, however, then you&#39;re going to have to resize it.</div><div=
>=A0</div><div>In terms of powering this, I don&#39;t see any reason we can=
&#39;t have a</div>





<div>=A0</div><div>template&lt;typename U, typename V&gt;</div><div>struct =
allocator_can_be_assigned : public std::false_type {};</div><div>=A0</div><=
div>template&lt;&gt;</div><div>struct allocator_can_be_assigned&lt;std:<u><=
/u><u></u>:allocator, my_no_construct_allocator&gt; : public std::true_type=
 {};</div>





<div>=A0</div><div>or similar. Any pair of allocators of course would have =
to deal with any of these cases correctly if they declare they support this=
 pattern.</div><div>=A0</div><div>There is precedent for allocators declari=
ng support for things like this; e.g. the existing std::allocator_traits&lt=
;T&gt;::<u></u>prop<u></u>agate_on_container_copy_<u></u>assign<u></u>ment =
and friends.</div>





</div></div><div><div><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&=
#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"=
_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http://stac=
koverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stackoverfl=
ow.com/<u></u>users<u></u>/82320/billy-oneal</a></div>





<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br></div><div class=3D"gmail_quote">On Tue, Sep 17, 2013 at 9:59 AM, N=
evin Liber <span dir=3D"ltr">&lt;<a>ne...@eviloverlord.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid">





<div dir=3D"ltr"><div><div><div>On 17 September 2013 11:34, Billy O&#39;Nea=
l <span dir=3D"ltr">&lt;<a>billy...@gmail.com</a>&gt;</span> wrote:<br>

</div><div class=3D"gmail_quote"><div>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><div>Of course, presumably you would want=
 to use resize rather than reserve.</div>





</div></blockquote><div>

<br></div></div><div>That&#39;s even more convoluted, as you now have *both=
* allocators used for constructing objects in the same container while only=
 other_allocator is used for destroying objects.</div></div></div><div>





-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a>ne...@eviloverlord.c=
om</a><u></u><u></u>&gt;=A0 <a value=3D"+18476911404">(847) 691-1404</a>
</div></div></div><div><div><div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>iso<u><=
/u>cpp.org/group/std-<u></u>proposals/</a>.<br>
</div></div></div></blockquote></div><br></div>
</blockquote></div></div><div><div>

<p></p>

-- <br>
=A0<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>std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--047d7b5d33d496eda004e6aa6900--

.

> There is some ambiguity here -- the "default constructor" of a built in
> value, e.g. that the user requests by doing "new int[42]()" (note the extra
> parens) zero initializes the object.

This form of initialization is value-initialization as described by 8.5 p11.

> In fact, N3691 23.3.7.3
> [vector.capacity]/12 (emphasis mine) says:
>
> void resize(size_type sz);
> Effects: If sz <= size(), equivalent to calling pop_back() size() - sz
> times. If size() < sz, appends sz - size() default-inserted elements to the
> sequence.

Attention: Default-insertion is no core language term, but a
library-defined term, see 23.2.1 p13:

"An element of X is default-inserted if it is initialized by
evaluation of the expression
allocator_traits<A>::construct(m, p)"

In C++03 resize was only one function with a default parameter and
used effectively value-initialization. The effect of the
default-allocator of std::vector has the same effect.

> I can't find anywhere in the standard where "default construct" is a
> concept. The closest thing I can find is "default initialize", N3691 8.5
> [dcl.init]/7.

You should no longer find a lot of occurrences in the Library
specification talking about default construct[ed] where the meaning is
unclear, several issues had cleaned them up (e.g. LWG 1012, 1420,
868), where the meaning was indeed misleading. Do you have a specific
example in mind where this term is still used and is still misleading?
(Examples where the affected type is a class type with user-provided
default constructor are usually not misleading).

Thanks,

- Daniel

--

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

.

--001a1132f7082febde04e6ab60e0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 18 September 2013 11:15, Daniel Kr=FCgler <daniel.kruegler@gmail.com>wro=
te:

>
> In C++03 resize was only one function with a default parameter and
> used effectively value-initialization. The effect of the
> default-allocator of std::vector has the same effect.
>

I misspoke when I thought this problem could be solved in C++03 with an
allocator.   This reminded me that in C++03, the only way to put an object
into a vector was by copying it, even if it is copying a value-initialized
object.

I wonder if one of the reasons we haven't seen an allocator solution to
this is because it couldn't be done before C++11.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

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

--001a1132f7082febde04e6ab60e0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 18 September 2013 11:15, Daniel Kr=FCgler <span dir=3D"=
ltr">&lt;<a href=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">dan=
iel.kruegler@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 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
In C++03 resize was only one function with a default parameter and<br>
used effectively value-initialization. The effect of the<br>
default-allocator of std::vector has the same effect.<br></blockquote><div>=
<br></div><div>I misspoke when I thought this problem could be solved in C+=
+03 with an allocator.=A0=A0 This reminded me that in C++03, the only way t=
o put an object into a vector was by copying it, even if it is copying a va=
lue-initialized object.<br>

<br>I wonder if one of the reasons we haven&#39;t seen an allocator solutio=
n to this is because it couldn&#39;t be done before C++11.<br></div></div>-=
- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@=
eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847)=
 691-1404
</div></div>

<p></p>

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

--001a1132f7082febde04e6ab60e0--

.

--089e0117601f1da61e04e6ab8477
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I wasn't saying it was misleading in the standard -- I was saying it was
misleading in the proposal email above. :) The standard is clear in this
area.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Wed, Sep 18, 2013 at 9:15 AM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com>wrote:

> > There is some ambiguity here -- the "default constructor" of a built in
> > value, e.g. that the user requests by doing "new int[42]()" (note the
> extra
> > parens) zero initializes the object.
>
> This form of initialization is value-initialization as described by 8.5
> p11.
>
> > In fact, N3691 23.3.7.3
> > [vector.capacity]/12 (emphasis mine) says:
> >
> > void resize(size_type sz);
> > Effects: If sz <=3D size(), equivalent to calling pop_back() size() - s=
z
> > times. If size() < sz, appends sz - size() default-inserted elements to
> the
> > sequence.
>
> Attention: Default-insertion is no core language term, but a
> library-defined term, see 23.2.1 p13:
>
> "An element of X is default-inserted if it is initialized by
> evaluation of the expression
> allocator_traits<A>::construct(m, p)"
>
> In C++03 resize was only one function with a default parameter and
> used effectively value-initialization. The effect of the
> default-allocator of std::vector has the same effect.
>
> > I can't find anywhere in the standard where "default construct" is a
> > concept. The closest thing I can find is "default initialize", N3691 8.=
5
> > [dcl.init]/7.
>
> You should no longer find a lot of occurrences in the Library
> specification talking about default construct[ed] where the meaning is
> unclear, several issues had cleaned them up (e.g. LWG 1012, 1420,
> 868), where the meaning was indeed misleading. Do you have a specific
> example in mind where this term is still used and is still misleading?
> (Examples where the affected type is a class type with user-provided
> default constructor are usually not misleading).
>
> Thanks,
>
> - Daniel
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

--089e0117601f1da61e04e6ab8477
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I wasn&#39;t saying it was misleading in the standard -- I=
 was saying it was misleading in the proposal email above. :) The standard =
is clear in this area.</div><div class=3D"gmail_extra"><br clear=3D"all"><d=
iv>

<div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bitbuck=
et.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</a></d=
iv><div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=
=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Sep 18, 2013 at 9:15 AM, Daniel =
Kr=FCgler <span dir=3D"ltr">&lt;<a href=3D"mailto:daniel.kruegler@gmail.com=
" target=3D"_blank">daniel.kruegler@gmail.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">

<div class=3D"im">&gt; There is some ambiguity here -- the &quot;default co=
nstructor&quot; of a built in<br>
&gt; value, e.g. that the user requests by doing &quot;new int[42]()&quot; =
(note the extra<br>
&gt; parens) zero initializes the object.<br>
<br>
</div>This form of initialization is value-initialization as described by 8=
..5 p11.<br>
<div class=3D"im"><br>
&gt; In fact, N3691 23.3.7.3<br>
&gt; [vector.capacity]/12 (emphasis mine) says:<br>
&gt;<br>
&gt; void resize(size_type sz);<br>
&gt; Effects: If sz &lt;=3D size(), equivalent to calling pop_back() size()=
 - sz<br>
&gt; times. If size() &lt; sz, appends sz - size() default-inserted element=
s to the<br>
&gt; sequence.<br>
<br>
</div>Attention: Default-insertion is no core language term, but a<br>
library-defined term, see 23.2.1 p13:<br>
<br>
&quot;An element of X is default-inserted if it is initialized by<br>
evaluation of the expression<br>
allocator_traits&lt;A&gt;::construct(m, p)&quot;<br>
<br>
In C++03 resize was only one function with a default parameter and<br>
used effectively value-initialization. The effect of the<br>
default-allocator of std::vector has the same effect.<br>
<div class=3D"im"><br>
&gt; I can&#39;t find anywhere in the standard where &quot;default construc=
t&quot; is a<br>
&gt; concept. The closest thing I can find is &quot;default initialize&quot=
;, N3691 8.5<br>
&gt; [dcl.init]/7.<br>
<br>
</div>You should no longer find a lot of occurrences in the Library<br>
specification talking about default construct[ed] where the meaning is<br>
unclear, several issues had cleaned them up (e.g. LWG 1012, 1420,<br>
868), where the meaning was indeed misleading. Do you have a specific<br>
example in mind where this term is still used and is still misleading?<br>
(Examples where the affected type is a class type with user-provided<br>
default constructor are usually not misleading).<br>
<br>
Thanks,<br>
<br>
- Daniel<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--089e0117601f1da61e04e6ab8477--

.

------=_Part_89_31839111.1381090623024
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

8 sept 2013 =C7., 0:50:51 UTC+4 Howard Hinnant:

> Yes, its a pain to write all this boilerplate.  Maybe you can generalize=
=20
> the iterator/generator so you only have to write it once.  Or maybe=20
> somebody (boost?) has already written it for you.  But it isn't going to=
=20
> get much faster than this.=20


Just for reference what is possible to do with boost::irange and=20
boost::adaptors::transformed - http://stackoverflow.com/a/15958135/1762344 =
:
const auto &gen =3D irange(0, 1024) | transformed([](int x)
{
    return something(x);
});
vector<Value> v(begin(gen), end(gen));=20

The vector constructor will subtract the pair of random access iterators in=
=20
> its constructor and allocate the right amount of memory.  And then it wil=
l=20
> iterate through the range constructing each Widget from the dereferenced=
=20
> iterator.=20
>

Generator approach can't extended to simultaneous filling of several=20
vectors (I think that was mentioned here before).
I think that unchecked_push_back would be valuable addition to vector. But=
=20
maybe at first we should try to add it to boost::container::vector -=20
http://www.boost.org/doc/libs/1_54_0/doc/html/boost/container/vector.html ?

--=20

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

------=_Part_89_31839111.1381090623024
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">8 sept 2013&nbsp;=C7., 0:50:51 UTC+4 Howard Hinnant:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">Yes, its a pain to write all thi=
s boilerplate. &nbsp;Maybe you can generalize the iterator/generator so you=
 only have to write it once. &nbsp;Or maybe somebody (boost?) has already w=
ritten it for you. &nbsp;But it isn't going to get much faster than this. <=
/blockquote><div><br>Just for reference what is possible to do with boost::=
irange and boost::adaptors::transformed - http://stackoverflow.com/a/159581=
35/1762344 :<br><div class=3D"prettyprint" style=3D"background-color: rgb(2=
50, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; borde=
r-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">gen </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> irange</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">102=
4</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">|</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> transformed</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">([](</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 something</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">});</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>vector</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Value</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">begin</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">gen</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">),</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">end</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">gen</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">));</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> <br></span></div></code></div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">The vector constructor will subtract the pair of rando=
m access iterators in its constructor and allocate the right amount of memo=
ry. &nbsp;And then it will iterate through the range constructing each Widg=
et from the dereferenced iterator.
<br></blockquote><div><br>Generator approach can't extended to simultaneous=
 filling of several vectors (I think that was mentioned here before).<br>I =
think that unchecked_push_back would be valuable addition to vector. But ma=
ybe at first we should try to add it to boost::container::vector - http://w=
ww.boost.org/doc/libs/1_54_0/doc/html/boost/container/vector.html ?<br></di=
v></div>

<p></p>

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

------=_Part_89_31839111.1381090623024--

.

------=_Part_12_11966091.1381097914487
Content-Type: text/plain; charset=ISO-8859-1

I have just realized that unchecked_emplace_back is actually feature
enabler.
With help of it vector can be used with non-copyable and non-movable types
(like deque).
For instance:
static_assert(!std::is_move_constructible<X>::value && !std::
is_copy_constructible<X>::value, "");
std::vector<X> v;
v.reserve(10);
v.emplace_back(2);
v.pop_back();
Besides addition of unchecked_emplace_back it would require a little
adjustment of .reserve - it should not "trigger" code which does
reallocation if value_type is not movable and not copyable.

--

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

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

<div dir=3D"ltr">I have just realized that unchecked_emplace_back is actual=
ly feature enabler.<br>With help of it vector can be used with non-copyable=
 and non-movable types (like deque).<br>For instance:<br><div class=3D"pret=
typrint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(1=
87, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wor=
d;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">static_assert</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(!</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">is_move_constructible</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">X</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">value </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">!</span><span style=3D"color: #000;" class=3D"styled-by-prettify">st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">is_copy_construct=
ible</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">X</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">value</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" =
class=3D"styled-by-prettify">""</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>std</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">vector</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">X</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> v</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>v</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">reserve</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">10</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>v</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">emplace_back</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>v</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">pop_back</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span></div></code></div><span id=3D"result_box" class=3D"short=
_text" lang=3D"en"><span class=3D"hps alt-edited">Besides addition of </spa=
n></span>unchecked_emplace_back it would require a little adjustment of .re=
serve - it should not "trigger" code which does reallocation if value_type =
is not movable and not copyable.<br></div>

<p></p>

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

------=_Part_12_11966091.1381097914487--

.

On Sun, 2013-10-06 at 15:18 -0700, Evgeny Panasyuk wrote:
> I have just realized that unchecked_emplace_back is actually feature
> enabler.
> With help of it vector can be used with non-copyable and non-movable
> types (like deque).
> For instance:
> static_assert(!std::is_move_constructible<X>::value && !
> std::is_copy_constructible<X>::value, "");
> std::vector<X> v;
> v.reserve(10);
> v.emplace_back(2);
> v.pop_back();
>
> Besides addition of unchecked_emplace_back it would require a little
> adjustment of .reserve - it should not "trigger" code which does
> reallocation if value_type is not movable and not copyable.

But why would you need unchecked_emplace_back for this case? Plain
emplace_back for non-movable types already cover this case - this is the
normal 'throw out_of_memory' case.

The one thing that becomes disabled is reallocation when the container
is non-empty.

/MF


--

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

.

On 7 October 2013 13:43, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> On Sun, 2013-10-06 at 15:18 -0700, Evgeny Panasyuk wrote:
>> I have just realized that unchecked_emplace_back is actually feature
>> enabler.
>> With help of it vector can be used with non-copyable and non-movable
>> types (like deque).
>> For instance:
>> static_assert(!std::is_move_constructible<X>::value && !
>> std::is_copy_constructible<X>::value, "");
>> std::vector<X> v;
>> v.reserve(10);
>> v.emplace_back(2);
>> v.pop_back();
>>
>> Besides addition of unchecked_emplace_back it would require a little
>> adjustment of .reserve - it should not "trigger" code which does
>> reallocation if value_type is not movable and not copyable.
>
> But why would you need unchecked_emplace_back for this case? Plain
> emplace_back for non-movable types already cover this case - this is the
> normal 'throw out_of_memory' case.

You can't call 'emplace_back' with a non-movable type, as the
container may have to extend the memory and move all values into the
new memory block if size() == reserve().

Chris

--

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

.

On Mon, 2013-10-07 at 13:58 +0100, Christopher Jefferson wrote:
> On 7 October 2013 13:43, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> > On Sun, 2013-10-06 at 15:18 -0700, Evgeny Panasyuk wrote:
> >> I have just realized that unchecked_emplace_back is actually feature
> >> enabler.
> >> With help of it vector can be used with non-copyable and non-movable
> >> types (like deque).
> >> For instance:
> >> static_assert(!std::is_move_constructible<X>::value && !
> >> std::is_copy_constructible<X>::value, "");
> >> std::vector<X> v;
> >> v.reserve(10);
> >> v.emplace_back(2);
> >> v.pop_back();
> >>
> >> Besides addition of unchecked_emplace_back it would require a little
> >> adjustment of .reserve - it should not "trigger" code which does
> >> reallocation if value_type is not movable and not copyable.
> >
> > But why would you need unchecked_emplace_back for this case? Plain
> > emplace_back for non-movable types already cover this case - this is the
> > normal 'throw out_of_memory' case.
>
> You can't call 'emplace_back' with a non-movable type, as the
> container may have to extend the memory and move all values into the
> new memory block if size() == reserve().

Yes, obviously.

What emplace_back principally does is to

1. Call reserve(size() + 1)
2. perform an unchecked_emplace_back

Can reserve(N) fail? Yes - it can fail due to the memory allocation
failure and if that happens it should throw out_of_memory.

With the nonmovable and noncopyable types there is a second way for
reserve(N) to fail - if N is greater than capacity() and size() isn't 0
then reallocation is impossible so somehow an error must be reported,
this feels like an exception in order to not break the interface
completely.
It could even be an out_of_memory exception but I think one would have
to squint to badly for that to  fit the bill.

So, in the case where size() < capacity() then emplace_back already
works.
In the case where capacity() != 0 and size() == capacity() emplace_back
have to be able to report an error.

Where do I need unchecked_emplace_back in the interface?

/MF

--

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

.

On 7 October 2013 14:57, Magnus Fromreide <magfr@lysator.liu.se> wrote:

>> You can't call 'emplace_back' with a non-movable type, as the
>> container may have to extend the memory and move all values into the
>> new memory block if size() == reserve().
>
> Yes, obviously.
>
> What emplace_back principally does is to
>
> 1. Call reserve(size() + 1)
> 2. perform an unchecked_emplace_back
>
> Can reserve(N) fail? Yes - it can fail due to the memory allocation
> failure and if that happens it should throw out_of_memory.
>
> With the nonmovable and noncopyable types there is a second way for
> reserve(N) to fail - if N is greater than capacity() and size() isn't 0
> then reallocation is impossible so somehow an error must be reported,
> this feels like an exception in order to not break the interface
> completely.

Please distinguish between the standard, and possible extensions.

Does the standard (either C++11, or a draft standard) talk about
reserve(N) failing for nonmovable types (if so, I missed this fairly
major change)? Or are you suggesting this as a future extension? That
seems like a fairly major change in behaviour, and we would have to
think about doing it consistently.

Chris

--

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

.

--047d7bdc979c755c4504e828413f
Content-Type: text/plain; charset=ISO-8859-1

On 7 October 2013 10:07, Christopher Jefferson <chris@bubblescope.net>wrote:

>
> Does the standard (either C++11, or a draft standard) talk about
> reserve(N) failing for nonmovable types (if so, I missed this fairly
> major change)?


C++03 required elements be copyable in order to store them in a vector.

C++11 relaxed that into requiring that elements only be moveable (there are
some corner cases where default constructible is all that is required when
first creating the vector; although doing so was a breaking change from
C++03).

There is no way to implement reserve(), push_back(), emplace_back(),
insert(), etc. without at least moveable elements, since it is a runtime
decision on whether or not elements have to be relocated.

Is this the fairly major change you think you missed?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bdc979c755c4504e828413f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 7 October 2013 10:07, Christopher Jefferson <span dir=
=3D"ltr">&lt;<a href=3D"mailto:chris@bubblescope.net" target=3D"_blank">chr=
is@bubblescope.net</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 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
Does the standard (either C++11, or a draft standard) talk about<br>
reserve(N) failing for nonmovable types (if so, I missed this fairly<br>
major change)?</blockquote><div><br></div><div>C++03 required elements be c=
opyable in order to store them in a vector.<br><br></div><div>C++11 relaxed=
 that into requiring that elements only be moveable (there are some corner =
cases where default constructible is all that is required when first creati=
ng the vector; although doing so was a breaking change from C++03).<br>


<br></div><div>There is no way to implement reserve(), push_back(), emplace=
_back(), insert(), etc. without at least moveable elements, since it is a r=
untime decision on whether or not elements have to be relocated.<br></div>

<div>
<br></div><div>Is this the fairly major change you think you missed?<br></d=
iv></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mai=
lto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt=
;=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"=
_blank">(847) 691-1404</a>
</div></div>

<p></p>

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

--047d7bdc979c755c4504e828413f--

.

------=_Part_9_14009926.1381162532241
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

7 oct 2013 =C7., 16:43:02 UTC+4  Magnus Fromreide:
>
> On Sun, 2013-10-06 at 15:18 -0700, Evgeny Panasyuk wrote:=20
> > Besides addition of unchecked_emplace_back it would require a little=20
> > adjustment of .reserve - it should not "trigger" code which does=20
> > reallocation if value_type is not movable and not copyable.=20
>
> But why would you need unchecked_emplace_back for this case?
>

Thanks, I haven't noticed that.
Yes, if we would have special code in reserve which disables reallocation=
=20
for
!std::is_move_constructible<X>::value && !std::is_copy_constructible<X>::
value
Then we can have similar thing for emplace_back - we don't need=20
unchecked_emplace_back for enable that - it is separate issue.

And I think that would be a bit dangerous - user can accidentally change=20
type of element, and behavior will be changed radically.

--=20

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

------=_Part_9_14009926.1381162532241
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">7 oct 2013&nbsp;=C7., 16:43:02 UTC+4&nbsp; Magnus Fromreid=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">On Sun, 2013-10-06 at 15:18 =
-0700, Evgeny Panasyuk wrote:
<br>&gt; Besides addition of unchecked_emplace_back it would require a litt=
le
<br>&gt; adjustment of .reserve - it should not "trigger" code which does
<br>&gt; reallocation if value_type is not movable and not copyable.
<br>
<br>But why would you need unchecked_emplace_back for this case?<br></block=
quote><div><br>Thanks, I haven't noticed that.<br>Yes, if we would have spe=
cial code in reserve which disables reallocation for<br><div class=3D"prett=
yprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word=
;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #660;" class=3D"styled-by-prettify">!</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">is_move_constructible</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">X</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;::</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">value </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&amp;&amp;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">!=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">is_copy_constructible</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">X</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">value</span></div></code></div>T=
hen we can have similar thing for emplace_back - we don't need unchecked_em=
place_back for enable that - it is separate issue.<br><br>And I think that =
would be a bit dangerous - user can accidentally change type of element, an=
d behavior will be changed radically.<br></div></div>

<p></p>

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

------=_Part_9_14009926.1381162532241--

.

------=_Part_13_18111764.1381163072865
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

7 oct 2013 =D0=B3., 19:24:21 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=
=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nevin ":-)" Liber:
>
> There is no way to implement reserve(), push_back(), emplace_back(),=20
> insert(), etc. without at least moveable elements, since it is a runtime=
=20
> decision on whether or not elements have to be relocated.
>

It is possible to implement reserve and emplace_back for non-movable and=20
non-copyable elements.
We know when element is non-movable and non-copyable at compile time - and=
=20
we can disable relocation code via enable_if or any other compile-time=20
dispatch mechanism.
However, I think that changing behavior of emplace_back is dangerous.

--=20

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

------=_Part_13_18111764.1381163072865
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">7 oct 2013&nbsp;=D0=B3., 19:24:21 UTC+4 =D0=BF=D0=BE=D0=BB=
=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nevin ":-)" Liber:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">There is no way=
 to implement reserve(), push_back(), emplace_back(), insert(), etc. withou=
t at least moveable elements, since it is a runtime decision on whether or =
not elements have to be relocated.<br></div></blockquote><div><br>It is pos=
sible to implement reserve and emplace_back for non-movable and non-copyabl=
e elements.<br>We know when element is non-movable and non-copyable at comp=
ile time - and we can disable relocation code via enable_if or any other co=
mpile-time dispatch mechanism.<br>However, I think that changing behavior o=
f emplace_back is dangerous.<br></div></div>

<p></p>

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

------=_Part_13_18111764.1381163072865--

.

--047d7b62249ab21cf604e82946d9
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

On 7 October 2013 11:24, Evgeny Panasyuk <evgeny.panasyuk@gmail.com> wrote:

> 7 oct 2013 =C7., 19:24:21 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Nevi=
n ":-)" Liber:
>
>> There is no way to implement reserve(), push_back(), emplace_back(),
>> insert(), etc. without at least moveable elements, since it is a runtime
>> decision on whether or not elements have to be relocated.
>>
>
> It is possible to implement reserve and emplace_back for non-movable and
> non-copyable elements.
>

Okay, technically you can, but it isn't terribly useful.

reserve(n) would need to throw if the precondition of empty() || n <=3D
capacity() is not met.

emplace_back(...) would need to throw if the precondition of empty() ||
size() < capacity() is not met.

This is morally equivalent to a specialization on vector for non-moveable
types, and after vector<bool>, I just don't see that happening.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

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

--047d7b62249ab21cf604e82946d9
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 7 October 2013 11:24, Evgeny Panasyuk <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:evgeny.panasyuk@gmail.com" target=3D"_blank">evgeny.=
panasyuk@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 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">7 oct 2013=9A=C7., 19:24:21=
 UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Nevin &quot;:-)&quot; Liber:<di=
v class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">There is no way to implement reserve(), push_back(), empla=
ce_back(), insert(), etc. without at least moveable elements, since it is a=
 runtime decision on whether or not elements have to be relocated.<br></div=
>

</blockquote></div><div><br>It is possible to implement reserve and emplace=
_back for non-movable and non-copyable elements.<br></div></div></blockquot=
e><div><br></div><div>Okay, technically you can, but it isn&#39;t terribly =
useful.<br>

<br></div><div>reserve(n) would need to throw if the precondition of empty(=
) || n &lt;=3D capacity() is not met.<br><br></div><div>emplace_back(...) w=
ould need to throw if the precondition of empty() || size() &lt; capacity()=
 is not met.<br>

<br></div><div>This is morally equivalent to a specialization on vector for=
 non-moveable types, and after vector&lt;bool&gt;, I just don&#39;t see tha=
t happening.<br></div></div>-- <br>=9ANevin &quot;:-)&quot; Liber=9A &lt;ma=
ilto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evil=
overlord.com</a>&gt;=9A (847) 691-1404
</div></div>

<p></p>

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

--047d7b62249ab21cf604e82946d9--

.

------=_Part_38_2650540.1381164800504
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

7 oct 2013 =C7., 20:37:24 UTC+4 Nevin ":-)" Liber:

> Okay, technically you can, but it isn't terribly useful.
>
> reserve(n) would need to throw if the precondition of empty() || n <=3D=
=20
> capacity() is not met.
>
> emplace_back(...) would need to throw if the precondition of empty() ||=
=20
> size() < capacity() is not met.
>
> This is morally equivalent to a specialization on vector for non-moveable=
=20
> types, and after vector<bool>, I just don't see that happening.
>

Yes, I agree - it is not a good idea.
Maybe if we would have unchecked_reserve and unchecked_emplace_back for=20
that case - but that sounds too cumbersome.

--=20

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

------=_Part_38_2650540.1381164800504
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">7 oct 2013&nbsp;=C7., 20:37:24 UTC+4 Nevin ":-)" Liber:<br=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote"><div>Okay, technically you can, but it isn't terribly u=
seful.<br>

<br></div><div>reserve(n) would need to throw if the precondition of empty(=
) || n &lt;=3D capacity() is not met.<br><br></div><div>emplace_back(...) w=
ould need to throw if the precondition of empty() || size() &lt; capacity()=
 is not met.<br>

<br></div><div>This is morally equivalent to a specialization on vector for=
 non-moveable types, and after vector&lt;bool&gt;, I just don't see that ha=
ppening.<br></div></div></div></div></blockquote><div><br>Yes, I agree - it=
 is not a good idea.<br>Maybe if we would have unchecked_reserve and unchec=
ked_emplace_back for that case - but that sounds too cumbersome.<br></div><=
/div>

<p></p>

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

------=_Part_38_2650540.1381164800504--

.

--001a11c3a8ccf944d104e829d1f8
Content-Type: text/plain; charset=ISO-8859-1

Not quite -- reserve grows linearly while push_back is required to grow
geometrically.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Mon, Oct 7, 2013 at 5:58 AM, Christopher Jefferson <chris@bubblescope.net
> wrote:

> On 7 October 2013 13:43, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> > On Sun, 2013-10-06 at 15:18 -0700, Evgeny Panasyuk wrote:
> >> I have just realized that unchecked_emplace_back is actually feature
> >> enabler.
> >> With help of it vector can be used with non-copyable and non-movable
> >> types (like deque).
> >> For instance:
> >> static_assert(!std::is_move_constructible<X>::value && !
> >> std::is_copy_constructible<X>::value, "");
> >> std::vector<X> v;
> >> v.reserve(10);
> >> v.emplace_back(2);
> >> v.pop_back();
> >>
> >> Besides addition of unchecked_emplace_back it would require a little
> >> adjustment of .reserve - it should not "trigger" code which does
> >> reallocation if value_type is not movable and not copyable.
> >
> > But why would you need unchecked_emplace_back for this case? Plain
> > emplace_back for non-movable types already cover this case - this is the
> > normal 'throw out_of_memory' case.
>
> You can't call 'emplace_back' with a non-movable type, as the
> container may have to extend the memory and move all values into the
> new memory block if size() == reserve().
>
> Chris
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--001a11c3a8ccf944d104e829d1f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Not quite -- reserve grows linearly while push_back is req=
uired to grow geometrically.</div><div class=3D"gmail_extra"><br clear=3D"a=
ll"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https:=
//bitbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONea=
l/</a></div>

<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Oct 7, 2013 at 5:58 AM, Christop=
her Jefferson <span dir=3D"ltr">&lt;<a href=3D"mailto:chris@bubblescope.net=
" target=3D"_blank">chris@bubblescope.net</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">

<div class=3D"im">On 7 October 2013 13:43, Magnus Fromreide &lt;<a href=3D"=
mailto:magfr@lysator.liu.se">magfr@lysator.liu.se</a>&gt; wrote:<br>
&gt; On Sun, 2013-10-06 at 15:18 -0700, Evgeny Panasyuk wrote:<br>
&gt;&gt; I have just realized that unchecked_emplace_back is actually featu=
re<br>
&gt;&gt; enabler.<br>
&gt;&gt; With help of it vector can be used with non-copyable and non-movab=
le<br>
&gt;&gt; types (like deque).<br>
&gt;&gt; For instance:<br>
&gt;&gt; static_assert(!std::is_move_constructible&lt;X&gt;::value &amp;&am=
p; !<br>
&gt;&gt; std::is_copy_constructible&lt;X&gt;::value, &quot;&quot;);<br>
&gt;&gt; std::vector&lt;X&gt; v;<br>
&gt;&gt; v.reserve(10);<br>
&gt;&gt; v.emplace_back(2);<br>
&gt;&gt; v.pop_back();<br>
&gt;&gt;<br>
&gt;&gt; Besides addition of unchecked_emplace_back it would require a litt=
le<br>
&gt;&gt; adjustment of .reserve - it should not &quot;trigger&quot; code wh=
ich does<br>
&gt;&gt; reallocation if value_type is not movable and not copyable.<br>
&gt;<br>
&gt; But why would you need unchecked_emplace_back for this case? Plain<br>
&gt; emplace_back for non-movable types already cover this case - this is t=
he<br>
&gt; normal &#39;throw out_of_memory&#39; case.<br>
<br>
</div>You can&#39;t call &#39;emplace_back&#39; with a non-movable type, as=
 the<br>
container may have to extend the memory and move all values into the<br>
new memory block if size() =3D=3D reserve().<br>
<br>
Chris<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11c3a8ccf944d104e829d1f8--

.

------=_Part_17_3441696.1384815098439
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, September 18, 2013 8:50:55 AM UTC-7, Billy O'Neal wrote:
>
> There is some ambiguity here -- the "default constructor" of a built in
> value, e.g. that the user requests by doing "new int[42]()" (note the extra
> parens) zero initializes the object.  In fact, N3691 23.3.7.3
> [vector.capacity]/12 (emphasis mine) says:
>
> *void resize(size_type sz);*
> Effects: If sz <= size(), equivalent to calling pop_back() size() - sz
> times. If size() < sz, *appends sz - size() default-inserted elements* to
> the sequence.
>
> I can't find anywhere in the standard where "default construct" is a
> concept. The closest thing I can find is "default initialize", N3691 8.5
> [dcl.init]/7.
>
> How about something like:
>
> class default_initialized_t {} default_initialized;
>
> // in vector
> void resize(size_type sz, default_initialized_t);
>
> // use
> vector<int> contains_trivial_type;
> contains_trivial_type.resize(123, default_initialized);
>
> Of course, this proposal has absolutely nothing to do with getting rid of
> the capacity check originally proposed in this thread.
>

Something like this might be generally useful.  I think that one of the
weak points of C++ is that there's very little control available to select
default-initialization vs value-initialization and to make class objects
behave different when default- or value-initialized.

For example, you can declare chars, ints, etc. and default-initialize them
(which gives them an indeterminate value) or value-initialize them (make
them zero).  You can do similar things to class objects that have default
constructors that don't actually initialize their elements.

You can't, however, forward your intent to default-initailze an object
through a mechanism like resize of emplace.  And you can't create a class
with non-trivial behavior when value-initialized that still has essentially
free default-initialization.

If initializing from an object of type default_initialized_t forced default
initialization, that would solve half of the problem.  The other half could
be solved if default-initialization would call a special constructor that
took a default_initialized_t parameter.

--Andy

--

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

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

<div dir=3D"ltr">On Wednesday, September 18, 2013 8:50:55 AM UTC-7, Billy O=
'Neal wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>There is some ambiguity here -- the "default constructor" of a built in=
 value, e.g. that the user requests by doing "new int[42]()" (note the extr=
a parens) zero initializes the object.&nbsp; In fact, N3691 23.3.7.3 [vecto=
r.capacity]/12 (emphasis mine) says:</div>

<div>&nbsp;</div><div><b>void resize(size_type sz);</b><br>Effects: If sz &=
lt;=3D size(), equivalent to calling pop_back() size() - sz times. If size(=
) &lt; sz, <b>appends sz - size() default-inserted elements</b> to the sequ=
ence.&nbsp;</div>

<div>&nbsp;</div><div>I can't find anywhere in the standard where "default =
construct" is a concept. The closest thing I can find is "default initializ=
e", N3691 8.5 [dcl.init]/7.</div><div>&nbsp;</div><div>How about something =
like:</div>

<div>&nbsp;</div><div><font face=3D"courier new,monospace">class default_in=
itialized_t {} default_initialized;</font></div><div><font face=3D"courier =
new,monospace">&nbsp;</font></div><div><font face=3D"courier new,monospace"=
>// in vector</font></div>

<div><font face=3D"courier new,monospace">void resize(size_type sz, default=
_initialized_t);</font></div><div><font face=3D"courier new,monospace"></fo=
nt>&nbsp;</div><div><font face=3D"courier new,monospace">// use</font></div=
><div>
<font face=3D"courier new,monospace">vector&lt;int&gt; contains_trivial_typ=
e;</font></div>
<div><font face=3D"courier new,monospace">contains_trivial_type.resize(<wbr=
>123, default_initialized);</font></div><div>&nbsp;</div><div>Of course, th=
is proposal has absolutely nothing to do with getting rid of the capacity c=
heck originally proposed in this thread.</div>

<div></div></div></blockquote><div><br>Something like this might be general=
ly useful.&nbsp; I think that one of the weak points of C++ is that there's=
 very little control available to select default-initialization vs value-in=
itialization and to make class objects behave different when default- or va=
lue-initialized.<br><br>For example, you can declare chars, ints, etc. and =
default-initialize them (which gives them an indeterminate value) or value-=
initialize them (make them zero).&nbsp; You can do similar things to class =
objects that have default constructors that don't actually initialize their=
 elements.<br><br>You can't, however, forward your intent to default-initai=
lze an object through a mechanism like resize of emplace.&nbsp; And you can=
't create a class with non-trivial behavior when value-initialized that sti=
ll has essentially free default-initialization.<br><br>If initializing from=
 an object of type default_initialized_t forced default initialization, tha=
t would solve half of the problem.&nbsp; The other half could be solved if =
default-initialization would call a special constructor that took a default=
_initialized_t parameter.<br><br>--Andy<br></div></div>

<p></p>

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

------=_Part_17_3441696.1384815098439--

.

------=_Part_2001_32601079.1385741407486
Content-Type: multipart/alternative;
 boundary="----=_Part_2002_16031424.1385741407486"

------=_Part_2002_16031424.1385741407486
Content-Type: text/plain; charset=ISO-8859-1

I have try them by changing the implements of VS2013 CTP's vector. That is
reasonable and easy to do. And, it can make our vectors as fast as arrays
when we need to build a "1000000+ elements" vector. I have
sent "vector.hpp" to all of you.
These functions are to optimize our vectors.
My implements(I added 4 new member functions):

 void unsafe_push_back(const value_type& _Val)
  { // insert element at end
   this->_Getal().construct(this->_Mylast,
    _Val);
   ++this->_Mylast;
  }

 void unsafe_push_back(value_type&& _Val)
  {
   this->_Getal().construct(this->_Mylast,
    _STD forward<value_type>(_Val));
   ++this->_Mylast;
  }

 template<class... _Valty>
  void unsafe_emplace_back(_Valty&&... _Val)
  { // insert by moving into element at end
  this->_Getal().construct(this->_Mylast,
   _STD forward<_Valty>(_Val)...);
  ++this->_Mylast;
  }

 void unsafe_resize(size_type _Newsize)
 {
  this->_Mylast += _Newsize - size();
 }

unsafe_resize cannot be given default value, its aim is to optimize
the efficiency of vector.
Besides, unsafe_insert, unsafe_emplace can be considered that whether they
should be added into vectors.

I think unsafe_push_back() is useful. For example, it is useful to make a
Graph.

--

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

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

<div dir=3D"ltr"><div>I have try them&nbsp;by&nbsp;changing the implements =
of&nbsp;VS2013 CTP's vector. That is reasonable and easy to do. And, it can=
 make our vectors as fast as arrays when we need to build a "1000000+ eleme=
nts" vector. I have sent&nbsp;"vector.hpp" to all of you.</div><div>These f=
unctions are to optimize our vectors.</div><div>My implements(I added 4 new=
&nbsp;member&nbsp;functions):</div><div><br></div><div>&nbsp;void unsafe_pu=
sh_back(const value_type&amp; _Val)<br>&nbsp;&nbsp;{&nbsp;// insert element=
 at end<br>&nbsp;&nbsp;&nbsp;this-&gt;_Getal().construct(this-&gt;_Mylast,<=
br>&nbsp;&nbsp;&nbsp;&nbsp;_Val);<br>&nbsp;&nbsp;&nbsp;++this-&gt;_Mylast;<=
br>&nbsp;&nbsp;}</div><div><br></div><div>&nbsp;void unsafe_push_back(value=
_type&amp;&amp; _Val)<br>&nbsp;&nbsp;{<br>&nbsp;&nbsp;&nbsp;this-&gt;_Getal=
().construct(this-&gt;_Mylast,<br>&nbsp;&nbsp;&nbsp;&nbsp;_STD forward&lt;v=
alue_type&gt;(_Val));<br>&nbsp;&nbsp;&nbsp;++this-&gt;_Mylast;<br>&nbsp;&nb=
sp;}</div><div><br></div><div>&nbsp;template&lt;class... _Valty&gt;<br>&nbs=
p;&nbsp;void unsafe_emplace_back(_Valty&amp;&amp;... _Val)<br>&nbsp;&nbsp;{=
&nbsp;// insert by moving into element at end<br>&nbsp;&nbsp;this-&gt;_Geta=
l().construct(this-&gt;_Mylast,<br>&nbsp;&nbsp;&nbsp;_STD forward&lt;_Valty=
&gt;(_Val)...);<br>&nbsp;&nbsp;++this-&gt;_Mylast;<br>&nbsp;&nbsp;}</div><d=
iv><br>&nbsp;void unsafe_resize(size_type _Newsize)<br>&nbsp;{<br>&nbsp;&nb=
sp;this-&gt;_Mylast +=3D _Newsize - size();<br>&nbsp;}</div><div><br></div>=
<div>unsafe_resize cannot be given default value, its aim is to optimize th=
e&nbsp;efficiency of vector.</div><div>Besides, unsafe_insert, unsafe_empla=
ce can be considered that whether they should be added into vectors.</div><=
div><br></div><div>I think unsafe_push_back() is useful.&nbsp;For example,&=
nbsp;it is useful to make a Graph.<br></div></div>

<p></p>

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

------=_Part_2002_16031424.1385741407486--
------=_Part_2001_32601079.1385741407486
Content-Type: text/x-c++hdr; charset=US-ASCII; name=vector.hpp
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=vector.hpp
X-Attachment-Id: 3ff00ee7-cd3d-4886-a562-a32c581cf084
Content-ID: <3ff00ee7-cd3d-4886-a562-a32c581cf084>

// vector standard header
#pragma once
#ifndef _VECTOR_
#define _VECTOR_
#ifndef RC_INVOKED
#include <xmemory>
#include <stdexcept>

 #pragma pack(push,_CRT_PACKING)
 #pragma warning(push,3)
 #pragma push_macro("new")
 #undef new

 #pragma warning(disable: 4127)
 #pragma warning(disable: 4244)

_STD_BEGIN
 #define _VECTOR_ORPHAN_RANGE (_ITERATOR_DEBUG_LEVEL == 2)

  // TEMPLATE CLASS _Vector_const_iterator
template<class _Myvec>
 class _Vector_const_iterator
  : public _Iterator012<random_access_iterator_tag,
   typename _Myvec::value_type,
   typename _Myvec::difference_type,
   typename _Myvec::const_pointer,
   typename _Myvec::const_reference,
   _Iterator_base>
 { // iterator for nonmutable vector
public:
 typedef _Vector_const_iterator<_Myvec> _Myiter;
 typedef random_access_iterator_tag iterator_category;

 typedef typename _Myvec::value_type value_type;
 typedef typename _Myvec::difference_type difference_type;
 typedef typename _Myvec::const_pointer pointer;
 typedef typename _Myvec::const_reference reference;
 typedef typename _Myvec::pointer _Tptr;

 _Vector_const_iterator()
  : _Ptr()
  { // construct with null pointer
  }

 _Vector_const_iterator(_Tptr _Parg, const _Container_base *_Pvector)
  : _Ptr(_Parg)
  { // construct with pointer _Parg
  this->_Adopt(_Pvector);
  }

 typedef pointer _Unchecked_type;

 _Myiter& _Rechecked(_Unchecked_type _Right)
  { // reset from unchecked iterator
  this->_Ptr = (_Tptr)_Right;
  return (*this);
  }

 _Unchecked_type _Unchecked() const
  { // make an unchecked iterator
  return (_Unchecked_type(this->_Ptr));
  }

 reference operator*() const
  { // return designated object
 #if _ITERATOR_DEBUG_LEVEL == 2
  if (this->_Getcont() == 0
   || this->_Ptr == 0
   || this->_Ptr < ((_Myvec *)this->_Getcont())->_Myfirst
   || ((_Myvec *)this->_Getcont())->_Mylast <= this->_Ptr)
   { // report error
   _DEBUG_ERROR("vector iterator not dereferencable");
   _SCL_SECURE_OUT_OF_RANGE;
   }

 #elif _ITERATOR_DEBUG_LEVEL == 1
  _SCL_SECURE_VALIDATE(this->_Getcont() != 0);
  _SCL_SECURE_VALIDATE_RANGE(
   this->_Ptr != _Tptr()
   && ((_Myvec *)this->_Getcont())->_Myfirst <= this->_Ptr
   && this->_Ptr < ((_Myvec *)this->_Getcont())->_Mylast);
 #endif /* _ITERATOR_DEBUG_LEVEL */

  _Analysis_assume_(this->_Ptr != _Tptr());

  return (*this->_Ptr);
  }

 pointer operator->() const
  { // return pointer to class object
  return (_STD pointer_traits<pointer>::pointer_to(**this));
  }

 _Myiter& operator++()
  { // preincrement
 #if _ITERATOR_DEBUG_LEVEL == 2
  if (this->_Getcont() == 0
   || this->_Ptr == 0
   || ((_Myvec *)this->_Getcont())->_Mylast <= this->_Ptr)
   { // report error
   _DEBUG_ERROR("vector iterator not incrementable");
   _SCL_SECURE_OUT_OF_RANGE;
   }

 #elif _ITERATOR_DEBUG_LEVEL == 1
  _SCL_SECURE_VALIDATE(this->_Getcont() != 0);
  _SCL_SECURE_VALIDATE_RANGE(
   this->_Ptr != _Tptr()
   && this->_Ptr < ((_Myvec *)this->_Getcont())->_Mylast);
 #endif /* _ITERATOR_DEBUG_LEVEL */

  ++this->_Ptr;
  return (*this);
  }

 _Myiter operator++(int)
  { // postincrement
  _Myiter _Tmp = *this;
  ++*this;
  return (_Tmp);
  }

 _Myiter& operator--()
  { // predecrement
 #if _ITERATOR_DEBUG_LEVEL == 2
  if (this->_Getcont() == 0
   || this->_Ptr == 0
   || this->_Ptr <= ((_Myvec *)this->_Getcont())->_Myfirst)
   { // report error
   _DEBUG_ERROR("vector iterator not decrementable");
   _SCL_SECURE_OUT_OF_RANGE;
   }

 #elif _ITERATOR_DEBUG_LEVEL == 1
  _SCL_SECURE_VALIDATE(this->_Getcont() != 0);
  _SCL_SECURE_VALIDATE_RANGE(
   this->_Ptr != _Tptr()
   && ((_Myvec *)this->_Getcont())->_Myfirst < this->_Ptr);
 #endif /* _ITERATOR_DEBUG_LEVEL */

  --this->_Ptr;
  return (*this);
  }

 _Myiter operator--(int)
  { // postdecrement
  _Myiter _Tmp = *this;
  --*this;
  return (_Tmp);
  }

 _Myiter& operator+=(difference_type _Off)
  { // increment by integer
 #if _ITERATOR_DEBUG_LEVEL == 2
  if (this->_Getcont() == 0
   || this->_Ptr + _Off < ((_Myvec *)this->_Getcont())->_Myfirst
   || ((_Myvec *)this->_Getcont())->_Mylast < this->_Ptr + _Off)
   { // report error
   _DEBUG_ERROR("vector iterator + offset out of range");
   _SCL_SECURE_OUT_OF_RANGE;
   }

 #elif _ITERATOR_DEBUG_LEVEL == 1
  _SCL_SECURE_VALIDATE(this->_Getcont() != 0);
  _SCL_SECURE_VALIDATE_RANGE(
   ((_Myvec *)this->_Getcont())->_Myfirst <= this->_Ptr + _Off
   && this->_Ptr + _Off <= ((_Myvec *)this->_Getcont())->_Mylast);
 #endif /* _ITERATOR_DEBUG_LEVEL */

  _Ptr += _Off;
  return (*this);
  }

 _Myiter operator+(difference_type _Off) const
  { // return this + integer
  _Myiter _Tmp = *this;
  return (_Tmp += _Off);
  }

 _Myiter& operator-=(difference_type _Off)
  { // decrement by integer
  return (*this += -_Off);
  }

 _Myiter operator-(difference_type _Off) const
  { // return this - integer
  _Myiter _Tmp = *this;
  return (_Tmp -= _Off);
  }

 difference_type operator-(const _Myiter& _Right) const
  { // return difference of iterators
  _Compat(_Right);
  return (this->_Ptr - _Right._Ptr);
  }

 reference operator[](difference_type _Off) const
  { // subscript
  return (*(*this + _Off));
  }

 bool operator==(const _Myiter& _Right) const
  { // test for iterator equality
  _Compat(_Right);
  return (this->_Ptr == _Right._Ptr);
  }

 bool operator!=(const _Myiter& _Right) const
  { // test for iterator inequality
  return (!(*this == _Right));
  }

 bool operator<(const _Myiter& _Right) const
  { // test if this < _Right
  _Compat(_Right);
  return (this->_Ptr < _Right._Ptr);
  }

 bool operator>(const _Myiter& _Right) const
  { // test if this > _Right
  return (_Right < *this);
  }

 bool operator<=(const _Myiter& _Right) const
  { // test if this <= _Right
  return (!(_Right < *this));
  }

 bool operator>=(const _Myiter& _Right) const
  { // test if this >= _Right
  return (!(*this < _Right));
  }

 #if _ITERATOR_DEBUG_LEVEL == 2
 void _Compat(const _Myiter& _Right) const
  { // test for compatible iterator pair
  if (this->_Getcont() == 0
   || this->_Getcont() != _Right._Getcont())
   { // report error
   _DEBUG_ERROR("vector iterators incompatible");
   _SCL_SECURE_INVALID_ARGUMENT;
   }
  }

 #elif _ITERATOR_DEBUG_LEVEL == 1
 void _Compat(const _Myiter& _Right) const
  { // test for compatible iterator pair
  _SCL_SECURE_VALIDATE(this->_Getcont() != 0);
  _SCL_SECURE_VALIDATE_RANGE(this->_Getcont() == _Right._Getcont());
  }

 #else /* _ITERATOR_DEBUG_LEVEL == 0 */
 void _Compat(const _Myiter&) const
  { // test for compatible iterator pair
  }
 #endif /* _ITERATOR_DEBUG_LEVEL */

 _Tptr _Ptr; // pointer to element in vector
 };

template<class _Myvec> inline
 typename _Vector_const_iterator<_Myvec>::_Unchecked_type
  _Unchecked(_Vector_const_iterator<_Myvec> _Iter)
 { // convert to unchecked
 return (_Iter._Unchecked());
 }

template<class _Myvec> inline
 _Vector_const_iterator<_Myvec>&
  _Rechecked(_Vector_const_iterator<_Myvec>& _Iter,
   typename _Vector_const_iterator<_Myvec>
    ::_Unchecked_type _Right)
 { // convert to checked
 return (_Iter._Rechecked(_Right));
 }

template<class _Myvec> inline
 _Vector_const_iterator<_Myvec> operator+(
  typename _Vector_const_iterator<_Myvec>::difference_type _Off,
  _Vector_const_iterator<_Myvec> _Next)
 { // add offset to iterator
 return (_Next += _Off);
 }

  // TEMPLATE CLASS _Vector_iterator
template<class _Myvec>
 class _Vector_iterator
  : public _Vector_const_iterator<_Myvec>
 { // iterator for mutable vector
public:
 typedef _Vector_iterator<_Myvec> _Myiter;
 typedef _Vector_const_iterator<_Myvec> _Mybase;
 typedef random_access_iterator_tag iterator_category;

 typedef typename _Myvec::value_type value_type;
 typedef typename _Myvec::difference_type difference_type;
 typedef typename _Myvec::pointer pointer;
 typedef typename _Myvec::reference reference;

 _Vector_iterator()
  { // construct with null vector pointer
  }

 _Vector_iterator(pointer _Parg, const _Container_base *_Pvector)
  : _Mybase(_Parg, _Pvector)
  { // construct with pointer _Parg
  }

 typedef pointer _Unchecked_type;

 _Myiter& _Rechecked(_Unchecked_type _Right)
  { // reset from unchecked iterator
  this->_Ptr = _Right;
  return (*this);
  }

 _Unchecked_type _Unchecked() const
  { // make an unchecked iterator
  return (_Unchecked_type(this->_Ptr));
  }

 reference operator*() const
  { // return designated object
  return ((reference)**(_Mybase *)this);
  }

 pointer operator->() const
  { // return pointer to class object
  return (_STD pointer_traits<pointer>::pointer_to(**this));
  }

 _Myiter& operator++()
  { // preincrement
  ++*(_Mybase *)this;
  return (*this);
  }

 _Myiter operator++(int)
  { // postincrement
  _Myiter _Tmp = *this;
  ++*this;
  return (_Tmp);
  }

 _Myiter& operator--()
  { // predecrement
  --*(_Mybase *)this;
  return (*this);
  }

 _Myiter operator--(int)
  { // postdecrement
  _Myiter _Tmp = *this;
  --*this;
  return (_Tmp);
  }

 _Myiter& operator+=(difference_type _Off)
  { // increment by integer
  *(_Mybase *)this += _Off;
  return (*this);
  }

 _Myiter operator+(difference_type _Off) const
  { // return this + integer
  _Myiter _Tmp = *this;
  return (_Tmp += _Off);
  }

 _Myiter& operator-=(difference_type _Off)
  { // decrement by integer
  return (*this += -_Off);
  }

 _Myiter operator-(difference_type _Off) const
  { // return this - integer
  _Myiter _Tmp = *this;
  return (_Tmp -= _Off);
  }

 difference_type operator-(const _Mybase& _Right) const
  { // return difference of iterators
  return (*(_Mybase *)this - _Right);
  }

 reference operator[](difference_type _Off) const
  { // subscript
  return (*(*this + _Off));
  }
 };

template<class _Myvec> inline
 typename _Vector_iterator<_Myvec>::_Unchecked_type
  _Unchecked(_Vector_iterator<_Myvec> _Iter)
 { // convert to unchecked
 return (_Iter._Unchecked());
 }

template<class _Myvec> inline
 _Vector_iterator<_Myvec>&
  _Rechecked(_Vector_iterator<_Myvec>& _Iter,
   typename _Vector_iterator<_Myvec>
    ::_Unchecked_type _Right)
 { // convert to checked
 return (_Iter._Rechecked(_Right));
 }

template<class _Myvec> inline
 _Vector_iterator<_Myvec> operator+(
  typename _Vector_iterator<_Myvec>::difference_type _Off,
  _Vector_iterator<_Myvec> _Next)
 { // add offset to iterator
 return (_Next += _Off);
 }

  // vector TYPE WRAPPERS
template<class _Value_type,
 class _Size_type,
 class _Difference_type,
 class _Pointer,
 class _Const_pointer,
 class _Reference,
 class _Const_reference>
 struct _Vec_iter_types
 { // wraps types needed by iterators
 typedef _Value_type value_type;
 typedef _Size_type size_type;
 typedef _Difference_type difference_type;
 typedef _Pointer pointer;
 typedef _Const_pointer const_pointer;
 typedef _Reference reference;
 typedef _Const_reference const_reference;
 };

template<class _Ty,
 class _Alloc0>
 struct _Vec_base_types
 { // types needed for a container base
 typedef _Alloc0 _Alloc;
 typedef _Vec_base_types<_Ty, _Alloc> _Myt;

 typedef _Wrap_alloc<_Alloc> _Alty0;
 typedef typename _Alty0::template rebind<_Ty>::other _Alty;


 typedef typename _Alty::pointer _Tptr;
 typedef typename _Alty::template rebind<_Tptr>::other _Alpty;

 typedef typename _If<_Is_simple_alloc<_Alty>::value,
  _Simple_types<typename _Alty::value_type>,
  _Vec_iter_types<typename _Alty::value_type,
   typename _Alty::size_type,
   typename _Alty::difference_type,
   typename _Alty::pointer,
   typename _Alty::const_pointer,
   typename _Alty::reference,
   typename _Alty::const_reference> >::type
  _Val_types;
 };

  // TEMPLATE CLASS _Vector_val
template<class _Val_types>
 class _Vector_val
  : public _Container_base
 { // base class for vector to hold data
public:
 typedef _Vector_val<_Val_types> _Myt;

 typedef typename _Val_types::value_type value_type;
 typedef typename _Val_types::size_type size_type;
 typedef typename _Val_types::difference_type difference_type;
 typedef typename _Val_types::pointer pointer;
 typedef typename _Val_types::const_pointer const_pointer;
 typedef typename _Val_types::reference reference;
 typedef typename _Val_types::const_reference const_reference;

 typedef _Vector_iterator<_Myt> iterator;
 typedef _Vector_const_iterator<_Myt> const_iterator;

 _Vector_val()
  { // initialize values
  _Myfirst = pointer();
  _Mylast = pointer();
  _Myend = pointer();
  }

 pointer _Myfirst; // pointer to beginning of array
 pointer _Mylast; // pointer to current end of sequence
 pointer _Myend; // pointer to end of array
 };

  // TEMPLATE CLASS _Vector_alloc
template<bool _Al_has_storage,
 class _Alloc_types>
 class _Vector_alloc
  : public _Vector_val<typename _Alloc_types::_Val_types>
 { // base class for vector to hold allocator with storage
public:
 typename _Alloc_types::_Alty _Alval; // allocator object

 typedef _Vector_alloc<_Al_has_storage, _Alloc_types> _Myt;
 typedef typename _Alloc_types::_Alloc _Alloc;
 typedef typename _Alloc_types::_Alty _Alty;

 #if _ITERATOR_DEBUG_LEVEL == 0
 _Vector_alloc(const _Alloc& _Al = _Alloc())
  : _Alval(_Al)
  { // construct allocator from _Al
  }

 void _Change_alloc(const _Alty& _Al)
  { // replace old allocator
  this->_Alval = _Al;
  }

 void _Swap_alloc(_Myt& _Right)
  { // swap allocators
  _Swap_adl(this->_Alval, _Right._Alval);
  }

 #else /* _ITERATOR_DEBUG_LEVEL == 0 */
 _Vector_alloc(const _Alty& _Al = _Alty())
  : _Alval(_Al)
  { // construct allocator from _Al
  _Alloc_proxy();
  }

 ~_Vector_alloc() _NOEXCEPT
  { // destroy proxy
  _Free_proxy();
  }

 void _Change_alloc(const _Alty& _Al)
  { // replace old allocator
  _Free_proxy();
  this->_Alval = _Al;
  _Alloc_proxy();
  }

 void _Swap_alloc(_Myt& _Right)
  { // swap allocators
  _Swap_adl(this->_Alval, _Right._Alval);
  _Swap_adl(this->_Myproxy, _Right._Myproxy);
  }

 void _Alloc_proxy()
  { // construct proxy from _Alval
  typename _Alty::template rebind<_Container_proxy>::other
   _Alproxy(this->_Alval);
  this->_Myproxy = _Alproxy.allocate(1);
  _Alproxy.construct(this->_Myproxy, _Container_proxy());
  this->_Myproxy->_Mycont = this;
  }

 void _Free_proxy()
  { // destroy proxy
  typename _Alty::template rebind<_Container_proxy>::other
   _Alproxy(this->_Alval);
  this->_Orphan_all();
  _Alproxy.destroy(this->_Myproxy);
  _Alproxy.deallocate(this->_Myproxy, 1);
  this->_Myproxy = 0;
  }
 #endif /* _ITERATOR_DEBUG_LEVEL == 0 */

 _Alty& _Getal()
  { // get reference to allocator
  return (this->_Alval);
  }

 const _Alty& _Getal() const
  { // get reference to allocator
  return (this->_Alval);
  }
 };

template<class _Alloc_types>
 class _Vector_alloc<false, _Alloc_types>
  : public _Vector_val<typename _Alloc_types::_Val_types>
 { // base class for vector to hold allocator with no storage
public:
 typedef _Vector_alloc<false, _Alloc_types> _Myt;
 typedef typename _Alloc_types::_Alloc _Alloc;

 typedef typename _Alloc_types::_Alty _Alty;

 #if _ITERATOR_DEBUG_LEVEL == 0
 _Vector_alloc(const _Alloc& = _Alloc())
  { // construct allocator from _Al
  }

 void _Change_alloc(const _Alty&)
  { // replace old allocator
  }

 void _Swap_alloc(_Myt&)
  { // swap allocators
  }

 #else /* _ITERATOR_DEBUG_LEVEL == 0 */
 _Vector_alloc(const _Alloc& = _Alloc())
  { // construct allocator from _Al
  _Alloc_proxy();
  }

 ~_Vector_alloc() _NOEXCEPT
  { // destroy proxy
  _Free_proxy();
  }

 void _Change_alloc(const _Alty&)
  { // replace old allocator
  }

 void _Swap_alloc(_Myt& _Right)
  { // swap allocators
  _Swap_adl(this->_Myproxy, _Right._Myproxy);
  }

 void _Alloc_proxy()
  { // construct proxy from _Alval
  typename _Alty::template rebind<_Container_proxy>::other
   _Alproxy;
  this->_Myproxy = _Alproxy.allocate(1);
  _Alproxy.construct(this->_Myproxy, _Container_proxy());
  this->_Myproxy->_Mycont = this;
  }

 void _Free_proxy()
  { // destroy proxy
  typename _Alty::template rebind<_Container_proxy>::other
   _Alproxy;
  this->_Orphan_all();
  _Alproxy.destroy(this->_Myproxy);
  _Alproxy.deallocate(this->_Myproxy, 1);
  this->_Myproxy = 0;
  }
 #endif /* _ITERATOR_DEBUG_LEVEL == 0 */

 _Alty _Getal() const
  { // get reference to allocator
  return (_Alty());
  }
 };

  // TEMPLATE CLASS vector
template<class _Ty,
 class _Alloc = allocator<_Ty> >
 class vector
  : public _Vector_alloc<!is_empty<_Alloc>::value,
   _Vec_base_types<_Ty, _Alloc> >
 { // varying size array of values
public:
 typedef vector<_Ty, _Alloc> _Myt;
 typedef _Vector_alloc<!is_empty<_Alloc>::value,
  _Vec_base_types<_Ty, _Alloc> > _Mybase;
 typedef _Alloc allocator_type;

 typedef typename _Mybase::_Alty _Alty;

 typedef typename _Mybase::value_type value_type;
 typedef typename _Mybase::size_type size_type;
 typedef typename _Mybase::difference_type difference_type;
 typedef typename _Mybase::pointer pointer;
 typedef typename _Mybase::const_pointer const_pointer;
 typedef typename _Mybase::reference reference;
 typedef typename _Mybase::const_reference const_reference;

 #define _VICONT(it) it._Getcont()
 #define _VIPTR(it) (it)._Ptr

 typedef typename _Mybase::iterator iterator;
 typedef typename _Mybase::const_iterator const_iterator;

 typedef _STD reverse_iterator<iterator> reverse_iterator;
 typedef _STD reverse_iterator<const_iterator> const_reverse_iterator;

 vector()
  : _Mybase()
  { // construct empty vector
  }

 explicit vector(const _Alloc& _Al)
  : _Mybase(_Al)
  { // construct empty vector, allocator
  }

 explicit vector(size_type _Count)
  : _Mybase()
  { // construct from _Count * value_type()
  if (_Buy(_Count))
   { // nonzero, fill it
   _Alty _Alval(this->_Getal());
   _TRY_BEGIN
   _Uninitialized_default_fill_n(this->_Myfirst, _Count, _Alval);
   this->_Mylast += _Count;
   _CATCH_ALL
   _Tidy();
   _RERAISE;
   _CATCH_END
   }
  }

 vector(size_type _Count, const value_type& _Val)
  : _Mybase()
  { // construct from _Count * _Val
  _Construct_n(_Count, _STD addressof(_Val));
  }

 vector(size_type _Count, const value_type& _Val, const _Alloc& _Al)
  : _Mybase(_Al)
  { // construct from _Count * _Val, allocator
  _Construct_n(_Count, _STD addressof(_Val));
  }

 vector(const _Myt& _Right)

  : _Mybase(_Right._Getal().select_on_container_copy_construction())


  { // construct by copying _Right
  if (_Buy(_Right.size()))
   _TRY_BEGIN
   this->_Mylast = _Ucopy(_Right.begin(), _Right.end(),
    this->_Myfirst);
   _CATCH_ALL
   _Tidy();
   _RERAISE;
   _CATCH_END
  }

 vector(const _Myt& _Right, const _Alloc& _Al)
  : _Mybase(_Al)
  { // construct by copying _Right, allocator
  if (_Buy(_Right.size()))
   _TRY_BEGIN
   this->_Mylast = _Ucopy(_Right.begin(), _Right.end(),
    this->_Myfirst);
   _CATCH_ALL
   _Tidy();
   _RERAISE;
   _CATCH_END
  }

 template<class _Iter,
  class = typename enable_if<_Is_iterator<_Iter>::value,
   void>:: type>
  vector(_Iter _First, _Iter _Last)
  : _Mybase()
  { // construct from [_First, _Last)
  _Construct(_First, _Last);
  }

 template<class _Iter,
  class = typename enable_if<_Is_iterator<_Iter>::value,
   void>:: type>
  vector(_Iter _First, _Iter _Last, const _Alloc& _Al)
  : _Mybase(_Al)
  { // construct from [_First, _Last) with allocator
  _Construct(_First, _Last);
  }

 template<class _Iter>
  void _Construct(_Iter _First, _Iter _Last)
  { // initialize with [_First, _Last)
  _Construct(_First, _Last, _Iter_cat(_First));
  }

 template<class _Iter>
  void _Construct(_Iter _First, _Iter _Last, input_iterator_tag)
  { // initialize with [_First, _Last), input iterators
  _TRY_BEGIN

  for (; _First != _Last; ++_First)
   emplace_back(*_First);

  _CATCH_ALL
  _Tidy();
  _RERAISE;
  _CATCH_END
  }

 template<class _Iter>
  void _Construct(_Iter _First, _Iter _Last, forward_iterator_tag)
  { // initialize with [_First, _Last), forward iterators
  if (_Buy(_STD distance(_First, _Last)))
   { // nonzero, fill it
   _TRY_BEGIN
   this->_Mylast = _Ucopy(_First, _Last, this->_Myfirst);
   _CATCH_ALL
   _Tidy();
   _RERAISE;
   _CATCH_END
   }
  }

 void _Construct_n(size_type _Count, const value_type *_Pval)
  { // construct from _Count * *_Pval
  if (_Buy(_Count))
   { // nonzero, fill it
   _TRY_BEGIN
   this->_Mylast = _Ufill(this->_Myfirst, _Count, _Pval);
   _CATCH_ALL
   _Tidy();
   _RERAISE;
   _CATCH_END
   }
  }

 vector(_Myt&& _Right)
  : _Mybase(_Right._Getal())
  { // construct by moving _Right
  _Assign_rv(_STD forward<_Myt>(_Right), true_type());
  }

 vector(_Myt&& _Right, const _Alloc& _Al)
  : _Mybase(_Al)
  { // construct by moving _Right, allocator
  _Assign_rv(_STD forward<_Myt>(_Right));
  }

 _Myt& operator=(_Myt&& _Right)
  { // assign by moving _Right
  if (this != &_Right)
   { // different, assign it
   _Tidy();
   if (_Alty::propagate_on_container_move_assignment::value
    && this->_Getal() != _Right._Getal())
    this->_Change_alloc(_Right._Getal());

   _Assign_rv(_STD forward<_Myt>(_Right));
   }
  return (*this);
  }

 void _Assign_rv(_Myt&& _Right, true_type)
  { // move from _Right, stealing its contents
  this->_Swap_all((_Myt&)_Right);
  this->_Myfirst = _Right._Myfirst;
  this->_Mylast = _Right._Mylast;
  this->_Myend = _Right._Myend;

  _Right._Myfirst = pointer();
  _Right._Mylast = pointer();
  _Right._Myend = pointer();
  }

 void _Assign_rv(_Myt&& _Right, false_type)
  { // move from _Right, possibly moving its contents
  if (get_allocator() == _Right.get_allocator())
   _Assign_rv(_STD forward<_Myt>(_Right), true_type());
  else
   _Construct(_STD make_move_iterator(_Right.begin()),
    _STD make_move_iterator(_Right.end()));
  }

 void _Assign_rv(_Myt&& _Right)
  { // assign by moving _Right
  _Assign_rv(_STD forward<_Myt>(_Right),
   typename _Alty::propagate_on_container_move_assignment());
  }


 void push_back(value_type&& _Val)
  { // insert by moving into element at end
  if (_Inside(_STD addressof(_Val)))
   { // push back an element
   size_type _Idx = _STD addressof(_Val) - this->_Myfirst;
   if (this->_Mylast == this->_Myend)
    _Reserve(1);
   _Orphan_range(this->_Mylast, this->_Mylast);
   this->_Getal().construct(this->_Mylast,
    _STD forward<value_type>(this->_Myfirst[_Idx]));
   ++this->_Mylast;
   }
  else
   { // push back a non-element
   if (this->_Mylast == this->_Myend)
    _Reserve(1);
   _Orphan_range(this->_Mylast, this->_Mylast);
   this->_Getal().construct(this->_Mylast,
    _STD forward<value_type>(_Val));
   ++this->_Mylast;
   }
  }
 void unsafe_push_back(value_type&& _Val)
  {
   this->_Getal().construct(this->_Mylast,
    _STD forward<value_type>(_Val));
   ++this->_Mylast;
  }
 iterator insert(const_iterator _Where, _Ty&& _Val)
  { // insert by moving _Val at _Where
  return (emplace(_Where, _STD move(_Val)));
  }

 template<class... _Valty>
  void emplace_back(_Valty&&... _Val)
  { // insert by moving into element at end
  if (this->_Mylast == this->_Myend)
   _Reserve(1);
  _Orphan_range(this->_Mylast, this->_Mylast);
  this->_Getal().construct(this->_Mylast,
   _STD forward<_Valty>(_Val)...);
  ++this->_Mylast;
  }
 template<class... _Valty>
  void unsafe_emplace_back(_Valty&&... _Val)
  { // insert by moving into element at end
  this->_Getal().construct(this->_Mylast,
   _STD forward<_Valty>(_Val)...);
  ++this->_Mylast;
  }
 template<class... _Valty>
  iterator emplace(const_iterator _Where, _Valty&&... _Val)
  { // insert by moving _Val at _Where
  size_type _Off = _VIPTR(_Where) - this->_Myfirst;

 #if _ITERATOR_DEBUG_LEVEL == 2
  if (size() < _Off)
   _DEBUG_ERROR("vector emplace iterator outside range");
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */

  emplace_back(_STD forward<_Valty>(_Val)...);
  _STD rotate(begin() + _Off, end() - 1, end());
  return (begin() + _Off);
  }


 vector(_XSTD initializer_list<value_type> _Ilist,
  const _Alloc& _Al = allocator_type())
  : _Mybase(_Al)
  { // construct from initializer_list
  insert(begin(), _Ilist.begin(), _Ilist.end());
  }

 _Myt& operator=(_XSTD initializer_list<value_type> _Ilist)
  { // assign initializer_list
  assign(_Ilist.begin(), _Ilist.end());
  return (*this);
  }

 void assign(_XSTD initializer_list<value_type> _Ilist)
  { // assign initializer_list
  assign(_Ilist.begin(), _Ilist.end());
  }

 iterator insert(const_iterator _Where,
  _XSTD initializer_list<value_type> _Ilist)
  { // insert initializer_list
  return (insert(_Where, _Ilist.begin(), _Ilist.end()));
  }

 ~vector() _NOEXCEPT
  { // destroy the object
  _Tidy();
  }

 _Myt& operator=(const _Myt& _Right)
  { // assign _Right
  if (this != &_Right)
   { // different, assign it
   if (this->_Getal() != _Right._Getal()
    && _Alty::propagate_on_container_copy_assignment::value)
    { // change allocator before copying
    _Tidy();
    this->_Change_alloc(_Right._Getal());
    }

   this->_Orphan_all();

   if (_Right.empty())
    clear(); // new sequence empty, erase existing sequence
   else if (_Right.size() <= size())
    { // enough elements, copy new and destroy old
    pointer _Ptr = _Copy_impl(_Right._Myfirst,
     _Right._Mylast, this->_Myfirst); // copy new
    _Destroy(_Ptr, this->_Mylast); // destroy old
    this->_Mylast = this->_Myfirst + _Right.size();
    }
   else if (_Right.size() <= capacity())
    { // enough room, copy and construct new
    pointer _Ptr = _Right._Myfirst + size();
    _Copy_impl(_Right._Myfirst,
     _Ptr, this->_Myfirst);
    this->_Mylast = _Ucopy(_Ptr, _Right._Mylast, this->_Mylast);
    }
   else
    { // not enough room, allocate new array and construct new
    if (this->_Myfirst != pointer())
     { // discard old array
     _Destroy(this->_Myfirst, this->_Mylast);
     this->_Getal().deallocate(this->_Myfirst,
      this->_Myend - this->_Myfirst);
     }
    if (_Buy(_Right.size()))
     _TRY_BEGIN
     this->_Mylast = _Ucopy(_Right._Myfirst, _Right._Mylast,
      this->_Myfirst);
     _CATCH_ALL
     _Tidy();
     _RERAISE;
     _CATCH_END
    }
   }
  return (*this);
  }

 void reserve(size_type _Count)
  { // determine new minimum length of allocated storage
  if (capacity() < _Count)
   { // something to do, check and reallocate
   if (max_size() < _Count)
    _Xlen();
   _Reallocate(_Count);
   }
  }

 size_type capacity() const _NOEXCEPT
  { // return current length of allocated storage
  return (this->_Myend - this->_Myfirst);
  }

 size_type _Unused_capacity() const _NOEXCEPT
  { // micro-optimization for capacity() - size()
  return (this->_Myend - this->_Mylast);
  }

 size_type _Has_unused_capacity() const _NOEXCEPT
  { // micro-optimization for capacity() != size()
  return (this->_Myend != this->_Mylast);
  }

 iterator begin() _NOEXCEPT
  { // return iterator for beginning of mutable sequence
  return (iterator(this->_Myfirst, this));
  }

 const_iterator begin() const _NOEXCEPT
  { // return iterator for beginning of nonmutable sequence
  return (const_iterator(this->_Myfirst, this));
  }

 iterator end() _NOEXCEPT
  { // return iterator for end of mutable sequence
  return (iterator(this->_Mylast, this));
  }

 const_iterator end() const _NOEXCEPT
  { // return iterator for end of nonmutable sequence
  return (const_iterator(this->_Mylast, this));
  }

 iterator _Make_iter(const_iterator _Where) const
  { // make iterator from const_iterator
  return (iterator(_Where._Ptr, this));
  }

 reverse_iterator rbegin() _NOEXCEPT
  { // return iterator for beginning of reversed mutable sequence
  return (reverse_iterator(end()));
  }

 const_reverse_iterator rbegin() const _NOEXCEPT
  { // return iterator for beginning of reversed nonmutable sequence
  return (const_reverse_iterator(end()));
  }

 reverse_iterator rend() _NOEXCEPT
  { // return iterator for end of reversed mutable sequence
  return (reverse_iterator(begin()));
  }

 const_reverse_iterator rend() const _NOEXCEPT
  { // return iterator for end of reversed nonmutable sequence
  return (const_reverse_iterator(begin()));
  }

 const_iterator cbegin() const _NOEXCEPT
  { // return iterator for beginning of nonmutable sequence
  return (((const _Myt *)this)->begin());
  }

 const_iterator cend() const _NOEXCEPT
  { // return iterator for end of nonmutable sequence
  return (((const _Myt *)this)->end());
  }

 const_reverse_iterator crbegin() const _NOEXCEPT
  { // return iterator for beginning of reversed nonmutable sequence
  return (((const _Myt *)this)->rbegin());
  }

 const_reverse_iterator crend() const _NOEXCEPT
  { // return iterator for end of reversed nonmutable sequence
  return (((const _Myt *)this)->rend());
  }

 void shrink_to_fit()
  { // reduce capacity
  if (_Has_unused_capacity())
   { // worth shrinking, do it
   if (empty())
    _Tidy();
   else
    _Reallocate(size());
   }
  }
 void unsafe_resize(size_type _Newsize)
 {
  this->_Mylast += _Newsize - size();
 }
 void resize(size_type _Newsize)
  { // determine new length, padding as needed
  if (_Newsize < size())
   _Pop_back_n(size() - _Newsize);
  else if (size() < _Newsize)
   { // pad as needed
   _Alty _Alval(this->_Getal());
   _Reserve(_Newsize - size());
   _TRY_BEGIN
   _Uninitialized_default_fill_n(this->_Mylast, _Newsize - size(),
    _Alval);
   _CATCH_ALL
   _Tidy();
   _RERAISE;
   _CATCH_END
   this->_Mylast += _Newsize - size();
   }
  }
 void resize(size_type _Newsize, const value_type& _Val)
  { // determine new length, padding with _Val elements as needed
  if (_Newsize < size())
   _Pop_back_n(size() - _Newsize);
  else if (size() < _Newsize)
   { // pad as needed
   const value_type *_Ptr = _STD addressof(_Val);

   if (_Inside(_Ptr))
    { // padding is inside vector, recompute _Ptr after reserve
    const difference_type _Idx = _Ptr
     - _STD addressof(*this->_Myfirst);
    _Reserve(_Newsize - size());
    _Ptr = _STD addressof(*this->_Myfirst) + _Idx;
    }
   else
    _Reserve(_Newsize - size());

   _TRY_BEGIN
   _Ufill(this->_Mylast, _Newsize - size(), _Ptr);
   _CATCH_ALL
   _Tidy();
   _RERAISE;
   _CATCH_END
   this->_Mylast += _Newsize - size();
   }
  }

 size_type size() const _NOEXCEPT
  { // return length of sequence
  return (this->_Mylast - this->_Myfirst);
  }

 size_type max_size() const _NOEXCEPT
  { // return maximum possible length of sequence
  return (this->_Getal().max_size());
  }

 bool empty() const _NOEXCEPT
  { // test if sequence is empty
  return (this->_Myfirst == this->_Mylast);
  }

 _Alloc get_allocator() const _NOEXCEPT
  { // return allocator object for values
  return (this->_Getal());
  }

 const_reference at(size_type _Pos) const
  { // subscript nonmutable sequence with checking
  if (size() <= _Pos)
   _Xran();
  return (*(this->_Myfirst + _Pos));
  }

 reference at(size_type _Pos)
  { // subscript mutable sequence with checking
  if (size() <= _Pos)
   _Xran();
  return (*(this->_Myfirst + _Pos));
  }

 const_reference operator[](size_type _Pos) const
  { // subscript nonmutable sequence
 #if _ITERATOR_DEBUG_LEVEL == 2
  if (size() <= _Pos)
   { // report error
   _DEBUG_ERROR("vector subscript out of range");
   _SCL_SECURE_OUT_OF_RANGE;
   }

 #elif _ITERATOR_DEBUG_LEVEL == 1
  _SCL_SECURE_VALIDATE_RANGE(_Pos < size());
 #endif /* _ITERATOR_DEBUG_LEVEL */

  return (*(this->_Myfirst + _Pos));
  }

 reference operator[](size_type _Pos)
  { // subscript mutable sequence
 #if _ITERATOR_DEBUG_LEVEL == 2
  if (size() <= _Pos)
   { // report error
   _DEBUG_ERROR("vector subscript out of range");
   _SCL_SECURE_OUT_OF_RANGE;
   }

 #elif _ITERATOR_DEBUG_LEVEL == 1
  _SCL_SECURE_VALIDATE_RANGE(_Pos < size());
 #endif /* _ITERATOR_DEBUG_LEVEL */

  return (*(this->_Myfirst + _Pos));
  }

 pointer data() _NOEXCEPT
  { // return address of first element
  return (this->_Myfirst);
  }

 const_pointer data() const _NOEXCEPT
  { // return address of first element
  return (this->_Myfirst);
  }

 reference front()
  { // return first element of mutable sequence
  return (*begin());
  }

 const_reference front() const
  { // return first element of nonmutable sequence
  return (*begin());
  }

 reference back()
  { // return last element of mutable sequence
  return (*(end() - 1));
  }

 const_reference back() const
  { // return last element of nonmutable sequence
  return (*(end() - 1));
  }

 void push_back(const value_type& _Val)
  { // insert element at end
  if (_Inside(_STD addressof(_Val)))
   { // push back an element
   size_type _Idx = _STD addressof(_Val) - this->_Myfirst;
   if (this->_Mylast == this->_Myend)
    _Reserve(1);
   _Orphan_range(this->_Mylast, this->_Mylast);
   this->_Getal().construct(this->_Mylast,
    this->_Myfirst[_Idx]);
   ++this->_Mylast;
   }
  else
   { // push back a non-element
   if (this->_Mylast == this->_Myend)
    _Reserve(1);
   _Orphan_range(this->_Mylast, this->_Mylast);
   this->_Getal().construct(this->_Mylast,
    _Val);
   ++this->_Mylast;
   }
  }
 void unsafe_push_back(const value_type& _Val)
  { // insert element at end
   this->_Getal().construct(this->_Mylast,
    _Val);
   ++this->_Mylast;
  }

 #if _ITERATOR_DEBUG_LEVEL == 2
 void pop_back()
  { // erase element at end
  if (empty())
   _DEBUG_ERROR("vector empty before pop");
  else
   { // erase last element
   _Orphan_range(this->_Mylast - 1, this->_Mylast);
   this->_Getal().destroy(this->_Mylast - 1);
   --this->_Mylast;
   }
  }

 #else /* _ITERATOR_DEBUG_LEVEL == 2 */
 void pop_back()
  { // erase element at end
  this->_Getal().destroy(this->_Mylast - 1);
  --this->_Mylast;
  }
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */

 template<class _Iter>
  typename enable_if<_Is_iterator<_Iter>::value,
   void>::type
  assign(_Iter _First, _Iter _Last)
  { // assign [_First, _Last)
  clear();
  _Assign(_First, _Last, _Iter_cat(_First));
  }

 template<class _Iter>
  void _Assign(_Iter _First, _Iter _Last, input_iterator_tag)
  { // assign [_First, _Last), input iterators
  for (; _First != _Last; ++_First)
   emplace_back(*_First);
  }

 template<class _Iter>
  void _Assign(_Iter _First, _Iter _Last, forward_iterator_tag)
  { // assign [_First, _Last), forward iterators
  if (_First == _Last)
   return; // nothing to do

  size_type _Newsize = _STD distance(_First, _Last);

  if (capacity() < _Newsize)
   { // need more room, try to get it
   size_type _Newcapacity = _Grow_to(_Newsize);
   _Tidy();
   _Buy(_Newcapacity);
   }

  this->_Mylast = _Ucopy(_First, _Last, this->_Myfirst);
  }

 void assign(size_type _Count, const value_type& _Val)
  { // assign _Count * _Val
  clear();
  insert(begin(), _Count, _Val);
  }

 iterator insert(const_iterator _Where, const _Ty& _Val)
  { // insert _Val at _Where
  return (_Insert_n(_Where, (size_type)1, _Val));
  }

 iterator insert(const_iterator _Where, size_type _Count,
  const _Ty& _Val)
  { // insert _Count * _Val at _Where
  return (_Insert_n(_Where, _Count, _Val));
  }

 template<class _Iter>
  typename enable_if<_Is_iterator<_Iter>::value,
   iterator>::type
  insert(const_iterator _Where, _Iter _First, _Iter _Last)
  { // insert [_First, _Last) at _Where
  size_type _Off = _VIPTR(_Where) - this->_Myfirst;
  _Insert(_Where, _First, _Last, _Iter_cat(_First));
  return (begin() + _Off);
  }

 template<class _Iter>
  void _Insert(const_iterator _Where, _Iter _First, _Iter _Last,
   input_iterator_tag)
  { // insert [_First, _Last) at _Where, input iterators
  size_type _Off = _VIPTR(_Where) - this->_Myfirst;

 #if _ITERATOR_DEBUG_LEVEL == 2
  if (size() < _Off)
   _DEBUG_ERROR("vector insert iterator outside range");
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */

  if (_First != _Last)
   { // worth doing, gather at end and rotate into place
   size_type _Oldsize = size();

   _TRY_BEGIN
   for (; _First != _Last; ++_First)
    push_back(*_First); // append

   _CATCH_ALL
   erase(begin() + _Oldsize, end());
   _RERAISE;
   _CATCH_END

   _STD rotate(begin() + _Off, begin() + _Oldsize, end());
   }
  }

 template<class _Iter>
  void _Insert(const_iterator _Where, _Iter _First, _Iter _Last,
   forward_iterator_tag)
  { // insert [_First, _Last) at _Where, forward iterators
 #if _ITERATOR_DEBUG_LEVEL == 2
  if (_VICONT(_Where) != this
   || _VIPTR(_Where) < this->_Myfirst
   || this->_Mylast < _VIPTR(_Where))
   _DEBUG_ERROR("vector insert iterator outside range");
  _DEBUG_RANGE(_First, _Last);
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */

  size_type _Count = 0;
  _Distance(_First, _Last, _Count);

  if (_Count == 0)
   ;
  else if (_Unused_capacity() < _Count)
   { // not enough room, reallocate
   if (max_size() - size() < _Count)
    _Xlen(); // result too long

   size_type _Capacity = _Grow_to(size() + _Count);
   pointer _Newvec = this->_Getal().allocate(_Capacity);
   pointer _Ptr = _Newvec;

   _TRY_BEGIN
   _Ptr = _Umove(this->_Myfirst, _VIPTR(_Where),
    _Newvec); // copy prefix
   _Ptr = _Ucopy(_First, _Last, _Ptr); // add new stuff
   _Umove(_VIPTR(_Where), this->_Mylast,
    _Ptr); // copy suffix
   _CATCH_ALL
   _Destroy(_Newvec, _Ptr);
   this->_Getal().deallocate(_Newvec, _Capacity);
   _RERAISE;
   _CATCH_END

   _Count += size();
   if (this->_Myfirst != pointer())
    { // destroy and deallocate old array
    _Destroy(this->_Myfirst, this->_Mylast);
    this->_Getal().deallocate(this->_Myfirst,
     this->_Myend - this->_Myfirst);
    }

   this->_Orphan_all();
   this->_Myend = _Newvec + _Capacity;
   this->_Mylast = _Newvec + _Count;
   this->_Myfirst = _Newvec;
   }
  else
   { // new stuff fits, append and rotate into place
   _Ucopy(_First, _Last, this->_Mylast);
   _STD rotate(_VIPTR(_Where), this->_Mylast,
    this->_Mylast + _Count);
   this->_Mylast += _Count;
   _Orphan_range(_VIPTR(_Where), this->_Mylast);
   }
  }

 #if _ITERATOR_DEBUG_LEVEL == 2
 iterator erase(const_iterator _Where)
  { // erase element at where
  if (_VICONT(_Where) != this
   || _VIPTR(_Where) < this->_Myfirst
   || this->_Mylast <= _VIPTR(_Where))
   _DEBUG_ERROR("vector erase iterator outside range");
  _Move(_VIPTR(_Where) + 1, this->_Mylast, _VIPTR(_Where));
  _Destroy(this->_Mylast - 1, this->_Mylast);
  _Orphan_range(_VIPTR(_Where), this->_Mylast);
  --this->_Mylast;
  return (_Make_iter(_Where));
  }

 #else /* _ITERATOR_DEBUG_LEVEL == 2 */
 iterator erase(const_iterator _Where)
  { // erase element at where
  _Move(_VIPTR(_Where) + 1, this->_Mylast,
   _VIPTR(_Where));
  _Destroy(this->_Mylast - 1, this->_Mylast);
  --this->_Mylast;
  return (_Make_iter(_Where));
  }
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */

 iterator erase(const_iterator _First_arg,
  const_iterator _Last_arg)
  { // erase [_First, _Last)
  if (_First_arg == begin() && _Last_arg == end())
   clear();
  else if (_First_arg != _Last_arg)
   { // clear partial
   iterator _First = _Make_iter(_First_arg);
   iterator _Last = _Make_iter(_Last_arg);

   if (_First != _Last)
    { // worth doing, copy down over hole
 #if _ITERATOR_DEBUG_LEVEL == 2
    if (_Last < _First || _VICONT(_First) != this
     || _VIPTR(_First) < this->_Myfirst
     || this->_Mylast < _VIPTR(_Last))
     _DEBUG_ERROR("vector erase iterator outside range");
    pointer _Ptr = _Move(_VIPTR(_Last), this->_Mylast,
     _VIPTR(_First));
    _Orphan_range(_VIPTR(_First), this->_Mylast);

 #else /* _ITERATOR_DEBUG_LEVEL == 2 */
    pointer _Ptr = _Move(_VIPTR(_Last), this->_Mylast,
     _VIPTR(_First));
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */

    _Destroy(_Ptr, this->_Mylast);
    this->_Mylast = _Ptr;
    }
   }
  return (_Make_iter(_First_arg));
  }

 void _Pop_back_n(size_type _Count)
  { // erase _Count elements at end
  pointer _Ptr = this->_Mylast - _Count;

 #if _ITERATOR_DEBUG_LEVEL == 2
  _Orphan_range(_Ptr, this->_Mylast);
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */

  _Destroy(_Ptr, this->_Mylast);
  this->_Mylast = _Ptr;
  }

 void clear() _NOEXCEPT
  { // erase all
  this->_Orphan_all();
  _Destroy(this->_Myfirst, this->_Mylast);
  this->_Mylast = this->_Myfirst;
  }

 void swap(_Myt& _Right)
  { // exchange contents with _Right
  if (this == &_Right)
   ; // same object, do nothing
  else if (this->_Getal() == _Right._Getal())
   { // same allocator, swap control information
   this->_Swap_all(_Right);
   _Swap_adl(this->_Myfirst, _Right._Myfirst);
   _Swap_adl(this->_Mylast, _Right._Mylast);
   _Swap_adl(this->_Myend, _Right._Myend);
   }

  else if (_Alty::propagate_on_container_swap::value)
   { // swap allocators and control information
   this->_Swap_alloc(_Right);
   _Swap_adl(this->_Myfirst, _Right._Myfirst);
   _Swap_adl(this->_Mylast, _Right._Mylast);
   _Swap_adl(this->_Myend, _Right._Myend);
   }

  else
   { // containers are incompatible
 #if _ITERATOR_DEBUG_LEVEL == 2
   _DEBUG_ERROR("vector containers incompatible for swap");

 #else /* ITERATOR_DEBUG_LEVEL == 2 */
   _XSTD terminate();
 #endif /* ITERATOR_DEBUG_LEVEL == 2 */
   }
  }

protected:
 bool _Buy(size_type _Capacity)
  { // allocate array with _Capacity elements
  this->_Myfirst = pointer();
  this->_Mylast = pointer();
  this->_Myend = pointer();

  if (_Capacity == 0)
   return (false);
  else if (max_size() < _Capacity)
   _Xlen(); // result too long
  else
   { // nonempty array, allocate storage
   this->_Myfirst = this->_Getal().allocate(_Capacity);
   this->_Mylast = this->_Myfirst;
   this->_Myend = this->_Myfirst + _Capacity;
   }
  return (true);
  }

 void _Destroy(pointer _First, pointer _Last)
  { // destroy [_First, _Last) using allocator
  _Alty _Alval(this->_Getal());
  _Destroy_range(_First, _Last, _Alval);
  }

 size_type _Grow_to(size_type _Count) const
  { // grow by 50% or at least to _Count
  size_type _Capacity = capacity();

  _Capacity = max_size() - _Capacity / 2 < _Capacity
   ? 0 : _Capacity + _Capacity / 2; // try to grow by 50%
  if (_Capacity < _Count)
   _Capacity = _Count;
  return (_Capacity);
  }

 bool _Inside(const value_type *_Ptr) const
  { // test if _Ptr points inside vector
  return (_Ptr < this->_Mylast && this->_Myfirst <= _Ptr);
  }

 void _Reallocate(size_type _Count)
  { // move to array of exactly _Count elements
  pointer _Ptr = this->_Getal().allocate(_Count);

  _TRY_BEGIN
  _Umove(this->_Myfirst, this->_Mylast, _Ptr);
  _CATCH_ALL
  this->_Getal().deallocate(_Ptr, _Count);
  _RERAISE;
  _CATCH_END

  size_type _Size = size();
  if (this->_Myfirst != pointer())
   { // destroy and deallocate old array
   _Destroy(this->_Myfirst, this->_Mylast);
   this->_Getal().deallocate(this->_Myfirst,
    this->_Myend - this->_Myfirst);
   }

  this->_Orphan_all();
  this->_Myend = _Ptr + _Count;
  this->_Mylast = _Ptr + _Size;
  this->_Myfirst = _Ptr;
  }

 void _Reserve(size_type _Count)
  { // ensure room for _Count new elements, grow exponentially
  if (_Unused_capacity() < _Count)
   { // need more room, try to get it
   if (max_size() - size() < _Count)
    _Xlen();
   _Reallocate(_Grow_to(size() + _Count));
   }
  }

 void _Tidy()
  { // free all storage
  if (this->_Myfirst != pointer())
   { // something to free, destroy and deallocate it
   this->_Orphan_all();
   _Destroy(this->_Myfirst, this->_Mylast);
   this->_Getal().deallocate(this->_Myfirst,
    this->_Myend - this->_Myfirst);
   this->_Myfirst = pointer();
   this->_Mylast = pointer();
   this->_Myend = pointer();
   }
  }

 template<class _Iter>
  pointer _Ucopy(_Iter _First, _Iter _Last, pointer _Ptr)
  { // copy initializing [_First, _Last), using allocator
  _Alty _Alval(this->_Getal());
  return (_Uninitialized_copy(_First, _Last,
   _Ptr, _Alval));
  }

 template<class _Iter>
  pointer _Umove(_Iter _First, _Iter _Last, pointer _Ptr)
  { // move initializing [_First, _Last), using allocator
  _Alty _Alval(this->_Getal());
  return (_Uninitialized_move(_First, _Last,
   _Ptr, _Alval));
  }

 iterator _Insert_n(const_iterator _Where,
  size_type _Count, const value_type& _Val)
  { // insert _Count * _Val at _Where
 #if _ITERATOR_DEBUG_LEVEL == 2
  if (_VICONT(_Where) != this
   || _VIPTR(_Where) < this->_Myfirst
   || this->_Mylast < _VIPTR(_Where))
   _DEBUG_ERROR("vector insert iterator outside range");
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */

  size_type _Off = _VIPTR(_Where) - this->_Myfirst;
  if (_Count == 0)
   ;
  else if (_Unused_capacity() < _Count)
   { // not enough room, reallocate
   if (max_size() - size() < _Count)
    _Xlen(); // result too long

   size_type _Capacity = _Grow_to(size() + _Count);
   pointer _Newvec = this->_Getal().allocate(_Capacity);
   size_type _Whereoff = _VIPTR(_Where) - this->_Myfirst;
   int _Ncopied = 0;

   _TRY_BEGIN
   _Ufill(_Newvec + _Whereoff, _Count,
    _STD addressof(_Val)); // add new stuff
   ++_Ncopied;
   _Umove(this->_Myfirst, _VIPTR(_Where),
    _Newvec); // copy prefix
   ++_Ncopied;
   _Umove(_VIPTR(_Where), this->_Mylast,
    _Newvec + (_Whereoff + _Count)); // copy suffix
   _CATCH_ALL
   if (1 < _Ncopied)
    _Destroy(_Newvec, _Newvec + _Whereoff);
   if (0 < _Ncopied)
    _Destroy(_Newvec + _Whereoff, _Newvec + _Whereoff + _Count);
   this->_Getal().deallocate(_Newvec, _Capacity);
   _RERAISE;
   _CATCH_END

   _Count += size();
   if (this->_Myfirst != pointer())
    { // destroy and deallocate old array
    _Destroy(this->_Myfirst, this->_Mylast);
    this->_Getal().deallocate(this->_Myfirst,
     this->_Myend - this->_Myfirst);
    }

   this->_Orphan_all();
   this->_Myend = _Newvec + _Capacity;
   this->_Mylast = _Newvec + _Count;
   this->_Myfirst = _Newvec;
   }
  else if ((size_type)(this->_Mylast - _VIPTR(_Where))
   < _Count)
   { // new stuff spills off end
   value_type _Tmp = _Val; // in case _Val is in sequence

   _Umove(_VIPTR(_Where), this->_Mylast,
    _VIPTR(_Where) + _Count); // copy suffix

   _TRY_BEGIN
   _Ufill(this->_Mylast,
    _Count - (this->_Mylast - _VIPTR(_Where)),
    _STD addressof(_Tmp)); // insert new stuff off end
   _CATCH_ALL
   _Destroy(_VIPTR(_Where) + _Count,
    this->_Mylast + _Count);
   _RERAISE;
   _CATCH_END

   this->_Mylast += _Count;
   _Orphan_range(_VIPTR(_Where), this->_Mylast);
   _STD fill(_VIPTR(_Where), this->_Mylast - _Count,
    _Tmp); // insert up to old end
   }
  else
   { // new stuff can all be assigned
   value_type _Tmp = _Val; // in case _Val is in sequence

   pointer _Oldend = this->_Mylast;
   this->_Mylast = _Umove(_Oldend - _Count, _Oldend,
    this->_Mylast); // copy suffix

   _Orphan_range(_VIPTR(_Where), this->_Mylast);
   _Copy_backward(_VIPTR(_Where), _Oldend - _Count,
    _Oldend); // copy hole
   _STD fill(_VIPTR(_Where),
    _VIPTR(_Where) + _Count, _Tmp); // insert into hole
   }
  return (begin() + _Off);
  }

 pointer _Ufill(pointer _Ptr, size_type _Count, const value_type *_Pval)
  { // copy initializing _Count * _Val, using allocator
  _Alty _Alval(this->_Getal());
  _Uninitialized_fill_n(_Ptr, _Count, _Pval, _Alval);
  return (_Ptr + _Count);
  }

 __declspec(noreturn) void _Xlen() const
  { // report a length_error
  _Xlength_error("vector<T> too long");
  }

 __declspec(noreturn) void _Xran() const
  { // report an out_of_range error
  _Xout_of_range("invalid vector<T> subscript");
  }

 #if _VECTOR_ORPHAN_RANGE
 void _Orphan_range(pointer _First, pointer _Last) const
  { // orphan iterators within specified (inclusive) range
  _Lockit _Lock(_LOCK_DEBUG);
  const_iterator **_Pnext = (const_iterator **)this->_Getpfirst();
  if (_Pnext != 0)
   while (*_Pnext != 0)
    if ((*_Pnext)->_Ptr < _First || _Last < (*_Pnext)->_Ptr)
     _Pnext = (const_iterator **)(*_Pnext)->_Getpnext();
    else
     { // orphan the iterator
     (*_Pnext)->_Clrcont();
     *_Pnext = *(const_iterator **)(*_Pnext)->_Getpnext();
     }
  }

 #else /* _VECTOR_ORPHAN_RANGE */
 void _Orphan_range(pointer, pointer) const
  { // orphan iterators within specified (inclusive) range
  }
 #endif /* _VECTOR_ORPHAN_RANGE */
 };

  // vector TEMPLATE OPERATORS

template<class _Ty,
 class _Alloc> inline
 void swap(vector<_Ty, _Alloc>& _Left, vector<_Ty, _Alloc>& _Right)
 { // swap _Left and _Right vectors
 _Left.swap(_Right);
 }

template<class _Ty,
 class _Alloc> inline
 bool operator==(const vector<_Ty, _Alloc>& _Left,
  const vector<_Ty, _Alloc>& _Right)
 { // test for vector equality
 return (_Left.size() == _Right.size()
  && equal(_Left.begin(), _Left.end(), _Right.begin()));
 }

template<class _Ty,
 class _Alloc> inline
 bool operator!=(const vector<_Ty, _Alloc>& _Left,
  const vector<_Ty, _Alloc>& _Right)
 { // test for vector inequality
 return (!(_Left == _Right));
 }

template<class _Ty,
 class _Alloc> inline
 bool operator<(const vector<_Ty, _Alloc>& _Left,
  const vector<_Ty, _Alloc>& _Right)
 { // test if _Left < _Right for vectors
 return (lexicographical_compare(_Left.begin(), _Left.end(),
  _Right.begin(), _Right.end()));
 }

template<class _Ty,
 class _Alloc> inline
 bool operator>(const vector<_Ty, _Alloc>& _Left,
  const vector<_Ty, _Alloc>& _Right)
 { // test if _Left > _Right for vectors
 return (_Right < _Left);
 }

template<class _Ty,
 class _Alloc> inline
 bool operator<=(const vector<_Ty, _Alloc>& _Left,
  const vector<_Ty, _Alloc>& _Right)
 { // test if _Left <= _Right for vectors
 return (!(_Right < _Left));
 }

template<class _Ty,
 class _Alloc> inline
 bool operator>=(const vector<_Ty, _Alloc>& _Left,
  const vector<_Ty, _Alloc>& _Right)
 { // test if _Left >= _Right for vectors
 return (!(_Left < _Right));
 }

//
// TEMPLATE CLASS vector<bool, Alloc> AND FRIENDS
//
typedef unsigned int _Vbase; // word type for vector<bool> representation
const int _VBITS = 8 * sizeof (_Vbase); // at least CHAR_BITS bits per word

  // CLASS _Vb_iter_base
template<class _Alloc>
 class _Vb_iter_base
  : public _Iterator012<random_access_iterator_tag,
   _Bool,
   typename _Alloc::difference_type,
   bool *,
   bool,
   _Iterator_base>
 { // store information common to reference and iterators
public:
 typedef typename _Alloc::size_type _Sizet;
 typedef vector<_Bool, _Alloc> _Mycont;

 _Vb_iter_base()
  : _Myptr(0), _Myoff(0)
  { // construct with null pointer
  }

 _Vb_iter_base(const _Vbase *_Ptr, _Sizet _Off,
  const _Container_base *_Mypvbool)
  : _Myptr(_Ptr), _Myoff(_Off)
  { // construct with offset and pointer
  this->_Adopt(_Mypvbool);
  }

 void _Advance(_Sizet _Off)
  { // advance iterator by _Off
  _Myoff += _Off;
  _Myptr += _Myoff / _VBITS;
  _Myoff %= _VBITS;
  }

 int _Valid(_Sizet _Inc) const
  { // test for valid incremented offset
 #if _ITERATOR_DEBUG_LEVEL == 2
  _Sizet _Mysize = ((_Mycont *)this->_Getcont())->_Mysize;

  _Inc += _Myoff;
  _Inc += _VBITS * (_Myptr
   - (((_Mycont *)this->_Getcont())->_Myvec)._Myfirst);
  return (_Inc < _Mysize ? -1 : _Inc == _Mysize ? 0 : +1);

 #else /* _ITERATOR_DEBUG_LEVEL == 2 */

  return (-1);
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */
  }

 const _Vbase *_Myptr;
 _Sizet _Myoff;
 };

  // CLASS _Vb_reference
template<class _Alloc>
 class _Vb_reference
  : public _Vb_iter_base<_Alloc>
 { // reference to a bit within a base word
 typedef _Vb_iter_base<_Alloc> _Mybase;
 typedef _Vb_reference<_Alloc> _Mytype;

 _Vb_reference() _NOEXCEPT
  { // construct with null pointer (private)
  }

public:
 _Vb_reference(const _Mybase& _Right)
  : _Mybase(_Right._Myptr, _Right._Myoff, _Right._Getcont())
  { // construct with base
  }

 _Mytype& operator=(const _Mytype& _Right) _NOEXCEPT
  { // assign _Vb_reference _Right to bit
  return (*this = bool(_Right));
  }

 _Mytype& operator=(bool _Val) _NOEXCEPT
  { // assign _Val to bit
  if (_Val)
   *(_Vbase *)_Getptr() |= _Mask();
  else
   *(_Vbase *)_Getptr() &= (~_Mask()); // STET
  return (*this);
  }

 void flip() _NOEXCEPT
  { // toggle the bit
  *(_Vbase *)_Getptr() ^= _Mask();
  }

 operator bool() const _NOEXCEPT
  { // test if bit is set
  return ((*_Getptr() & _Mask()) != 0);
  }

 const _Vbase *_Getptr() const
  { // get pointer to base word
 #if _ITERATOR_DEBUG_LEVEL == 2
  if (this->_Getcont() == 0
   || this->_Myptr == 0
   || 0 <= this->_Valid(0))
   { // report error
   _DEBUG_ERROR("vector<bool> iterator not dereferencable");
   _SCL_SECURE_OUT_OF_RANGE;
   }

 #elif _ITERATOR_DEBUG_LEVEL == 1
  _SCL_SECURE_VALIDATE(this->_Getcont() != 0 && this->_Myptr != 0);
  _SCL_SECURE_VALIDATE_RANGE(this->_Valid(0) < 0);
 #endif /* _ITERATOR_DEBUG_LEVEL */

  return (this->_Myptr);
  }

protected:
 _Vbase _Mask() const
  { // convert offset to mask
  return ((_Vbase)(1 << this->_Myoff));
  }
 };

template<class _Alloc> inline
 void swap(_Vb_reference<_Alloc> _Left,
  _Vb_reference<_Alloc> _Right)
 { // swap _Left and _Right vector<bool> elements
 bool _Val = _Left; // NOT _STD swap
 _Left = _Right;
 _Right = _Val;
 }

  // CLASS _Vb_const_iterator
template<class _Alloc>
 class _Vb_const_iterator
  : public _Vb_iter_base<_Alloc>
 { // iterator for nonmutable vector<bool>
public:
 typedef _Vb_iter_base<_Alloc> _Mybase;
 typedef _Vb_const_iterator<_Alloc> _Mytype;

 typedef _Vb_reference<_Alloc> _Reft;
 typedef bool const_reference;

 typedef random_access_iterator_tag iterator_category;
 typedef _Bool value_type;
 typedef typename _Alloc::size_type size_type;
 typedef typename _Alloc::difference_type difference_type;
 typedef const_reference *pointer;
 typedef const_reference reference;

 _Vb_const_iterator()
  { // construct with null reference
  }

 _Vb_const_iterator(const _Vbase *_Ptr, const _Container_base *_Mypvbool)
  : _Mybase(_Ptr, 0, _Mypvbool)
  { // construct with offset and pointer
  }

 const_reference operator*() const
  { // return (reference to) designated object
  return (_Reft(*this));
  }

 _Mytype& operator++()
  { // preincrement
  _Inc();
  return (*this);
  }

 _Mytype operator++(int)
  { // postincrement
  _Mytype _Tmp = *this;
  ++*this;
  return (_Tmp);
  }

 _Mytype& operator--()
  { // predecrement
  _Dec();
  return (*this);
  }

 _Mytype operator--(int)
  { // postdecrement
  _Mytype _Tmp = *this;
  --*this;
  return (_Tmp);
  }

 _Mytype& operator+=(difference_type _Off)
  { // increment by integer
  if (_Off < 0 && this->_Myoff < 0 - (size_type)_Off)
   { /* add negative increment */
   this->_Myoff += _Off;
   this->_Myptr -= 1 + ((size_type)(-1) - this->_Myoff) / _VBITS;
   this->_Myoff %= _VBITS;
   }
  else
   { /* add non-negative increment */
   this->_Myoff += _Off;
   this->_Myptr += this->_Myoff / _VBITS;
   this->_Myoff %= _VBITS;
   }
  return (*this);
  }

 _Mytype operator+(difference_type _Off) const
  { // return this + integer
  _Mytype _Tmp = *this;
  return (_Tmp += _Off);
  }

 _Mytype& operator-=(difference_type _Off)
  { // decrement by integer
  return (*this += -_Off);
  }

 _Mytype operator-(difference_type _Off) const
  { // return this - integer
  _Mytype _Tmp = *this;
  return (_Tmp -= _Off);
  }

 difference_type operator-(
  const _Mytype& _Right) const
  { // return difference of iterators
  _Compat(_Right);
  return (_VBITS * (this->_Myptr - _Right._Myptr)
   + (difference_type)this->_Myoff
   - (difference_type)_Right._Myoff);
  }

 const_reference operator[](difference_type _Off) const
  { // subscript
  return (*(*this + _Off));
  }

 bool operator==(const _Mytype& _Right) const
  { // test for iterator equality
  _Compat(_Right);
  return (this->_Myptr == _Right._Myptr
   && this->_Myoff == _Right._Myoff);
  }

 bool operator!=(const _Mytype& _Right) const
  { // test for iterator inequality
  return (!(*this == _Right));
  }

 bool operator<(const _Mytype& _Right) const
  { // test if this < _Right
  _Compat(_Right);
  return (this->_Myptr < _Right._Myptr
   || (this->_Myptr == _Right._Myptr
    && this->_Myoff < _Right._Myoff));
  }

 bool operator>(const _Mytype& _Right) const
  { // test if this > _Right
  return (_Right < *this);
  }

 bool operator<=(const _Mytype& _Right) const
  { // test if this <= _Right
  return (!(_Right < *this));
  }

 bool operator>=(const _Mytype& _Right) const
  { // test if this >= _Right
  return (!(*this < _Right));
  }

 #if _ITERATOR_DEBUG_LEVEL == 2
 void _Compat(const _Mytype& _Right) const
  { // test for compatible iterator pair
  if (this->_Getcont() == 0
   || this->_Getcont() != _Right._Getcont())
   _DEBUG_ERROR("vector<bool> iterators incompatible");
  }

 #elif _ITERATOR_DEBUG_LEVEL == 1
 void _Compat(const _Mytype& _Right) const
  { // test for compatible iterator pair
  _SCL_SECURE_VALIDATE(this->_Getcont() != 0);
  _SCL_SECURE_VALIDATE_RANGE(this->_Getcont() == _Right._Getcont());
  }

 #else /* _ITERATOR_DEBUG_LEVEL == 0 */
 void _Compat(const _Mytype&) const
  { // test for compatible iterator pair
  }
 #endif /* _ITERATOR_DEBUG_LEVEL */

 void _Dec()
  { // decrement bit position
  if (this->_Myoff != 0)
   --this->_Myoff;
  else
   { // move to previous word
 #if _ITERATOR_DEBUG_LEVEL == 2
   if (this->_Getcont() == 0 || 0 < this->_Valid((size_type)-1))
    { // report error
    _DEBUG_ERROR("vector<bool> iterator not decrementable");
    _SCL_SECURE_OUT_OF_RANGE;
    }

 #elif _ITERATOR_DEBUG_LEVEL == 1
   _SCL_SECURE_VALIDATE(this->_Getcont() != 0);
   _SCL_SECURE_VALIDATE_RANGE(this->_Valid((size_type)-1) <= 0);
 #endif /* _ITERATOR_DEBUG_LEVEL */

   this->_Myoff = _VBITS - 1;
   --this->_Myptr;
   }
  }

 void _Inc()
  { // increment bit position
  if (this->_Myoff < _VBITS - 1)
   ++this->_Myoff;
  else
   { // move to next word
 #if _ITERATOR_DEBUG_LEVEL == 2
   if (this->_Getcont() == 0 || 0 < this->_Valid(1))
    { // report error
    _DEBUG_ERROR("vector<bool> iterator not incrementable");
    _SCL_SECURE_OUT_OF_RANGE;
    }

 #elif _ITERATOR_DEBUG_LEVEL == 1
   _SCL_SECURE_VALIDATE(this->_Getcont() != 0);
   _SCL_SECURE_VALIDATE_RANGE(this->_Valid(1) <= 0);
 #endif /* _ITERATOR_DEBUG_LEVEL */

   this->_Myoff = 0;
   ++this->_Myptr;
   }
  }
 };

template<class _Alloc> inline
 _Vb_const_iterator<_Alloc> operator+(
  typename _Alloc::difference_type _Off,
  _Vb_const_iterator<_Alloc> _Right)
  { // return _Right + integer
  return (_Right += _Off);
  }

template<class _Alloc>
 struct _Is_checked_helper<_Vb_const_iterator<_Alloc> >
  : public true_type
 { // mark _Vb_const_iterator as checked
 };

 // CLASS _Vb_iterator
template<class _Alloc>
 class _Vb_iterator
  : public _Vb_const_iterator<_Alloc>
 { // iterator for mutable vector<bool>
public:
 typedef _Vb_const_iterator<_Alloc> _Mybase;
 typedef _Vb_iterator<_Alloc> _Mytype;

 typedef _Vb_reference<_Alloc> _Reft;
 typedef bool const_reference;

 typedef random_access_iterator_tag iterator_category;
 typedef _Bool value_type;
 typedef typename _Alloc::size_type size_type;
 typedef typename _Alloc::difference_type difference_type;
 typedef _Reft *pointer;
 typedef _Reft reference;

 _Vb_iterator()
  { // construct with null reference
  }

 _Vb_iterator(_Vbase *_Ptr, _Container_base *_Mypvbool)
  : _Mybase(_Ptr, _Mypvbool)
  { // construct with offset and pointer
  }

 reference operator*() const
  { // return (reference to) designated object
  return (_Reft(*this));
  }

 _Mytype& operator++()
  { // preincrement
  ++*(_Mybase *)this;
  return (*this);
  }

 _Mytype operator++(int)
  { // postincrement
  _Mytype _Tmp = *this;
  ++*this;
  return (_Tmp);
  }

 _Mytype& operator--()
  { // predecrement
  --*(_Mybase *)this;
  return (*this);
  }

 _Mytype operator--(int)
  { // postdecrement
  _Mytype _Tmp = *this;
  --*this;
  return (_Tmp);
  }

 _Mytype& operator+=(difference_type _Off)
  { // increment by integer
  *(_Mybase *)this += _Off;
  return (*this);
  }

 _Mytype operator+(difference_type _Off) const
  { // return this + integer
  _Mytype _Tmp = *this;
  return (_Tmp += _Off);
  }

 _Mytype& operator-=(difference_type _Off)
  { // decrement by integer
  return (*this += -_Off);
  }

 _Mytype operator-(difference_type _Off) const
  { // return this - integer
  _Mytype _Tmp = *this;
  return (_Tmp -= _Off);
  }

 difference_type operator-(const _Mybase& _Right) const
  { // return difference of iterators
  return (*(_Mybase *)this - _Right);
  }

 reference operator[](difference_type _Off) const
  { // subscript
  return (*(*this + _Off));
  }
 };

template<class _Alloc> inline
 _Vb_iterator<_Alloc> operator+(typename _Alloc::difference_type _Off,
  _Vb_iterator<_Alloc> _Right)
  { // return _Right + integer
  return (_Right += _Off);
  }

template<class _Alloc>
 struct _Is_checked_helper<_Vb_iterator<_Alloc> >
  : public true_type
 { // mark _Vb_iterator as checked
 };

  // TEMPLATE CLASS _Vb_val
template<class _Alloc>
 class _Vb_val
  : public _Container_base
 { // base class for vector<bool> to hold data
public:
 typedef _STD vector<_Vbase, _Alloc> _Vectype;
 typedef typename _Vectype::_Alty _Alty;
 typedef typename _Alty::size_type size_type;

 _Vb_val(size_type _Count, const bool& _Val, const _Alloc& _Al = _Alloc())
  : _Myvec(_Nw(_Count), (_Vbase)(_Val ? -1 : 0), _Al)
  { // construct _Count * _Val elements with allocator _Al
  _Alloc_proxy();
  _Mysize = 0;
  }

 _Vb_val(const _Vb_val& _Right)
  : _Myvec(_Right._Myvec),
   _Mysize(_Right._Mysize)
  { // copy construct
  _Alloc_proxy();
  }

 _Vb_val(const _Vb_val& _Right, const _Alloc& _Al)
  : _Myvec(_Right._Myvec, _Al),
   _Mysize(_Right._Mysize)
  { // copy construct, allocator
  _Alloc_proxy();
  }

 _Vb_val(_Vb_val&& _Right)
  : _Myvec(_STD forward<_Vectype>(_Right._Myvec)),
   _Mysize(_Right._Mysize)
  { // move construct
  _Right._Mysize = 0;
  _Alloc_proxy();
  }

 _Vb_val(_Vb_val&& _Right, const _Alloc& _Al)
  : _Myvec(_STD forward<_Vectype>(_Right._Myvec), _Al),
   _Mysize(_Right._Mysize)
  { // move construct, allocator
  _Right._Mysize = 0;
  _Alloc_proxy();
  }

 ~_Vb_val() _NOEXCEPT
  { // destroy proxy
  _Free_proxy();
  }

 #if _ITERATOR_DEBUG_LEVEL == 0
 void _Swap_alloc(_Vb_val&)
  { // do nothing
  }

 void _Alloc_proxy()
  { // do nothing
  }

 void _Free_proxy()
  { // do nothing
  }

 #else /* _ITERATOR_DEBUG_LEVEL == 0 */
 void _Swap_alloc(_Vb_val& _Right)
  { // swap proxies to follow allocators in vector
  _Swap_adl(this->_Myproxy, _Right._Myproxy);
  }

 void _Alloc_proxy()
  { // allocate a proxy
  typename _Alty::template rebind<_Container_proxy>::other
   _Alproxy(_Myvec.get_allocator());
  this->_Myproxy = _Alproxy.allocate(1);
  _Alproxy.construct(this->_Myproxy, _Container_proxy());
  this->_Myproxy->_Mycont = this;
  }

 void _Free_proxy()
  { // destroy proxy
  typename _Alty::template rebind<_Container_proxy>::other
   _Alproxy(_Myvec.get_allocator());
  this->_Orphan_all();
  _Alproxy.destroy(this->_Myproxy);
  _Alproxy.deallocate(this->_Myproxy, 1);
  this->_Myproxy = 0;
  }
 #endif /* _ITERATOR_DEBUG_LEVEL == 0 */

 static size_type _Nw(size_type _Count)
  { // return number of base words from number of bits
  return ((_Count + _VBITS - 1) / _VBITS);
  }

 _Vectype _Myvec; // base vector of words
 typename _Alty::size_type _Mysize; // current length of sequence
 };

  // CLASS vector<bool>

template<class _Alloc>
 class vector<_Bool, _Alloc>
  : public _Vb_val<_Alloc>
 { // varying size array of bits
public:
 typedef _STD vector<_Bool, _Alloc> _Myt;
 typedef _Vb_val<_Alloc> _Mybase;
 typedef typename _Mybase::_Alty _Alty;
 typedef typename _Mybase::_Vectype _Vectype;

 typedef typename _Alty::size_type size_type;
 typedef typename _Alty::difference_type difference_type;
 typedef _Bool _Ty;
 typedef _Alloc allocator_type;

 typedef _Vb_reference<_Alty> reference;
 typedef bool const_reference;
 typedef bool value_type;

 typedef reference _Reft;
 typedef _Vb_const_iterator<_Alty> const_iterator;
 typedef _Vb_iterator<_Alty> iterator;

 typedef iterator pointer;
 typedef const_iterator const_pointer;
 typedef _STD reverse_iterator<iterator> reverse_iterator;
 typedef _STD reverse_iterator<const_iterator> const_reverse_iterator;

 static const int _VBITS = _STD _VBITS;
 enum {_EEN_VBITS = _VBITS}; // helper for expression evaluator
 vector()
  : _Mybase(0, false)
  { // construct empty vector
  }

 explicit vector(const _Alloc& _Al)
  : _Mybase(0, false, _Al)
  { // construct empty vector, allocator
  }

 explicit vector(size_type _Count, const bool& _Val = false)
  : _Mybase(_Count, _Val)
  { // construct from _Count * _Val
  _Trim(_Count);
  }

 vector(size_type _Count, const bool& _Val, const _Alloc& _Al)
  : _Mybase(_Count, _Val, _Al)
  { // construct from _Count * _Val, allocator
  _Trim(_Count);
  }

 vector(const _Myt& _Right)
  : _Mybase(_Right)
  { // construct by copying _Right
  }

 vector(const _Myt& _Right, const _Alloc& _Al)
  : _Mybase(_Right, _Al)
  { // construct by copying _Right, allocator
  }

 template<class _Iter,
  class = typename enable_if<_Is_iterator<_Iter>::value,
   void>::type>
  vector(_Iter _First, _Iter _Last)
  : _Mybase(0, false)
  { // construct from [_First, _Last)
  _BConstruct(_First, _Last);
  }

 template<class _Iter,
  class = typename enable_if<_Is_iterator<_Iter>::value,
   void>::type>
  vector(_Iter _First, _Iter _Last, const _Alloc& _Al)
  : _Mybase(0, false, _Al)
  { // construct from [_First, _Last), allocator
  _BConstruct(_First, _Last);
  }

 template<class _Iter>
  void _BConstruct(_Iter _First, _Iter _Last)
  { // initialize from [_First, _Last), input iterators
  insert(begin(), _First, _Last);
  }

 vector(_Myt&& _Right)
  : _Mybase(_STD forward<_Myt>(_Right))
  { // move construct by moving _Right
  }

 vector(_Myt&& _Right, const _Alloc& _Al)
  : _Mybase(_STD forward<_Myt>(_Right), _Al)
  { // move construct by moving _Right, allocator
  }

 _Myt& operator=(_Myt&& _Right)
  { // assign by moving _Right
  if (this != &_Right)
   { // different, assign it
   clear();

   if (_Alty::propagate_on_container_move_assignment::value
    && this->get_allocator() != _Right.get_allocator())
    { // assign vector, dumping proxy
    this->_Free_proxy();
    this->_Myvec = _STD move(_Right._Myvec);
    this->_Alloc_proxy();
    }
   else
    this->_Myvec = _STD move(_Right._Myvec);


   this->_Mysize = _Right._Mysize;
   _Right._Mysize = 0;
   }
  return (*this);
  }

 vector(_XSTD initializer_list<bool> _Ilist,
   const _Alloc& _Al = allocator_type())
  : _Mybase(0, false, _Al)
  { // construct from initializer_list
  insert(begin(), _Ilist.begin(), _Ilist.end());
  }

 _Myt& operator=(_XSTD initializer_list<bool> _Ilist)
  { // assign initializer_list
  assign(_Ilist.begin(), _Ilist.end());
  return (*this);
  }

 void assign(_XSTD initializer_list<bool> _Ilist)
  { // assign initializer_list
  assign(_Ilist.begin(), _Ilist.end());
  }

 iterator insert(const_iterator _Where,
   _XSTD initializer_list<bool> _Ilist)
  { // insert initializer_list
  return (insert(_Where, _Ilist.begin(), _Ilist.end()));
  }

 ~vector() _NOEXCEPT
  { // destroy the object
  this->_Mysize = 0;
  }

 _Myt& operator=(const _Myt& _Right)
  { // assign from _Right
  this->_Mysize = _Right._Mysize;
  this->_Myvec = _Right._Myvec;
  return (*this);
  }

 void reserve(size_type _Count)
  { // determine new minimum length of allocated storage
  this->_Myvec.reserve(this->_Nw(_Count));
  }

 size_type capacity() const _NOEXCEPT
  { // return current length of allocated storage
  return (this->_Myvec.capacity() * _VBITS);
  }

 iterator begin() _NOEXCEPT
  { // return iterator for beginning of mutable sequence
  return (iterator((_Vbase *)this->_Myvec._Myfirst, this));
  }

 const_iterator begin() const _NOEXCEPT
  { // return iterator for beginning of nonmutable sequence
  return (const_iterator((_Vbase *)this->_Myvec._Myfirst, this));
  }

 iterator end() _NOEXCEPT
  { // return iterator for end of mutable sequence
  iterator _Tmp = begin();
  if (0 < this->_Mysize)
   _Tmp += this->_Mysize;
  return (_Tmp);
  }

 const_iterator end() const _NOEXCEPT
  { // return iterator for end of nonmutable sequence
  const_iterator _Tmp = begin();
  if (0 < this->_Mysize)
   _Tmp += this->_Mysize;
  return (_Tmp);
  }

 const_iterator cbegin() const _NOEXCEPT
  { // return iterator for beginning of nonmutable sequence
  return (((const _Myt *)this)->begin());
  }

 const_iterator cend() const _NOEXCEPT
  { // return iterator for end of nonmutable sequence
  return (((const _Myt *)this)->end());
  }

 const_reverse_iterator crbegin() const _NOEXCEPT
  { // return iterator for beginning of reversed nonmutable sequence
  return (((const _Myt *)this)->rbegin());
  }

 const_reverse_iterator crend() const _NOEXCEPT
  { // return iterator for end of reversed nonmutable sequence
  return (((const _Myt *)this)->rend());
  }

 void shrink_to_fit()
  { // reduce capacity
  if (this->_Myvec._Has_unused_capacity())
   { // worth shrinking, do it
   _Myt _Tmp(*this);
   swap(_Tmp);
   }
  }

 iterator _Make_iter(const_iterator _Where)
  { // make iterator from const_iterator
  iterator _Tmp = begin();
  if (0 < this->_Mysize)
   _Tmp += _Where - begin();
  return (_Tmp);
  }

 reverse_iterator rbegin() _NOEXCEPT
  { // return iterator for beginning of reversed mutable sequence
  return (reverse_iterator(end()));
  }

 const_reverse_iterator rbegin() const _NOEXCEPT
  { // return iterator for beginning of reversed nonmutable sequence
  return (const_reverse_iterator(end()));
  }

 reverse_iterator rend() _NOEXCEPT
  { // return iterator for end of reversed mutable sequence
  return (reverse_iterator(begin()));
  }

 const_reverse_iterator rend() const _NOEXCEPT
  { // return iterator for end of reversed nonmutable sequence
  return (const_reverse_iterator(begin()));
  }

 void resize(size_type _Newsize, bool _Val = false)
  { // determine new length, padding with _Val elements as needed
  if (size() < _Newsize)
   _Insert_n(end(), _Newsize - size(), _Val);
  else if (_Newsize < size())
   erase(begin() + _Newsize, end());
  }

 size_type size() const _NOEXCEPT
  { // return length of sequence
  return (this->_Mysize);
  }

 size_type max_size() const _NOEXCEPT
  { // return maximum possible length of sequence
  const size_type _Maxsize = this->_Myvec.max_size();
  return (_Maxsize < (size_type)(-1) / _VBITS
   ? _Maxsize * _VBITS : (size_type)(-1));
  }

 bool empty() const _NOEXCEPT
  { // test if sequence is empty
  return (size() == 0);
  }

 _Alloc get_allocator() const _NOEXCEPT
  { // return allocator object for values
  return (this->_Myvec.get_allocator());
  }

 const_reference at(size_type _Off) const
  { // subscript nonmutable sequence with checking
  if (size() <= _Off)
   _Xran();
  return ((*this)[_Off]);
  }

 reference at(size_type _Off)
  { // subscript mutable sequence with checking
  if (size() <= _Off)
   _Xran();
  return ((*this)[_Off]);
  }

 const_reference operator[](size_type _Off) const
  { // subscript nonmutable sequence
  const_iterator _It = begin();
  _It._Advance(_Off);
  return (*_It);
  }

 reference operator[](size_type _Off)
  { // subscript mutable sequence
  iterator _It = begin();
  _It._Advance(_Off);
  return (*_It);
  }

 reference front()
  { // return first element of mutable sequence
  return (*begin());
  }

 const_reference front() const
  { // return first element of nonmutable sequence
  return (*begin());
  }

 reference back()
  { // return last element of mutable sequence
  return (*(end() - 1));
  }

 const_reference back() const
  { // return last element of nonmutable sequence
  return (*(end() - 1));
  }

 void push_back(const bool& _Val)
  { // insert element at end
  insert(end(), _Val);
  }

 void pop_back()
  { // erase element at end
  erase(end() - 1);
  }

 template<class _Iter>
  typename enable_if<_Is_iterator<_Iter>::value,
   void>::type
  assign(_Iter _First, _Iter _Last)
  { // assign [_First, _Last), input iterators
  erase(begin(), end());
  insert(begin(), _First, _Last);
  }

 void assign(size_type _Count, const bool& _Val)
  { // assign _Count * _Val
  erase(begin(), end());
  _Insert_n(begin(), _Count, _Val);
  }

 iterator insert(const_iterator _Where, const bool& _Val)
  { // insert _Val at _Where
  return (_Insert_n(_Where, (size_type)1, _Val));
  }

 iterator insert(const_iterator _Where, size_type _Count,
  const bool& _Val)
  { // insert _Count * _Val at _Where
  return (_Insert_n(_Where, _Count, _Val));
  }

 template<class _Iter>
  typename enable_if<_Is_iterator<_Iter>::value,
   iterator>::type
  insert(const_iterator _Where, _Iter _First, _Iter _Last)
  { // insert [_First, _Last) at _Where
  size_type _Off = _Where - begin();
  _Insert(_Where, _First, _Last, _Iter_cat(_First));
  return (begin() + _Off);
  }

 template<class _Iter>
  void _Insert(const_iterator _Where, _Iter _First, _Iter _Last,
   input_iterator_tag)
  { // insert [_First, _Last) at _Where, input iterators
  size_type _Off = _Where - begin();

  for (; _First != _Last; ++_First, ++_Off)
   insert(begin() + _Off, *_First);
  }

 template<class _Iter>
  void _Insert(const_iterator _Where,
   _Iter _First, _Iter _Last,
   forward_iterator_tag)
  { // insert [_First, _Last) at _Where, forward iterators
  _DEBUG_RANGE(_First, _Last);
  size_type _Count = 0;
  _Distance(_First, _Last, _Count);

  size_type _Off = _Insert_x(_Where, _Count);
  _STD copy(_First, _Last, begin() + _Off);
  }

 iterator erase(const_iterator _Where_arg)
  { // erase element at _Where
  iterator _Where = _Make_iter(_Where_arg);
  size_type _Off = _Where - begin();

 #if _ITERATOR_DEBUG_LEVEL == 2
  if (end() <= _Where)
   _DEBUG_ERROR("vector<bool> erase iterator outside range");
  _STD copy(_Where + 1, end(), _Where);
  _Orphan_range(_Off, this->_Mysize);

 #else /* _ITERATOR_DEBUG_LEVEL == 2 */
  _STD copy(_Where + 1, end(), _Where);
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */

  _Trim(this->_Mysize - 1);
  return (begin() + _Off);
  }

 iterator erase(const_iterator _First_arg, const_iterator _Last_arg)
  { // erase [_First, _Last)
  iterator _First = _Make_iter(_First_arg);
  iterator _Last = _Make_iter(_Last_arg);
  size_type _Off = _First - begin();

  if (_First != _Last)
   { // worth doing, copy down over hole
 #if _ITERATOR_DEBUG_LEVEL == 2
   if (_Last < _First || end() < _Last)
    _DEBUG_ERROR("vector<bool> erase iterator outside range");
   iterator _Next = _STD copy(_Last, end(), _First);
   size_type _Newsize = _Next - begin();
   _Orphan_range(_Newsize, this->_Mysize);
   _Trim(_Newsize);

 #else /* _ITERATOR_DEBUG_LEVEL == 2 */
   iterator _Next = _STD copy(_Last, end(), _First);
   _Trim(_Next - begin());
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */
   }
  return (begin() + _Off);
  }

 void clear() _NOEXCEPT
  { // erase all elements
  erase(begin(), end());
  }

 void flip() _NOEXCEPT
  { // toggle all elements
  for (typename _Vectype::iterator _Next = this->_Myvec.begin();
   _Next != this->_Myvec.end(); ++_Next)
   *_Next = (_Vbase)~*_Next;
  _Trim(this->_Mysize);
  }

 void swap(_Myt& _Right)
  { // exchange contents with right
  if (this == &_Right)
   ; // same object, do nothing
  else if (this->get_allocator() == _Right.get_allocator())
   { // same allocator, swap control information
   this->_Swap_all(_Right);
   this->_Myvec.swap(_Right._Myvec);
   _STD swap(this->_Mysize, _Right._Mysize);
   }

  else if (_Alty::propagate_on_container_swap::value)
   { // swap allocators and control information
   this->_Swap_alloc(_Right);
   this->_Myvec.swap(_Right._Myvec);
   _STD swap(this->_Mysize, _Right._Mysize);
   }

  else
   { // containers are incompatible
 #if _ITERATOR_DEBUG_LEVEL == 2
   _DEBUG_ERROR("vector<bool> containers incompatible for swap");

 #else /* ITERATOR_DEBUG_LEVEL == 2 */
   _XSTD terminate();
 #endif /* ITERATOR_DEBUG_LEVEL == 2 */
   }
  }

 static void swap(reference _Left, reference _Right) _NOEXCEPT
  { // swap _Left and _Right vector<bool> elements
  bool _Val = _Left; // NOT _STD swap

  _Left = _Right;
  _Right = _Val;
  }

 size_t hash() const
  { // hash bits to size_t value by pseudorandomizing transform
  return (_Hash_seq((const unsigned char *)this->_Myvec.data(),
   this->_Myvec.size() * sizeof (_Vbase)));
  }

 iterator _Insert_n(const_iterator _Where,
  size_type _Count, const bool& _Val)
  { // insert _Count * _Val at _Where
  size_type _Off = _Insert_x(_Where, _Count);
  _STD fill(begin() + _Off, begin() + (_Off + _Count), _Val);
  return (begin() + _Off);
  }

 size_type _Insert_x(const_iterator _Where, size_type _Count)
  { // make room to insert _Count elements at _Where
  size_type _Off = _Where - begin();

 #if _ITERATOR_DEBUG_LEVEL == 2
  if (end() < _Where)
   _DEBUG_ERROR("vector<bool> insert iterator outside range");
  bool _Realloc = capacity() - size() < _Count;
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */

  if (_Count == 0)
   ;
  else if (max_size() - size() < _Count)
   _Xlen(); // result too long
  else
   { // worth doing
   this->_Myvec.resize(this->_Nw(size() + _Count), 0);
   if (empty())
    this->_Mysize += _Count;
   else
    { // make room and copy down suffix
    iterator _Oldend = end();
    this->_Mysize += _Count;
    _STD copy_backward(begin() + _Off, _Oldend, end());
    }

 #if _ITERATOR_DEBUG_LEVEL == 2
   _Orphan_range(_Realloc ? 0 : _Off, this->_Mysize);
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */
   }
  return (_Off);
  }

 #if _VECTOR_ORPHAN_RANGE
 void _Orphan_range(size_type _Offlo, size_type _Offhi) const
  { // orphan iterators within specified (inclusive) range
  typedef _Vb_iter_base<_Alty> _Myiterbase;

  _Lockit _Lock(_LOCK_DEBUG);
  _Vbase *_Base = (_Vbase *)this->_Myvec._Myfirst;

  const_iterator **_Pnext = (const_iterator **)this->_Getpfirst();
  if (_Pnext != 0)
   while (*_Pnext != 0)
    { // test offset from beginning of vector
    size_type _Off = _VBITS * ((*_Pnext)->_Myptr - _Base)
     + (*_Pnext)->_Myoff;
    if (_Off < _Offlo || _Offhi < _Off)
     _Pnext = (const_iterator **)(*_Pnext)->_Getpnext();
    else
     { // orphan the iterator
     (*_Pnext)->_Clrcont();
     *_Pnext = *(const_iterator **)(*_Pnext)->_Getpnext();
     }
    }
  }

 #else /* _VECTOR_ORPHAN_RANGE */
 void _Orphan_range(size_type, size_type) const
  { // orphan iterators within specified (inclusive) range
  }
 #endif /* _VECTOR_ORPHAN_RANGE */

 void _Trim(size_type _Size)
  { // trim base vector to exact length in bits
  if (max_size() < _Size)
   _Xlen(); // result too long
  size_type _Words = this->_Nw(_Size);

  if (_Words < this->_Myvec.size())
   this->_Myvec.erase(this->_Myvec.begin() + _Words,
    this->_Myvec.end());
  this->_Mysize = _Size;
  _Size %= _VBITS;
  if (0 < _Size)
   this->_Myvec[_Words - 1] &= (_Vbase)((1 << _Size) - 1);
  }

 __declspec(noreturn) void _Xlen() const
  { // report a length_error
  _Xlength_error("vector<bool> too long");
  }

 __declspec(noreturn) void _Xran() const
  { // report an out_of_range error
  _Xout_of_range("invalid vector<bool> subscript");
  }
 };

template<class _Alloc> inline
 bool operator==(const vector<bool, _Alloc>& _Left,
  const vector<bool, _Alloc>& _Right)
 { // test for vector equality
 return (_Left.size() == _Right.size()
  && equal(_Left._Myvec.begin(), _Left._Myvec.end(),
   _Right._Myvec.begin()));
 }

template<class _Alloc> inline
 bool operator!=(const vector<bool, _Alloc>& _Left,
  const vector<bool, _Alloc>& _Right)
 { // test for vector inequality
 return (!(_Left == _Right));
 }

 // TEMPLATE STRUCT SPECIALIZATION hash
template<class _Alloc>
 struct hash<vector<_Bool, _Alloc> >
  : public unary_function<vector<_Bool, _Alloc>, size_t>
 { // hash functor
 typedef vector<_Bool, _Alloc> _Kty;

 size_t operator()(const _Kty& _Keyval) const
  { // hash _Keyval to size_t value by pseudorandomizing transform
  return (_Keyval.hash());
  }
 };
_STD_END

 #pragma pop_macro("new")
 #pragma warning(pop)
 #pragma pack(pop)
#endif /* RC_INVOKED */
#endif /* _VECTOR_ */

/*
 * This file is derived from software bearing the following
 * restrictions:
 *
 * Copyright (c) 1994
 * Hewlett-Packard Company
 *
 * Permission to use, copy, modify, distribute and sell this
 * software and its documentation for any purpose is hereby
 * granted without fee, provided that the above copyright notice
 * appear in all copies and that both that copyright notice and
 * this permission notice appear in supporting documentation.
 * Hewlett-Packard Company makes no representations about the
 * suitability of this software for any purpose. It is provided
 * "as is" without express or implied warranty.
 */

/*
 * Copyright (c) 1992-2012 by P.J. Plauger.  ALL RIGHTS RESERVED.
 * Consult your license regarding permissions and restrictions.
V6.00:0009 */

------=_Part_2001_32601079.1385741407486--

.

------=_Part_1850_12264534.1385742339439
Content-Type: text/plain; charset=ISO-8859-1



Test results(vector.hpp):

vs2013 NOV CTP
100000000 elements:

std::vector<std::size_t> vec;
constexpr std::size_t capa(100000000);
vec.reserve(capa);
for(std::size_t i(0);i!=capa;++i)
 vec.unsafe_push_back(i);
reserve+unsafe_push_back:0.468794s

std::vector<std::size_t> vec;
constexpr std::size_t capa(100000000);
vec.reserve(capa);
for(std::size_t i(0);i!=capa;++i)
 vec.push_back(i);
reserve+push_back:0.765595s

std::vector<std::size_t> vec;
constexpr std::size_t capa(100000000);
vec.reserve(capa);
for(std::size_t i(0);i!=capa;++i)
 vec.unsafe_emplace_back(i);
reserve+unsafe_emplace_back:0.468721s

std::vector<std::size_t> vec;
constexpr std::size_t capa(100000000);
vec.reserve(capa);
for(std::size_t i(0);i!=capa;++i)
 vec.emplace_back(i);
reserve+emplace_back:0.640626s

std::vector<std::size_t> vec;
constexpr std::size_t capa(100000000);
vec.reserve(capa);
vec.unsafe_resize(capa);
std::iota(vec.begin(),vec.end(),0);
reserve+unsafe_resize:0.468792s

constexpr std::size_t capa(100000000);
std::vector<std::size_t> vec(capa);
std::iota(vec.begin(),vec.end(),0);
This:0.64063s

From these tests, unsafe_operations:0.46s , safe operations: 0.64s.
They are useful, I think.

--

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

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

<div dir=3D"ltr"><p>Test results(vector.hpp):</p><p>vs2013 NOV CTP<br>10000=
0000 elements:</p><p>std::vector&lt;std::size_t&gt; vec;<br>constexpr std::=
size_t capa(100000000); <br>vec.reserve(capa);<br>for(std::size_t i(0);i!=
=3Dcapa;++i)<br>&nbsp;vec.unsafe_push_back(i);<br>reserve+unsafe_push_back:=
0.468794s</p><p>std::vector&lt;std::size_t&gt; vec;<br>constexpr std::size_=
t capa(100000000); <br>vec.reserve(capa);<br>for(std::size_t i(0);i!=3Dcapa=
;++i)<br>&nbsp;vec.push_back(i);<br>reserve+push_back:0.765595s</p><p>std::=
vector&lt;std::size_t&gt; vec;<br>constexpr std::size_t capa(100000000); <b=
r>vec.reserve(capa);<br>for(std::size_t i(0);i!=3Dcapa;++i)<br>&nbsp;vec.un=
safe_emplace_back(i);<br>reserve+unsafe_emplace_back:0.468721s</p><p>std::v=
ector&lt;std::size_t&gt; vec;<br>constexpr std::size_t capa(100000000); <br=
>vec.reserve(capa);<br>for(std::size_t i(0);i!=3Dcapa;++i)<br>&nbsp;vec.emp=
lace_back(i);<br>reserve+emplace_back:0.640626s</p><p>std::vector&lt;std::s=
ize_t&gt; vec;<br>constexpr std::size_t capa(100000000);<br>vec.reserve(cap=
a);<br>vec.unsafe_resize(capa);<br>std::iota(vec.begin(),vec.end(),0);<br>r=
eserve+unsafe_resize:0.468792s</p><p>constexpr std::size_t capa(100000000);=
<br>std::vector&lt;std::size_t&gt; vec(capa);<br>std::iota(vec.begin(),vec.=
end(),0);<br>This:0.64063s</p><p>From these tests, unsafe_operations:0.46s =
, safe operations: 0.64s.<br>They are useful, I think.</p></div>

<p></p>

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

------=_Part_1850_12264534.1385742339439--

.

------=_Part_516_13266616.1385742901393
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

ps: std::string can be added the following operations too.

=E5=9C=A8 2013=E5=B9=B411=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=ADUTC=
+8=E4=B8=8A=E5=8D=8812=E6=97=B625=E5=88=8639=E7=A7=92=EF=BC=8Ceulo...@live.=
com=E5=86=99=E9=81=93=EF=BC=9A
>
> Test results(vector.hpp):
>
> vs2013 NOV CTP
> 100000000 elements:
>
> std::vector<std::size_t> vec;
> constexpr std::size_t capa(100000000);=20
> vec.reserve(capa);
> for(std::size_t i(0);i!=3Dcapa;++i)
>  vec.unsafe_push_back(i);
> reserve+unsafe_push_back:0.468794s
>
> std::vector<std::size_t> vec;
> constexpr std::size_t capa(100000000);=20
> vec.reserve(capa);
> for(std::size_t i(0);i!=3Dcapa;++i)
>  vec.push_back(i);
> reserve+push_back:0.765595s
>
> std::vector<std::size_t> vec;
> constexpr std::size_t capa(100000000);=20
> vec.reserve(capa);
> for(std::size_t i(0);i!=3Dcapa;++i)
>  vec.unsafe_emplace_back(i);
> reserve+unsafe_emplace_back:0.468721s
>
> std::vector<std::size_t> vec;
> constexpr std::size_t capa(100000000);=20
> vec.reserve(capa);
> for(std::size_t i(0);i!=3Dcapa;++i)
>  vec.emplace_back(i);
> reserve+emplace_back:0.640626s
>
> std::vector<std::size_t> vec;
> constexpr std::size_t capa(100000000);
> vec.reserve(capa);
> vec.unsafe_resize(capa);
> std::iota(vec.begin(),vec.end(),0);
> reserve+unsafe_resize:0.468792s
>
> constexpr std::size_t capa(100000000);
> std::vector<std::size_t> vec(capa);
> std::iota(vec.begin(),vec.end(),0);
> This:0.64063s
>
> From these tests, unsafe_operations:0.46s , safe operations: 0.64s.
> They are useful, I think.
>

--=20

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

------=_Part_516_13266616.1385742901393
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">ps: std::string can be added the following operations too.=
<br><br>=E5=9C=A8 2013=E5=B9=B411=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=85=ADUTC+8=E4=B8=8A=E5=8D=8812=E6=97=B625=E5=88=8639=E7=A7=92=EF=BC=8Ceulo=
....@live.com=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb=
(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div di=
r=3D"ltr"><p>Test results(vector.hpp):</p><p>vs2013 NOV CTP<br>100000000 el=
ements:</p><p>std::vector&lt;std::size_t&gt; vec;<br>constexpr std::size_t =
capa(100000000); <br>vec.reserve(capa);<br>for(std::size_t i(0);i!=3Dcapa;+=
+i)<br>&nbsp;vec.unsafe_push_back(i);<br>reserve+unsafe_push_back:0.<wbr>46=
8794s</p><p>std::vector&lt;std::size_t&gt; vec;<br>constexpr std::size_t ca=
pa(100000000); <br>vec.reserve(capa);<br>for(std::size_t i(0);i!=3Dcapa;++i=
)<br>&nbsp;vec.push_back(i);<br>reserve+push_back:0.765595s</p><p>std::vect=
or&lt;std::size_t&gt; vec;<br>constexpr std::size_t capa(100000000); <br>ve=
c.reserve(capa);<br>for(std::size_t i(0);i!=3Dcapa;++i)<br>&nbsp;vec.unsafe=
_emplace_back(i);<br>reserve+unsafe_emplace_back:0.<wbr>468721s</p><p>std::=
vector&lt;std::size_t&gt; vec;<br>constexpr std::size_t capa(100000000); <b=
r>vec.reserve(capa);<br>for(std::size_t i(0);i!=3Dcapa;++i)<br>&nbsp;vec.em=
place_back(i);<br>reserve+emplace_back:0.640626s</p><p>std::vector&lt;std::=
size_t&gt; vec;<br>constexpr std::size_t capa(100000000);<br>vec.reserve(ca=
pa);<br>vec.unsafe_resize(capa);<br>std::iota(vec.begin(),vec.end(<wbr>),0)=
;<br>reserve+unsafe_resize:0.<wbr>468792s</p><p>constexpr std::size_t capa(=
100000000);<br>std::vector&lt;std::size_t&gt; vec(capa);<br>std::iota(vec.b=
egin(),vec.end(<wbr>),0);<br>This:0.64063s</p><p>From these tests, unsafe_o=
perations:0.46s , safe operations: 0.64s.<br>They are useful, I think.</p><=
/div></blockquote></div>

<p></p>

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

------=_Part_516_13266616.1385742901393--

.

------=_Part_2714_23940300.1385753610323
Content-Type: text/plain; charset=ISO-8859-1

Another advantage of unchecked_push_back is a better noexcept guarantee:
indeed, it cannot throw as long as Widget's constructor doesn't (which is
common for the intended use scenario). This is in contrast to the usual
push_back which can throw due to a failed memory reallocation.

--

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

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

<div dir=3D"ltr"><div>Another&nbsp;advantage of unchecked_push_back is a be=
tter noexcept guarantee: indeed, it cannot throw as long as Widget's constr=
uctor doesn't (which is common for the intended use scenario). This is in c=
ontrast to the usual push_back which can throw due to a failed memory reall=
ocation.</div></div>

<p></p>

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

------=_Part_2714_23940300.1385753610323--

.

------=_Part_0_1385757521742
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

False. Push/Emplace back are guaranteed not to throw so long as size() < ca=
pacity().

Sent from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: Victor.Khomenko@ncl.ac.uk
To: <std-proposals@isocpp.org>
Cc: <Victor.Khomenko@ncl.ac.uk>
Subject: [std-proposals] Re: proposal to add vector::push_back_()
Date: Fri, Nov 29, 2013 2:33 PM

Another advantage of unchecked_push_back is a better noexcept guarantee: in=
deed, it cannot throw as long as Widget's constructor doesn't (which is com=
mon for the intended use scenario). This is in contrast to the usual push_b=
ack which can throw due to a failed memory reallocation.




--=20

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

--=20

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

------=_Part_0_1385757521742
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div style=3D"font-size: 12pt; font-family: Calibri,sans-serif;"><div>False=
.. Push/Emplace back are guaranteed not to throw so long as size() &lt; capa=
city().</div><div><br></div><div>Sent from a touchscreen. Please excuse the=
 brevity and tpyos.</div><br><div id=3D"htc_header">----- Reply message ---=
--<br>From: Victor.Khomenko@ncl.ac.uk<br>To: &lt;std-proposals@isocpp.org&g=
t;<br>Cc: &lt;Victor.Khomenko@ncl.ac.uk&gt;<br>Subject: [std-proposals] Re:=
 proposal to add vector::push_back_()<br>Date: Fri, Nov 29, 2013 2:33 PM</d=
iv></div><br><div dir=3D"ltr"><div>Another&nbsp;advantage of unchecked_push=
_back is a better noexcept guarantee: indeed, it cannot throw as long as Wi=
dget's constructor doesn't (which is common for the intended use scenario).=
 This is in contrast to the usual push_back which can throw due to a failed=
 memory reallocation.</div></div>

<p></p>

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

<p></p>

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

------=_Part_0_1385757521742--


.

------=_Part_695_21541542.1385768634560
Content-Type: text/plain; charset=ISO-8859-1



On Friday, 29 November 2013 20:38:41 UTC, Billy O'Neal wrote:
>
> False. Push/Emplace back are guaranteed not to throw so long as size() <
> capacity().
>


You should have sent this to the original thread...

Anyway, you're missing the point: even if push_back is guaranteed not to
throw when size() < capacity(), it cannot be declared noexcept.

--

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

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

<div dir=3D"ltr"><br><br>On Friday, 29 November 2013 20:38:41 UTC, Billy O'=
Neal  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;"><div style=3D"font-family: Calibri=
,sans-serif; font-size: 12pt;"><div>False. Push/Emplace back are guaranteed=
 not to throw so long as size() &lt; capacity().<br></div></div></blockquot=
e><div><br></div><div><br></div><div>You should have sent this to the origi=
nal thread...</div><div><br></div><div>Anyway, you're missing&nbsp;the poin=
t: even if push_back is guaranteed not to throw&nbsp;when&nbsp;size() &lt; =
capacity(), it cannot be declared noexcept.</div></div>

<p></p>

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

------=_Part_695_21541542.1385768634560--

.

------=_Part_0_1385769199962
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline

The unchecked versions can't be declared noexcept either due to debugging implementations.

Sent from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: Victor.Khomenko@ncl.ac.uk
To: <std-proposals@isocpp.org>
Subject: [std-proposals] Re: proposal to add vector::push_back_()
Date: Fri, Nov 29, 2013 6:43 PM

On Friday, 29 November 2013 20:38:41 UTC, Billy O'Neal  wrote:False. Push/Emplace back are guaranteed not to throw so long as size() < capacity().



You should have sent this to the original thread...

Anyway, you're missing the point: even if push_back is guaranteed not to throw when size() < capacity(), it cannot be declared noexcept.




--

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

--

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

------=_Part_0_1385769199962
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div style=3D"font-size: 12pt; font-family: Calibri,sans-serif;"><div>The u=
nchecked versions can't be declared noexcept either due to debugging implem=
entations.</div><div><br></div><div>Sent from a touchscreen. Please excuse =
the brevity and tpyos.</div><br><div id=3D"htc_header">----- Reply message =
-----<br>From: Victor.Khomenko@ncl.ac.uk<br>To: &lt;std-proposals@isocpp.or=
g&gt;<br>Subject: [std-proposals] Re: proposal to add vector::push_back_()<=
br>Date: Fri, Nov 29, 2013 6:43 PM</div></div><br><div dir=3D"ltr"><br><br>=
On Friday, 29 November 2013 20:38:41 UTC, Billy O'Neal  wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex;=
 border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left=
-style: solid;"><div style=3D"font-family: Calibri,sans-serif; font-size: 1=
2pt;"><div>False. Push/Emplace back are guaranteed not to throw so long as =
size() &lt; capacity().<br></div></div></blockquote><div><br></div><div><br=
></div><div>You should have sent this to the original thread...</div><div><=
br></div><div>Anyway, you're missing&nbsp;the point: even if push_back is g=
uaranteed not to throw&nbsp;when&nbsp;size() &lt; capacity(), it cannot be =
declared noexcept.</div></div>

<p></p>

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

<p></p>

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

------=_Part_0_1385769199962--


.

------=_Part_298_17751970.1385839561359
Content-Type: text/plain; charset=ISO-8859-1



On Friday, 29 November 2013 23:53:19 UTC, Billy O'Neal wrote:
>
> The unchecked versions can't be declared noexcept either due to debugging
> implementations.
>
>
I'm puzzled by your reply - could you elaborate?

--

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

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

<div dir=3D"ltr"><br><br>On Friday, 29 November 2013 23:53:19 UTC, Billy O'=
Neal  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;"><div style=3D"font-family: Calibri=
,sans-serif; font-size: 12pt;"><div>The unchecked versions can't be declare=
d noexcept either due to debugging implementations.</div><div><br></div></d=
iv></blockquote><div><br></div><div>I'm puzzled by your reply - could you e=
laborate?&nbsp;</div></div>

<p></p>

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

------=_Part_298_17751970.1385839561359--

.

--001a1133458e30627104ec740507
Content-Type: text/plain; charset=ISO-8859-1

The committee has taken a stance against marking members noexcept, except
when strictly necessary to enable correct behavior under certain conditions
-- given that noexcept is an immutable part of the interface.
Implementations are allowed to throw exceptions, even if not required to do
so by the standard. If a particular implementation is capable of supporting
noexcept, it is allowed to mark something noexcept.

In your specific "unchecked push back" case, an implementation may wish to
throw an exception in the event size() == capacity() when compiled with
debugging settings turned on, rather than incur undefined behavior. If the
standard marks the interface with noexcept, an implementation can't provide
these kinds of checks and remain conforming. Therefore, things aren't
marked noexcept in the standard unless absolutely positively required for
correct behavior of the interface, not merely when an implementation which
can provide noexcept is possible.

(Side note: You broke Visual C++'s EULA by posting that header file to this
list earlier. You don't have a license to redistribute the VC headers.
Don't do that.)

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sat, Nov 30, 2013 at 11:26 AM, <Victor.Khomenko@ncl.ac.uk> wrote:

>
>
> On Friday, 29 November 2013 23:53:19 UTC, Billy O'Neal wrote:
>>
>> The unchecked versions can't be declared noexcept either due to debugging
>> implementations.
>>
>>
> I'm puzzled by your reply - could you elaborate?
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--001a1133458e30627104ec740507
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The committee has taken a stance against marking members n=
oexcept, except when strictly necessary to enable correct behavior under ce=
rtain conditions -- given that noexcept is an immutable part of the interfa=
ce. Implementations are allowed to throw exceptions, even if not required t=
o do so by the standard. If a particular implementation is capable of suppo=
rting noexcept, it is allowed to mark something noexcept.<div>

<br></div><div>In your specific &quot;unchecked push back&quot; case, an im=
plementation may wish to throw an exception in the event size() =3D=3D capa=
city() when compiled with debugging settings turned on, rather than incur u=
ndefined behavior. If the standard marks the interface with noexcept, an im=
plementation can&#39;t provide these kinds of checks and remain conforming.=
 Therefore, things aren&#39;t marked noexcept in the standard unless absolu=
tely positively required for correct behavior of the interface, not merely =
when an implementation which can provide noexcept is possible.</div>

<div><br></div><div>(Side note: You broke Visual C++&#39;s EULA by posting =
that header file to this list earlier. You don&#39;t have a license to redi=
stribute the VC headers. Don&#39;t do that.)</div></div><div class=3D"gmail=
_extra">

<br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a =
href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://github=
..com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users/82=
320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/bil=
ly-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sat, Nov 30, 2013 at 11:26 AM,  <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:Victor.Khomenko@ncl.ac.uk" target=3D"_bl=
ank">Victor.Khomenko@ncl.ac.uk</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div dir=3D"ltr"><div class=3D"im"><br><br>On Friday, 29 November 2013 23:5=
3:19 UTC, Billy O&#39;Neal  wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">

<div style=3D"font-family:Calibri,sans-serif;font-size:12pt"><div>The unche=
cked versions can&#39;t be declared noexcept either due to debugging implem=
entations.</div><div><br></div></div></blockquote><div><br></div></div><div=
>

I&#39;m puzzled by your reply - could you elaborate?=A0</div></div><div cla=
ss=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a1133458e30627104ec740507--

.

------=_Part_281_3183156.1385924358745
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, 1 December 2013 07:28:34 UTC, Billy O'Neal wrote:
>
> The committee has taken a stance against marking members noexcept, except
> when strictly necessary to enable correct behavior under certain conditions
> -- given that noexcept is an immutable part of the interface.
> Implementations are allowed to throw exceptions, even if not required to do
> so by the standard. If a particular implementation is capable of supporting
> noexcept, it is allowed to mark something noexcept.
>

So your last sentence would give the library vendors the flexibility to
mark unchecked_push_back noexcept, which makes sense as this method is
meant for high performance, and can be useful in cases when no-throw
guarantee is required for whatever reason.



> In your specific "unchecked push back" case, an implementation may wish to
> throw an exception in the event size() == capacity() when compiled with
> debugging settings turned on, rather than incur undefined behavior. If the
> standard marks the interface with noexcept, an implementation can't provide
> these kinds of checks and remain conforming. Therefore, things aren't
> marked noexcept in the standard unless absolutely positively required for
> correct behavior of the interface, not merely when an implementation which
> can provide noexcept is possible.
>
>
The problem you describe is not specific to unchecked_push_back, but
generic, i.e. debuggers anyway have to cope with incorrect noexcept
functions somehow. I think this is not particularly difficult, e.g. the
debug code for noexcept functions can be generated in such a way as if they
can in fact throw, and report an error if they do.


--

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

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

<div dir=3D"ltr"><br><br>On Sunday, 1 December 2013 07:28:34 UTC, Billy O'N=
eal  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;"><div dir=3D"ltr">The committee has =
taken a stance against marking members noexcept, except when strictly neces=
sary to enable correct behavior under certain conditions -- given that noex=
cept is an immutable part of the interface. Implementations are allowed to =
throw exceptions, even if not required to do so by the standard. If a parti=
cular implementation is capable of supporting noexcept, it is allowed to ma=
rk something noexcept.</div></blockquote><div><br></div><div>So your last s=
entence would give the library vendors the flexibility to mark unchecked_pu=
sh_back noexcept, which makes sense as this method is meant for high perfor=
mance, and can be useful in cases when no-throw guarantee is required for w=
hatever reason.</div><div><br></div><div>&nbsp;</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;"><div dir=3D"ltr"><div>

In your specific "unchecked push back" case, an implementation may wish to =
throw an exception in the event size() =3D=3D capacity() when compiled with=
 debugging settings turned on, rather than incur undefined behavior. If the=
 standard marks the interface with noexcept, an implementation can't provid=
e these kinds of checks and remain conforming. Therefore, things aren't mar=
ked noexcept in the standard unless absolutely positively required for corr=
ect behavior of the interface, not merely when an implementation which can =
provide noexcept is possible.</div>

<div><br></div></div></blockquote><div><br></div><div>The problem you descr=
ibe is not specific to unchecked_push_back, but generic, i.e. debuggers any=
way have to cope with incorrect noexcept functions somehow. I think this is=
 not particularly difficult, e.g.&nbsp;the debug code for noexcept function=
s can be generated in such a way as if they can in fact throw, and report a=
n error if&nbsp;they do.</div><div><br></div><div><br></div></div>

<p></p>

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

------=_Part_281_3183156.1385924358745--

.

In the past, I have got equal speed to an unchecked push_back by using
passing a "generating iterator" to 'insert' (basically write a custom
input iterator which returns a new member of your data whenever
operator* is called).

This has the advantage of not requiring any unsafe interfaces.

Chris



On 29 November 2013 16:10,  <euloanty@live.com> wrote:
> I have try them by changing the implements of VS2013 CTP's vector. That is
> reasonable and easy to do. And, it can make our vectors as fast as arrays
> when we need to build a "1000000+ elements" vector. I have sent "vector.hpp"
> to all of you.
> These functions are to optimize our vectors.
> My implements(I added 4 new member functions):
>
>  void unsafe_push_back(const value_type& _Val)
>   { // insert element at end
>    this->_Getal().construct(this->_Mylast,
>     _Val);
>    ++this->_Mylast;
>   }
>
>  void unsafe_push_back(value_type&& _Val)
>   {
>    this->_Getal().construct(this->_Mylast,
>     _STD forward<value_type>(_Val));
>    ++this->_Mylast;
>   }
>
>  template<class... _Valty>
>   void unsafe_emplace_back(_Valty&&... _Val)
>   { // insert by moving into element at end
>   this->_Getal().construct(this->_Mylast,
>    _STD forward<_Valty>(_Val)...);
>   ++this->_Mylast;
>   }
>
>  void unsafe_resize(size_type _Newsize)
>  {
>   this->_Mylast += _Newsize - size();
>  }
>
> unsafe_resize cannot be given default value, its aim is to optimize the
> efficiency of vector.
> Besides, unsafe_insert, unsafe_emplace can be considered that whether they
> should be added into vectors.
>
> I think unsafe_push_back() is useful. For example, it is useful to make a
> Graph.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

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

.

--089e013c71e45f6d3b04ec8300d0
Content-Type: text/plain; charset=ISO-8859-1

>So your last sentence would give the library vendors the flexibility to
mark unchecked_push_back noexcept, which makes sense as this method is
meant for high performance, and can be useful in cases when no-throw
guarantee is required for whatever reason.

No -- callers cannot rely on a no-throw guarantee there. That is precisely
my point. You get no gaurantees over what push_back already provides.

>The problem you describe is not specific to unchecked_push_back, but
generic, i.e. debuggers anyway have to cope with incorrect noexcept
functions somehow. I think this is not particularly difficult, e.g. the
debug code for noexcept functions can be generated in such a way as if they
can in fact throw, and report an error if they do.

This isn't a problem to be solved. The committee already made this decision
-- things which do not absolutely need to be noexcept are *not* marked as
such. If it isn't marked that way in the standard, callers can't rely on it.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sun, Dec 1, 2013 at 10:59 AM, <Victor.Khomenko@ncl.ac.uk> wrote:

>
>
> On Sunday, 1 December 2013 07:28:34 UTC, Billy O'Neal wrote:
>>
>> The committee has taken a stance against marking members noexcept, except
>> when strictly necessary to enable correct behavior under certain conditions
>> -- given that noexcept is an immutable part of the interface.
>> Implementations are allowed to throw exceptions, even if not required to do
>> so by the standard. If a particular implementation is capable of supporting
>> noexcept, it is allowed to mark something noexcept.
>>
>
> So your last sentence would give the library vendors the flexibility to
> mark unchecked_push_back noexcept, which makes sense as this method is
> meant for high performance, and can be useful in cases when no-throw
> guarantee is required for whatever reason.
>
>
>
>>  In your specific "unchecked push back" case, an implementation may wish
>> to throw an exception in the event size() == capacity() when compiled with
>> debugging settings turned on, rather than incur undefined behavior. If the
>> standard marks the interface with noexcept, an implementation can't provide
>> these kinds of checks and remain conforming. Therefore, things aren't
>> marked noexcept in the standard unless absolutely positively required for
>> correct behavior of the interface, not merely when an implementation which
>> can provide noexcept is possible.
>>
>>
> The problem you describe is not specific to unchecked_push_back, but
> generic, i.e. debuggers anyway have to cope with incorrect noexcept
> functions somehow. I think this is not particularly difficult, e.g. the
> debug code for noexcept functions can be generated in such a way as if they
> can in fact throw, and report an error if they do.
>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--089e013c71e45f6d3b04ec8300d0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;<span style=3D"font-family:arial,sans-serif;font-size:=
13px">So your last sentence would give the library vendors the flexibility =
to mark unchecked_push_back noexcept, which makes sense as this method is m=
eant for high performance, and can be useful in cases when no-throw guarant=
ee is required for whatever reason.</span><div>

<span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></di=
v><div><span style=3D"font-family:arial,sans-serif;font-size:13px">No -- ca=
llers cannot rely on a no-throw guarantee there. That is precisely my point=
.. You get no gaurantees over what push_back already provides.</span></div>

<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">&gt=
;</span><span style=3D"font-family:arial,sans-serif;font-size:13px">The pro=
blem you describe is not specific to unchecked_push_back, but generic, i.e.=
 debuggers anyway have to cope with incorrect noexcept functions somehow. I=
 think this is not particularly difficult, e.g.=A0the debug code for noexce=
pt functions can be generated in such a way as if they can in fact throw, a=
nd report an error if=A0they do.</span></div>

<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><font face=3D"arial, sans-serif">This isn&#39;t a problem to be=
 solved. The committee already made this decision -- things which do not ab=
solutely need to be noexcept are *not* marked as such. If it isn&#39;t mark=
ed that way in the standard, callers can&#39;t rely on it.</font></div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sun, Dec 1, 2013 at 10:59 AM,  <span =
dir=3D"ltr">&lt;<a href=3D"mailto:Victor.Khomenko@ncl.ac.uk" target=3D"_bla=
nk">Victor.Khomenko@ncl.ac.uk</a>&gt;</span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">

<div dir=3D"ltr"><div class=3D"im"><br><br>On Sunday, 1 December 2013 07:28=
:34 UTC, Billy O&#39;Neal  wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,20=
4);border-left-width:1px;border-left-style:solid">

<div dir=3D"ltr">The committee has taken a stance against marking members n=
oexcept, except when strictly necessary to enable correct behavior under ce=
rtain conditions -- given that noexcept is an immutable part of the interfa=
ce. Implementations are allowed to throw exceptions, even if not required t=
o do so by the standard. If a particular implementation is capable of suppo=
rting noexcept, it is allowed to mark something noexcept.</div>

</blockquote><div><br></div></div><div>So your last sentence would give the=
 library vendors the flexibility to mark unchecked_push_back noexcept, whic=
h makes sense as this method is meant for high performance, and can be usef=
ul in cases when no-throw guarantee is required for whatever reason.</div>

<div class=3D"im"><div><br></div><div>=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:=
rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D=
"ltr">

<div>

In your specific &quot;unchecked push back&quot; case, an implementation ma=
y wish to throw an exception in the event size() =3D=3D capacity() when com=
piled with debugging settings turned on, rather than incur undefined behavi=
or. If the standard marks the interface with noexcept, an implementation ca=
n&#39;t provide these kinds of checks and remain conforming. Therefore, thi=
ngs aren&#39;t marked noexcept in the standard unless absolutely positively=
 required for correct behavior of the interface, not merely when an impleme=
ntation which can provide noexcept is possible.</div>



<div><br></div></div></blockquote><div><br></div></div><div>The problem you=
 describe is not specific to unchecked_push_back, but generic, i.e. debugge=
rs anyway have to cope with incorrect noexcept functions somehow. I think t=
his is not particularly difficult, e.g.=A0the debug code for noexcept funct=
ions can be generated in such a way as if they can in fact throw, and repor=
t an error if=A0they do.</div>

<div><br></div><div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5"=
>

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--089e013c71e45f6d3b04ec8300d0--

.

--_A752549D-C6A9-4937-A07B-D4254BB51538_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=windows-1252

In many conditions, we need it.

std::vector<std::vector<int>> vec;

//do something to allocate spaces.

vec[2].unsafe_back(3);

vec[4].unsafe_back(4);


Using a pair of random-access iterators has too much trouble for a programm=
er.

In my opinion, our vectors should both face to high-level programming but l=
ow-level programming as well.

Vec.data() is a  good advance to low-level programming, we could and should=
 do better.

It=92s our first choice to use dynamic space.




Sent from Windows Mail





From: Christopher Jefferson
Sent: Monday, December 2, 2013 6:07 AM
To: std-proposals@isocpp.org





In the past, I have got equal speed to an unchecked push_back by using
passing a "generating iterator" to 'insert' (basically write a custom
input iterator which returns a new member of your data whenever
operator* is called).

This has the advantage of not requiring any unsafe interfaces.

Chris



On 29 November 2013 16:10,  <euloanty@live.com> wrote:
> I have try them by changing the implements of VS2013 CTP's vector. That i=
s
> reasonable and easy to do. And, it can make our vectors as fast as arrays
> when we need to build a "1000000+ elements" vector. I have sent "vector.h=
pp"
> to all of you.
> These functions are to optimize our vectors.
> My implements(I added 4 new member functions):
>
>  void unsafe_push_back(const value_type& _Val)
>   { // insert element at end
>    this->_Getal().construct(this->_Mylast,
>     _Val);
>    ++this->_Mylast;
>   }
>
>  void unsafe_push_back(value_type&& _Val)
>   {
>    this->_Getal().construct(this->_Mylast,
>     _STD forward<value_type>(_Val));
>    ++this->_Mylast;
>   }
>
>  template<class... _Valty>
>   void unsafe_emplace_back(_Valty&&... _Val)
>   { // insert by moving into element at end
>   this->_Getal().construct(this->_Mylast,
>    _STD forward<_Valty>(_Val)...);
>   ++this->_Mylast;
>   }
>
>  void unsafe_resize(size_type _Newsize)
>  {
>   this->_Mylast +=3D _Newsize - size();
>  }
>
> unsafe_resize cannot be given default value, its aim is to optimize the
> efficiency of vector.
> Besides, unsafe_insert, unsafe_emplace can be considered that whether the=
y
> should be added into vectors.
>
> I think unsafe_push_back() is useful. For example, it is useful to make a
> Graph.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20

---=20
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.or=
g/d/topic/std-proposals/5BnNHEr07QM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--=20

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

--_A752549D-C6A9-4937-A07B-D4254BB51538_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=windows-1252


<html>
<head>
<meta name=3D"generator" content=3D"Windows Mail 17.5.9600.20315">
<style><!--
..EmailQuote {
margin-left:1pt;
padding-left:4pt;
border-left:#800000 2px solid;
}
--></style><style data-externalstyle=3D"true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParag=
raphCxSpFirst,=20
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListPar=
agraphCxSpMiddle,=20
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagra=
phCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style></head>
<body dir=3D"ltr">
<div data-externalstyle=3D"false" dir=3D"ltr" style=3D"font-family: 'Calibr=
i', 'Microsoft YaHei UI', 'Segoe UI', 'Meiryo', 'Microsoft JhengHei UI', 'M=
algun Gothic', 'sans-serif';font-size:12pt;"><div style=3D"color: rgb(0, 0,=
 0);">In many conditions, we need it.</div><div style=3D"color: rgb(0, 0, 0=
);">std::vector&lt;std::vector&lt;int&gt;&gt; vec;</div><div style=3D"color=
: rgb(0, 0, 0);">//do something to allocate spaces.</div><div style=3D"colo=
r: rgb(0, 0, 0);">vec[2].unsafe_back(3);</div><div style=3D"color: rgb(0, 0=
, 0);">vec[4].unsafe_back(4);</div><div style=3D"color: rgb(0, 0, 0);" data=
-signatureblock=3D"true"><div style=3D"color: rgb(0, 0, 0);">Using a pair o=
f&nbsp;random-access iterators has too much trouble for a programmer.</div>=
<div style=3D"color: rgb(0, 0, 0);">In my opinion, our vectors should both =
face to high-level programming but low-level programming as well.</div><div=
 style=3D"color: rgb(0, 0, 0);">Vec.data() is a&nbsp; good advance to low-l=
evel programming, we could and&nbsp;should do better.</div><div style=3D"co=
lor: rgb(0, 0, 0);">It=92s our first choice to use dynamic space.</div><div=
 style=3D"color: rgb(0, 0, 0);"><br></div><div style=3D"color: rgb(0, 0, 0)=
;">Sent from Windows Mail</div><div style=3D"color: rgb(0, 0, 0);"><br></di=
v></div><div style=3D"padding-top: 5px; border-top-color: rgb(229, 229, 229=
); border-top-width: 1px; border-top-style: solid;"><div><font face=3D" 'Ca=
libri', 'Microsoft YaHei UI', 'Segoe UI', 'Meiryo', 'Microsoft JhengHei UI'=
, 'Malgun Gothic', 'sans-serif'" style=3D'line-height: 15pt; letter-spacing=
: 0.02em; font-family: "Calibri", "Microsoft YaHei UI", "Segoe UI", "Meiryo=
", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 12pt;=
'><b>From:</b>&nbsp;<a href=3D"mailto:chris@bubblescope.net" target=3D"_par=
ent">Christopher Jefferson</a><br><b>Sent:</b>&nbsp;Monday, December 2, 201=
3 6:07 AM<br><b>To:</b>&nbsp;<a href=3D"mailto:std-proposals@isocpp.org" ta=
rget=3D"_parent">std-proposals@isocpp.org</a></font></div></div><div><br></=
div><div dir=3D"">
<div class=3D"PlainText">In the past, I have got equal speed to an unchecke=
d push_back by using<br>
passing a "generating iterator" to 'insert' (basically write a custom<br>
input iterator which returns a new member of your data whenever<br>
operator* is called).<br>
<br>
This has the advantage of not requiring any unsafe interfaces.<br>
<br>
Chris<br>
<br>
<br>
<br>
On 29 November 2013 16:10,&nbsp; &lt;euloanty@live.com&gt; wrote:<br>
&gt; I have try them by changing the implements of VS2013 CTP's vector. Tha=
t is<br>
&gt; reasonable and easy to do. And, it can make our vectors as fast as arr=
ays<br>
&gt; when we need to build a "1000000+ elements" vector. I have sent "vecto=
r.hpp"<br>
&gt; to all of you.<br>
&gt; These functions are to optimize our vectors.<br>
&gt; My implements(I added 4 new member functions):<br>
&gt;<br>
&gt;&nbsp; void unsafe_push_back(const value_type&amp; _Val)<br>
&gt;&nbsp;&nbsp; { // insert element at end<br>
&gt;&nbsp;&nbsp;&nbsp; this-&gt;_Getal().construct(this-&gt;_Mylast,<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; _Val);<br>
&gt;&nbsp;&nbsp;&nbsp; ++this-&gt;_Mylast;<br>
&gt;&nbsp;&nbsp; }<br>
&gt;<br>
&gt;&nbsp; void unsafe_push_back(value_type&amp;&amp; _Val)<br>
&gt;&nbsp;&nbsp; {<br>
&gt;&nbsp;&nbsp;&nbsp; this-&gt;_Getal().construct(this-&gt;_Mylast,<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; _STD forward&lt;value_type&gt;(_Val));<br>
&gt;&nbsp;&nbsp;&nbsp; ++this-&gt;_Mylast;<br>
&gt;&nbsp;&nbsp; }<br>
&gt;<br>
&gt;&nbsp; template&lt;class... _Valty&gt;<br>
&gt;&nbsp;&nbsp; void unsafe_emplace_back(_Valty&amp;&amp;... _Val)<br>
&gt;&nbsp;&nbsp; { // insert by moving into element at end<br>
&gt;&nbsp;&nbsp; this-&gt;_Getal().construct(this-&gt;_Mylast,<br>
&gt;&nbsp;&nbsp;&nbsp; _STD forward&lt;_Valty&gt;(_Val)...);<br>
&gt;&nbsp;&nbsp; ++this-&gt;_Mylast;<br>
&gt;&nbsp;&nbsp; }<br>
&gt;<br>
&gt;&nbsp; void unsafe_resize(size_type _Newsize)<br>
&gt;&nbsp; {<br>
&gt;&nbsp;&nbsp; this-&gt;_Mylast +=3D _Newsize - size();<br>
&gt;&nbsp; }<br>
&gt;<br>
&gt; unsafe_resize cannot be given default value, its aim is to optimize th=
e<br>
&gt; efficiency of vector.<br>
&gt; Besides, unsafe_insert, unsafe_emplace can be considered that whether =
they<br>
&gt; should be added into vectors.<br>
&gt;<br>
&gt; I think unsafe_push_back() is useful. For example, it is useful to mak=
e a<br>
&gt; Graph.<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; "ISO C++ Standard - Future Proposals" group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to std-proposals+unsubscribe@isocpp.org.<br>
&gt; To post to this group, send email to std-proposals@isocpp.org.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 target=3D"_parent">http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/</a>.<br>
<br>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe" target=3D"_pare=
nt">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07Q=
M/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.<br>
To post to this group, send email to std-proposals@isocpp.org.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_parent">http://groups.google.com/a/isocpp.org/gr=
oup/std-proposals/</a>.<br>
</div>


</div></div>
</body>
</html>

<p></p>

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

--_A752549D-C6A9-4937-A07B-D4254BB51538_--

.

--_DBF442B2-0A49-45ED-BA8B-71067AD2D03F_
Content-Type: text/plain; charset=ISO-8859-1

A sample program to calculate shortest-path.

#include<fstream>
#include<vector>
#include<queue>
#include<utility>
#include<cstddef>
#include<cstdint>
#include<string>
#include<ctime>
#include<limits>
#include<iostream>
#include<memory>
#include<tuple>
#include<cctype>
#include<cstring>


class fread_analyse
{
 std::vector<char> arr;
 std::vector<char>::iterator iter;
public:
 fread_analyse()
 {
  FILE *file(std::fopen("ghin.txt","r"));
  std::fseek(file,0,SEEK_END);
  arr.reserve(std::ftell(file)+1);
  std::fseek(file,0,SEEK_SET);
  std::fread(arr.data(),1,arr.capacity(),file);
  iter=arr.begin();
  std::fclose(file);
 }
 template<typename UInt>
 fread_analyse& readuint(UInt &a)
 {
  for(;std::isspace(*iter);++iter);
  for(a=*iter-'0';std::isdigit(*++iter);a=a*10+*iter-'0');
  return *this;
 }
};


void process()
{
 fread_analyse frd;
 std::size_t m,n;
 frd.readuint(m).readuint(n);
 std::vector<std::vector<std::pair<std::size_t,int>>> graph;
 std::vector<std::tuple<std::size_t,std::size_t,int>> edges;
 std::vector<std::size_t> ind(n);
 edges.reserve(m);
 for(std::size_t i(0),a,b;i!=m;++i)
 {
  int w;
  frd.readuint(a).readuint(b).readuint(w);
  edges.unsafe_emplace_back(a,b,w);
  ++ind[a];
 }
 graph.reserve(n);
 for(auto iter(ind.cbegin());iter!=ind.cend();++iter)
 {
  graph.unsafe_emplace_back();
  graph.back().reserve(*iter);
 }
 for(auto iter(edges.cbegin());iter!=edges.cend();++iter)
  graph[std::get<0>(*iter)].unsafe_emplace_back(std::get<1>(*iter),std::get<2>(*iter));//if no unsafe_emplace_back, this is very slow, and you can hardly use a iterator-range to initialize them;
 std::cout<<static_cast<double>(std::clock())/CLOCKS_PER_SEC<<std::endl;
 auto time0(std::clock());
 std::vector<std::int64_t> relax(n,INT64_MAX);
 relax.front()=0;
 std::vector<bool> ss(n);
 ss.front()=1;
 for(std::deque<std::size_t> que(1,0);!que.empty();)
 {
  const auto front(que.front());
  que.pop_front();
  for(auto iter(graph[front].cbegin());iter!=graph[front].cend();++iter)
   if(relax[front]+iter->second<relax[iter->first])
   {
    relax[iter->first]=relax[front]+iter->second;
    if(!ss[iter->first])
    {
     if(que.empty()||relax[que.front()]<relax[iter->first])
      que.push_back(iter->first);
     else
      que.push_front(iter->first);
     ss[iter->first]=1;
    }
   }
  ss[front]=0;
 }
 std::ofstream fout("spfao.txt");
 if(relax.back()==std::numeric_limits<std::int64_t>::max())
  fout.rdbuf()->sputn("-1\n",3);
 else
  (fout<<relax.back()).rdbuf()->sputc('\n');
 std::cout<<static_cast<double>(std::clock()-time0)/CLOCKS_PER_SEC<<std::endl;
}


int main()
{
 process();
 std::cout<<static_cast<double>(std::clock())/CLOCKS_PER_SEC<<std::endl;
 return 0;
}



But, Of course, next is better.


#include<fstream>
#include<vector>
#include<deque>
#include<utility>
#include<cstddef>
#include<cstdint>
#include<string>
#include<ctime>
#include<iostream>
#include<sstream>
#include<array>
#include<cctype>


class fread_analyse
{
 std::vector<char> arr;
 std::vector<char>::iterator iter;
public:
 fread_analyse()
 {
  FILE *file(std::fopen("ghin.txt","r"));
  std::fseek(file,0,SEEK_END);
  arr.reserve(std::ftell(file)+1);
  std::fseek(file,0,SEEK_SET);
  std::fread(arr.data(),1,arr.capacity(),file);
  iter=arr.begin();
  std::fclose(file);
 }
 template<typename UInt>
 fread_analyse& readuint(UInt &a)
 {
  for(;std::isspace(*iter);++iter);
  for(a=*iter-'0';std::isdigit(*++iter);a=a*10+*iter-'0');
  return *this;
 }
};


void process()
{
 std::vector<std::vector<std::pair<std::size_t,int>>> graph;
 std::size_t m,n;
 {
 fread_analyse frd;
 frd.readuint(m).readuint(n);
 graph.reserve(n);
 {
 const std::size_t mtcapa((m%n?m/n+1:m/n)*6/5);
 for(std::size_t i(0);i!=n;++i)
 {
  graph.unsafe_emplace_back();
  graph.back().reserve(mtcapa);
 }
 }
 for(std::size_t i(0),a,b;i!=m;++i)
 {
  int w;
  frd.readuint(a).readuint(b).readuint(w);
  graph[a].emplace_back(b,w);
 }
 }
 std::cout<<static_cast<double>(std::clock())/CLOCKS_PER_SEC<<std::endl;
 auto time0(std::clock());
 std::vector<std::int64_t> relax(n,INT64_MAX);
 relax.front()=0;
 std::vector<char> ss(n);
 ss.front()=1;
 for(std::deque<std::size_t> que(1,0);!que.empty();)
 {
  auto front(que.front());
  que.pop_front();
  for(auto iter(graph[front].cbegin());iter!=graph[front].cend();++iter)
   if(relax[front]+iter->second<relax[iter->first])
   {
    relax[iter->first]=relax[front]+iter->second;
    if(!ss[iter->first])
    {
     if(que.empty()||relax[que.front()]<relax[iter->first])
      que.push_back(iter->first);
     else
      que.push_front(iter->first);
     ss[iter->first]=1;
    }
   }
  ss[front]=0;
 }
 std::ofstream fout("spfao1.txt");
 if(relax.back()==INT64_MAX)
  fout<<"-1"<<std::endl;
 else
  fout<<relax.back()<<std::endl;
 std::cout<<static_cast<double>(std::clock()-time0)/CLOCKS_PER_SEC<<std::endl;
}


int main()
{
 std::ios::sync_with_stdio(false);
 process();
 std::cout<<static_cast<double>(std::clock())/CLOCKS_PER_SEC<<std::endl;
 return 0;
}









Sent from Windows Mail





From: Christopher Jefferson
Sent: Monday, December 2, 2013 6:07 AM
To: std-proposals@isocpp.org





In the past, I have got equal speed to an unchecked push_back by using
passing a "generating iterator" to 'insert' (basically write a custom
input iterator which returns a new member of your data whenever
operator* is called).

This has the advantage of not requiring any unsafe interfaces.

Chris



On 29 November 2013 16:10,  <euloanty@live.com> wrote:
> I have try them by changing the implements of VS2013 CTP's vector. That is
> reasonable and easy to do. And, it can make our vectors as fast as arrays
> when we need to build a "1000000+ elements" vector. I have sent "vector.hpp"
> to all of you.
> These functions are to optimize our vectors.
> My implements(I added 4 new member functions):
>
>  void unsafe_push_back(const value_type& _Val)
>   { // insert element at end
>    this->_Getal().construct(this->_Mylast,
>     _Val);
>    ++this->_Mylast;
>   }
>
>  void unsafe_push_back(value_type&& _Val)
>   {
>    this->_Getal().construct(this->_Mylast,
>     _STD forward<value_type>(_Val));
>    ++this->_Mylast;
>   }
>
>  template<class... _Valty>
>   void unsafe_emplace_back(_Valty&&... _Val)
>   { // insert by moving into element at end
>   this->_Getal().construct(this->_Mylast,
>    _STD forward<_Valty>(_Val)...);
>   ++this->_Mylast;
>   }
>
>  void unsafe_resize(size_type _Newsize)
>  {
>   this->_Mylast += _Newsize - size();
>  }
>
> unsafe_resize cannot be given default value, its aim is to optimize the
> efficiency of vector.
> Besides, unsafe_insert, unsafe_emplace can be considered that whether they
> should be added into vectors.
>
> I think unsafe_push_back() is useful. For example, it is useful to make a
> Graph.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

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

--_DBF442B2-0A49-45ED-BA8B-71067AD2D03F_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1


<html>
<head>
<meta name=3D"generator" content=3D"Windows Mail 17.5.9600.20315">
<style><!--
..EmailQuote {
margin-left:1pt;
padding-left:4pt;
border-left:#800000 2px solid;
}
--></style><style data-externalstyle=3D"true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParag=
raphCxSpFirst,=20
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListPar=
agraphCxSpMiddle,=20
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagra=
phCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style></head>
<body dir=3D"ltr">
<div data-externalstyle=3D"false" dir=3D"ltr" style=3D"font-family: 'Calibr=
i', 'Microsoft YaHei UI', 'Segoe UI', 'Meiryo', 'Microsoft JhengHei UI', 'M=
algun Gothic', 'sans-serif';font-size:12pt;"><div style=3D"color: rgb(0, 0,=
 0);">A&nbsp;sample&nbsp;program to calculate&nbsp;shortest-path.</div><div=
 style=3D"color: rgb(0, 0, 0);">#include&lt;fstream&gt;<br>#include&lt;vect=
or&gt;<br>#include&lt;queue&gt;<br>#include&lt;utility&gt;<br>#include&lt;c=
stddef&gt;<br>#include&lt;cstdint&gt;<br>#include&lt;string&gt;<br>#include=
&lt;ctime&gt;<br>#include&lt;limits&gt;<br>#include&lt;iostream&gt;<br>#inc=
lude&lt;memory&gt;<br>#include&lt;tuple&gt;<br>#include&lt;cctype&gt;<br>#i=
nclude&lt;cstring&gt;</div><div><br></div><div style=3D"color: rgb(0, 0, 0)=
;">class fread_analyse<br>{<br>&nbsp;std::vector&lt;char&gt; arr;<br>&nbsp;=
std::vector&lt;char&gt;::iterator iter;<br>public:<br>&nbsp;fread_analyse()=
<br>&nbsp;{<br>&nbsp;&nbsp;FILE *file(std::fopen("ghin.txt","r"));<br>&nbsp=
;&nbsp;std::fseek(file,0,SEEK_END);<br>&nbsp;&nbsp;arr.reserve(std::ftell(f=
ile)+1);<br>&nbsp;&nbsp;std::fseek(file,0,SEEK_SET);<br>&nbsp;&nbsp;std::fr=
ead(arr.data(),1,arr.capacity(),file);<br>&nbsp;&nbsp;iter=3Darr.begin();<b=
r>&nbsp;&nbsp;std::fclose(file);<br>&nbsp;}<br>&nbsp;template&lt;typename U=
Int&gt;<br>&nbsp;fread_analyse&amp; readuint(UInt &amp;a)<br>&nbsp;{<br>&nb=
sp;&nbsp;for(;std::isspace(*iter);++iter);<br>&nbsp;&nbsp;for(a=3D*iter-'0'=
;std::isdigit(*++iter);a=3Da*10+*iter-'0');<br>&nbsp;&nbsp;return *this;<br=
>&nbsp;}<br>};</div><div><br></div><div style=3D"color: rgb(0, 0, 0);">void=
 process()<br>{<br>&nbsp;fread_analyse frd;<br>&nbsp;std::size_t m,n;<br>&n=
bsp;frd.readuint(m).readuint(n);<br>&nbsp;std::vector&lt;std::vector&lt;std=
::pair&lt;std::size_t,int&gt;&gt;&gt; graph;<br>&nbsp;std::vector&lt;std::t=
uple&lt;std::size_t,std::size_t,int&gt;&gt; edges;<br>&nbsp;std::vector&lt;=
std::size_t&gt; ind(n);<br>&nbsp;edges.reserve(m);<br>&nbsp;for(std::size_t=
 i(0),a,b;i!=3Dm;++i)<br>&nbsp;{<br>&nbsp;&nbsp;int w;<br>&nbsp;&nbsp;frd.r=
eaduint(a).readuint(b).readuint(w);<br>&nbsp;&nbsp;edges.unsafe_emplace_bac=
k(a,b,w);<br>&nbsp;&nbsp;++ind[a];<br>&nbsp;}<br>&nbsp;graph.reserve(n);<br=
>&nbsp;for(auto iter(ind.cbegin());iter!=3Dind.cend();++iter)<br>&nbsp;{<br=
>&nbsp;&nbsp;graph.unsafe_emplace_back();<br>&nbsp;&nbsp;graph.back().reser=
ve(*iter);<br>&nbsp;}<br>&nbsp;for(auto iter(edges.cbegin());iter!=3Dedges.=
cend();++iter)<br>&nbsp;&nbsp;graph[std::get&lt;0&gt;(*iter)].unsafe_emplac=
e_back(std::get&lt;1&gt;(*iter),std::get&lt;2&gt;(*iter));//if no unsafe_em=
place_back, this is&nbsp;very slow, and you can hardly&nbsp;use a iterator-=
range to initialize&nbsp;them;<br>&nbsp;std::cout&lt;&lt;static_cast&lt;dou=
ble&gt;(std::clock())/CLOCKS_PER_SEC&lt;&lt;std::endl;<br>&nbsp;auto time0(=
std::clock());<br>&nbsp;std::vector&lt;std::int64_t&gt; relax(n,INT64_MAX);=
<br>&nbsp;relax.front()=3D0;<br>&nbsp;std::vector&lt;bool&gt; ss(n);<br>&nb=
sp;ss.front()=3D1;<br>&nbsp;for(std::deque&lt;std::size_t&gt; que(1,0);!que=
..empty();)<br>&nbsp;{<br>&nbsp;&nbsp;const auto front(que.front());<br>&nbs=
p;&nbsp;que.pop_front();<br>&nbsp;&nbsp;for(auto iter(graph[front].cbegin()=
);iter!=3Dgraph[front].cend();++iter)<br>&nbsp;&nbsp;&nbsp;if(relax[front]+=
iter-&gt;second&lt;relax[iter-&gt;first])<br>&nbsp;&nbsp;&nbsp;{<br>&nbsp;&=
nbsp;&nbsp;&nbsp;relax[iter-&gt;first]=3Drelax[front]+iter-&gt;second;<br>&=
nbsp;&nbsp;&nbsp;&nbsp;if(!ss[iter-&gt;first])<br>&nbsp;&nbsp;&nbsp;&nbsp;{=
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if(que.empty()||relax[que.front()]&lt;rel=
ax[iter-&gt;first])<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;que.push_back(it=
er-&gt;first);<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else<br>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;que.push_front(iter-&gt;first);<br>&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;ss[iter-&gt;first]=3D1;<br>&nbsp;&nbsp;&nbsp;&nbsp;}<br>&nbsp;&nbsp;=
&nbsp;}<br>&nbsp;&nbsp;ss[front]=3D0;<br>&nbsp;}<br>&nbsp;std::ofstream fou=
t("spfao.txt");<br>&nbsp;if(relax.back()=3D=3Dstd::numeric_limits&lt;std::i=
nt64_t&gt;::max())<br>&nbsp;&nbsp;fout.rdbuf()-&gt;sputn("-1\n",3);<br>&nbs=
p;else<br>&nbsp;&nbsp;(fout&lt;&lt;relax.back()).rdbuf()-&gt;sputc('\n');<b=
r>&nbsp;std::cout&lt;&lt;static_cast&lt;double&gt;(std::clock()-time0)/CLOC=
KS_PER_SEC&lt;&lt;std::endl;<br>}</div><div><br></div><div style=3D"color: =
rgb(0, 0, 0);">int main()<br>{<br>&nbsp;process();<br>&nbsp;std::cout&lt;&l=
t;static_cast&lt;double&gt;(std::clock())/CLOCKS_PER_SEC&lt;&lt;std::endl;<=
br>&nbsp;return 0;<br>}</div><div><br></div><div style=3D"color: rgb(0, 0, =
0);"><br></div><div style=3D"color: rgb(0, 0, 0);">But, Of course, next is =
better.</div><div style=3D"color: rgb(0, 0, 0);"><br></div><div style=3D"co=
lor: rgb(0, 0, 0);">#include&lt;fstream&gt;<br>#include&lt;vector&gt;<br>#i=
nclude&lt;deque&gt;<br>#include&lt;utility&gt;<br>#include&lt;cstddef&gt;<b=
r>#include&lt;cstdint&gt;<br>#include&lt;string&gt;<br>#include&lt;ctime&gt=
;<br>#include&lt;iostream&gt;<br>#include&lt;sstream&gt;<br>#include&lt;arr=
ay&gt;<br>#include&lt;cctype&gt;</div><div><br></div><div style=3D"color: r=
gb(0, 0, 0);">class fread_analyse<br>{<br>&nbsp;std::vector&lt;char&gt; arr=
;<br>&nbsp;std::vector&lt;char&gt;::iterator iter;<br>public:<br>&nbsp;frea=
d_analyse()<br>&nbsp;{<br>&nbsp;&nbsp;FILE *file(std::fopen("ghin.txt","r")=
);<br>&nbsp;&nbsp;std::fseek(file,0,SEEK_END);<br>&nbsp;&nbsp;arr.reserve(s=
td::ftell(file)+1);<br>&nbsp;&nbsp;std::fseek(file,0,SEEK_SET);<br>&nbsp;&n=
bsp;std::fread(arr.data(),1,arr.capacity(),file);<br>&nbsp;&nbsp;iter=3Darr=
..begin();<br>&nbsp;&nbsp;std::fclose(file);<br>&nbsp;}<br>&nbsp;template&lt=
;typename UInt&gt;<br>&nbsp;fread_analyse&amp; readuint(UInt &amp;a)<br>&nb=
sp;{<br>&nbsp;&nbsp;for(;std::isspace(*iter);++iter);<br>&nbsp;&nbsp;for(a=
=3D*iter-'0';std::isdigit(*++iter);a=3Da*10+*iter-'0');<br>&nbsp;&nbsp;retu=
rn *this;<br>&nbsp;}<br>};</div><div><br></div><div style=3D"color: rgb(0, =
0, 0);">void process()<br>{<br>&nbsp;std::vector&lt;std::vector&lt;std::pai=
r&lt;std::size_t,int&gt;&gt;&gt; graph;<br>&nbsp;std::size_t m,n;<br>&nbsp;=
{<br>&nbsp;fread_analyse frd;<br>&nbsp;frd.readuint(m).readuint(n);<br>&nbs=
p;graph.reserve(n);<br>&nbsp;{<br>&nbsp;const std::size_t mtcapa((m%n?m/n+1=
:m/n)*6/5);<br>&nbsp;for(std::size_t i(0);i!=3Dn;++i)<br>&nbsp;{<br>&nbsp;&=
nbsp;graph.unsafe_emplace_back();<br>&nbsp;&nbsp;graph.back().reserve(mtcap=
a);<br>&nbsp;}<br>&nbsp;}<br>&nbsp;for(std::size_t i(0),a,b;i!=3Dm;++i)<br>=
&nbsp;{<br>&nbsp;&nbsp;int w;<br>&nbsp;&nbsp;frd.readuint(a).readuint(b).re=
aduint(w);<br>&nbsp;&nbsp;graph[a].emplace_back(b,w);<br>&nbsp;}<br>&nbsp;}=
<br>&nbsp;std::cout&lt;&lt;static_cast&lt;double&gt;(std::clock())/CLOCKS_P=
ER_SEC&lt;&lt;std::endl;<br>&nbsp;auto time0(std::clock());<br>&nbsp;std::v=
ector&lt;std::int64_t&gt; relax(n,INT64_MAX);<br>&nbsp;relax.front()=3D0;<b=
r>&nbsp;std::vector&lt;char&gt; ss(n);<br>&nbsp;ss.front()=3D1;<br>&nbsp;fo=
r(std::deque&lt;std::size_t&gt; que(1,0);!que.empty();)<br>&nbsp;{<br>&nbsp=
;&nbsp;auto front(que.front());<br>&nbsp;&nbsp;que.pop_front();<br>&nbsp;&n=
bsp;for(auto iter(graph[front].cbegin());iter!=3Dgraph[front].cend();++iter=
)<br>&nbsp;&nbsp;&nbsp;if(relax[front]+iter-&gt;second&lt;relax[iter-&gt;fi=
rst])<br>&nbsp;&nbsp;&nbsp;{<br>&nbsp;&nbsp;&nbsp;&nbsp;relax[iter-&gt;firs=
t]=3Drelax[front]+iter-&gt;second;<br>&nbsp;&nbsp;&nbsp;&nbsp;if(!ss[iter-&=
gt;first])<br>&nbsp;&nbsp;&nbsp;&nbsp;{<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if=
(que.empty()||relax[que.front()]&lt;relax[iter-&gt;first])<br>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;que.push_back(iter-&gt;first);<br>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;else<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;que.push_front(iter=
-&gt;first);<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ss[iter-&gt;first]=3D1;<br>&n=
bsp;&nbsp;&nbsp;&nbsp;}<br>&nbsp;&nbsp;&nbsp;}<br>&nbsp;&nbsp;ss[front]=3D0=
;<br>&nbsp;}<br>&nbsp;std::ofstream fout("spfao1.txt");<br>&nbsp;if(relax.b=
ack()=3D=3DINT64_MAX)<br>&nbsp;&nbsp;fout&lt;&lt;"-1"&lt;&lt;std::endl;<br>=
&nbsp;else<br>&nbsp;&nbsp;fout&lt;&lt;relax.back()&lt;&lt;std::endl;<br>&nb=
sp;std::cout&lt;&lt;static_cast&lt;double&gt;(std::clock()-time0)/CLOCKS_PE=
R_SEC&lt;&lt;std::endl;<br>}</div><div><br></div><div style=3D"color: rgb(0=
, 0, 0);">int main()<br>{<br>&nbsp;std::ios::sync_with_stdio(false);<br>&nb=
sp;process();<br>&nbsp;std::cout&lt;&lt;static_cast&lt;double&gt;(std::cloc=
k())/CLOCKS_PER_SEC&lt;&lt;std::endl;<br>&nbsp;return 0;<br>}</div><div><br=
></div><div style=3D"color: rgb(0, 0, 0);"><br></div><div style=3D"color: r=
gb(0, 0, 0);" data-signatureblock=3D"true"><div style=3D"color: rgb(0, 0, 0=
);"><br></div><div style=3D"color: rgb(0, 0, 0);">Sent from Windows Mail</d=
iv><div style=3D"color: rgb(0, 0, 0);"><br></div></div><div style=3D"paddin=
g-top: 5px; border-top-color: rgb(229, 229, 229); border-top-width: 1px; bo=
rder-top-style: solid;"><div><font face=3D" 'Calibri', 'Microsoft YaHei UI'=
, 'Segoe UI', 'Meiryo', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-ser=
if'" style=3D'line-height: 15pt; letter-spacing: 0.02em; font-family: "Cali=
bri", "Microsoft YaHei UI", "Segoe UI", "Meiryo", "Microsoft JhengHei UI", =
"Malgun Gothic", "sans-serif"; font-size: 12pt;'><b>From:</b>&nbsp;<a href=
=3D"mailto:chris@bubblescope.net" target=3D"_parent">Christopher Jefferson<=
/a><br><b>Sent:</b>&nbsp;Monday, December 2, 2013 6:07 AM<br><b>To:</b>&nbs=
p;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_parent">std-propos=
als@isocpp.org</a></font></div></div><div><br></div><div dir=3D"">
<div class=3D"PlainText">In the past, I have got equal speed to an unchecke=
d push_back by using<br>
passing a "generating iterator" to 'insert' (basically write a custom<br>
input iterator which returns a new member of your data whenever<br>
operator* is called).<br>
<br>
This has the advantage of not requiring any unsafe interfaces.<br>
<br>
Chris<br>
<br>
<br>
<br>
On 29 November 2013 16:10,&nbsp; &lt;euloanty@live.com&gt; wrote:<br>
&gt; I have try them by changing the implements of VS2013 CTP's vector. Tha=
t is<br>
&gt; reasonable and easy to do. And, it can make our vectors as fast as arr=
ays<br>
&gt; when we need to build a "1000000+ elements" vector. I have sent "vecto=
r.hpp"<br>
&gt; to all of you.<br>
&gt; These functions are to optimize our vectors.<br>
&gt; My implements(I added 4 new member functions):<br>
&gt;<br>
&gt;&nbsp; void unsafe_push_back(const value_type&amp; _Val)<br>
&gt;&nbsp;&nbsp; { // insert element at end<br>
&gt;&nbsp;&nbsp;&nbsp; this-&gt;_Getal().construct(this-&gt;_Mylast,<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; _Val);<br>
&gt;&nbsp;&nbsp;&nbsp; ++this-&gt;_Mylast;<br>
&gt;&nbsp;&nbsp; }<br>
&gt;<br>
&gt;&nbsp; void unsafe_push_back(value_type&amp;&amp; _Val)<br>
&gt;&nbsp;&nbsp; {<br>
&gt;&nbsp;&nbsp;&nbsp; this-&gt;_Getal().construct(this-&gt;_Mylast,<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; _STD forward&lt;value_type&gt;(_Val));<br>
&gt;&nbsp;&nbsp;&nbsp; ++this-&gt;_Mylast;<br>
&gt;&nbsp;&nbsp; }<br>
&gt;<br>
&gt;&nbsp; template&lt;class... _Valty&gt;<br>
&gt;&nbsp;&nbsp; void unsafe_emplace_back(_Valty&amp;&amp;... _Val)<br>
&gt;&nbsp;&nbsp; { // insert by moving into element at end<br>
&gt;&nbsp;&nbsp; this-&gt;_Getal().construct(this-&gt;_Mylast,<br>
&gt;&nbsp;&nbsp;&nbsp; _STD forward&lt;_Valty&gt;(_Val)...);<br>
&gt;&nbsp;&nbsp; ++this-&gt;_Mylast;<br>
&gt;&nbsp;&nbsp; }<br>
&gt;<br>
&gt;&nbsp; void unsafe_resize(size_type _Newsize)<br>
&gt;&nbsp; {<br>
&gt;&nbsp;&nbsp; this-&gt;_Mylast +=3D _Newsize - size();<br>
&gt;&nbsp; }<br>
&gt;<br>
&gt; unsafe_resize cannot be given default value, its aim is to optimize th=
e<br>
&gt; efficiency of vector.<br>
&gt; Besides, unsafe_insert, unsafe_emplace can be considered that whether =
they<br>
&gt; should be added into vectors.<br>
&gt;<br>
&gt; I think unsafe_push_back() is useful. For example, it is useful to mak=
e a<br>
&gt; Graph.<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; "ISO C++ Standard - Future Proposals" group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to std-proposals+unsubscribe@isocpp.org.<br>
&gt; To post to this group, send email to std-proposals@isocpp.org.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 target=3D"_parent">http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/</a>.<br>
<br>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe" target=3D"_pare=
nt">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07Q=
M/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.<br>
To post to this group, send email to std-proposals@isocpp.org.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_parent">http://groups.google.com/a/isocpp.org/gr=
oup/std-proposals/</a>.<br>
</div>


</div></div>
</body>
</html>

<p></p>

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

--_DBF442B2-0A49-45ED-BA8B-71067AD2D03F_--

.

------=_Part_3435_5761978.1386019663936
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le lundi 2 d=E9cembre 2013 02:20:57 UTC+1, Billy O'Neal a =E9crit :
>
> The committee already made this decision -- things which do not absolutel=
y=20
> need to be noexcept are *not* marked as such. If it isn't marked that way=
=20
> in the standard, callers can't rely on it.
>

Things are not quite so clear.
1) Recent committee discussions suggest that the policy of not marking=20
weak-guarantee functions as noexcept is likely to be revisited.
2) There is such a thing as Quality of Implementation, and the standard=20
often relies on it. You can't rely on a standard function being implemented=
=20
cleverly, but you can complain to your compiler vendor if it isn't and/or=
=20
consider using a different compiler.

--=20

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

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

<div dir=3D"ltr">Le lundi 2 d=E9cembre 2013 02:20:57 UTC+1, Billy O'Neal a =
=E9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><font face=3D"arial, sans-serif"> The committee already made this decision=
 -- things which do not absolutely need to be noexcept are *not* marked as =
such. If it isn't marked that way in the standard, callers can't rely on it=
..</font></div></blockquote><div><br>Things are not quite so clear.<br>1) Re=
cent committee discussions suggest that the policy of not marking weak-guar=
antee functions as noexcept is likely to be revisited.<br>2) There is such =
a thing as Quality of Implementation, and the standard often relies on it. =
You can't rely on a standard function being implemented cleverly, but you c=
an complain to your compiler vendor if it isn't and/or consider using a dif=
ferent compiler.<br></div></div>

<p></p>

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

------=_Part_3435_5761978.1386019663936--

.

------=_Part_624_12724051.1386024931048
Content-Type: text/plain; charset=ISO-8859-1

On Sunday, 1 December 2013 22:06:58 UTC, Chris Jefferson wrote:
>
> In the past, I have got equal speed to an unchecked push_back by using
> passing a "generating iterator" to 'insert' (basically write a custom
> input iterator which returns a new member of your data whenever
> operator* is called).
>
> This has the advantage of not requiring any unsafe interfaces.
>


This idea was already discussed in this thread. It does have the advantages
of achieving the same speed and not requiring any library modification, but
it has some disadvantages: it's a boilerplate to write, and the average
programmer would not come up with such an unnatural idea mixing iterators
with generators, and instead would simply use the good old malloc.

Concerning the idea that unchecked_push_back is unsafe, it was already
pointed that:
  * vector::operator[] has undefined behaviour when index is out of range
  * iterator invalidation is a much more serious issue, causing
difficult-to-catch bugs
So the behaviour of unchecked_push_back is in line with other vector's
methods. It was also pointed that an assertion can be used to check the
pre-condition of unchecked_push_back in the debug mode.

It looks like initially the speed/safety trade-off for vector was decided
in favour of speed, although some subsequent decisions (like disallowing
realloc-like behaviour in allocators and the inhibition of move semantics
unless the move constructor is noexcept) go in the opposite direction. So
currently vector is neither fast nor safe :-(

--

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

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

<div dir=3D"ltr">On Sunday, 1 December 2013 22:06:58 UTC, Chris Jefferson  =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
 padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;">In the past, I have got equal speed to a=
n unchecked push_back by using
<br>passing a "generating iterator" to 'insert' (basically write a custom
<br>input iterator which returns a new member of your data whenever
<br>operator* is called).
<br>
<br>This has the advantage of not requiring any unsafe interfaces.
<br>
</blockquote><div><br></div><div><br></div><div>This idea was already discu=
ssed in this thread.&nbsp;It does&nbsp;have the advantages of achieving the=
 same speed and not requiring any library modification, but it has some&nbs=
p;disadvantages: it's&nbsp;a boilerplate to write, and the average programm=
er would not come up with&nbsp;such an unnatural&nbsp;idea mixing iterators=
 with generators, and instead would simply use the good old malloc.</div><d=
iv><br></div><div>Concerning the idea that unchecked_push_back is unsafe, i=
t was already pointed that:</div><div>&nbsp; * vector::operator[] has undef=
ined behaviour when index is out of range</div><div>&nbsp; * iterator inval=
idation is a much more serious issue, causing difficult-to-catch bugs</div>=
<div>So the behaviour of unchecked_push_back&nbsp;is in line with other vec=
tor's methods. It was also pointed that an assertion can be used to check t=
he pre-condition of unchecked_push_back in the debug mode.</div><div><br></=
div><div>It looks like&nbsp;initially the speed/safety trade-off for vector=
 was decided in favour of speed, although some subsequent decisions (like d=
isallowing realloc-like behaviour in allocators and the inhibition of move =
semantics unless the move constructor is noexcept) go in the opposite direc=
tion. So currently vector is neither fast nor safe :-(</div></div>

<p></p>

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

------=_Part_624_12724051.1386024931048--

.

--001a11333dc867decb04ec95adfe
Content-Type: text/plain; charset=ISO-8859-1

Vector is plenty fast and safe. Nobody has shown a serious application
where the performance cost of checking size in push_back made any
measurable difference in an overall application in an application compiled
in release mode.

>This idea was already discussed in this thread. It does have the
advantages of achieving the same speed and not requiring any library
modification, but it has some disadvantages: it's a boilerplate to write,
and the average programmer would not come up with such an unnatural idea
mixing iterators with generators, and instead would simply use the good old
malloc.

The average programmer is not writing an application where the size check
inside push_back is significant enough to make a significant difference in
application performance. Vector is designed for the 99.9% case. This
proposed optimization is describing an optimization for a 0.01% case.

>   * vector::operator[] has undefined behaviour when index is out of range
So do arrays, and all other types of indexed memory access.

>   * iterator invalidation is a much more serious issue, causing
difficult-to-catch bugs
As a QoI issue, implementations already catch iterator invalidation
problems in debug mode. All containers have iterator invalidation
conditions / guarantees.

> disallowing realloc-like behaviour in allocators
I am unaware of any such mechanism which would work for arbitrary T. I am
also unaware of an allocator in common use which significantly benefits
from this optimization. If you can show that such an optimization would
be valuable, have you proposed modifications to allocator's interface which
would allow this kind of behavior?

>inhibition of move semantics unless the move constructor is noexcept
It is impossible to do this in an exception-safe way unless the move
constructor is noexcept. This isn't specific to vector -- what behavior
would you expect to happen if during the move from the old memory block to
a new memory block on reallocation, an exception was thrown? The objects
which were already moved can't be moved back to the old memory block
because *that* move could throw an exception. There are objects which have
not yet been moved though, and because the move threw an exception, there's
not a safe way to move them all to the new memory block.
Designs which produce completely invalid internal states in the event of an
exception aren't okay.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Mon, Dec 2, 2013 at 2:55 PM, <Victor.Khomenko@ncl.ac.uk> wrote:

> On Sunday, 1 December 2013 22:06:58 UTC, Chris Jefferson wrote:
>>
>> In the past, I have got equal speed to an unchecked push_back by using
>> passing a "generating iterator" to 'insert' (basically write a custom
>> input iterator which returns a new member of your data whenever
>> operator* is called).
>>
>> This has the advantage of not requiring any unsafe interfaces.
>>
>
>
> This idea was already discussed in this thread. It does have the
> advantages of achieving the same speed and not requiring any library
> modification, but it has some disadvantages: it's a boilerplate to write,
> and the average programmer would not come up with such an unnatural idea
> mixing iterators with generators, and instead would simply use the good old
> malloc.
>
> Concerning the idea that unchecked_push_back is unsafe, it was already
> pointed that:
>   * vector::operator[] has undefined behaviour when index is out of range
>   * iterator invalidation is a much more serious issue, causing
> difficult-to-catch bugs
> So the behaviour of unchecked_push_back is in line with other vector's
> methods. It was also pointed that an assertion can be used to check the
> pre-condition of unchecked_push_back in the debug mode.
>
> It looks like initially the speed/safety trade-off for vector was decided
> in favour of speed, although some subsequent decisions (like disallowing
> realloc-like behaviour in allocators and the inhibition of move semantics
> unless the move constructor is noexcept) go in the opposite direction. So
> currently vector is neither fast nor safe :-(
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--001a11333dc867decb04ec95adfe
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Vector is plenty fast and safe. Nobody has shown a serious=
 application where the performance cost of checking size in push_back made =
any measurable difference in an overall application in an application compi=
led in release mode.<div>

<br></div><div>&gt;<span style=3D"font-family:arial,sans-serif;font-size:13=
px">This idea was already discussed in this thread.=A0It does=A0have the ad=
vantages of achieving the same speed and not requiring any library modifica=
tion, but it has some=A0disadvantages: it&#39;s=A0a boilerplate to write, a=
nd the average programmer would not come up with=A0such an unnatural=A0idea=
 mixing iterators with generators, and instead would simply use the good ol=
d malloc.</span></div>

<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">The average programmer is not writing an application wher=
e the size check inside push_back is significant enough to make a significa=
nt difference in application performance. Vector is designed for the 99.9% =
case. This proposed optimization is describing an optimization for a 0.01% =
case.<br>

</font><div><br></div><div>&gt;=A0<span style=3D"font-family:arial,sans-ser=
if;font-size:13px">=A0 * vector::operator[] has undefined behaviour when in=
dex is out of range</span></div><div><span style=3D"font-family:arial,sans-=
serif;font-size:13px">So do arrays, and all other types of indexed memory a=
ccess.</span></div>

<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">&gt=
;=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13px">=A0 =
* iterator invalidation is a much more serious issue, causing difficult-to-=
catch bugs</span></div>

<div><font face=3D"arial, sans-serif">As a QoI issue, implementations alrea=
dy catch iterator invalidation problems in debug mode. All containers have =
iterator invalidation conditions /=A0guarantees.</font><br><br></div><div>
&gt;=A0<span style=3D"font-family:arial,sans-serif;font-size:13px">disallow=
ing realloc-like behaviour in allocators</span></div>
<div><font face=3D"arial, sans-serif">I am unaware of any such mechanism wh=
ich would work for arbitrary T. I am also unaware of an allocator in common=
 use which significantly benefits from this optimization. If you can show t=
hat such an optimization would be=A0valuable, have you proposed modificatio=
ns to allocator&#39;s interface which would allow=A0this kind of behavior?<=
/font></div>

<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">&gt=
;</span><span style=3D"font-family:arial,sans-serif;font-size:13px">inhibit=
ion of move semantics unless the move constructor is noexcept</span></div>

<div><span style=3D"font-family:arial,sans-serif;font-size:13px">It is impo=
ssible to do this in an exception-safe way unless the move constructor is n=
oexcept. This isn&#39;t specific to vector -- what behavior would you expec=
t to happen if during the move from the old memory block to a new memory bl=
ock on reallocation, an exception was thrown? The objects which were alread=
y moved can&#39;t be moved back to the old memory block because *that* move=
 could throw an exception. There are objects which have not yet been moved =
though, and because the move threw an exception, there&#39;s not a safe way=
 to move them all to the new memory block.</span></div>

<div><span style=3D"font-family:arial,sans-serif;font-size:13px">Designs wh=
ich produce completely invalid internal states in the event of an exception=
 aren&#39;t okay.</span></div></div></div><div class=3D"gmail_extra"><br cl=
ear=3D"all">

<div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bi=
tbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</=
a></div><div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" t=
arget=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Dec 2, 2013 at 2:55 PM,  <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:Victor.Khomenko@ncl.ac.uk" target=3D"_blan=
k">Victor.Khomenko@ncl.ac.uk</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">

<div dir=3D"ltr">On Sunday, 1 December 2013 22:06:58 UTC, Chris Jefferson  =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;p=
adding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bo=
rder-left-style:solid">

In the past, I have got equal speed to an unchecked push_back by using
<br>passing a &quot;generating iterator&quot; to &#39;insert&#39; (basicall=
y write a custom
<br>input iterator which returns a new member of your data whenever
<br>operator* is called).
<br>
<br>This has the advantage of not requiring any unsafe interfaces.
<br>
</blockquote><div><br></div><div><br></div><div>This idea was already discu=
ssed in this thread.=A0It does=A0have the advantages of achieving the same =
speed and not requiring any library modification, but it has some=A0disadva=
ntages: it&#39;s=A0a boilerplate to write, and the average programmer would=
 not come up with=A0such an unnatural=A0idea mixing iterators with generato=
rs, and instead would simply use the good old malloc.</div>

<div><br></div><div>Concerning the idea that unchecked_push_back is unsafe,=
 it was already pointed that:</div><div>=A0 * vector::operator[] has undefi=
ned behaviour when index is out of range</div><div>=A0 * iterator invalidat=
ion is a much more serious issue, causing difficult-to-catch bugs</div>

<div>So the behaviour of unchecked_push_back=A0is in line with other vector=
&#39;s methods. It was also pointed that an assertion can be used to check =
the pre-condition of unchecked_push_back in the debug mode.</div><div><br>

</div><div>It looks like=A0initially the speed/safety trade-off for vector =
was decided in favour of speed, although some subsequent decisions (like di=
sallowing realloc-like behaviour in allocators and the inhibition of move s=
emantics unless the move constructor is noexcept) go in the opposite direct=
ion. So currently vector is neither fast nor safe :-(</div>

</div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--001a11333dc867decb04ec95adfe--

.

--_78667186-AAEB-47C1-93CC-B96D97B17759_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=windows-1252

I think efficiency is more important than robust.


In fact, the best way to deal safe problems is to use iterator-range to lim=
it them.


If we don=92t need efficiency, why we use a computer???????????


C++ is faster than C, okay?????






Sent from Windows Mail





From: Victor.Khomenko@ncl.ac.uk
Sent: Tuesday, December 3, 2013 6:55 AM
To: std-proposals@isocpp.org





On Sunday, 1 December 2013 22:06:58 UTC, Chris Jefferson wrote:
In the past, I have got equal speed to an unchecked push_back by using=20
passing a "generating iterator" to 'insert' (basically write a custom=20
input iterator which returns a new member of your data whenever=20
operator* is called).=20

This has the advantage of not requiring any unsafe interfaces.=20








This idea was already discussed in this thread. It does have the advantages=
 of achieving the same speed and not requiring any library modification, bu=
t it has some disadvantages: it's a boilerplate to write, and the average p=
rogrammer would not come up with such an unnatural idea mixing iterators wi=
th generators, and instead would simply use the good old malloc.




Concerning the idea that unchecked_push_back is unsafe, it was already poin=
ted that:

  * vector::operator[] has undefined behaviour when index is out of range

  * iterator invalidation is a much more serious issue, causing difficult-t=
o-catch bugs

So the behaviour of unchecked_push_back is in line with other vector's meth=
ods. It was also pointed that an assertion can be used to check the pre-con=
dition of unchecked_push_back in the debug mode.




It looks like initially the speed/safety trade-off for vector was decided i=
n favour of speed, although some subsequent decisions (like disallowing rea=
lloc-like behaviour in allocators and the inhibition of move semantics unle=
ss the move constructor is noexcept) go in the opposite direction. So curre=
ntly vector is neither fast nor safe :-(

--=20
=20
---=20
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.or=
g/d/topic/std-proposals/5BnNHEr07QM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--=20

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

--_78667186-AAEB-47C1-93CC-B96D97B17759_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=windows-1252


<html>
<head>
<meta name=3D"generator" content=3D"Windows Mail 17.5.9600.20315">
<style data-externalstyle=3D"true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParag=
raphCxSpFirst,=20
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListPar=
agraphCxSpMiddle,=20
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagra=
phCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style></head>
<body dir=3D"ltr">
<div data-externalstyle=3D"false" dir=3D"ltr" style=3D"font-family: 'Calibr=
i', 'Microsoft YaHei UI', 'Segoe UI', 'Meiryo', 'Microsoft JhengHei UI', 'M=
algun Gothic', 'sans-serif';font-size:12pt;">





<div style=3D"color: rgb(0, 0, 0);">I think efficiency is more important th=
an robust.</div><div style=3D"color: rgb(0, 0, 0);"><br></div><div style=3D=
"color: rgb(0, 0, 0);">In fact, the best&nbsp;way to deal safe problems is =
to use iterator-range to&nbsp;limit them.</div><div style=3D"color: rgb(0, =
0, 0);"><br></div><div style=3D"color: rgb(0, 0, 0);">If we don=92t need ef=
ficiency, why we use a computer???????????</div><div style=3D"color: rgb(0,=
 0, 0);"><br></div><div style=3D"color: rgb(0, 0, 0);">C++ is faster than C=
, okay?????<br></div><div style=3D"color: rgb(0, 0, 0);" data-signaturebloc=
k=3D"true"><div style=3D"color: rgb(0, 0, 0);"><br></div><div style=3D"colo=
r: rgb(0, 0, 0);">Sent from Windows Mail</div><div style=3D"color: rgb(0, 0=
, 0);"><br></div></div><div style=3D"padding-top: 5px; border-top-color: rg=
b(229, 229, 229); border-top-width: 1px; border-top-style: solid;"><div><fo=
nt face=3D" 'Calibri', 'Microsoft YaHei UI', 'Segoe UI', 'Meiryo', 'Microso=
ft JhengHei UI', 'Malgun Gothic', 'sans-serif'" style=3D'line-height: 15pt;=
 letter-spacing: 0.02em; font-family: "Calibri", "Microsoft YaHei UI", "Seg=
oe UI", "Meiryo", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; f=
ont-size: 12pt;'><b>From:</b>&nbsp;<a href=3D"mailto:Victor.Khomenko@ncl.ac=
..uk" target=3D"_parent">Victor.Khomenko@ncl.ac.uk</a><br><b>Sent:</b>&nbsp;=
Tuesday, December 3, 2013 6:55 AM<br><b>To:</b>&nbsp;<a href=3D"mailto:std-=
proposals@isocpp.org" target=3D"_parent">std-proposals@isocpp.org</a></font=
></div></div><div><br></div><div dir=3D""><div dir=3D"ltr">On Sunday, 1 Dec=
ember 2013 22:06:58 UTC, Chris Jefferson  wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-c=
olor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;=
">In the past, I have got equal speed to an unchecked push_back by using
<br>passing a "generating iterator" to 'insert' (basically write a custom
<br>input iterator which returns a new member of your data whenever
<br>operator* is called).
<br>
<br>This has the advantage of not requiring any unsafe interfaces.
<br>
</blockquote><div><br></div><div><br></div><div>This idea was already discu=
ssed in this thread.&nbsp;It does&nbsp;have the advantages of achieving the=
 same speed and not requiring any library modification, but it has some&nbs=
p;disadvantages: it's&nbsp;a boilerplate to write, and the average programm=
er would not come up with&nbsp;such an unnatural&nbsp;idea mixing iterators=
 with generators, and instead would simply use the good old malloc.</div><d=
iv><br></div><div>Concerning the idea that unchecked_push_back is unsafe, i=
t was already pointed that:</div><div>&nbsp; * vector::operator[] has undef=
ined behaviour when index is out of range</div><div>&nbsp; * iterator inval=
idation is a much more serious issue, causing difficult-to-catch bugs</div>=
<div>So the behaviour of unchecked_push_back&nbsp;is in line with other vec=
tor's methods. It was also pointed that an assertion can be used to check t=
he pre-condition of unchecked_push_back in the debug mode.</div><div><br></=
div><div>It looks like&nbsp;initially the speed/safety trade-off for vector=
 was decided in favour of speed, although some subsequent decisions (like d=
isallowing realloc-like behaviour in allocators and the inhibition of move =
semantics unless the move constructor is noexcept) go in the opposite direc=
tion. So currently vector is neither fast nor safe :-(</div></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe" target=3D"_pare=
nt">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07Q=
M/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.<br>
To post to this group, send email to std-proposals@isocpp.org.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_parent">http://groups.google.com/a/isocpp.org/gr=
oup/std-proposals/</a>.<br>
</div>

















</div>
</body>
</html>

<p></p>

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

--_78667186-AAEB-47C1-93CC-B96D97B17759_--

.

--_D5A13824-1BE4-44ED-876D-02E5E98BED92_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=windows-1252

Many low-level programmers don=92t need safe-check, if we need safe-check, =
we should use =93at=94.





Sent from Windows Mail





From: Victor.Khomenko@ncl.ac.uk
Sent: Tuesday, December 3, 2013 6:55 AM
To: std-proposals@isocpp.org





On Sunday, 1 December 2013 22:06:58 UTC, Chris Jefferson wrote:
In the past, I have got equal speed to an unchecked push_back by using=20
passing a "generating iterator" to 'insert' (basically write a custom=20
input iterator which returns a new member of your data whenever=20
operator* is called).=20

This has the advantage of not requiring any unsafe interfaces.=20








This idea was already discussed in this thread. It does have the advantages=
 of achieving the same speed and not requiring any library modification, bu=
t it has some disadvantages: it's a boilerplate to write, and the average p=
rogrammer would not come up with such an unnatural idea mixing iterators wi=
th generators, and instead would simply use the good old malloc.




Concerning the idea that unchecked_push_back is unsafe, it was already poin=
ted that:

  * vector::operator[] has undefined behaviour when index is out of range

  * iterator invalidation is a much more serious issue, causing difficult-t=
o-catch bugs

So the behaviour of unchecked_push_back is in line with other vector's meth=
ods. It was also pointed that an assertion can be used to check the pre-con=
dition of unchecked_push_back in the debug mode.




It looks like initially the speed/safety trade-off for vector was decided i=
n favour of speed, although some subsequent decisions (like disallowing rea=
lloc-like behaviour in allocators and the inhibition of move semantics unle=
ss the move constructor is noexcept) go in the opposite direction. So curre=
ntly vector is neither fast nor safe :-(

--=20
=20
---=20
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.or=
g/d/topic/std-proposals/5BnNHEr07QM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--=20

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

--_D5A13824-1BE4-44ED-876D-02E5E98BED92_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=windows-1252


<html>
<head>
<meta name=3D"generator" content=3D"Windows Mail 17.5.9600.20315">
<style data-externalstyle=3D"true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParag=
raphCxSpFirst,=20
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListPar=
agraphCxSpMiddle,=20
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagra=
phCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style></head>
<body dir=3D"ltr">
<div data-externalstyle=3D"false" dir=3D"ltr" style=3D"font-family: 'Calibr=
i', 'Microsoft YaHei UI', 'Segoe UI', 'Meiryo', 'Microsoft JhengHei UI', 'M=
algun Gothic', 'sans-serif';font-size:12pt;"><div style=3D"color: rgb(0, 0,=
 0);">Many low-level programmers&nbsp;don=92t need safe-check, if we need s=
afe-check, we should use&nbsp;=93at=94.</div><div style=3D"color: rgb(0, 0,=
 0);" data-signatureblock=3D"true"><div style=3D"color: rgb(0, 0, 0);"><br>=
</div><div style=3D"color: rgb(0, 0, 0);">Sent from Windows Mail</div><div =
style=3D"color: rgb(0, 0, 0);"><br></div></div><div style=3D"padding-top: 5=
px; border-top-color: rgb(229, 229, 229); border-top-width: 1px; border-top=
-style: solid;"><div><font face=3D" 'Calibri', 'Microsoft YaHei UI', 'Segoe=
 UI', 'Meiryo', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif'" sty=
le=3D'line-height: 15pt; letter-spacing: 0.02em; font-family: "Calibri", "M=
icrosoft YaHei UI", "Segoe UI", "Meiryo", "Microsoft JhengHei UI", "Malgun =
Gothic", "sans-serif"; font-size: 12pt;'><b>From:</b>&nbsp;<a href=3D"mailt=
o:Victor.Khomenko@ncl.ac.uk" target=3D"_parent">Victor.Khomenko@ncl.ac.uk</=
a><br><b>Sent:</b>&nbsp;Tuesday, December 3, 2013 6:55 AM<br><b>To:</b>&nbs=
p;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_parent">std-propos=
als@isocpp.org</a></font></div></div><div><br></div><div dir=3D""><div dir=
=3D"ltr">On Sunday, 1 December 2013 22:06:58 UTC, Chris Jefferson  wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding=
-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; =
border-left-style: solid;">In the past, I have got equal speed to an unchec=
ked push_back by using
<br>passing a "generating iterator" to 'insert' (basically write a custom
<br>input iterator which returns a new member of your data whenever
<br>operator* is called).
<br>
<br>This has the advantage of not requiring any unsafe interfaces.
<br>
</blockquote><div><br></div><div><br></div><div>This idea was already discu=
ssed in this thread.&nbsp;It does&nbsp;have the advantages of achieving the=
 same speed and not requiring any library modification, but it has some&nbs=
p;disadvantages: it's&nbsp;a boilerplate to write, and the average programm=
er would not come up with&nbsp;such an unnatural&nbsp;idea mixing iterators=
 with generators, and instead would simply use the good old malloc.</div><d=
iv><br></div><div>Concerning the idea that unchecked_push_back is unsafe, i=
t was already pointed that:</div><div>&nbsp; * vector::operator[] has undef=
ined behaviour when index is out of range</div><div>&nbsp; * iterator inval=
idation is a much more serious issue, causing difficult-to-catch bugs</div>=
<div>So the behaviour of unchecked_push_back&nbsp;is in line with other vec=
tor's methods. It was also pointed that an assertion can be used to check t=
he pre-condition of unchecked_push_back in the debug mode.</div><div><br></=
div><div>It looks like&nbsp;initially the speed/safety trade-off for vector=
 was decided in favour of speed, although some subsequent decisions (like d=
isallowing realloc-like behaviour in allocators and the inhibition of move =
semantics unless the move constructor is noexcept) go in the opposite direc=
tion. So currently vector is neither fast nor safe :-(</div></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe" target=3D"_pare=
nt">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07Q=
M/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.<br>
To post to this group, send email to std-proposals@isocpp.org.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_parent">http://groups.google.com/a/isocpp.org/gr=
oup/std-proposals/</a>.<br>
</div></div>
</body>
</html>

<p></p>

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

--_D5A13824-1BE4-44ED-876D-02E5E98BED92_--

.

--_385B8022-F1CE-4F3D-B775-326857A482B5_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=windows-1252


I hate programmers who likes to talk about =93robust=94.

Often, the programs of them are not robust at all!!!!


Safe-check may cause more unsafe problems and more bugs.


A good program-habit is more important than safe-check!
It can avoid most of safe-problems to develop a good program-habit !!




"Playing=94 Containers, iterators, algorithms needs a feeling.
After I use the thinking of =93iterator-range=94, I can hardly get exceptio=
ns of out-of-range.


This is the feeling a C++ programmer needs, do you understand?


In fact, adding these operations may make C++ programs more safe.

Some programmers who want to use unsafe operations may use dynamic memory, =
and manage pointers by themselves, it=92s more unsafe!!


PS: The people who can't understand me must not read through =93C++ primer =
4 or 5=94.




Sent from Windows Mail





From: Victor.Khomenko@ncl.ac.uk
Sent: Tuesday, December 3, 2013 6:55 AM
To: std-proposals@isocpp.org





On Sunday, 1 December 2013 22:06:58 UTC, Chris Jefferson wrote:
In the past, I have got equal speed to an unchecked push_back by using=20
passing a "generating iterator" to 'insert' (basically write a custom=20
input iterator which returns a new member of your data whenever=20
operator* is called).=20

This has the advantage of not requiring any unsafe interfaces.=20








This idea was already discussed in this thread. It does have the advantages=
 of achieving the same speed and not requiring any library modification, bu=
t it has some disadvantages: it's a boilerplate to write, and the average p=
rogrammer would not come up with such an unnatural idea mixing iterators wi=
th generators, and instead would simply use the good old malloc.




Concerning the idea that unchecked_push_back is unsafe, it was already poin=
ted that:

  * vector::operator[] has undefined behaviour when index is out of range

  * iterator invalidation is a much more serious issue, causing difficult-t=
o-catch bugs

So the behaviour of unchecked_push_back is in line with other vector's meth=
ods. It was also pointed that an assertion can be used to check the pre-con=
dition of unchecked_push_back in the debug mode.




It looks like initially the speed/safety trade-off for vector was decided i=
n favour of speed, although some subsequent decisions (like disallowing rea=
lloc-like behaviour in allocators and the inhibition of move semantics unle=
ss the move constructor is noexcept) go in the opposite direction. So curre=
ntly vector is neither fast nor safe :-(

--=20
=20
---=20
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.or=
g/d/topic/std-proposals/5BnNHEr07QM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--=20

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

--_385B8022-F1CE-4F3D-B775-326857A482B5_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=windows-1252


<html>
<head>
<meta name=3D"generator" content=3D"Windows Mail 17.5.9600.20315">
<style data-externalstyle=3D"true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParag=
raphCxSpFirst,=20
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListPar=
agraphCxSpMiddle,=20
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagra=
phCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style></head>
<body dir=3D"ltr">
<div data-externalstyle=3D"false" dir=3D"ltr" style=3D"font-family: 'Calibr=
i', 'Microsoft YaHei UI', 'Segoe UI', 'Meiryo', 'Microsoft JhengHei UI', 'M=
algun Gothic', 'sans-serif';font-size:12pt;"><div style=3D"color: rgb(0, 0,=
 0);" data-signatureblock=3D"true"><div style=3D"color: rgb(0, 0, 0);">I ha=
te programmers&nbsp;who likes to talk about&nbsp;=93robust=94.</div><div st=
yle=3D"color: rgb(0, 0, 0);">Often, the&nbsp;programs of them&nbsp;are not =
robust at all!!!!</div><div style=3D"color: rgb(0, 0, 0);"><br></div><div s=
tyle=3D"color: rgb(0, 0, 0);">Safe-check may cause more unsafe&nbsp;problem=
s and more bugs.</div></div><div style=3D"color: rgb(0, 0, 0);" data-signat=
ureblock=3D"true"><br></div><div style=3D"color: rgb(0, 0, 0);" data-signat=
ureblock=3D"true">A&nbsp;good program-habit is more important than&nbsp;saf=
e-check!<div style=3D"color: rgb(0, 0, 0);">It can avoid most of&nbsp;safe-=
problems&nbsp;to develop a good program-habit !!</div><div style=3D"color: =
rgb(0, 0, 0);"><div style=3D"color: rgb(0, 0, 0);"><div style=3D"color: rgb=
(0, 0, 0);"><br></div>"Playing=94 Containers, iterators, algorithms needs a=
 feeling.</div><div style=3D"color: rgb(0, 0, 0);">After I use the&nbsp;thi=
nking of&nbsp;=93iterator-range=94, I can hardly&nbsp;get exceptions of&nbs=
p;out-of-range.</div><div style=3D"color: rgb(0, 0, 0);"><br></div></div><d=
iv style=3D"color: rgb(0, 0, 0);">This is the feeling a C++ programmer need=
s, do you understand?</div><div style=3D"color: rgb(0, 0, 0);"><br></div><d=
iv style=3D"color: rgb(0, 0, 0);">In fact, adding these operations may&nbsp=
;make C++ programs more safe.</div><div style=3D"color: rgb(0, 0, 0);">Some=
 programmers who want to use unsafe operations may use dynamic memory, and =
manage pointers by themselves, it=92s more unsafe!!</div><div style=3D"colo=
r: rgb(0, 0, 0);"><br></div><div style=3D"color: rgb(0, 0, 0);">PS: The peo=
ple who can't understand me must not read through&nbsp;=93C++ primer 4 or 5=
=94.</div><div style=3D"color: rgb(0, 0, 0);"><br></div><div style=3D"color=
: rgb(0, 0, 0);">Sent from Windows Mail</div><div style=3D"color: rgb(0, 0,=
 0);"><br></div></div><div style=3D"padding-top: 5px; border-top-color: rgb=
(229, 229, 229); border-top-width: 1px; border-top-style: solid;"><div><fon=
t face=3D" 'Calibri', 'Microsoft YaHei UI', 'Segoe UI', 'Meiryo', 'Microsof=
t JhengHei UI', 'Malgun Gothic', 'sans-serif'" style=3D'line-height: 15pt; =
letter-spacing: 0.02em; font-family: "Calibri", "Microsoft YaHei UI", "Sego=
e UI", "Meiryo", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; fo=
nt-size: 12pt;'><b>From:</b>&nbsp;<a href=3D"mailto:Victor.Khomenko@ncl.ac.=
uk" target=3D"_parent">Victor.Khomenko@ncl.ac.uk</a><br><b>Sent:</b>&nbsp;T=
uesday, December 3, 2013 6:55 AM<br><b>To:</b>&nbsp;<a href=3D"mailto:std-p=
roposals@isocpp.org" target=3D"_parent">std-proposals@isocpp.org</a></font>=
</div></div><div><br></div><div dir=3D""><div dir=3D"ltr">On Sunday, 1 Dece=
mber 2013 22:06:58 UTC, Chris Jefferson  wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-co=
lor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"=
>In the past, I have got equal speed to an unchecked push_back by using
<br>passing a "generating iterator" to 'insert' (basically write a custom
<br>input iterator which returns a new member of your data whenever
<br>operator* is called).
<br>
<br>This has the advantage of not requiring any unsafe interfaces.
<br>
</blockquote><div><br></div><div><br></div><div>This idea was already discu=
ssed in this thread.&nbsp;It does&nbsp;have the advantages of achieving the=
 same speed and not requiring any library modification, but it has some&nbs=
p;disadvantages: it's&nbsp;a boilerplate to write, and the average programm=
er would not come up with&nbsp;such an unnatural&nbsp;idea mixing iterators=
 with generators, and instead would simply use the good old malloc.</div><d=
iv><br></div><div>Concerning the idea that unchecked_push_back is unsafe, i=
t was already pointed that:</div><div>&nbsp; * vector::operator[] has undef=
ined behaviour when index is out of range</div><div>&nbsp; * iterator inval=
idation is a much more serious issue, causing difficult-to-catch bugs</div>=
<div>So the behaviour of unchecked_push_back&nbsp;is in line with other vec=
tor's methods. It was also pointed that an assertion can be used to check t=
he pre-condition of unchecked_push_back in the debug mode.</div><div><br></=
div><div>It looks like&nbsp;initially the speed/safety trade-off for vector=
 was decided in favour of speed, although some subsequent decisions (like d=
isallowing realloc-like behaviour in allocators and the inhibition of move =
semantics unless the move constructor is noexcept) go in the opposite direc=
tion. So currently vector is neither fast nor safe :-(</div></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe" target=3D"_pare=
nt">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07Q=
M/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.<br>
To post to this group, send email to std-proposals@isocpp.org.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_parent">http://groups.google.com/a/isocpp.org/gr=
oup/std-proposals/</a>.<br>
</div></div>
</body>
</html>

<p></p>

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

--_385B8022-F1CE-4F3D-B775-326857A482B5_--

.

------=_Part_177_6808522.1386065006306
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I agree that efficiency is more important than robust. That's why I wrote=
=20
the most efficient program possible: https://gist.github.com/5363882.

On Tuesday, December 3, 2013 4:29:14 AM UTC+1, wsdwsd wrote:
>
>  I think efficiency is more important than robust.
>
> In fact, the best way to deal safe problems is to use iterator-range=20
> to limit them.
>
> If we don=92t need efficiency, why we use a computer???????????
>
> C++ is faster than C, okay?????
>
> Sent from Windows Mail
>
> *From:* Victor....@ncl.ac.uk <javascript:>
> *Sent:* Tuesday, December 3, 2013 6:55 AM
> *To:* std-pr...@isocpp.org <javascript:>
>
> On Sunday, 1 December 2013 22:06:58 UTC, Chris Jefferson wrote:
>>
>> In the past, I have got equal speed to an unchecked push_back by using=
=20
>> passing a "generating iterator" to 'insert' (basically write a custom=20
>> input iterator which returns a new member of your data whenever=20
>> operator* is called).=20
>>
>> This has the advantage of not requiring any unsafe interfaces.=20
>>
>
>
> This idea was already discussed in this thread. It does have the=20
> advantages of achieving the same speed and not requiring any library=20
> modification, but it has some disadvantages: it's a boilerplate to write,=
=20
> and the average programmer would not come up with such an unnatural idea=
=20
> mixing iterators with generators, and instead would simply use the good o=
ld=20
> malloc.
>
> Concerning the idea that unchecked_push_back is unsafe, it was already=20
> pointed that:
>   * vector::operator[] has undefined behaviour when index is out of range
>   * iterator invalidation is a much more serious issue, causing=20
> difficult-to-catch bugs
> So the behaviour of unchecked_push_back is in line with other vector's=20
> methods. It was also pointed that an assertion can be used to check the=
=20
> pre-condition of unchecked_push_back in the debug mode.
>
> It looks like initially the speed/safety trade-off for vector was decided=
=20
> in favour of speed, although some subsequent decisions (like disallowing=
=20
> realloc-like behaviour in allocators and the inhibition of move semantics=
=20
> unless the move constructor is noexcept) go in the opposite direction. So=
=20
> currently vector is neither fast nor safe :-(
>
> --=20
> =20
> ---=20
> You received this message because you are subscribed to a topic in the=20
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit=20
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to=20
> std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>  =20

--=20

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

------=_Part_177_6808522.1386065006306
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I agree that efficiency is more important than robust. Tha=
t's why I wrote the most efficient program possible: https://gist.github.co=
m/5363882.<br><br>On Tuesday, December 3, 2013 4:29:14 AM UTC+1, wsdwsd wro=
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 dir=3D"ltr" style=3D"font-family:'Calibri','Microsoft YaHei UI','Segoe=
 UI','Meiryo','Microsoft JhengHei UI','Malgun Gothic','sans-serif';font-siz=
e:12pt">





<div style=3D"color:rgb(0,0,0)">I think efficiency is more important than r=
obust.</div><div style=3D"color:rgb(0,0,0)"><br></div><div style=3D"color:r=
gb(0,0,0)">In fact, the best&nbsp;way to deal safe problems is to use itera=
tor-range to&nbsp;limit them.</div><div style=3D"color:rgb(0,0,0)"><br></di=
v><div style=3D"color:rgb(0,0,0)">If we don=92t need efficiency, why we use=
 a computer???????????</div><div style=3D"color:rgb(0,0,0)"><br></div><div =
style=3D"color:rgb(0,0,0)">C++ is faster than C, okay?????<br></div><div st=
yle=3D"color:rgb(0,0,0)"><div style=3D"color:rgb(0,0,0)"><br></div><div sty=
le=3D"color:rgb(0,0,0)">Sent from Windows Mail</div><div style=3D"color:rgb=
(0,0,0)"><br></div></div><div style=3D"padding-top:5px;border-top-color:rgb=
(229,229,229);border-top-width:1px;border-top-style:solid"><div><font style=
=3D"line-height:15pt;letter-spacing:0.02em;font-family:&quot;Calibri&quot;,=
&quot;Microsoft YaHei UI&quot;,&quot;Segoe UI&quot;,&quot;Meiryo&quot;,&quo=
t;Microsoft JhengHei UI&quot;,&quot;Malgun Gothic&quot;,&quot;sans-serif&qu=
ot;;font-size:12pt" face=3D" 'Calibri', 'Microsoft YaHei UI', 'Segoe UI', '=
Meiryo', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif'"><b>From:</=
b>&nbsp;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
sN5kGYrxe_AJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">Victor....@ncl.ac.<wbr>uk</a><=
br><b>Sent:</b>&nbsp;Tuesday, December 3, 2013 6:55 AM<br><b>To:</b>&nbsp;<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"sN5kGYrxe=
_AJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">std-pr...@isocpp.org</a></font></div></=
div><div><br></div><div dir=3D""><div dir=3D"ltr">On Sunday, 1 December 201=
3 22:06:58 UTC, Chris Jefferson  wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,=
204,204);border-left-width:1px;border-left-style:solid">In the past, I have=
 got equal speed to an unchecked push_back by using
<br>passing a "generating iterator" to 'insert' (basically write a custom
<br>input iterator which returns a new member of your data whenever
<br>operator* is called).
<br>
<br>This has the advantage of not requiring any unsafe interfaces.
<br>
</blockquote><div><br></div><div><br></div><div>This idea was already discu=
ssed in this thread.&nbsp;It does&nbsp;have the advantages of achieving the=
 same speed and not requiring any library modification, but it has some&nbs=
p;disadvantages: it's&nbsp;a boilerplate to write, and the average programm=
er would not come up with&nbsp;such an unnatural&nbsp;idea mixing iterators=
 with generators, and instead would simply use the good old malloc.</div><d=
iv><br></div><div>Concerning the idea that unchecked_push_back is unsafe, i=
t was already pointed that:</div><div>&nbsp; * vector::operator[] has undef=
ined behaviour when index is out of range</div><div>&nbsp; * iterator inval=
idation is a much more serious issue, causing difficult-to-catch bugs</div>=
<div>So the behaviour of unchecked_push_back&nbsp;is in line with other vec=
tor's methods. It was also pointed that an assertion can be used to check t=
he pre-condition of unchecked_push_back in the debug mode.</div><div><br></=
div><div>It looks like&nbsp;initially the speed/safety trade-off for vector=
 was decided in favour of speed, although some subsequent decisions (like d=
isallowing realloc-like behaviour in allocators and the inhibition of move =
semantics unless the move constructor is noexcept) go in the opposite direc=
tion. So currently vector is neither fast nor safe :-(</div></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe" target=3D"_blan=
k" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/top=
ic/std-proposals/5BnNHEr07QM/unsubscribe';return true;" onclick=3D"this.hre=
f=3D'https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07=
QM/unsubscribe';return true;">https://groups.google.com/a/<wbr>isocpp.org/d=
/topic/std-<wbr>proposals/5BnNHEr07QM/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"sN5kGYrxe_AJ" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"sN5kGYrxe_AJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div>

















</div>
</div>

</blockquote></div>

<p></p>

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

------=_Part_177_6808522.1386065006306--

.

------=_Part_883_18618192.1386104294107
Content-Type: text/plain; charset=ISO-8859-1

On Monday, 2 December 2013 23:37:50 UTC, Billy O'Neal wrote:
>
> Vector is plenty fast and safe. Nobody has shown a serious application
> where the performance cost of checking size in push_back made any
> measurable difference in an overall application in an application compiled
> in release mode.
>


You are making a sweeping generalization here. I had a significant
performance deterioration due to this issue, like 10% for the whole
program, when I moved from my home-brewed vector-like class to vector. More
precisely, the innermost loop was a call to std::transform with
std::back_inserter(vector) as the output range. And it was serious enough
for me (of course, you're free to choose which applications you consider
"serious"). I believe that push_back in an innermost loop is quite common,
although I don't have any statistics to back it up. Another common case
where vector is VERY slow (for a different reason) is given at the end.



> The average programmer is not writing an application where the size check
> inside push_back is significant enough to make a significant difference in
> application performance. Vector is designed for the 99.9% case. This
> proposed optimization is describing an optimization for a 0.01% case.
>
>
Confess, you just faked these numbers (they don't even add up to 100% ;-).



> >   * vector::operator[] has undefined behaviour when index is out of
> range
> So do arrays, and all other types of indexed memory access.
>
>
That was precisely my point: unchecked_push_back would correspond to the
*p++=... idiom, and its safety guarantee is in line with the other methods
of vector. In fact, reserve+unchecked_push_back form a very natural
interface for vector.

>   * iterator invalidation is a much more serious issue, causing
> difficult-to-catch bugs
> As a QoI issue, implementations already catch iterator invalidation
> problems in debug mode. All containers have iterator invalidation
> conditions / guarantees.
>

I know, such checks are implemented by the vector maintaining the
collection of all the valid iterators that it had issued, which makes the
debug version rather slow. Checking the correct use of unchecked_push_back
is a single assertion. In any case, my point was that safety is not an
issue here.



> > disallowing realloc-like behaviour in allocators
> I am unaware of any such mechanism which would work for arbitrary T.
>

What's the problem? If the block can be extended in-place, just go for it,
no need to copy or move elements. Otherwise, just fall back to the usual
allocation. BTW, by "realloc-like" I didn't mean that realloc is called,
but rather something like _expand:
http://msdn.microsoft.com/en-us/library/wfzt8b7y.aspx

I am also unaware of an allocator in common use which significantly
> benefits from this optimization. If you can show that such an optimization
> would be valuable, have you proposed modifications to allocator's interface
> which would allow this kind of behavior?
>

This was discussed earlier in this thread - somebody mentioned 2X speedups,
apparently there was a proposal, but the Committee decided against it. So
Important People Up There are aware of the issue, and I don't feel like
interfering (I know next to nothing about allocators anyway - in fact I
assumed the default allocator did have realloc-like behaviour, and was
unpleasantly surprised by that post).

>inhibition of move semantics unless the move constructor is noexcept
> It is impossible to do this in an exception-safe way unless the move
> constructor is noexcept. This isn't specific to vector -- what behavior
> would you expect to happen if during the move from the old memory block to
> a new memory block on reallocation, an exception was thrown? The objects
> which were already moved can't be moved back to the old memory block
> because *that* move could throw an exception. There are objects which have
> not yet been moved though, and because the move threw an exception, there's
> not a safe way to move them all to the new memory block.
> Designs which produce completely invalid internal states in the event of
> an exception aren't okay.
>
>
You seem to be confused here: it is impossible only if one needs the strong
guarantee. However, if one is content with the basic guarantee, it is quite
possible, and will yield a valid (but unspecified) state, contrary to your
last sentence.

The Committee decided on this strategy to avoid breaking code in situations
where a throwing move constructor is automatically generated, but the code
depended on strong guarantee. I can understand this, but notwithstanding,
the fact is that this does make vector very slow in some common examples,
in particular, since vector's own move constructor is not noexcept,
vector<vector<T>> is VERY slow, as vector<list<T>>, vector<deque<T>>,...
are.

--

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

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

<div dir=3D"ltr">On Monday, 2 December 2013 23:37:50 UTC, Billy O'Neal  wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pa=
dding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: =
1px; border-left-style: solid;"><div dir=3D"ltr">Vector is plenty fast and =
safe. Nobody has shown a serious application where the performance cost of =
checking size in push_back made any measurable difference in an overall app=
lication in an application compiled in release mode.<br></div></blockquote>=
<div><br></div><div><br></div><div>You are making a sweeping&nbsp;generaliz=
ation here. I had a significant performance deterioration due to this issue=
, like 10% for the whole program, when I moved from my home-brewed vector-l=
ike class to vector. More precisely, the innermost loop was&nbsp;a call to =
std::transform with std::back_inserter(vector) as the output range. And it =
was serious enough for me (of course, you're free to choose which applicati=
ons you consider "serious"). I believe that push_back in an innermost loop =
is quite&nbsp;common, although I don't have any statistics to back it up.&n=
bsp;Another&nbsp;common case where vector is VERY slow (for a different rea=
son)&nbsp;is given at the end.</div><div><br></div><div>&nbsp;</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;"><div dir=3D"ltr"><div></div><div><font face=3D"arial,=
 sans-serif">The average programmer is not writing an application where the=
 size check inside push_back is significant enough to make a significant di=
fference in application performance. Vector is designed for the 99.9% case.=
 This proposed optimization is describing an optimization for a 0.01% case.=
<br>

</font><div><br></div></div></div></blockquote><div><br></div><div>Confess,=
 you&nbsp;just faked these numbers (they don't even add up to 100% ;-).</di=
v><div><br></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><div><div></div><div>&gt;&nbsp;<span style=3D"font-family: arial,s=
ans-serif; font-size: 13px;">&nbsp; * vector::operator[] has undefined beha=
viour when index is out of range</span></div><div><span style=3D"font-famil=
y: arial,sans-serif; font-size: 13px;">So do arrays, and all other types of=
 indexed memory access.</span></div>

<div><span style=3D"font-family: arial,sans-serif; font-size: 13px;"><br></=
span></div></div></div></blockquote><div><br></div><div>That was precisely =
my point: unchecked_push_back would correspond to the *p++=3D... idiom, and=
 its safety guarantee is in line with the other methods of vector. In fact,=
 reserve+unchecked_push_back form a very natural interface for vector.</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div><sp=
an style=3D"font-family: arial,sans-serif; font-size: 13px;"></span></div><=
div><span style=3D"font-family: arial,sans-serif; font-size: 13px;">&gt;&nb=
sp;</span><span style=3D"font-family: arial,sans-serif; font-size: 13px;">&=
nbsp; * iterator invalidation is a much more serious issue, causing difficu=
lt-to-catch bugs</span></div>

<div><font face=3D"arial, sans-serif">As a QoI issue, implementations alrea=
dy catch iterator invalidation problems in debug mode. All containers have =
iterator invalidation conditions /&nbsp;guarantees.</font></div></div></div=
></blockquote><div><br></div><div>I know, such checks are implemented by th=
e vector&nbsp;maintaining the collection of all the valid&nbsp;iterators th=
at it had issued, which makes the debug version rather slow. Checking the c=
orrect use of unchecked_push_back is a single assertion. In any case, my po=
int was that safety is not an issue here.</div><div><br></div><div>&nbsp;<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8e=
x; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wi=
dth: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div>
&gt;&nbsp;<span style=3D"font-family: arial,sans-serif; font-size: 13px;">d=
isallowing realloc-like behaviour in allocators</span></div>
<div><font face=3D"arial, sans-serif">I am unaware of any such mechanism wh=
ich would work for arbitrary T. </font></div></div></div></blockquote><div>=
<br></div><div>What's the problem? If the block can be extended in-place, j=
ust go for it, no need to copy or move elements. Otherwise, just fall back =
to the usual allocation. BTW, by "realloc-like" I didn't mean that realloc =
is called, but rather something like _expand: <a href=3D"http://msdn.micros=
oft.com/en-us/library/wfzt8b7y.aspx">http://msdn.microsoft.com/en-us/librar=
y/wfzt8b7y.aspx</a></div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div d=
ir=3D"ltr"><div><div><font face=3D"arial, sans-serif">I am also unaware of =
an allocator in common use which significantly benefits from this optimizat=
ion. If you can show that such an optimization would be&nbsp;valuable, have=
 you proposed modifications to allocator's interface which would allow&nbsp=
;this kind of behavior?</font><span style=3D"font-family: arial,sans-serif;=
 font-size: 13px;"><br></span></div></div></div></blockquote><div><br></div=
><div>This was discussed earlier in this thread - somebody mentioned 2X spe=
edups, apparently there was a proposal, but the Committee decided against i=
t. So Important People Up There are aware of the issue, and I don't feel li=
ke interfering (I know next to nothing about allocators anyway - in fact I =
assumed the default allocator did have realloc-like&nbsp;behaviour, and was=
 unpleasantly surprised by that post).</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bo=
rder-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-st=
yle: solid;"><div dir=3D"ltr"><div><div><span style=3D"font-family: arial,s=
ans-serif; font-size: 13px;"></span></div><div><span style=3D"font-family: =
arial,sans-serif; font-size: 13px;">&gt;</span><span style=3D"font-family: =
arial,sans-serif; font-size: 13px;">inhibition of move semantics unless the=
 move constructor is noexcept</span></div>

<div><span style=3D"font-family: arial,sans-serif; font-size: 13px;">It is =
impossible to do this in an exception-safe way unless the move constructor =
is noexcept. This isn't specific to vector -- what behavior would you expec=
t to happen if during the move from the old memory block to a new memory bl=
ock on reallocation, an exception was thrown? The objects which were alread=
y moved can't be moved back to the old memory block because *that* move cou=
ld throw an exception. There are objects which have not yet been moved thou=
gh, and because the move threw an exception, there's not a safe way to move=
 them all to the new memory block.</span></div>

<div><span style=3D"font-family: arial,sans-serif; font-size: 13px;">Design=
s which produce completely invalid internal states in the event of an excep=
tion aren't okay.</span><br clear=3D"all">
<br></div></div></div></blockquote><div><br></div><div>You seem to be confu=
sed here: it is impossible only if one needs the strong guarantee. However,=
 if one is content with&nbsp;the basic guarantee, it is quite possible, and=
 will yield a valid (but unspecified) state, contrary to your last sentence=
.. </div><div><br></div><div>The Committee decided on this strategy to avoid=
 breaking code in situations where a throwing move constructor is automatic=
ally generated, but the code depended on strong guarantee. I can understand=
 this, but notwithstanding, the fact is that this does make vector very slo=
w in some common examples, in particular, since vector's own move construct=
or is not noexcept, vector&lt;vector&lt;T&gt;&gt; is VERY slow, as vector&l=
t;list&lt;T&gt;&gt;, vector&lt;deque&lt;T&gt;&gt;,... are.</div></div>

<p></p>

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

------=_Part_883_18618192.1386104294107--

.

On Tue, Dec 3, 2013 at 12:58 PM,  <Victor.Khomenko@ncl.ac.uk> wrote:
> On Monday, 2 December 2013 23:37:50 UTC, Billy O'Neal wrote:
>>
>> Vector is plenty fast and safe. Nobody has shown a serious application
>> where the performance cost of checking size in push_back made any measurable
>> difference in an overall application in an application compiled in release
>> mode.
>
>
>
> You are making a sweeping generalization here. I had a significant
> performance deterioration due to this issue, like 10% for the whole program,
> when I moved from my home-brewed vector-like class to vector. More
> precisely, the innermost loop was a call to std::transform with
> std::back_inserter(vector) as the output range. And it was serious enough
> for me (of course, you're free to choose which applications you consider
> "serious"). I believe that push_back in an innermost loop is quite common,
> although I don't have any statistics to back it up. Another common case
> where vector is VERY slow (for a different reason) is given at the end.
>
>
>>
>> The average programmer is not writing an application where the size check
>> inside push_back is significant enough to make a significant difference in
>> application performance. Vector is designed for the 99.9% case. This
>> proposed optimization is describing an optimization for a 0.01% case.
>>
>
> Confess, you just faked these numbers (they don't even add up to 100% ;-).
>
>
>>
>> >   * vector::operator[] has undefined behaviour when index is out of
>> > range
>> So do arrays, and all other types of indexed memory access.
>>
>
> That was precisely my point: unchecked_push_back would correspond to the
> *p++=... idiom, and its safety guarantee is in line with the other methods
> of vector. In fact, reserve+unchecked_push_back form a very natural
> interface for vector.

Is there any obvious reason that reserve + unchecked_push_back is
better than resize_uninitialized + push_back (+ resize if needed)?
That is, how common is this issue with vectors of nontrivial types?

--Andy

--

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

.

--_623d5ad7-721c-491b-9753-a628ee04f1f2_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1

Who said unsafe operations are only used for 0.01% conditions? It's a big p=
rejudice!
Many programs must cater for c-style interfaces. No unsafe_resize, we can h=
ardly use a vector to do it.
After we add unsafe_emplace_back, many programs will use it to replace empl=
ace_back. In fact, if A programmer use a emplace_back, he sometimes can't c=
heck wrong answers easily. For example, what he needs to add are 10 element=
s, but in fact, he adds 11 elements. He can't check the wrong easily. If he=
 uses unsafe operations, when the answer is wrong, the program will crash o=
r run a strange answer. This will tell programs you may wrong.
Just as vectors can't replace arrays, so we made std::array. std::arrays ar=
e more unsafe than vectors.


Sent from my Windows Phone
________________________________
From: Andrew Lutomirski<mailto:andy@luto.us>
Sent: 2013/12/4 5:54
To: std-proposals@isocpp.org<mailto:std-proposals@isocpp.org>
Subject: Re: [std-proposals] Re: proposal to add vector::push_back_()

On Tue, Dec 3, 2013 at 12:58 PM,  <Victor.Khomenko@ncl.ac.uk> wrote:
> On Monday, 2 December 2013 23:37:50 UTC, Billy O'Neal wrote:
>>
>> Vector is plenty fast and safe. Nobody has shown a serious application
>> where the performance cost of checking size in push_back made any measur=
able
>> difference in an overall application in an application compiled in relea=
se
>> mode.
>
>
>
> You are making a sweeping generalization here. I had a significant
> performance deterioration due to this issue, like 10% for the whole progr=
am,
> when I moved from my home-brewed vector-like class to vector. More
> precisely, the innermost loop was a call to std::transform with
> std::back_inserter(vector) as the output range. And it was serious enough
> for me (of course, you're free to choose which applications you consider
> "serious"). I believe that push_back in an innermost loop is quite common=
,
> although I don't have any statistics to back it up. Another common case
> where vector is VERY slow (for a different reason) is given at the end.
>
>
>>
>> The average programmer is not writing an application where the size chec=
k
>> inside push_back is significant enough to make a significant difference =
in
>> application performance. Vector is designed for the 99.9% case. This
>> proposed optimization is describing an optimization for a 0.01% case.
>>
>
> Confess, you just faked these numbers (they don't even add up to 100% ;-)=
..
>
>
>>
>> >   * vector::operator[] has undefined behaviour when index is out of
>> > range
>> So do arrays, and all other types of indexed memory access.
>>
>
> That was precisely my point: unchecked_push_back would correspond to the
> *p++=3D... idiom, and its safety guarantee is in line with the other meth=
ods
> of vector. In fact, reserve+unchecked_push_back form a very natural
> interface for vector.

Is there any obvious reason that reserve + unchecked_push_back is
better than resize_uninitialized + push_back (+ resize if needed)?
That is, how common is this issue with vectors of nontrivial types?

--Andy

--

---
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.or=
g/d/topic/std-proposals/5BnNHEr07QM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--=20

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

--_623d5ad7-721c-491b-9753-a628ee04f1f2_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
</head>
<body>
<div>
<div style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">Who said un=
safe operations are only used for 0.01% conditions? It's a big prejudice!<b=
r>
Many programs must cater for c-style interfaces. No unsafe_resize, we can h=
ardly use a vector to do it.
<br>
After we add unsafe_emplace_back, many programs will use it to replace empl=
ace_back. In fact, if A programmer use a emplace_back, he sometimes can't c=
heck wrong answers easily. For example, what he needs to add are 10 element=
s, but in fact, he adds 11 elements.
 He can't check the wrong easily. If he uses unsafe operations, when the an=
swer is wrong, the program will crash or run a strange answer. This will te=
ll programs you may wrong.
<br>
Just as vectors can't replace arrays, so we made std::array. std::arrays ar=
e more unsafe than vectors.<br>
<br>
<br>
Sent from my Windows Phone</div>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGH=
T: bold">From:
</span><span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><a =
href=3D"mailto:andy@luto.us">Andrew Lutomirski</a></span><br>
<span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGH=
T: bold">Sent:
</span><span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">201=
3/12/4 5:54</span><br>
<span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGH=
T: bold">To:
</span><span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><a =
href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a></span=
><br>
<span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGH=
T: bold">Subject:
</span><span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">Re:=
 [std-proposals] Re: proposal to add vector::push_back_()</span><br>
<br>
</div>
<div class=3D"BodyFragment">
<div class=3D"PlainText">On Tue, Dec 3, 2013 at 12:58 PM,&nbsp; &lt;Victor.=
Khomenko@ncl.ac.uk&gt; wrote:<br>
&gt; On Monday, 2 December 2013 23:37:50 UTC, Billy O'Neal wrote:<br>
&gt;&gt;<br>
&gt;&gt; Vector is plenty fast and safe. Nobody has shown a serious applica=
tion<br>
&gt;&gt; where the performance cost of checking size in push_back made any =
measurable<br>
&gt;&gt; difference in an overall application in an application compiled in=
 release<br>
&gt;&gt; mode.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; You are making a sweeping generalization here. I had a significant<br>
&gt; performance deterioration due to this issue, like 10% for the whole pr=
ogram,<br>
&gt; when I moved from my home-brewed vector-like class to vector. More<br>
&gt; precisely, the innermost loop was a call to std::transform with<br>
&gt; std::back_inserter(vector) as the output range. And it was serious eno=
ugh<br>
&gt; for me (of course, you're free to choose which applications you consid=
er<br>
&gt; &quot;serious&quot;). I believe that push_back in an innermost loop is=
 quite common,<br>
&gt; although I don't have any statistics to back it up. Another common cas=
e<br>
&gt; where vector is VERY slow (for a different reason) is given at the end=
..<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; The average programmer is not writing an application where the siz=
e check<br>
&gt;&gt; inside push_back is significant enough to make a significant diffe=
rence in<br>
&gt;&gt; application performance. Vector is designed for the 99.9% case. Th=
is<br>
&gt;&gt; proposed optimization is describing an optimization for a 0.01% ca=
se.<br>
&gt;&gt;<br>
&gt;<br>
&gt; Confess, you just faked these numbers (they don't even add up to 100% =
;-).<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt;&nbsp;&nbsp; * vector::operator[] has undefined behaviour when=
 index is out of<br>
&gt;&gt; &gt; range<br>
&gt;&gt; So do arrays, and all other types of indexed memory access.<br>
&gt;&gt;<br>
&gt;<br>
&gt; That was precisely my point: unchecked_push_back would correspond to t=
he<br>
&gt; *p&#43;&#43;=3D... idiom, and its safety guarantee is in line with the=
 other methods<br>
&gt; of vector. In fact, reserve&#43;unchecked_push_back form a very natura=
l<br>
&gt; interface for vector.<br>
<br>
Is there any obvious reason that reserve &#43; unchecked_push_back is<br>
better than resize_uninitialized &#43; push_back (&#43; resize if needed)?<=
br>
That is, how common is this issue with vectors of nontrivial types?<br>
<br>
--Andy<br>
<br>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C&#43;&#43; Standard - Future Proposals&quot; group.<br=
>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe">
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/un=
subscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to std-pro=
posals&#43;unsubscribe@isocpp.org.<br>
To post to this group, send email to std-proposals@isocpp.org.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</body>
</html>

<p></p>

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

--_623d5ad7-721c-491b-9753-a628ee04f1f2_--

.

--089e01634ec215836b04ecaaaf1c
Content-Type: text/plain; charset=ISO-8859-1

> If he uses unsafe operations, when the answer is wrong, the program will
crash or run a strange answer. This will tell programs you may wrong.

If and only if those unsafe operations result in a crash or strange answer.
Undefined behavior means undefined -- and unfortunately often works as
expected.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Dec 3, 2013 at 4:36 PM, wsdwsd <euloanty@live.com> wrote:

>  Who said unsafe operations are only used for 0.01% conditions? It's a
> big prejudice!
> Many programs must cater for c-style interfaces. No unsafe_resize, we can
> hardly use a vector to do it.
> After we add unsafe_emplace_back, many programs will use it to replace
> emplace_back. In fact, if A programmer use a emplace_back, he sometimes
> can't check wrong answers easily. For example, what he needs to add are 10
> elements, but in fact, he adds 11 elements. He can't check the wrong
> easily. If he uses unsafe operations, when the answer is wrong, the program
> will crash or run a strange answer. This will tell programs you may wrong.
> Just as vectors can't replace arrays, so we made std::array. std::arrays
> are more unsafe than vectors.
>
>
> Sent from my Windows Phone
>  ------------------------------
> From: Andrew Lutomirski <andy@luto.us>
> Sent: 2013/12/4 5:54
> To: std-proposals@isocpp.org
> Subject: Re: [std-proposals] Re: proposal to add vector::push_back_()
>
>  On Tue, Dec 3, 2013 at 12:58 PM,  <Victor.Khomenko@ncl.ac.uk> wrote:
> > On Monday, 2 December 2013 23:37:50 UTC, Billy O'Neal wrote:
> >>
> >> Vector is plenty fast and safe. Nobody has shown a serious application
> >> where the performance cost of checking size in push_back made any
> measurable
> >> difference in an overall application in an application compiled in
> release
> >> mode.
> >
> >
> >
> > You are making a sweeping generalization here. I had a significant
> > performance deterioration due to this issue, like 10% for the whole
> program,
> > when I moved from my home-brewed vector-like class to vector. More
> > precisely, the innermost loop was a call to std::transform with
> > std::back_inserter(vector) as the output range. And it was serious enough
> > for me (of course, you're free to choose which applications you consider
> > "serious"). I believe that push_back in an innermost loop is quite
> common,
> > although I don't have any statistics to back it up. Another common case
> > where vector is VERY slow (for a different reason) is given at the end.
> >
> >
> >>
> >> The average programmer is not writing an application where the size
> check
> >> inside push_back is significant enough to make a significant difference
> in
> >> application performance. Vector is designed for the 99.9% case. This
> >> proposed optimization is describing an optimization for a 0.01% case.
> >>
> >
> > Confess, you just faked these numbers (they don't even add up to 100%
> ;-).
> >
> >
> >>
> >> >   * vector::operator[] has undefined behaviour when index is out of
> >> > range
> >> So do arrays, and all other types of indexed memory access.
> >>
> >
> > That was precisely my point: unchecked_push_back would correspond to the
> > *p++=... idiom, and its safety guarantee is in line with the other
> methods
> > of vector. In fact, reserve+unchecked_push_back form a very natural
> > interface for vector.
>
> Is there any obvious reason that reserve + unchecked_push_back is
> better than resize_uninitialized + push_back (+ resize if needed)?
> That is, how common is this issue with vectors of nontrivial types?
>
> --Andy
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--089e01634ec215836b04ecaaaf1c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=A0<span style=3D"font-family:Calibri,sans-serif;font-=
size:15px">If he uses unsafe operations, when the answer is wrong, the prog=
ram will crash or run a strange answer. This will tell programs you may wro=
ng.=A0</span><div>

<span style=3D"font-family:Calibri,sans-serif;font-size:15px"><br></span></=
div><div><span style=3D"font-family:Calibri,sans-serif;font-size:15px">If a=
nd only if those unsafe operations result in a crash or strange answer. Und=
efined behavior means undefined -- and unfortunately often works as expecte=
d.</span></div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Dec 3, 2013 at 4:36 PM, wsdwsd <=
span dir=3D"ltr">&lt;<a href=3D"mailto:euloanty@live.com" target=3D"_blank"=
>euloanty@live.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div>
<div>
<div style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif">Who said unsaf=
e operations are only used for 0.01% conditions? It&#39;s a big prejudice!<=
br>
Many programs must cater for c-style interfaces. No unsafe_resize, we can h=
ardly use a vector to do it.
<br>
After we add unsafe_emplace_back, many programs will use it to replace empl=
ace_back. In fact, if A programmer use a emplace_back, he sometimes can&#39=
;t check wrong answers easily. For example, what he needs to add are 10 ele=
ments, but in fact, he adds 11 elements.
 He can&#39;t check the wrong easily. If he uses unsafe operations, when th=
e answer is wrong, the program will crash or run a strange answer. This wil=
l tell programs you may wrong.
<br>
Just as vectors can&#39;t replace arrays, so we made std::array. std::array=
s are more unsafe than vectors.<br>
<br>
<br>
Sent from my Windows Phone</div>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bo=
ld">From:
</span><span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif"><a hre=
f=3D"mailto:andy@luto.us" target=3D"_blank">Andrew Lutomirski</a></span><br=
>
<span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bo=
ld">Sent:
</span><span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif">2013/1=
2/4 5:54</span><br>
<span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bo=
ld">To:
</span><span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif"><a hre=
f=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocp=
p.org</a></span><br>
<span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bo=
ld">Subject:
</span><span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif">Re: [s=
td-proposals] Re: proposal to add vector::push_back_()</span><br>
<br>
</div>
<div>
<div>On Tue, Dec 3, 2013 at 12:58 PM,=A0 &lt;<a href=3D"mailto:Victor.Khome=
nko@ncl.ac.uk" target=3D"_blank">Victor.Khomenko@ncl.ac.uk</a>&gt; wrote:<b=
r>
&gt; On Monday, 2 December 2013 23:37:50 UTC, Billy O&#39;Neal wrote:<br>
&gt;&gt;<br>
&gt;&gt; Vector is plenty fast and safe. Nobody has shown a serious applica=
tion<br>
&gt;&gt; where the performance cost of checking size in push_back made any =
measurable<br>
&gt;&gt; difference in an overall application in an application compiled in=
 release<br>
&gt;&gt; mode.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; You are making a sweeping generalization here. I had a significant<br>
&gt; performance deterioration due to this issue, like 10% for the whole pr=
ogram,<br>
&gt; when I moved from my home-brewed vector-like class to vector. More<br>
&gt; precisely, the innermost loop was a call to std::transform with<br>
&gt; std::back_inserter(vector) as the output range. And it was serious eno=
ugh<br>
&gt; for me (of course, you&#39;re free to choose which applications you co=
nsider<br>
&gt; &quot;serious&quot;). I believe that push_back in an innermost loop is=
 quite common,<br>
&gt; although I don&#39;t have any statistics to back it up. Another common=
 case<br>
&gt; where vector is VERY slow (for a different reason) is given at the end=
..<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; The average programmer is not writing an application where the siz=
e check<br>
&gt;&gt; inside push_back is significant enough to make a significant diffe=
rence in<br>
&gt;&gt; application performance. Vector is designed for the 99.9% case. Th=
is<br>
&gt;&gt; proposed optimization is describing an optimization for a 0.01% ca=
se.<br>
&gt;&gt;<br>
&gt;<br>
&gt; Confess, you just faked these numbers (they don&#39;t even add up to 1=
00% ;-).<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt;=A0=A0 * vector::operator[] has undefined behaviour when index=
 is out of<br>
&gt;&gt; &gt; range<br>
&gt;&gt; So do arrays, and all other types of indexed memory access.<br>
&gt;&gt;<br>
&gt;<br>
&gt; That was precisely my point: unchecked_push_back would correspond to t=
he<br>
&gt; *p++=3D... idiom, and its safety guarantee is in line with the other m=
ethods<br>
&gt; of vector. In fact, reserve+unchecked_push_back form a very natural<br=
>
&gt; interface for vector.<br>
<br>
Is there any obvious reason that reserve + unchecked_push_back is<br>
better than resize_uninitialized + push_back (+ resize if needed)?<br>
That is, how common is this issue with vectors of nontrivial types?<br>
<br>
--Andy<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe" target=3D"_blan=
k">
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/un=
subscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">


<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--089e01634ec215836b04ecaaaf1c--

.

------=_Part_5570_30922423.1386199899617
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, 3 December 2013 21:54:12 UTC, Andrew Lutomirski wrote:
>
>
> Is there any obvious reason that reserve + unchecked_push_back is
> better than resize_uninitialized + push_back (+ resize if needed)?
> That is, how common is this issue with vectors of nontrivial types?
>
>
This was discussed early in this thread: resize_uninitialized will leave a
vector in an invalid state, which is extremely dangerous. Note that
vector<T> must be able to work with any type T satisfying some simple
conditions (presence of certain constructors/assignments), not just trivial
types. So it does not matter whether vectors of nontrivial types are common
or not (they are, btw).

--

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

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

<div dir=3D"ltr"><br><br>On Tuesday, 3 December 2013 21:54:12 UTC, Andrew L=
utomirski  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><br>Is there any obvious reas=
on that reserve + unchecked_push_back is
<br>better than resize_uninitialized + push_back (+ resize if needed)?
<br>That is, how common is this issue with vectors of nontrivial types?
<br>
<br></blockquote><div><br></div><div><div>This was discussed early in this =
thread:&nbsp;resize_uninitialized will leave a vector in an invalid state, =
which is extremely dangerous. Note that vector&lt;T&gt;&nbsp;must be able t=
o work with&nbsp;any type T satisfying some simple conditions (presence of =
certain constructors/assignments), not just trivial types. So it does not m=
atter whether vectors of nontrivial types are common or not (they are, btw)=
..</div></div></div>

<p></p>

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

------=_Part_5570_30922423.1386199899617--

.

------=_Part_166_26941968.1386285981793
Content-Type: text/plain; charset=ISO-8859-1

No, there is absolutely nothing dangerous about this:

The only difference between resize_uninitialized(), or as I more
appropriately named it before in this thread resize_default_constructed()
is that it calls the default constructor for the elements
rather than the value constructor. These two constructors can only differ
for basic types and pointers. For class types these constructors are always
the same. Of course you can write a default constructor for your class that
does not set the member values, but in that case the regular resize() would
be exactly as bad.

A resize_uninitialized() which does not call a default constructor for the
elements would on the other hand be a real disaster as the succeding
operator[] = construct (BTW: not push_back!) would try to assign to a left
hand sidfe object that has not be constructed, which fails for most
non-trivial types.

The only dangerous thing about a resize_default_constructed() would be for
pointers, which in this case (in contrast with a regular resize()) do not
get set to 0.

To me it has always been strange that vector calls value construction
instead of default construction as one would think that it would be modeled
after a C array which calls the default constructor.

However, the resize_default_constructed() does not solve the entire initial
problem as it only makes a difference for "dumb" types. On the other hand
anything but moving a few bytes of data (for instance copying a string)
would render the speed gain from the missing size check negligable.

I think the use case where the speed gain is most profound is when using a
vector<char> or similar as a buffer into which a file contents or network
packet is received.

Den torsdagen den 5:e december 2013 kl. 00:31:39 UTC+1 skrev
Victor....@ncl.ac.uk:
>
>
>
> On Tuesday, 3 December 2013 21:54:12 UTC, Andrew Lutomirski wrote:
>>
>>
>> Is there any obvious reason that reserve + unchecked_push_back is
>> better than resize_uninitialized + push_back (+ resize if needed)?
>> That is, how common is this issue with vectors of nontrivial types?
>>
>>
> This was discussed early in this thread: resize_uninitialized will leave a
> vector in an invalid state, which is extremely dangerous. Note that
> vector<T> must be able to work with any type T satisfying some simple
> conditions (presence of certain constructors/assignments), not just trivial
> types. So it does not matter whether vectors of nontrivial types are common
> or not (they are, btw).
>

--

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

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

<div dir=3D"ltr">No, there is absolutely nothing dangerous about this:<div>=
<br></div><div>The only difference between resize_uninitialized(), or as I =
more appropriately named it before in this thread resize_default_constructe=
d() is that it calls the default constructor for the elements</div><div>rat=
her than the value constructor. These two constructors can only differ for =
basic types and pointers. For class types these constructors are always the=
 same. Of course you can write a default constructor for your class that do=
es not set the member values, but in that case the regular resize() would b=
e exactly as bad.</div><div><br></div><div>A resize_uninitialized() which d=
oes not call a default constructor for the elements would on the other hand=
 be a real disaster as the succeding operator[] =3D construct (BTW: not pus=
h_back!) would try to assign to a left hand sidfe object that has not be co=
nstructed, which fails for most non-trivial types.</div><div><br></div><div=
>The only dangerous thing about a resize_default_constructed() would be for=
 pointers, which in this case (in contrast with a regular resize()) do not =
get set to 0.</div><div><br></div><div>To me it has always been strange tha=
t vector calls value construction instead of default construction as one wo=
uld think that it would be modeled after a C array which calls the default =
constructor.</div><div><br></div><div>However, the resize_default_construct=
ed() does not solve the entire initial problem as it only makes a differenc=
e for "dumb" types. On the other hand anything but moving a few bytes of da=
ta (for instance copying a string) would render the speed gain from the mis=
sing size check negligable.</div><div><br></div><div>I think the use case w=
here the speed gain is most profound is when using a vector&lt;char&gt; or =
similar as a buffer into which a file contents or network packet is receive=
d.</div><div><div><br>Den torsdagen den 5:e december 2013 kl. 00:31:39 UTC+=
1 skrev Victor....@ncl.ac.uk:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><br><br>On Tuesday, 3 December 2013 21:54:12 UTC, Andrew Lu=
tomirski  wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wi=
dth:1px;border-left-style:solid"><br>Is there any obvious reason that reser=
ve + unchecked_push_back is
<br>better than resize_uninitialized + push_back (+ resize if needed)?
<br>That is, how common is this issue with vectors of nontrivial types?
<br>
<br></blockquote><div><br></div><div><div>This was discussed early in this =
thread:&nbsp;resize_uninitialized will leave a vector in an invalid state, =
which is extremely dangerous. Note that vector&lt;T&gt;&nbsp;must be able t=
o work with&nbsp;any type T satisfying some simple conditions (presence of =
certain constructors/assignments), not just trivial types. So it does not m=
atter whether vectors of nontrivial types are common or not (they are, btw)=
..</div></div></div></blockquote></div></div></div>

<p></p>

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

------=_Part_166_26941968.1386285981793--

.

On 6 December 2013 01:26, Bengt Gustafsson
<bengt.gustafsson@beamways.com> wrote:
> I think the use case where the speed gain is most profound is when using a
> vector<char> or similar as a buffer into which a file contents or network
> packet is received.


Sorry if I have missed something, but if this gain is indeed profound, can you
provide a real-life measurement of it?

I have, in principle, nothing against adding facilities to vector that remove
the remnants of overhead from it. I am not adamantly against it. I would
like to have practical numbers supporting such facilities, so that we don't
end up discussing ephemeral illusions (and I'm NOT saying this idea
is one, I mean both the arguments for and against it!).

Having said that, vector was never, as far as I understood it, meant to
be as-fast-as-possible, but rather as-fast-as-possible-with-additional-safety.
Being the crazy person that I am, I wouldn't find it far-fetched to have
these 'unsafe' facilities in a (pardon the deliberately stupid name)
'fast_vector' or 'unsafe_vector'.

And yes, I would absolutely be for any reasonable facility that is
better than telling people "if you really care _that_ much about
performance, use raw arrays and new and write your own container".

--

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

.

--_21653f5f-ba55-4691-8a93-3f5e1350b3cf_
Content-Type: text/plain; charset=ISO-8859-1

Library containers can be very fast.

Your mean is just as " move-segments"is useless.

We should make vectors  more open to users.

Sent from my Windows Phone
________________________________
From: Ville Voutilainen<mailto:ville.voutilainen@gmail.com>
Sent: 2013/12/6 7:40
To: std-proposals@isocpp.org<mailto:std-proposals@isocpp.org>
Cc: andy@luto.us<mailto:andy@luto.us>; Victor.Khomenko@ncl.ac.uk<mailto:Victor.Khomenko@ncl.ac.uk>
Subject: Re: [std-proposals] Re: proposal to add vector::push_back_()

On 6 December 2013 01:26, Bengt Gustafsson
<bengt.gustafsson@beamways.com> wrote:
> I think the use case where the speed gain is most profound is when using a
> vector<char> or similar as a buffer into which a file contents or network
> packet is received.


Sorry if I have missed something, but if this gain is indeed profound, can you
provide a real-life measurement of it?

I have, in principle, nothing against adding facilities to vector that remove
the remnants of overhead from it. I am not adamantly against it. I would
like to have practical numbers supporting such facilities, so that we don't
end up discussing ephemeral illusions (and I'm NOT saying this idea
is one, I mean both the arguments for and against it!).

Having said that, vector was never, as far as I understood it, meant to
be as-fast-as-possible, but rather as-fast-as-possible-with-additional-safety.
Being the crazy person that I am, I wouldn't find it far-fetched to have
these 'unsafe' facilities in a (pardon the deliberately stupid name)
'fast_vector' or 'unsafe_vector'.

And yes, I would absolutely be for any reasonable facility that is
better than telling people "if you really care _that_ much about
performance, use raw arrays and new and write your own container".

--

---
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

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

--_21653f5f-ba55-4691-8a93-3f5e1350b3cf_
Content-Type: text/html; charset=ISO-8859-1

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>
<div style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">Library containers can be very fast.
<br>
<br>
Your mean is just as &quot; move-segments&quot;is useless.<br>
<br>
We should make vectors&nbsp; more open to users.<br>
<br>
Sent from my Windows Phone</div>
</div>
<div dir="ltr">
<hr>
<span style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">From:
</span><span style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><a href="mailto:ville.voutilainen@gmail.com">Ville Voutilainen</a></span><br>
<span style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">Sent:
</span><span style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">2013/12/6 7:40</span><br>
<span style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">To:
</span><span style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a></span><br>
<span style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">Cc:
</span><span style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><a href="mailto:andy@luto.us">andy@luto.us</a>;
<a href="mailto:Victor.Khomenko@ncl.ac.uk">Victor.Khomenko@ncl.ac.uk</a></span><br>
<span style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: bold">Subject:
</span><span style="FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">Re: [std-proposals] Re: proposal to add vector::push_back_()</span><br>
<br>
</div>
<div class="BodyFragment">
<div class="PlainText">On 6 December 2013 01:26, Bengt Gustafsson<br>
&lt;bengt.gustafsson@beamways.com&gt; wrote:<br>
&gt; I think the use case where the speed gain is most profound is when using a<br>
&gt; vector&lt;char&gt; or similar as a buffer into which a file contents or network<br>
&gt; packet is received.<br>
<br>
<br>
Sorry if I have missed something, but if this gain is indeed profound, can you<br>
provide a real-life measurement of it?<br>
<br>
I have, in principle, nothing against adding facilities to vector that remove<br>
the remnants of overhead from it. I am not adamantly against it. I would<br>
like to have practical numbers supporting such facilities, so that we don't<br>
end up discussing ephemeral illusions (and I'm NOT saying this idea<br>
is one, I mean both the arguments for and against it!).<br>
<br>
Having said that, vector was never, as far as I understood it, meant to<br>
be as-fast-as-possible, but rather as-fast-as-possible-with-additional-safety.<br>
Being the crazy person that I am, I wouldn't find it far-fetched to have<br>
these 'unsafe' facilities in a (pardon the deliberately stupid name)<br>
'fast_vector' or 'unsafe_vector'.<br>
<br>
And yes, I would absolutely be for any reasonable facility that is<br>
better than telling people &quot;if you really care _that_ much about<br>
performance, use raw arrays and new and write your own container&quot;.<br>
<br>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Google Groups &quot;ISO C&#43;&#43; Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href="https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe">
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to std-proposals&#43;unsubscribe@isocpp.org.<br>
To post to this group, send email to std-proposals@isocpp.org.<br>
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</body>
</html>

<p></p>

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

--_21653f5f-ba55-4691-8a93-3f5e1350b3cf_--

.

------=_Part_3245_1092065.1386626515294
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, 5 December 2013 23:26:21 UTC, Bengt Gustafsson wrote:
>
> On the other hand anything but moving a few bytes of data (for instance
> copying a string) would render the speed gain from the missing size check
> negligable.
>

The innermost loop determines the performance. If you replace a small type
by something like a string, the loop ceases to be innermost - now the
innermost loop is inside string's implementation. Hence the innermost loop
operates with small objects (of course, one can invent artificial code
where this is not the case, e.g. a large struct is used, but in practice
that would be unusual).

Also, as noted early in this thread, the reason unchecked_push_back is
faster is mostly because the store instruction for vector::end_ptr is moved
outside the loop by the optimiser, which cannot be done for push_back.

--

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

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

<div dir=3D"ltr"><br><br>On Thursday, 5 December 2013 23:26:21 UTC, Bengt G=
ustafsson  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On the other=
 hand anything but moving a few bytes of data (for instance copying a strin=
g) would render the speed gain from the missing size check negligable.</div=
></blockquote><div><br></div><div>The innermost loop determines the perform=
ance. If you replace a small type by something like a&nbsp;string, the loop=
 ceases to be innermost - now the innermost&nbsp;loop is inside string's im=
plementation. Hence the innermost loop operates with small objects (of cour=
se, one can invent artificial code where this is not the case, e.g. a large=
 struct is used, but in practice that would be unusual).</div><div><br></di=
v><div>Also, as noted early in this thread, the reason unchecked_push_back =
is faster is mostly&nbsp;because the store instruction for vector::end_ptr =
is moved outside the loop by the optimiser, which cannot be done&nbsp;for p=
ush_back.</div></div>

<p></p>

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

------=_Part_3245_1092065.1386626515294--

.

------=_Part_850_11214633.1386628353195
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, 5 December 2013 23:39:59 UTC, Ville Voutilainen wrote:
>
> Sorry if I have missed something, but if this gain is indeed profound, can
> you
> provide a real-life measurement of it?
>

Nobody posted measurements for resize_default_constructed(), but we do have
measurements for unchecked_push_back early in the thread, showing 40%
speedup (for the whole loop) when an int wrapping class is used.

I'd *guess* that resize_default_constructed() would have similar speedup
for elementary types, but no speedup for classes with initialising
constructors.



> Having said that, vector was never, as far as I understood it, meant to
> be as-fast-as-possible, but rather
> as-fast-as-possible-with-additional-safety.
>

Just a few days ago I posted some comments arguing that vector is neither
safe nor fast, with examples.


Being the crazy person that I am, I wouldn't find it far-fetched to have
> these 'unsafe' facilities in a (pardon the deliberately stupid name)
> 'fast_vector' or 'unsafe_vector'.
>

Sad but true :-( That's exactly what I did, bar the name.



> And yes, I would absolutely be for any reasonable facility that is
> better than telling people "if you really care _that_ much about
> performance, use raw arrays and new and write your own container".
>


Or rather malloc / realloc, as one doesn't want to call the default
constructors (they may do something for non-basic types).

--

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

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

<div dir=3D"ltr"><br><br>On Thursday, 5 December 2013 23:39:59 UTC, Ville V=
outilainen  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;">Sorry if I have missed somet=
hing, but if this gain is indeed profound, can you
<br>provide a real-life measurement of it?<br></blockquote><div><br></div><=
div>Nobody posted measurements for resize_default_constructed(), but we do =
have measurements for unchecked_push_back&nbsp;early in the thread, showing=
 40% speedup (for the whole loop) when an int wrapping class is used.</div>=
<div><br></div><div>I'd *guess* that resize_default_constructed() would hav=
e similar speedup for elementary types, but no speedup for classes with ini=
tialising constructors.</div><div><br></div><div>&nbsp;</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; =
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-=
style: solid;">Having said that, vector was never, as far as I understood i=
t, meant to
<br>be as-fast-as-possible, but rather as-fast-as-possible-with-<wbr>additi=
onal-safety.
<br></blockquote><div><br></div><div>Just a few days ago I posted some comm=
ents arguing that vector is neither safe nor fast, with examples.</div><div=
>&nbsp;</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;">Being the crazy pe=
rson that I am, I wouldn't find it far-fetched to have
<br>these 'unsafe' facilities in a (pardon the deliberately stupid name)
<br>'fast_vector' or 'unsafe_vector'.
<br></blockquote><div><br></div><div>Sad but true :-( That's exactly what I=
 did, bar the name.</div><div><br></div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">And yes, I would absolutely be for any reasonable facility that=
 is
<br>better than telling people "if you really care _that_ much about
<br>performance, use raw arrays and new and write your own container".
<br></blockquote><div><br></div><div><br></div><div>Or rather malloc / real=
loc, as one doesn't want to call the default constructors (they may do some=
thing for non-basic types).&nbsp;</div></div>

<p></p>

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

------=_Part_850_11214633.1386628353195--

.

No.class:
vector<vector<int>> vec(1000,vector<int>(1000));



Sent from my Windows Phone

-----Original Message-----
From: "Victor.Khomenko@ncl.ac.uk" <Victor.Khomenko@ncl.ac.uk>
Sent: 2013/12/10 6:32
To: "std-proposals@isocpp.org" <std-proposals@isocpp.org>
Cc: "andy@luto.us" <andy@luto.us>; "Victor.Khomenko@ncl.ac.uk" <Victor.Khomenko@ncl.ac.uk>
Subject: Re: [std-proposals] Re: proposal to add vector::push_back_()



On Thursday, 5 December 2013 23:39:59 UTC, Ville Voutilainen wrote:
Sorry if I have missed something, but if this gain is indeed profound, can you
provide a real-life measurement of it?



Nobody posted measurements for resize_default_constructed(), but we do have measurements for unchecked_push_back early in the thread, showing 40% speedup (for the whole loop) when an int wrapping class is used.


I'd *guess* that resize_default_constructed() would have similar speedup for elementary types, but no speedup for classes with initialising constructors.



Having said that, vector was never, as far as I understood it, meant to
be as-fast-as-possible, but rather as-fast-as-possible-with-additional-safety.



Just a few days ago I posted some comments arguing that vector is neither safe nor fast, with examples.



Being the crazy person that I am, I wouldn't find it far-fetched to have
these 'unsafe' facilities in a (pardon the deliberately stupid name)
'fast_vector' or 'unsafe_vector'.



Sad but true :-( That's exactly what I did, bar the name.



And yes, I would absolutely be for any reasonable facility that is
better than telling people "if you really care _that_ much about
performance, use raw arrays and new and write your own container".





Or rather malloc / realloc, as one doesn't want to call the default constructors (they may do something for non-basic types).
--

---
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

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

.

--_C0469A43-12B5-48EC-B05E-A7296BFD8458_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=windows-1252

In fact, unsafe_push_back() is very useful. unsafe_resize() is also useful.


In  my opinion, if one thing could make us avoid to use =93new[], delete[],=
  malloc , free=94 or to reduce the use of pointers, it=92s good and could =
be added into C++.



In fact, std::vector<> is the dynamic-array of C++ style.




Sent from Windows Mail





From: Victor.Khomenko@ncl.ac.uk
Sent: Tuesday, December 10, 2013 6:32 AM
To: std-proposals@isocpp.org
Cc: andy@luto.us, Victor.Khomenko@ncl.ac.uk







On Thursday, 5 December 2013 23:39:59 UTC, Ville Voutilainen wrote:
Sorry if I have missed something, but if this gain is indeed profound, can =
you=20
provide a real-life measurement of it?





Nobody posted measurements for resize_default_constructed(), but we do have=
 measurements for unchecked_push_back early in the thread, showing 40% spee=
dup (for the whole loop) when an int wrapping class is used.




I'd *guess* that resize_default_constructed() would have similar speedup fo=
r elementary types, but no speedup for classes with initialising constructo=
rs.




=20

Having said that, vector was never, as far as I understood it, meant to=20
be as-fast-as-possible, but rather as-fast-as-possible-with-additional-safe=
ty.=20





Just a few days ago I posted some comments arguing that vector is neither s=
afe nor fast, with examples.

=20




Being the crazy person that I am, I wouldn't find it far-fetched to have=20
these 'unsafe' facilities in a (pardon the deliberately stupid name)=20
'fast_vector' or 'unsafe_vector'.=20





Sad but true :-( That's exactly what I did, bar the name.




=20

And yes, I would absolutely be for any reasonable facility that is=20
better than telling people "if you really care _that_ much about=20
performance, use raw arrays and new and write your own container".=20








Or rather malloc / realloc, as one doesn't want to call the default constru=
ctors (they may do something for non-basic types).=20

--=20
=20
---=20
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.or=
g/d/topic/std-proposals/5BnNHEr07QM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--=20

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

--_C0469A43-12B5-48EC-B05E-A7296BFD8458_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=windows-1252


<html>
<head>
<meta name=3D"generator" content=3D"Windows Mail 17.5.9600.20315">
<style data-externalstyle=3D"true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParag=
raphCxSpFirst,=20
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListPar=
agraphCxSpMiddle,=20
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagra=
phCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style></head>
<body dir=3D"ltr">
<div data-externalstyle=3D"false" dir=3D"ltr" style=3D"font-family: 'Calibr=
i', 'Microsoft YaHei UI', 'Segoe UI', 'Meiryo', 'Microsoft JhengHei UI', 'M=
algun Gothic', 'sans-serif';font-size:12pt;"><div style=3D"color: rgb(0, 0,=
 0);">In fact, unsafe_push_back()&nbsp;is very useful. unsafe_resize() is a=
lso useful.</div><div style=3D"color: rgb(0, 0, 0);"><br></div><div style=
=3D"color: rgb(0, 0, 0);">In&nbsp; my opinion, if one thing could&nbsp;make=
 us&nbsp;avoid to use&nbsp;=93new[], delete[],&nbsp;&nbsp;malloc , free=94 =
or&nbsp;to reduce the use of pointers, it=92s good and&nbsp;could be added =
into C++.</div><div style=3D"color: rgb(0, 0, 0);" data-signatureblock=3D"t=
rue"><div style=3D"color: rgb(0, 0, 0);"><br></div><div style=3D"color: rgb=
(0, 0, 0);">In fact, std::vector&lt;&gt; is&nbsp;the&nbsp;dynamic-array&nbs=
p;of C++ style.</div><div style=3D"color: rgb(0, 0, 0);"><br></div><div sty=
le=3D"color: rgb(0, 0, 0);">Sent from Windows Mail</div><div style=3D"color=
: rgb(0, 0, 0);"><br></div></div><div style=3D"padding-top: 5px; border-top=
-color: rgb(229, 229, 229); border-top-width: 1px; border-top-style: solid;=
"><div><font face=3D" 'Calibri', 'Microsoft YaHei UI', 'Segoe UI', 'Meiryo'=
, 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-serif'" style=3D'line-hei=
ght: 15pt; letter-spacing: 0.02em; font-family: "Calibri", "Microsoft YaHei=
 UI", "Segoe UI", "Meiryo", "Microsoft JhengHei UI", "Malgun Gothic", "sans=
-serif"; font-size: 12pt;'><b>From:</b>&nbsp;<a href=3D"mailto:Victor.Khome=
nko@ncl.ac.uk" target=3D"_parent">Victor.Khomenko@ncl.ac.uk</a><br><b>Sent:=
</b>&nbsp;Tuesday, December 10, 2013 6:32 AM<br><b>To:</b>&nbsp;<a href=3D"=
mailto:std-proposals@isocpp.org" target=3D"_parent">std-proposals@isocpp.or=
g</a><br><b>Cc:</b>&nbsp;<a href=3D"mailto:andy@luto.us" target=3D"_parent"=
>andy@luto.us</a>, <a href=3D"mailto:Victor.Khomenko@ncl.ac.uk" target=3D"_=
parent">Victor.Khomenko@ncl.ac.uk</a></font></div></div><div><br></div><div=
 dir=3D""><div dir=3D"ltr"><br><br>On Thursday, 5 December 2013 23:39:59 UT=
C, Ville Voutilainen  wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;">Sorry if I have mi=
ssed something, but if this gain is indeed profound, can you
<br>provide a real-life measurement of it?<br></blockquote><div><br></div><=
div>Nobody posted measurements for resize_default_constructed(), but we do =
have measurements for unchecked_push_back&nbsp;early in the thread, showing=
 40% speedup (for the whole loop) when an int wrapping class is used.</div>=
<div><br></div><div>I'd *guess* that resize_default_constructed() would hav=
e similar speedup for elementary types, but no speedup for classes with ini=
tialising constructors.</div><div><br></div><div>&nbsp;</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; =
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-=
style: solid;">Having said that, vector was never, as far as I understood i=
t, meant to
<br>be as-fast-as-possible, but rather as-fast-as-possible-with-<wbr>additi=
onal-safety.
<br></blockquote><div><br></div><div>Just a few days ago I posted some comm=
ents arguing that vector is neither safe nor fast, with examples.</div><div=
>&nbsp;</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;">Being the crazy pe=
rson that I am, I wouldn't find it far-fetched to have
<br>these 'unsafe' facilities in a (pardon the deliberately stupid name)
<br>'fast_vector' or 'unsafe_vector'.
<br></blockquote><div><br></div><div>Sad but true :-( That's exactly what I=
 did, bar the name.</div><div><br></div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">And yes, I would absolutely be for any reasonable facility that=
 is
<br>better than telling people "if you really care _that_ much about
<br>performance, use raw arrays and new and write your own container".
<br></blockquote><div><br></div><div><br></div><div>Or rather malloc / real=
loc, as one doesn't want to call the default constructors (they may do some=
thing for non-basic types).&nbsp;</div></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe" target=3D"_pare=
nt">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07Q=
M/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.<br>
To post to this group, send email to std-proposals@isocpp.org.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_parent">http://groups.google.com/a/isocpp.org/gr=
oup/std-proposals/</a>.<br>
</div></div>
</body>
</html>

<p></p>

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

--_C0469A43-12B5-48EC-B05E-A7296BFD8458_--

.

--001a11c1d7e08f303d04ed26dcf1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I still remain unconvinced that the type for this is vector. If the user
wants unsafe semantics, there's no reason they can't use a separate type
which has uninitialized semantics, and can have checks e.g. to make sure T
is a POD type.

The argument of "well there is code out there that accepts plain vector"
doesn't sell me -- that code should be accepting a range.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Mon, Dec 9, 2013 at 8:35 PM, wsdwsd <euloanty@live.com> wrote:

>  In fact, unsafe_push_back() is very useful. unsafe_resize() is also
> useful.
>
> In  my opinion, if one thing could make us avoid to use =93new[],
> delete[],  malloc , free=94 or to reduce the use of pointers, it=92s good
> and could be added into C++.
>
> In fact, std::vector<> is the dynamic-array of C++ style.
>
> Sent from Windows Mail
>
> *From:* Victor.Khomenko@ncl.ac.uk
> *Sent:* Tuesday, December 10, 2013 6:32 AM
> *To:* std-proposals@isocpp.org
> *Cc:* andy@luto.us, Victor.Khomenko@ncl.ac.uk
>
>
>
> On Thursday, 5 December 2013 23:39:59 UTC, Ville Voutilainen wrote:
>>
>> Sorry if I have missed something, but if this gain is indeed profound,
>> can you
>> provide a real-life measurement of it?
>>
>
> Nobody posted measurements for resize_default_constructed(), but we do
> have measurements for unchecked_push_back early in the thread, showing 40=
%
> speedup (for the whole loop) when an int wrapping class is used.
>
> I'd *guess* that resize_default_constructed() would have similar speedup
> for elementary types, but no speedup for classes with initialising
> constructors.
>
>
>
>> Having said that, vector was never, as far as I understood it, meant to
>> be as-fast-as-possible, but rather as-fast-as-possible-with-additional-s=
afety.
>>
>>
>
> Just a few days ago I posted some comments arguing that vector is neither
> safe nor fast, with examples.
>
>
> Being the crazy person that I am, I wouldn't find it far-fetched to have
>> these 'unsafe' facilities in a (pardon the deliberately stupid name)
>> 'fast_vector' or 'unsafe_vector'.
>>
>
> Sad but true :-( That's exactly what I did, bar the name.
>
>
>
>> And yes, I would absolutely be for any reasonable facility that is
>> better than telling people "if you really care _that_ much about
>> performance, use raw arrays and new and write your own container".
>>
>
>
> Or rather malloc / realloc, as one doesn't want to call the default
> constructors (they may do something for non-basic types).
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

--001a11c1d7e08f303d04ed26dcf1
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I still remain unconvinced=A0that the type for this i=
s vector. If the user wants unsafe semantics, there&#39;s no reason they ca=
n&#39;t use a separate type which has uninitialized semantics, and can have=
 checks e.g. to make sure T is a POD type.</div>

<div><br></div><div>The argument of &quot;well there is code out there that=
 accepts plain vector&quot; doesn&#39;t sell me -- that code should be acce=
pting a range.</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div=
>

<div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bitbuck=
et.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</a></d=
iv><div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=
=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Dec 9, 2013 at 8:35 PM, wsdwsd <=
span dir=3D"ltr">&lt;<a href=3D"mailto:euloanty@live.com" target=3D"_blank"=
>euloanty@live.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">






<div dir=3D"ltr">
<div style=3D"font-family:&quot;Calibri&quot;,&quot;Microsoft YaHei UI&quot=
;,&quot;Segoe UI&quot;,&quot;Meiryo&quot;,&quot;Microsoft JhengHei UI&quot;=
,&quot;Malgun Gothic&quot;,&quot;sans-serif&quot;;font-size:12pt" dir=3D"lt=
r">

<div>In fact, unsafe_push_back()=A0is very useful. unsafe_resize() is also =
useful.</div><div><br></div><div>In=A0 my opinion, if one thing could=A0mak=
e us=A0avoid to use=A0=93new[], delete[],=A0=A0malloc , free=94 or=A0to red=
uce the use of pointers, it=92s good and=A0could be added into C++.</div>

<div><div><br></div><div>In fact, std::vector&lt;&gt; is=A0the=A0dynamic-ar=
ray=A0of C++ style.</div><div><br></div><div>Sent from Windows Mail</div><d=
iv><br></div></div><div style=3D"padding-top:5px;border-top-color:rgb(229,2=
29,229);border-top-width:1px;border-top-style:solid">

<div><font face=3D" &#39;Calibri&#39;, &#39;Microsoft YaHei UI&#39;, &#39;S=
egoe UI&#39;, &#39;Meiryo&#39;, &#39;Microsoft JhengHei UI&#39;, &#39;Malgu=
n Gothic&#39;, &#39;sans-serif&#39;" style=3D"line-height:15pt;letter-spaci=
ng:0.02em;font-family:&quot;Calibri&quot;,&quot;Microsoft YaHei UI&quot;,&q=
uot;Segoe UI&quot;,&quot;Meiryo&quot;,&quot;Microsoft JhengHei UI&quot;,&qu=
ot;Malgun Gothic&quot;,&quot;sans-serif&quot;;font-size:12pt"><b>From:</b>=
=A0<a href=3D"mailto:Victor.Khomenko@ncl.ac.uk" target=3D"_blank">Victor.Kh=
omenko@ncl.ac.uk</a><br>

<b>Sent:</b>=A0Tuesday, December 10, 2013 6:32 AM<br><b>To:</b>=A0<a href=
=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp=
..org</a><br><b>Cc:</b>=A0<a href=3D"mailto:andy@luto.us" target=3D"_blank">=
andy@luto.us</a>, <a href=3D"mailto:Victor.Khomenko@ncl.ac.uk" target=3D"_b=
lank">Victor.Khomenko@ncl.ac.uk</a></font></div>

</div><div><br></div><div dir=3D""><div dir=3D"ltr"><br><br>On Thursday, 5 =
December 2013 23:39:59 UTC, Ville Voutilainen  wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-=
color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">

Sorry if I have missed something, but if this gain is indeed profound, can =
you
<br>provide a real-life measurement of it?<br></blockquote><div><br></div><=
div>Nobody posted measurements for resize_default_constructed(), but we do =
have measurements for unchecked_push_back=A0early in the thread, showing 40=
% speedup (for the whole loop) when an int wrapping class is used.</div>

<div><br></div><div>I&#39;d *guess* that resize_default_constructed() would=
 have similar speedup for elementary types, but no speedup for classes with=
 initialising constructors.</div><div><br></div><div>=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bor=
der-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:sol=
id">

Having said that, vector was never, as far as I understood it, meant to
<br>be as-fast-as-possible, but rather as-fast-as-possible-with-<u></u>addi=
tional-safety.
<br></blockquote><div><br></div><div>Just a few days ago I posted some comm=
ents arguing that vector is neither safe nor fast, with examples.</div><div=
>=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);borde=
r-left-width:1px;border-left-style:solid">

Being the crazy person that I am, I wouldn&#39;t find it far-fetched to hav=
e
<br>these &#39;unsafe&#39; facilities in a (pardon the deliberately stupid =
name)
<br>&#39;fast_vector&#39; or &#39;unsafe_vector&#39;.
<br></blockquote><div><br></div><div>Sad but true :-( That&#39;s exactly wh=
at I did, bar the name.</div><div><br></div><div>=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">

And yes, I would absolutely be for any reasonable facility that is
<br>better than telling people &quot;if you really care _that_ much about
<br>performance, use raw arrays and new and write your own container&quot;.
<br></blockquote><div><br></div><div><br></div><div>Or rather malloc / real=
loc, as one doesn&#39;t want to call the default constructors (they may do =
something for non-basic types).=A0</div></div><span class=3D"HOEnZb"><font =
color=3D"#888888">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM=
/unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></div></div><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">


<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--001a11c1d7e08f303d04ed26dcf1--

.

On Sun, Sep 8, 2013 at 3:17 PM,  <Victor.Khomenko@ncl.ac.uk> wrote:
>
> On Sunday, September 8, 2013 4:18:56 PM UTC+1, Bengt Gustafsson wrote:
>>
>> We could consider a totally different way to handle this, which also has
>> other uses. Admittedly, this can easily crash if misused (just as index out
>> of range or too many push_back_ calls). I will call this tentatively
>> uninitialized_resize(size_t sz). It just moves the end pointer and
>> reallocates as required, but leaves the new elements uninitialized.
>
>
> I think this will never be adopted as vector no longer can enforce its
> invariants. Example:
> {
>     vector<Widget> v;
>     v.uninitialized_resize(10);
>     // at this point the desctructors are called, resulting in a crash
> }

AFAICS this is intended.  The vector can only be destructed
when the invariants are back to work; thus, until the 10 elements
are filled in.  If an exception is thrown before this is done, UB.

PS: It does not mean I'm in favor of this pattern.

Sorry for replying dated posts.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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

.

--_D943A961-83E3-4622-B875-90C2B1A66DFC_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=windows-1252

=93uninitialized_resize()=94s not enough.

We should both have uninitialized_resize(), uninitialized_push_back(), unin=
itialized_emplace_back,uninitialized_insert.

The uses of them are quite different.

in many conditions uninitialized_resize() can=92t replace uninitialized_pus=
h_back().

I have posted the condition on the net. You could read it.

We should add them all, do you understand??






Sent from Windows Mail





From: Zhihao Yuan
Sent: Tuesday, December 10, 2013 1:14 PM
To: std-proposals@isocpp.org





On Sun, Sep 8, 2013 at 3:17 PM,  <Victor.Khomenko@ncl.ac.uk> wrote:
>
> On Sunday, September 8, 2013 4:18:56 PM UTC+1, Bengt Gustafsson wrote:
>>
>> We could consider a totally different way to handle this, which also has
>> other uses. Admittedly, this can easily crash if misused (just as index =
out
>> of range or too many push_back_ calls). I will call this tentatively
>> uninitialized_resize(size_t sz). It just moves the end pointer and
>> reallocates as required, but leaves the new elements uninitialized.
>
>
> I think this will never be adopted as vector no longer can enforce its
> invariants. Example:
> {
>     vector<Widget> v;
>     v.uninitialized_resize(10);
>     // at this point the desctructors are called, resulting in a crash
> }

AFAICS this is intended.  The vector can only be destructed
when the invariants are back to work; thus, until the 10 elements
are filled in.  If an exception is thrown before this is done, UB.

PS: It does not mean I'm in favor of this pattern.

Sorry for replying dated posts.

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--=20

---=20
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.or=
g/d/topic/std-proposals/5BnNHEr07QM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--=20

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

--_D943A961-83E3-4622-B875-90C2B1A66DFC_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=windows-1252


<html>
<head>
<meta name=3D"generator" content=3D"Windows Mail 17.5.9600.20315">
<style><!--
..EmailQuote {
margin-left:1pt;
padding-left:4pt;
border-left:#800000 2px solid;
}
--></style><style data-externalstyle=3D"true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParag=
raphCxSpFirst,=20
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListPar=
agraphCxSpMiddle,=20
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagra=
phCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style></head>
<body dir=3D"ltr">
<div data-externalstyle=3D"false" dir=3D"ltr" style=3D"font-family: 'Calibr=
i', 'Microsoft YaHei UI', 'Segoe UI', 'Meiryo', 'Microsoft JhengHei UI', 'M=
algun Gothic', 'sans-serif';font-size:12pt;"><div style=3D"color: rgb(0, 0,=
 0);">=93uninitialized_resize()=94s not enough.</div><div style=3D"color: r=
gb(0, 0, 0);">We should both have uninitialized_resize(), uninitialized_pus=
h_back(), uninitialized_emplace_back,uninitialized_insert.</div><div style=
=3D"color: rgb(0, 0, 0);">The uses of them are quite different.</div><div s=
tyle=3D"color: rgb(0, 0, 0);">in many conditions uninitialized_resize() can=
=92t replace uninitialized_push_back().</div><div style=3D"color: rgb(0, 0,=
 0);">I have posted the condition on the net. You could read it.</div><div =
style=3D"color: rgb(0, 0, 0);">We should add them all, do you understand??<=
br></div><div style=3D"color: rgb(0, 0, 0);" data-signatureblock=3D"true"><=
div style=3D"color: rgb(0, 0, 0);"><br></div><div style=3D"color: rgb(0, 0,=
 0);">Sent from Windows Mail</div><div style=3D"color: rgb(0, 0, 0);"><br><=
/div></div><div style=3D"padding-top: 5px; border-top-color: rgb(229, 229, =
229); border-top-width: 1px; border-top-style: solid;"><div><font face=3D" =
'Calibri', 'Microsoft YaHei UI', 'Segoe UI', 'Meiryo', 'Microsoft JhengHei =
UI', 'Malgun Gothic', 'sans-serif'" style=3D'line-height: 15pt; letter-spac=
ing: 0.02em; font-family: "Calibri", "Microsoft YaHei UI", "Segoe UI", "Mei=
ryo", "Microsoft JhengHei UI", "Malgun Gothic", "sans-serif"; font-size: 12=
pt;'><b>From:</b>&nbsp;<a href=3D"mailto:zy@miator.net" target=3D"_parent">=
Zhihao Yuan</a><br><b>Sent:</b>&nbsp;Tuesday, December 10, 2013 1:14 PM<br>=
<b>To:</b>&nbsp;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_pare=
nt">std-proposals@isocpp.org</a></font></div></div><div><br></div><div dir=
=3D"">
<div class=3D"PlainText">On Sun, Sep 8, 2013 at 3:17 PM,&nbsp; &lt;Victor.K=
homenko@ncl.ac.uk&gt; wrote:<br>
&gt;<br>
&gt; On Sunday, September 8, 2013 4:18:56 PM UTC+1, Bengt Gustafsson wrote:=
<br>
&gt;&gt;<br>
&gt;&gt; We could consider a totally different way to handle this, which al=
so has<br>
&gt;&gt; other uses. Admittedly, this can easily crash if misused (just as =
index out<br>
&gt;&gt; of range or too many push_back_ calls). I will call this tentative=
ly<br>
&gt;&gt; uninitialized_resize(size_t sz). It just moves the end pointer and=
<br>
&gt;&gt; reallocates as required, but leaves the new elements uninitialized=
..<br>
&gt;<br>
&gt;<br>
&gt; I think this will never be adopted as vector no longer can enforce its=
<br>
&gt; invariants. Example:<br>
&gt; {<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; vector&lt;Widget&gt; v;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; v.uninitialized_resize(10);<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; // at this point the desctructors are called, =
resulting in a crash<br>
&gt; }<br>
<br>
AFAICS this is intended.&nbsp; The vector can only be destructed<br>
when the invariants are back to work; thus, until the 10 elements<br>
are filled in.&nbsp; If an exception is thrown before this is done, UB.<br>
<br>
PS: It does not mean I'm in favor of this pattern.<br>
<br>
Sorry for replying dated posts.<br>
<br>
-- <br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
___________________________________________________<br>
4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_parent">http://4bsd.biz/</a=
><br>
<br>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe" target=3D"_pare=
nt">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07Q=
M/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.<br>
To post to this group, send email to std-proposals@isocpp.org.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_parent">http://groups.google.com/a/isocpp.org/gr=
oup/std-proposals/</a>.<br>
</div>


</div></div>
</body>
</html>

<p></p>

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

--_D943A961-83E3-4622-B875-90C2B1A66DFC_--

.

------=_Part_646_14110350.1386696398347
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

you probably need `uninitialized_vector` not `std::vector`.
probably most of your needs would be fulfilled by warper around array of=20
unions.


On Tuesday, December 10, 2013 6:58:51 AM UTC+1, wsdwsd wrote:
>
>  =93uninitialized_resize()=94s not enough.
> We should both have uninitialized_resize(), uninitialized_push_back(),=20
> uninitialized_emplace_back,uninitialized_insert.
> The uses of them are quite different.
> in many conditions uninitialized_resize() can=92t replace=20
> uninitialized_push_back().
> I have posted the condition on the net. You could read it.
> We should add them all, do you understand??
>
> Sent from Windows Mail
>
>=20

--=20

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

------=_Part_646_14110350.1386696398347
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">you probably need `uninitialized_vector` not `std::vector`=
..<br>probably most of your needs would be fulfilled by warper around array =
of unions.<br><br><br>On Tuesday, December 10, 2013 6:58:51 AM UTC+1, wsdws=
d 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">
<div dir=3D"ltr" style=3D"font-family:'Calibri','Microsoft YaHei UI','Segoe=
 UI','Meiryo','Microsoft JhengHei UI','Malgun Gothic','sans-serif';font-siz=
e:12pt"><div style=3D"color:rgb(0,0,0)">=93uninitialized_resize()=94s not e=
nough.</div><div style=3D"color:rgb(0,0,0)">We should both have uninitializ=
ed_resize(), uninitialized_push_back(), uninitialized_emplace_back,<wbr>uni=
nitialized_insert.</div><div style=3D"color:rgb(0,0,0)">The uses of them ar=
e quite different.</div><div style=3D"color:rgb(0,0,0)">in many conditions =
uninitialized_resize() can=92t replace uninitialized_push_back().</div><div=
 style=3D"color:rgb(0,0,0)">I have posted the condition on the net. You cou=
ld read it.</div><div style=3D"color:rgb(0,0,0)">We should add them all, do=
 you understand??<br></div><div style=3D"color:rgb(0,0,0)"><div style=3D"co=
lor:rgb(0,0,0)"><br></div><div style=3D"color:rgb(0,0,0)">Sent from Windows=
 Mail</div><br></div></div>
</div>

</blockquote></div>

<p></p>

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

------=_Part_646_14110350.1386696398347--

.

------=_Part_807_12769673.1386719628381
Content-Type: text/plain; charset=ISO-8859-1

Has anyone really proposed an uninitialized_resize() which would only move
the end pointer for any T? I know I haven't, which is why I called it
resize_default_constructed().

As per your exception related reasons, and many other things it would be
very unwise to allow an uninitialized_resize(), but I think that a resize
which calls the default ctor for each element instead of the value ctor
would be very useful for vectors of simple types, as the vector would then
do the same initialization as an uninitialized scalar variable of the same
type for all types. To me this is totally logical, and I even suggest that
it was a mistake from the beginning that vector<int>::resize() clears the
elements as it now does. That said, of course there is now some code out
there that relies on such resize() clearing the ints, which is why I
suggested the name resize_default_constructed().

For more complex types where the default constructor (mandatorily) does the
same thing as the value constructor from () it is probably of little
consequence to do the end pointer increment each time. With a nothrow
default constructor or (after inlining) a constructor that the compiler can
know to be implicitly nothrow this will get optimized away anyway. This
means that the only case that the current vector does not cater for is
avoiding the default clearing of simple types.

Another solution that I have thought about is to introduce a special type
"default_constructed" or something like that, and have the built in types
(int, char, bool etc, and all pointers) have ctors that take this type of
argument and don't do anything. Then a resize_emplaced() function with an
object of this type as the second parameter could be used to explicitly
non-initialize a vector<int> etc. The added benefit would be that any class
could be equipped with a constructor from default_constructed which does
whatever it wants to do. This would be beneficial to some template code I
presume. Note that regrettably the resize_emplaced() function is needed
asfor a regular resize() the one uninitialized object would get copied to
all the new vector elements, probably at a higher cost than the current
clearing operation. The resize_emplaced() function would have some
additional benefit in other situations, I guess.

Den tisdagen den 10:e december 2013 kl. 06:14:43 UTC+1 skrev Zhihao Yuan:
>
> On Sun, Sep 8, 2013 at 3:17 PM,  <Victor....@ncl.ac.uk <javascript:>>
> wrote:
> >
> > On Sunday, September 8, 2013 4:18:56 PM UTC+1, Bengt Gustafsson wrote:
> >>
> >> We could consider a totally different way to handle this, which also
> has
> >> other uses. Admittedly, this can easily crash if misused (just as index
> out
> >> of range or too many push_back_ calls). I will call this tentatively
> >> uninitialized_resize(size_t sz). It just moves the end pointer and
> >> reallocates as required, but leaves the new elements uninitialized.
> >
> >
> > I think this will never be adopted as vector no longer can enforce its
> > invariants. Example:
> > {
> >     vector<Widget> v;
> >     v.uninitialized_resize(10);
> >     // at this point the desctructors are called, resulting in a crash
> > }
>
> AFAICS this is intended.  The vector can only be destructed
> when the invariants are back to work; thus, until the 10 elements
> are filled in.  If an exception is thrown before this is done, UB.
>
> PS: It does not mean I'm in favor of this pattern.
>
> Sorry for replying dated posts.
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>

--

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

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

<div dir=3D"ltr">Has anyone really proposed an uninitialized_resize() which=
 would only move the end pointer for any T? I know I haven't, which is why =
I called it resize_default_constructed().<div><br></div><div>As per your ex=
ception related reasons, and many other things it would be very unwise to a=
llow an uninitialized_resize(), but I think that a resize which calls the d=
efault ctor for each element instead of the value ctor would be very useful=
 for vectors of simple types, as the vector would then do the same initiali=
zation as an uninitialized scalar variable of the same type for all types. =
To me this is totally logical, and I even suggest that it was a mistake fro=
m the beginning that vector&lt;int&gt;::resize() clears the elements as it =
now does. That said, of course there is now some code out there that relies=
 on such resize() clearing the ints, which is why I suggested the name resi=
ze_default_constructed().</div><div><br></div><div>For more complex types w=
here the default constructor (mandatorily) does the same thing as the value=
 constructor from () it is probably of little consequence to do the end poi=
nter increment each time. With a nothrow default constructor or (after inli=
ning) a constructor that the compiler can know to be implicitly nothrow thi=
s will get optimized away anyway. This means that the only case that the cu=
rrent vector does not cater for is avoiding the default clearing of simple =
types.</div><div><br></div><div>Another solution that I have thought about =
is to introduce a special type "default_constructed" or something like that=
, and have the built in types (int, char, bool etc, and all pointers) have =
ctors that take this type of argument and don't do anything. Then a resize_=
emplaced() function with an object of this type as the second parameter cou=
ld be used to explicitly non-initialize a vector&lt;int&gt; etc. The added =
benefit would be that any class could be equipped with a constructor from d=
efault_constructed which does whatever it wants to do. This would be benefi=
cial to some template code I presume. Note that regrettably the resize_empl=
aced() function is needed asfor a regular resize() the one uninitialized ob=
ject would get copied to all the new vector elements, probably at a higher =
cost than the current clearing operation. The resize_emplaced() function wo=
uld have some additional benefit in other situations, I guess.<br><br>Den t=
isdagen den 10:e december 2013 kl. 06:14:43 UTC+1 skrev Zhihao Yuan:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Sun, Sep 8, 2013 at 3:17 PM, &nbsp=
;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Zxy=
HlFeR_aYJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">Victor....@ncl.ac.uk</a>&gt; wr=
ote:
<br>&gt;
<br>&gt; On Sunday, September 8, 2013 4:18:56 PM UTC+1, Bengt Gustafsson wr=
ote:
<br>&gt;&gt;
<br>&gt;&gt; We could consider a totally different way to handle this, whic=
h also has
<br>&gt;&gt; other uses. Admittedly, this can easily crash if misused (just=
 as index out
<br>&gt;&gt; of range or too many push_back_ calls). I will call this tenta=
tively
<br>&gt;&gt; uninitialized_resize(size_t sz). It just moves the end pointer=
 and
<br>&gt;&gt; reallocates as required, but leaves the new elements uninitial=
ized.
<br>&gt;
<br>&gt;
<br>&gt; I think this will never be adopted as vector no longer can enforce=
 its
<br>&gt; invariants. Example:
<br>&gt; {
<br>&gt; &nbsp; &nbsp; vector&lt;Widget&gt; v;
<br>&gt; &nbsp; &nbsp; v.uninitialized_resize(10);
<br>&gt; &nbsp; &nbsp; // at this point the desctructors are called, result=
ing in a crash
<br>&gt; }
<br>
<br>AFAICS this is intended. &nbsp;The vector can only be destructed
<br>when the invariants are back to work; thus, until the 10 elements
<br>are filled in. &nbsp;If an exception is thrown before this is done, UB.
<br>
<br>PS: It does not mean I'm in favor of this pattern.
<br>
<br>Sorry for replying dated posts.
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank" onmousedown=3D"t=
his.href=3D'http://www.google.com/url?q\75http%3A%2F%2F4bsd.biz%2F\46sa\75D=
\46sntz\0751\46usg\75AFQjCNEEohiBBmXaBWMbzqBFWtWEgT5t9g';return true;" oncl=
ick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2F4bsd.biz%2F\=
46sa\75D\46sntz\0751\46usg\75AFQjCNEEohiBBmXaBWMbzqBFWtWEgT5t9g';return tru=
e;">http://4bsd.biz/</a>
<br></blockquote></div></div>

<p></p>

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

------=_Part_807_12769673.1386719628381--

.

------=_Part_68_28912046.1386883365866
Content-Type: text/plain; charset=ISO-8859-1


On Tuesday, 10 December 2013 23:53:48 UTC, Bengt Gustafsson wrote:
>
> For more complex types where the default constructor (mandatorily) does
> the same thing as the value constructor from () it is probably of little
> consequence to do the end pointer increment each time. With a nothrow
> default constructor or (after inlining) a constructor that the compiler can
> know to be implicitly nothrow this will get optimized away anyway. This
> means that the only case that the current vector does not cater for is
> avoiding the default clearing of simple types.
>

I'd tend to agree that calling default constructor would have been a good
idea from the start. It wouldn't, however, solve the situation for more
complex types. There are plenty of small classes that wrap an int, a
pointer, or bitfields, but have non-trivial invariants, e.g. (ptr==nullptr
|| ptr points to an object in a heap), val>=0, val!=UNDEFINED, etc., and so
their default constructors would actually do something (or even not
available). E.g. vector<unique_ptr<T>> is particularly common. Hence
unchecked_push_back and unchecked_emplace_back would be useful anyway.

--

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

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

<div dir=3D"ltr"><br>On Tuesday, 10 December 2013 23:53:48 UTC, Bengt Gusta=
fsson  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>For more co=
mplex types where the default constructor (mandatorily) does the same thing=
 as the value constructor from () it is probably of little consequence to d=
o the end pointer increment each time. With a nothrow default constructor o=
r (after inlining) a constructor that the compiler can know to be implicitl=
y nothrow this will get optimized away anyway. This means that the only cas=
e that the current vector does not cater for is avoiding the default cleari=
ng of simple types.<br></div></div></blockquote><div><br></div><div>I'd ten=
d to agree that calling default constructor would have been a good idea fro=
m the start. It wouldn't, however, solve the situation for more complex typ=
es. There are plenty of small classes that wrap an int, a pointer, or&nbsp;=
bitfields, but have non-trivial invariants, e.g. (ptr=3D=3Dnullptr || ptr p=
oints to an object in a heap), val&gt;=3D0, val!=3DUNDEFINED, etc., and so =
their default constructors would actually do something (or even not availab=
le).&nbsp;E.g. vector&lt;unique_ptr&lt;T&gt;&gt; is particularly common.&nb=
sp;Hence unchecked_push_back and unchecked_emplace_back&nbsp;would be usefu=
l anyway.</div></div>

<p></p>

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

------=_Part_68_28912046.1386883365866--

.

--_0D3FCEF3-1CB9-4B88-B129-CEE7FDCF62F2_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1

It is a poor idea to limit the ability of vector. There will always be some=
 programmers who need use them.






Sent from Windows Mail





From: Victor.Khomenko@ncl.ac.uk
Sent: Friday, December 13, 2013 5:22 AM
To: std-proposals@isocpp.org






On Tuesday, 10 December 2013 23:53:48 UTC, Bengt Gustafsson wrote:


For more complex types where the default constructor (mandatorily) does the=
 same thing as the value constructor from () it is probably of little conse=
quence to do the end pointer increment each time. With a nothrow default co=
nstructor or (after inlining) a constructor that the compiler can know to b=
e implicitly nothrow this will get optimized away anyway. This means that t=
he only case that the current vector does not cater for is avoiding the def=
ault clearing of simple types.





I'd tend to agree that calling default constructor would have been a good i=
dea from the start. It wouldn't, however, solve the situation for more comp=
lex types. There are plenty of small classes that wrap an int, a pointer, o=
r bitfields, but have non-trivial invariants, e.g. (ptr=3D=3Dnullptr || ptr=
 points to an object in a heap), val>=3D0, val!=3DUNDEFINED, etc., and so t=
heir default constructors would actually do something (or even not availabl=
e). E.g. vector<unique_ptr<T>> is particularly common. Hence unchecked_push=
_back and unchecked_emplace_back would be useful anyway.

--=20
=20
---=20
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.or=
g/d/topic/std-proposals/5BnNHEr07QM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--=20

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

--_0D3FCEF3-1CB9-4B88-B129-CEE7FDCF62F2_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1


<html>
<head>
<meta name=3D"generator" content=3D"Windows Mail 17.5.9600.20315">
<style data-externalstyle=3D"true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin:0in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParag=
raphCxSpFirst,=20
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListPar=
agraphCxSpMiddle,=20
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagra=
phCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style></head>
<body dir=3D"ltr">
<div data-externalstyle=3D"false" dir=3D"ltr" style=3D"font-family: 'Calibr=
i', 'Microsoft YaHei UI', 'Segoe UI', 'Meiryo', 'Microsoft JhengHei UI', 'M=
algun Gothic', 'sans-serif';font-size:12pt;"><div style=3D"color: rgb(0, 0,=
 0);">It is a poor idea to limit the ability&nbsp;of vector. There will alw=
ays be some programmers who need use them.<br></div><div style=3D"color: rg=
b(0, 0, 0);" data-signatureblock=3D"true"><div style=3D"color: rgb(0, 0, 0)=
;"><br></div><div style=3D"color: rgb(0, 0, 0);">Sent from Windows Mail</di=
v><div style=3D"color: rgb(0, 0, 0);"><br></div></div><div style=3D"padding=
-top: 5px; border-top-color: rgb(229, 229, 229); border-top-width: 1px; bor=
der-top-style: solid;"><div><font face=3D" 'Calibri', 'Microsoft YaHei UI',=
 'Segoe UI', 'Meiryo', 'Microsoft JhengHei UI', 'Malgun Gothic', 'sans-seri=
f'" style=3D'line-height: 15pt; letter-spacing: 0.02em; font-family: "Calib=
ri", "Microsoft YaHei UI", "Segoe UI", "Meiryo", "Microsoft JhengHei UI", "=
Malgun Gothic", "sans-serif"; font-size: 12pt;'><b>From:</b>&nbsp;<a href=
=3D"mailto:Victor.Khomenko@ncl.ac.uk" target=3D"_parent">Victor.Khomenko@nc=
l.ac.uk</a><br><b>Sent:</b>&nbsp;Friday, December 13, 2013 5:22 AM<br><b>To=
:</b>&nbsp;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_parent">s=
td-proposals@isocpp.org</a></font></div></div><div><br></div><div dir=3D"">=
<div dir=3D"ltr"><br>On Tuesday, 10 December 2013 23:53:48 UTC, Bengt Gusta=
fsson  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>For more co=
mplex types where the default constructor (mandatorily) does the same thing=
 as the value constructor from () it is probably of little consequence to d=
o the end pointer increment each time. With a nothrow default constructor o=
r (after inlining) a constructor that the compiler can know to be implicitl=
y nothrow this will get optimized away anyway. This means that the only cas=
e that the current vector does not cater for is avoiding the default cleari=
ng of simple types.<br></div></div></blockquote><div><br></div><div>I'd ten=
d to agree that calling default constructor would have been a good idea fro=
m the start. It wouldn't, however, solve the situation for more complex typ=
es. There are plenty of small classes that wrap an int, a pointer, or&nbsp;=
bitfields, but have non-trivial invariants, e.g. (ptr=3D=3Dnullptr || ptr p=
oints to an object in a heap), val&gt;=3D0, val!=3DUNDEFINED, etc., and so =
their default constructors would actually do something (or even not availab=
le).&nbsp;E.g. vector&lt;unique_ptr&lt;T&gt;&gt; is particularly common.&nb=
sp;Hence unchecked_push_back and unchecked_emplace_back&nbsp;would be usefu=
l anyway.</div></div>

<p></p>

-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe" target=3D"_pare=
nt">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07Q=
M/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.<br>
To post to this group, send email to std-proposals@isocpp.org.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_parent">http://groups.google.com/a/isocpp.org/gr=
oup/std-proposals/</a>.<br>
</div></div>
</body>
</html>

<p></p>

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

--_0D3FCEF3-1CB9-4B88-B129-CEE7FDCF62F2_--

.

------=_Part_146_25880094.1386941003639
Content-Type: text/plain; charset=ISO-8859-1

On Friday, December 13, 2013 8:53:13 AM UTC+1, wsdwsd wrote:
>
>  There are plenty of small classes that wrap an int, a pointer,
> or bitfields, but have non-trivial invariants, e.g. (ptr==nullptr || ptr
> points to an object in a heap), val>=0, val!=UNDEFINED, etc., and so their
> default constructors would actually do something (or even not
> available). E.g. vector<unique_ptr<T>> is particularly common. Hence
> unchecked_push_back and unchecked_emplace_back would be useful anyway.
>
> Wait what. Tell me I misunderstood.

Are you saying that since there are classes that actually hold invariants
(i.e. you know, like *real* classes with encapsulation and stuff), vector
needs to support a way to break those invariants by not calling their
constructors?


--

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

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

<div dir=3D"ltr">On Friday, December 13, 2013 8:53:13 AM UTC+1, wsdwsd wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">




<div dir=3D"ltr">
<div dir=3D"ltr" style=3D"font-family:'Calibri','Microsoft YaHei UI','Segoe=
 UI','Meiryo','Microsoft JhengHei UI','Malgun Gothic','sans-serif';font-siz=
e:12pt"><div dir=3D""><div dir=3D"ltr"><div>There are plenty of small class=
es that wrap an int, a pointer, or&nbsp;bitfields, but have non-trivial inv=
ariants, e.g. (ptr=3D=3Dnullptr || ptr points to an object in a heap), val&=
gt;=3D0, val!=3DUNDEFINED, etc., and so their default constructors would ac=
tually do something (or even not available).&nbsp;E.g. vector&lt;unique_ptr=
&lt;T&gt;&gt; is particularly common.&nbsp;Hence unchecked_push_back and un=
checked_emplace_back&nbsp;would be useful anyway.</div></div>

<p></p>

</div></div></div></blockquote><div>Wait what. Tell me I misunderstood.<br>=
<br>Are you saying that since there are classes that actually hold invarian=
ts (i.e. you know, like *real* classes with encapsulation and stuff), vecto=
r needs to support a way to break those invariants by not calling their con=
structors?<br>&nbsp;</div></div>

<p></p>

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

------=_Part_146_25880094.1386941003639--

.

--047d7b6d9b1cfd14f904ed6a7ca4
Content-Type: text/plain; charset=ISO-8859-1

From what I understand, unchecked_push_back would just skip the check that
there's enough storage and unconditionally copy- (or move-) construct the
object. The place where the object will be constructed was previously
allocated by calling reserve, but no object exists there (same as when you
call reserve now), nothing half-constructed will be destroyed in case of an
exception, etc. so invariants are never broken. Only the capacity check is
skipped when you know there is enough space.


2013/12/13 R. Martinho Fernandes <martinho.fernandes@gmail.com>

> On Friday, December 13, 2013 8:53:13 AM UTC+1, wsdwsd wrote:
>>
>>  There are plenty of small classes that wrap an int, a pointer,
>> or bitfields, but have non-trivial invariants, e.g. (ptr==nullptr || ptr
>> points to an object in a heap), val>=0, val!=UNDEFINED, etc., and so their
>> default constructors would actually do something (or even not
>> available). E.g. vector<unique_ptr<T>> is particularly common. Hence
>> unchecked_push_back and unchecked_emplace_back would be useful anyway.
>>
>> Wait what. Tell me I misunderstood.
>
> Are you saying that since there are classes that actually hold invariants
> (i.e. you know, like *real* classes with encapsulation and stuff), vector
> needs to support a way to break those invariants by not calling their
> constructors?
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

--047d7b6d9b1cfd14f904ed6a7ca4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">From what I understand, unchecked_push_back would just ski=
p the check that there&#39;s enough storage and unconditionally copy- (or m=
ove-) construct the object. The place where the object will be constructed =
was previously allocated by calling reserve, but no object exists there (sa=
me as when you call reserve now), nothing half-constructed will be destroye=
d in case of an exception, etc. so invariants are never broken. Only the ca=
pacity check is skipped when you know there is enough space.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/12/13 R.=
 Martinho Fernandes <span dir=3D"ltr">&lt;<a href=3D"mailto:martinho.fernan=
des@gmail.com" target=3D"_blank">martinho.fernandes@gmail.com</a>&gt;</span=
><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im">On Friday, December 13, 2013 8:53:13 AM =
UTC+1, wsdwsd wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir=3D"ltr">
<div dir=3D"ltr" style=3D"font-family:&#39;Calibri&#39;,&#39;Microsoft YaHe=
i UI&#39;,&#39;Segoe UI&#39;,&#39;Meiryo&#39;,&#39;Microsoft JhengHei UI&#3=
9;,&#39;Malgun Gothic&#39;,&#39;sans-serif&#39;;font-size:12pt"><div dir=3D=
"">
<div dir=3D"ltr"><div>There are plenty of small classes that wrap an int, a=
 pointer, or=A0bitfields, but have non-trivial invariants, e.g. (ptr=3D=3Dn=
ullptr || ptr points to an object in a heap), val&gt;=3D0, val!=3DUNDEFINED=
, etc., and so their default constructors would actually do something (or e=
ven not available).=A0E.g. vector&lt;unique_ptr&lt;T&gt;&gt; is particularl=
y common.=A0Hence unchecked_push_back and unchecked_emplace_back=A0would be=
 useful anyway.</div>
</div>

<p></p>

</div></div></div></blockquote></div><div>Wait what. Tell me I misunderstoo=
d.<br><br>Are you saying that since there are classes that actually hold in=
variants (i.e. you know, like *real* classes with encapsulation and stuff),=
 vector needs to support a way to break those invariants by not calling the=
ir constructors?<br>
=A0</div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--047d7b6d9b1cfd14f904ed6a7ca4--

.

------=_Part_188_28973459.1386973748727
Content-Type: text/plain; charset=ISO-8859-1



On Friday, 13 December 2013 13:23:23 UTC, R. Martinho Fernandes wrote:
>
> On Friday, December 13, 2013 8:53:13 AM UTC+1, wsdwsd wrote:
>>
>>  There are plenty of small classes that wrap an int, a pointer,
>> or bitfields, but have non-trivial invariants, e.g. (ptr==nullptr || ptr
>> points to an object in a heap), val>=0, val!=UNDEFINED, etc., and so their
>> default constructors would actually do something (or even not
>> available). E.g. vector<unique_ptr<T>> is particularly common. Hence
>> unchecked_push_back and unchecked_emplace_back would be useful anyway.
>>
>> Wait what. Tell me I misunderstood.
>
> Are you saying that since there are classes that actually hold invariants
> (i.e. you know, like *real* classes with encapsulation and stuff), vector
> needs to support a way to break those invariants by not calling their
> constructors?
>


You misunderstood ;-)  (as Xavi Gratal explained).

BTW, you quoting my text as if it were wsdwsd's - were you actually
replying to some different post?



--

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

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

<div dir=3D"ltr"><br><br>On Friday, 13 December 2013 13:23:23 UTC, R. Marti=
nho Fernandes  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Frida=
y, December 13, 2013 8:53:13 AM UTC+1, wsdwsd wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-le=
ft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: so=
lid;">




<div dir=3D"ltr">
<div style=3D'font-family: "Calibri","Microsoft YaHei UI","Segoe UI","Meiry=
o","Microsoft JhengHei UI","Malgun Gothic","sans-serif"; font-size: 12pt;' =
dir=3D"ltr"><div dir=3D""><div dir=3D"ltr"><div>There are plenty of small c=
lasses that wrap an int, a pointer, or&nbsp;bitfields, but have non-trivial=
 invariants, e.g. (ptr=3D=3Dnullptr || ptr points to an object in a heap), =
val&gt;=3D0, val!=3DUNDEFINED, etc., and so their default constructors woul=
d actually do something (or even not available).&nbsp;E.g. vector&lt;unique=
_ptr&lt;T&gt;&gt; is particularly common.&nbsp;Hence unchecked_push_back an=
d unchecked_emplace_back&nbsp;would be useful anyway.</div></div>

<p></p>

</div></div></div></blockquote><div>Wait what. Tell me I misunderstood.<br>=
<br>Are you saying that since there are classes that actually hold invarian=
ts (i.e. you know, like *real* classes with encapsulation and stuff), vecto=
r needs to support a way to break those invariants by not calling their con=
structors?<br></div></div></blockquote><div><br></div><div><br></div><div>Y=
ou misunderstood ;-)&nbsp; (as Xavi Gratal explained).</div><div><br></div>=
<div>BTW, you quoting my text as if it were wsdwsd's - were you actually re=
plying to some different post?</div><div><br></div><div>&nbsp;</div></div>

<p></p>

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

------=_Part_188_28973459.1386973748727--

.

Oh, I'm really sorry about the misquote. This thing shows up in
separate threads so I got confused and messed up.
Mit freundlichen Gr=FC=DFen,

Martinho


On Fri, Dec 13, 2013 at 11:29 PM,  <Victor.Khomenko@ncl.ac.uk> wrote:
>
>
> On Friday, 13 December 2013 13:23:23 UTC, R. Martinho Fernandes wrote:
>>
>> On Friday, December 13, 2013 8:53:13 AM UTC+1, wsdwsd wrote:
>>>
>>> There are plenty of small classes that wrap an int, a pointer, or
>>> bitfields, but have non-trivial invariants, e.g. (ptr=3D=3Dnullptr || p=
tr points
>>> to an object in a heap), val>=3D0, val!=3DUNDEFINED, etc., and so their=
 default
>>> constructors would actually do something (or even not available). E.g.
>>> vector<unique_ptr<T>> is particularly common. Hence unchecked_push_back=
 and
>>> unchecked_emplace_back would be useful anyway.
>>
>> Wait what. Tell me I misunderstood.
>>
>> Are you saying that since there are classes that actually hold invariant=
s
>> (i.e. you know, like *real* classes with encapsulation and stuff), vecto=
r
>> needs to support a way to break those invariants by not calling their
>> constructors?
>
>
>
> You misunderstood ;-)  (as Xavi Gratal explained).
>
> BTW, you quoting my text as if it were wsdwsd's - were you actually reply=
ing
> to some different post?
>
>
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/JVvRGhkVwgc/=
unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20

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

.

--089e0160cdf85e84d104eed777f3
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Dec 10, 2013 at 6:53 PM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> Has anyone really proposed an uninitialized_resize() which would only move
> the end pointer for any T? I know I haven't, which is why I called it
> resize_default_constructed().
>
> Isn't this  what 'resize(size_type)' already does?

Note that since C++11 the original 'resize(size_type,const T& = T() )' was
split into two signatures, one without an argument that will default
construct the new elements and another with an argument that will
copy-construct from the second argument.

   David

--

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

--089e0160cdf85e84d104eed777f3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Dec 10, 2013 at 6:53 PM, Bengt Gustafsson <span dir=3D"ltr">&lt;<a =
href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gusta=
fsson@beamways.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Has anyone really proposed =
an uninitialized_resize() which would only move the end pointer for any T? =
I know I haven&#39;t, which is why I called it resize_default_constructed()=
..<div>
<br></div></div></blockquote><div>Isn&#39;t this =A0what &#39;resize(size_t=
ype)&#39; already does? <br><br>Note that since C++11 the original &#39;res=
ize(size_type,const T&amp; =3D T() )&#39; was split into two signatures, on=
e without an argument that will default construct the new elements and anot=
her with an argument that will copy-construct from the second argument.<br>
<br>=A0 =A0David</div></div></div></div>

<p></p>

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

--089e0160cdf85e84d104eed777f3--

.

--e89a8ff1cbda974b4604eed872f3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It was split, but it still does default-construction of the elements in the
vector. The behavior desired by other posters here is that the contents of
the vector are garbage-init'd.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Dec 31, 2013 at 8:58 AM, David Rodr=EDguez Ibeas <dibeas@ieee.org>w=
rote:

>
> On Tue, Dec 10, 2013 at 6:53 PM, Bengt Gustafsson <
> bengt.gustafsson@beamways.com> wrote:
>
>> Has anyone really proposed an uninitialized_resize() which would only
>> move the end pointer for any T? I know I haven't, which is why I called =
it
>> resize_default_constructed().
>>
>> Isn't this  what 'resize(size_type)' already does?
>
> Note that since C++11 the original 'resize(size_type,const T& =3D T() )' =
was
> split into two signatures, one without an argument that will default
> construct the new elements and another with an argument that will
> copy-construct from the second argument.
>
>    David
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">It was split, but it still does default-construction of th=
e elements in the vector. The behavior desired by other posters here is tha=
t the contents of the vector are garbage-init&#39;d.</div><div class=3D"gma=
il_extra">

<br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a =
href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://github=
..com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users/82=
320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/bil=
ly-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Dec 31, 2013 at 8:58 AM, David R=
odr=EDguez Ibeas <span dir=3D"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" t=
arget=3D"_blank">dibeas@ieee.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Dec 10, 2013 at 6:53 PM, Bengt Gustafsson <span dir=3D"ltr">&lt;<a =
href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gusta=
fsson@beamways.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Has anyone really proposed =
an uninitialized_resize() which would only move the end pointer for any T? =
I know I haven&#39;t, which is why I called it resize_default_constructed()=
..<div>


<br></div></div></blockquote><div>Isn&#39;t this =A0what &#39;resize(size_t=
ype)&#39; already does? <br><br>Note that since C++11 the original &#39;res=
ize(size_type,const T&amp; =3D T() )&#39; was split into two signatures, on=
e without an argument that will default construct the new elements and anot=
her with an argument that will copy-construct from the second argument.<spa=
n class=3D"HOEnZb"><font color=3D"#888888"><br>


<br>=A0 =A0David</font></span></div></div></div></div><span class=3D"HOEnZb=
"><font color=3D"#888888">

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--e89a8ff1cbda974b4604eed872f3--

.

--089e0122f6aa96d98604eed966b0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ah thanks,

   What I was missing is that the requirement on 'resize(size_type)' is to
do *value-initialization*. The default-construction will actually do what
is being asked for (a default constructed 'int' has an unspecified value,
likewise for 'struct S { int a, b; };') I imagine that the requirement is
there to maintain the same semantics present in C++03 (where the default
value for the second argument is *value-initialized*).

David


On Tue, Dec 31, 2013 at 1:07 PM, Billy O'Neal <billy.oneal@gmail.com> wrote=
:

> It was split, but it still does default-construction of the elements in
> the vector. The behavior desired by other posters here is that the conten=
ts
> of the vector are garbage-init'd.
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Tue, Dec 31, 2013 at 8:58 AM, David Rodr=EDguez Ibeas <dibeas@ieee.org=
>wrote:
>
>>
>> On Tue, Dec 10, 2013 at 6:53 PM, Bengt Gustafsson <
>> bengt.gustafsson@beamways.com> wrote:
>>
>>> Has anyone really proposed an uninitialized_resize() which would only
>>> move the end pointer for any T? I know I haven't, which is why I called=
 it
>>> resize_default_constructed().
>>>
>>> Isn't this  what 'resize(size_type)' already does?
>>
>> Note that since C++11 the original 'resize(size_type,const T& =3D T() )'
>> was split into two signatures, one without an argument that will default
>> construct the new elements and another with an argument that will
>> copy-construct from the second argument.
>>
>>    David
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

--089e0122f6aa96d98604eed966b0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Ah thanks,<br><br>=A0 =A0What I was missing is that the re=
quirement on &#39;resize(size_type)&#39; is to do *value-initialization*. T=
he default-construction will actually do what is being asked for (a default=
 constructed &#39;int&#39; has an unspecified value, likewise for &#39;stru=
ct S { int a, b; };&#39;) I imagine that the requirement is there to mainta=
in the same semantics present in C++03 (where the default value for the sec=
ond argument is *value-initialized*).<br>
<br>David</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote=
">On Tue, Dec 31, 2013 at 1:07 PM, Billy O&#39;Neal <span dir=3D"ltr">&lt;<=
a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail=
..com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">It was split, but it still =
does default-construction of the elements in the vector. The behavior desir=
ed by other posters here is that the contents of the vector are garbage-ini=
t&#39;d.</div>
<div class=3D"gmail_extra"><div class=3D"im">

<br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a =
href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://github=
..com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users/82=
320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/bil=
ly-oneal</a></div>


<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br></div><div class=3D"gmail_quote"><div><div class=3D"h5">On Tue, Dec=
 31, 2013 at 8:58 AM, David Rodr=EDguez Ibeas <span dir=3D"ltr">&lt;<a href=
=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.org</a>&gt;</span=
> wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Dec 10, 2013 at 6:53 PM, Bengt Gustafsson <span dir=3D"ltr">&lt;<a =
href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gusta=
fsson@beamways.com</a>&gt;</span> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Has anyone really proposed =
an uninitialized_resize() which would only move the end pointer for any T? =
I know I haven&#39;t, which is why I called it resize_default_constructed()=
..<div>



<br></div></div></blockquote><div>Isn&#39;t this =A0what &#39;resize(size_t=
ype)&#39; already does? <br><br>Note that since C++11 the original &#39;res=
ize(size_type,const T&amp; =3D T() )&#39; was split into two signatures, on=
e without an argument that will default construct the new elements and anot=
her with an argument that will copy-construct from the second argument.<spa=
n><font color=3D"#888888"><br>



<br>=A0 =A0David</font></span></div></div></div></div></div></div><span><fo=
nt color=3D"#888888">

<p></p>

-- <br><div class=3D"im">
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></font></span></blockquote></div><br></div><div class=3D"HOEnZb"><div=
 class=3D"h5">

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--089e0122f6aa96d98604eed966b0--

.

--001a1133056a23d60904eed9a11d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sorry, I was speaking informally. The values do get initialized. They do
not get garbage-init.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Dec 31, 2013 at 11:16 AM, David Rodr=EDguez Ibeas <dibeas@ieee.org>=
wrote:

> Ah thanks,
>
>    What I was missing is that the requirement on 'resize(size_type)' is t=
o
> do *value-initialization*. The default-construction will actually do what
> is being asked for (a default constructed 'int' has an unspecified value,
> likewise for 'struct S { int a, b; };') I imagine that the requirement is
> there to maintain the same semantics present in C++03 (where the default
> value for the second argument is *value-initialized*).
>
> David
>
>
> On Tue, Dec 31, 2013 at 1:07 PM, Billy O'Neal <billy.oneal@gmail.com>wrot=
e:
>
>> It was split, but it still does default-construction of the elements in
>> the vector. The behavior desired by other posters here is that the conte=
nts
>> of the vector are garbage-init'd.
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/users/82320/billy-oneal
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Tue, Dec 31, 2013 at 8:58 AM, David Rodr=EDguez Ibeas <dibeas@ieee.or=
g>wrote:
>>
>>>
>>> On Tue, Dec 10, 2013 at 6:53 PM, Bengt Gustafsson <
>>> bengt.gustafsson@beamways.com> wrote:
>>>
>>>> Has anyone really proposed an uninitialized_resize() which would only
>>>> move the end pointer for any T? I know I haven't, which is why I calle=
d it
>>>> resize_default_constructed().
>>>>
>>>> Isn't this  what 'resize(size_type)' already does?
>>>
>>> Note that since C++11 the original 'resize(size_type,const T& =3D T() )=
'
>>> was split into two signatures, one without an argument that will defaul=
t
>>> construct the new elements and another with an argument that will
>>> copy-construct from the second argument.
>>>
>>>    David
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

--001a1133056a23d60904eed9a11d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry, I was speaking informally. The values do get initia=
lized. They do not get garbage-init.</div><div class=3D"gmail_extra"><br cl=
ear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=
=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://github.com=
/BillyONeal/</a></div>

<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Dec 31, 2013 at 11:16 AM, David =
Rodr=EDguez Ibeas <span dir=3D"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" =
target=3D"_blank">dibeas@ieee.org</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">

<div dir=3D"ltr">Ah thanks,<br><br>=A0 =A0What I was missing is that the re=
quirement on &#39;resize(size_type)&#39; is to do *value-initialization*. T=
he default-construction will actually do what is being asked for (a default=
 constructed &#39;int&#39; has an unspecified value, likewise for &#39;stru=
ct S { int a, b; };&#39;) I imagine that the requirement is there to mainta=
in the same semantics present in C++03 (where the default value for the sec=
ond argument is *value-initialized*).<span class=3D"HOEnZb"><font color=3D"=
#888888"><br>


<br>David</font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div c=
lass=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Dec 31, 201=
3 at 1:07 PM, Billy O&#39;Neal <span dir=3D"ltr">&lt;<a href=3D"mailto:bill=
y.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail.com</a>&gt;</span> w=
rote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">It was split, but it still does default-c=
onstruction of the elements in the vector. The behavior desired by other po=
sters here is that the contents of the vector are garbage-init&#39;d.</div>


<div class=3D"gmail_extra"><div>

<br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a =
href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://github=
..com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users/82=
320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/bil=
ly-oneal</a></div>




<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br></div><div class=3D"gmail_quote"><div><div>On Tue, Dec 31, 2013 at =
8:58 AM, David Rodr=EDguez Ibeas <span dir=3D"ltr">&lt;<a href=3D"mailto:di=
beas@ieee.org" target=3D"_blank">dibeas@ieee.org</a>&gt;</span> wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:=
1px;border-left-style:solid"><div><div>

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Dec 10, 2013 at 6:53 PM, Bengt Gustafsson <span dir=3D"ltr">&lt;<a =
href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gusta=
fsson@beamways.com</a>&gt;</span> wrote:<br>





<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">Has anyone really proposed an uninitializ=
ed_resize() which would only move the end pointer for any T? I know I haven=
&#39;t, which is why I called it resize_default_constructed().<div>





<br></div></div></blockquote><div>Isn&#39;t this =A0what &#39;resize(size_t=
ype)&#39; already does? <br><br>Note that since C++11 the original &#39;res=
ize(size_type,const T&amp; =3D T() )&#39; was split into two signatures, on=
e without an argument that will default construct the new elements and anot=
her with an argument that will copy-construct from the second argument.<spa=
n><font color=3D"#888888"><br>





<br>=A0 =A0David</font></span></div></div></div></div></div></div><span><fo=
nt color=3D"#888888">

<p></p>

-- <br><div>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></font></span></blockquote></div><br></div><div><div>

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a1133056a23d60904eed9a11d--

.

--_d7d1cbc1-8b15-429d-bb53-5a754089d71c_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1

You may misunderstand my means. I mean unsafe_resize unsafe_push_back etc o=
perations will make vector more useful. Some people need these operations. =
Although  these operations shouldn't be used frequently. We should use vect=
ors to avoid new/malloc arrays.

Sent from my Windows Phone
________________________________
From: Billy O'Neal<mailto:billy.oneal@gmail.com>
Sent: 2014/1/1 3:33
To: std-proposals<mailto:std-proposals@isocpp.org>
Subject: Re: [std-proposals] proposal to add vector::push_back_()

Sorry, I was speaking informally. The values do get initialized. They do
not get garbage-init.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Dec 31, 2013 at 11:16 AM, David Rodr=EDguez Ibeas <dibeas@ieee.org>=
wrote:

> Ah thanks,
>
>    What I was missing is that the requirement on 'resize(size_type)' is t=
o
> do *value-initialization*. The default-construction will actually do what
> is being asked for (a default constructed 'int' has an unspecified value,
> likewise for 'struct S { int a, b; };') I imagine that the requirement is
> there to maintain the same semantics present in C++03 (where the default
> value for the second argument is *value-initialized*).
>
> David
>
>
> On Tue, Dec 31, 2013 at 1:07 PM, Billy O'Neal <billy.oneal@gmail.com>wrot=
e:
>
>> It was split, but it still does default-construction of the elements in
>> the vector. The behavior desired by other posters here is that the conte=
nts
>> of the vector are garbage-init'd.
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/users/82320/billy-oneal
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Tue, Dec 31, 2013 at 8:58 AM, David Rodr=EDguez Ibeas <dibeas@ieee.or=
g>wrote:
>>
>>>
>>> On Tue, Dec 10, 2013 at 6:53 PM, Bengt Gustafsson <
>>> bengt.gustafsson@beamways.com> wrote:
>>>
>>>> Has anyone really proposed an uninitialized_resize() which would only
>>>> move the end pointer for any T? I know I haven't, which is why I calle=
d it
>>>> resize_default_constructed().
>>>>
>>>> Isn't this  what 'resize(size_type)' already does?
>>>
>>> Note that since C++11 the original 'resize(size_type,const T& =3D T() )=
'
>>> was split into two signatures, one without an argument that will defaul=
t
>>> construct the new elements and another with an argument that will
>>> copy-construct from the second argument.
>>>
>>>    David
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.or=
g/d/topic/std-proposals/5BnNHEr07QM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--=20

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

--_d7d1cbc1-8b15-429d-bb53-5a754089d71c_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
</head>
<body>
<div>
<div style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">You may mis=
understand my means. I mean unsafe_resize unsafe_push_back etc operations w=
ill make vector more useful. Some people need these operations. Although&nb=
sp; these operations shouldn't be used
 frequently. We should use vectors to avoid new/malloc arrays.<br>
<br>
Sent from my Windows Phone</div>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGH=
T: bold">From:
</span><span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><a =
href=3D"mailto:billy.oneal@gmail.com">Billy O'Neal</a></span><br>
<span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGH=
T: bold">Sent:
</span><span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">201=
4/1/1 3:33</span><br>
<span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGH=
T: bold">To:
</span><span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><a =
href=3D"mailto:std-proposals@isocpp.org">std-proposals</a></span><br>
<span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGH=
T: bold">Subject:
</span><span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">Re:=
 [std-proposals] proposal to add vector::push_back_()</span><br>
<br>
</div>
<div>
<div dir=3D"ltr">Sorry, I was speaking informally. The values do get initia=
lized. They do not get garbage-init.</div>
<div class=3D"x_gmail_extra"><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>Billy O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:=
//github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div class=3D"x_gmail_quote">On Tue, Dec 31, 2013 at 11:16 AM, David Rodr=
=EDguez Ibeas
<span dir=3D"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">=
dibeas@ieee.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0 0 0 .8ex; border-left=
:1px #ccc solid; padding-left:1ex">
<div dir=3D"ltr">Ah thanks,<br>
<br>
&nbsp; &nbsp;What I was missing is that the requirement on 'resize(size_typ=
e)' is to do *value-initialization*. The default-construction will actually=
 do what is being asked for (a default constructed 'int' has an unspecified=
 value, likewise for 'struct S { int a, b;
 };') I imagine that the requirement is there to maintain the same semantic=
s present in C&#43;&#43;03 (where the default value for the second argument=
 is *value-initialized*).<span class=3D"x_HOEnZb"><font color=3D"#888888"><=
br>
<br>
David</font></span></div>
<div class=3D"x_HOEnZb">
<div class=3D"x_h5">
<div class=3D"x_gmail_extra"><br>
<br>
<div class=3D"x_gmail_quote">On Tue, Dec 31, 2013 at 1:07 PM, Billy O'Neal =
<span dir=3D"ltr">
&lt;<a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@=
gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; padd=
ing-left:1ex; border-left-color:rgb(204,204,204); border-left-width:1px; bo=
rder-left-style:solid">
<div dir=3D"ltr">It was split, but it still does default-construction of th=
e elements in the vector. The behavior desired by other posters here is tha=
t the contents of the vector are garbage-init'd.</div>
<div class=3D"x_gmail_extra">
<div><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>Billy O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:=
//github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div>
</div>
</div>
<br>
<br>
</div>
<div class=3D"x_gmail_quote">
<div>
<div>On Tue, Dec 31, 2013 at 8:58 AM, David Rodr=EDguez Ibeas <span dir=3D"=
ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.o=
rg</a>&gt;</span> wrote:<br>
</div>
</div>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; padd=
ing-left:1ex; border-left-color:rgb(204,204,204); border-left-width:1px; bo=
rder-left-style:solid">
<div>
<div>
<div dir=3D"ltr">
<div class=3D"x_gmail_extra"><br>
<div class=3D"x_gmail_quote">On Tue, Dec 10, 2013 at 6:53 PM, Bengt Gustafs=
son <span dir=3D"ltr">
&lt;<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">beng=
t.gustafsson@beamways.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; padd=
ing-left:1ex; border-left-color:rgb(204,204,204); border-left-width:1px; bo=
rder-left-style:solid">
<div dir=3D"ltr">Has anyone really proposed an uninitialized_resize() which=
 would only move the end pointer for any T? I know I haven't, which is why =
I called it resize_default_constructed().
<div><br>
</div>
</div>
</blockquote>
<div>Isn't this &nbsp;what 'resize(size_type)' already does? <br>
<br>
Note that since C&#43;&#43;11 the original 'resize(size_type,const T&amp; =
=3D T() )' was split into two signatures, one without an argument that will=
 default construct the new elements and another with an argument that will =
copy-construct from the second argument.<span><font color=3D"#888888"><br>
<br>
&nbsp; &nbsp;David</font></span></div>
</div>
</div>
</div>
</div>
</div>
<span><font color=3D"#888888">
<p></p>
-- <br>
<div>&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C&#43;&#43; 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&#43;unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</font></span></blockquote>
</div>
<br>
</div>
<div>
<div>
<p></p>
-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C&#43;&#43; 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&#43;unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<p></p>
-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C&#43;&#43; 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&#43;unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<p></p>
-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C&#43;&#43; Standard - Future Proposals&quot; group.<br=
>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe">
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/un=
subscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to std-pro=
posals&#43;unsubscribe@isocpp.org.<br>
To post to this group, send email to std-proposals@isocpp.org.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</body>
</html>

<p></p>

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

--_d7d1cbc1-8b15-429d-bb53-5a754089d71c_--

.

--089e011613aed0328c04eedeeefb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

You misunderstand the criticism. It isn't that this would never be useful,
it is that there are plenty of workarounds to get the behavior you want
without modifying vector; and that the utility is relatively small.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Dec 31, 2013 at 5:39 PM, wsdwsd <euloanty@live.com> wrote:

>  You may misunderstand my means. I mean unsafe_resize unsafe_push_back
> etc operations will make vector more useful. Some people need these
> operations. Although  these operations shouldn't be used frequently. We
> should use vectors to avoid new/malloc arrays.
>
> Sent from my Windows Phone
>  ------------------------------
> From: Billy O'Neal <billy.oneal@gmail.com>
> Sent: 2014/1/1 3:33
> To: std-proposals <std-proposals@isocpp.org>
> Subject: Re: [std-proposals] proposal to add vector::push_back_()
>
>  Sorry, I was speaking informally. The values do get initialized. They do
> not get garbage-init.
>
>  Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Tue, Dec 31, 2013 at 11:16 AM, David Rodr=EDguez Ibeas <dibeas@ieee.or=
g>wrote:
>
> Ah thanks,
>
>    What I was missing is that the requirement on 'resize(size_type)' is t=
o
> do *value-initialization*. The default-construction will actually do what
> is being asked for (a default constructed 'int' has an unspecified value,
> likewise for 'struct S { int a, b; };') I imagine that the requirement is
> there to maintain the same semantics present in C++03 (where the default
> value for the second argument is *value-initialized*).
>
> David
>
>
> On Tue, Dec 31, 2013 at 1:07 PM, Billy O'Neal <billy.oneal@gmail.com>wrot=
e:
>
> It was split, but it still does default-construction of the elements in
> the vector. The behavior desired by other posters here is that the conten=
ts
> of the vector are garbage-init'd.
>
>  Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
>   On Tue, Dec 31, 2013 at 8:58 AM, David Rodr=EDguez Ibeas <dibeas@ieee.o=
rg>wrote:
>
>
> On Tue, Dec 10, 2013 at 6:53 PM, Bengt Gustafsson <
> bengt.gustafsson@beamways.com> wrote:
>
> Has anyone really proposed an uninitialized_resize() which would only mov=
e
> the end pointer for any T? I know I haven't, which is why I called it
> resize_default_constructed().
>
>   Isn't this  what 'resize(size_type)' already does?
>
> Note that since C++11 the original 'resize(size_type,const T& =3D T() )' =
was
> split into two signatures, one without an argument that will default
> construct the new elements and another with an argument that will
> copy-construct from the second argument.
>
>    David
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>   --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>  --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

--089e011613aed0328c04eedeeefb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You misunderstand the criticism. It isn&#39;t that this wo=
uld never be useful, it is that there are plenty of workarounds to get the =
behavior you want without modifying vector; and that the utility is relativ=
ely small.</div>

<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" targe=
t=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http:/=
/stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stacko=
verflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Dec 31, 2013 at 5:39 PM, wsdwsd =
<span dir=3D"ltr">&lt;<a href=3D"mailto:euloanty@live.com" target=3D"_blank=
">euloanty@live.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>





<div>
<div>
<div style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif">You may misund=
erstand my means. I mean unsafe_resize unsafe_push_back etc operations will=
 make vector more useful. Some people need these operations. Although=A0 th=
ese operations shouldn&#39;t be used
 frequently. We should use vectors to avoid new/malloc arrays.<br>
<br>
Sent from my Windows Phone</div>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bo=
ld">From:
</span><span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif"><a hre=
f=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">Billy O&#39;Neal</a></=
span><br>
<span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bo=
ld">Sent:
</span><span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif">2014/1=
/1 3:33</span><br>
<span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bo=
ld">To:
</span><span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif"><a hre=
f=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals</a></=
span><br>
<span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif;FONT-WEIGHT:bo=
ld">Subject:
</span><span style=3D"FONT-SIZE:11pt;FONT-FAMILY:Calibri,sans-serif">Re: [s=
td-proposals] proposal to add vector::push_back_()</span><br>
<br>
</div>
<div>
<div dir=3D"ltr">Sorry, I was speaking informally. The values do get initia=
lized. They do not get garbage-init.</div>
<div><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>Billy O&#39;Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:=
//github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div>On Tue, Dec 31, 2013 at 11:16 AM, David Rodr=EDguez Ibeas
<span dir=3D"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">=
dibeas@ieee.org</a>&gt;</span> wrote:<br>
<blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<div dir=3D"ltr">Ah thanks,<br>
<br>
=A0 =A0What I was missing is that the requirement on &#39;resize(size_type)=
&#39; is to do *value-initialization*. The default-construction will actual=
ly do what is being asked for (a default constructed &#39;int&#39; has an u=
nspecified value, likewise for &#39;struct S { int a, b;
 };&#39;) I imagine that the requirement is there to maintain the same sema=
ntics present in C++03 (where the default value for the second argument is =
*value-initialized*).<span><font color=3D"#888888"><br>
<br>
David</font></span></div>
<div>
<div>
<div><br>
<br>
<div>On Tue, Dec 31, 2013 at 1:07 PM, Billy O&#39;Neal <span dir=3D"ltr">
&lt;<a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@=
gmail.com</a>&gt;</span> wrote:<br>
<blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-=
color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">It was split, but it still does default-construction of th=
e elements in the vector. The behavior desired by other posters here is tha=
t the contents of the vector are garbage-init&#39;d.</div>
<div>
<div><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>Billy O&#39;Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:=
//github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div>
</div>
</div>
<br>
<br>
</div>
<div>
<div>
<div>On Tue, Dec 31, 2013 at 8:58 AM, David Rodr=EDguez Ibeas <span dir=3D"=
ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.o=
rg</a>&gt;</span> wrote:<br>
</div>
</div>
<blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-=
color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div>
<div>
<div dir=3D"ltr">
<div><br>
<div>On Tue, Dec 10, 2013 at 6:53 PM, Bengt Gustafsson <span dir=3D"ltr">
&lt;<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">beng=
t.gustafsson@beamways.com</a>&gt;</span> wrote:<br>
<blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-=
color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">Has anyone really proposed an uninitialized_resize() which=
 would only move the end pointer for any T? I know I haven&#39;t, which is =
why I called it resize_default_constructed().
<div><br>
</div>
</div>
</blockquote>
<div>Isn&#39;t this =A0what &#39;resize(size_type)&#39; already does? <br>
<br>
Note that since C++11 the original &#39;resize(size_type,const T&amp; =3D T=
() )&#39; was split into two signatures, one without an argument that will =
default construct the new elements and another with an argument that will c=
opy-construct from the second argument.<span><font color=3D"#888888"><br>


<br>
=A0 =A0David</font></span></div>
</div>
</div>
</div>
</div>
</div>
<span><font color=3D"#888888">
<p></p>
-- <br>
<div>=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</font></span></blockquote>
</div>
<br>
</div>
<div>
<div>
<p></p>
-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<p></p>
-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<span class=
=3D"HOEnZb"><font color=3D"#888888"><br>
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></blockquote><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<br>
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe" target=3D"_blan=
k">
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/un=
subscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">


<p></p>

-- <br>
=A0<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@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--089e011613aed0328c04eedeeefb--

.

--_338fc70b-3165-425c-80e0-3b46e1ede9b1_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1

I think it's no.. If we have them, less new[] will be used.

Sent from my Windows Phone
________________________________
From: Billy O'Neal<mailto:billy.oneal@gmail.com>
Sent: 2014/1/1 9:52
To: std-proposals<mailto:std-proposals@isocpp.org>
Subject: Re: [std-proposals] proposal to add vector::push_back_()

You misunderstand the criticism. It isn't that this would never be useful,
it is that there are plenty of workarounds to get the behavior you want
without modifying vector; and that the utility is relatively small.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Tue, Dec 31, 2013 at 5:39 PM, wsdwsd <euloanty@live.com> wrote:

>  You may misunderstand my means. I mean unsafe_resize unsafe_push_back
> etc operations will make vector more useful. Some people need these
> operations. Although  these operations shouldn't be used frequently. We
> should use vectors to avoid new/malloc arrays.
>
> Sent from my Windows Phone
>  ------------------------------
> From: Billy O'Neal <billy.oneal@gmail.com>
> Sent: 2014/1/1 3:33
> To: std-proposals <std-proposals@isocpp.org>
> Subject: Re: [std-proposals] proposal to add vector::push_back_()
>
>  Sorry, I was speaking informally. The values do get initialized. They do
> not get garbage-init.
>
>  Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Tue, Dec 31, 2013 at 11:16 AM, David Rodr=EDguez Ibeas <dibeas@ieee.or=
g>wrote:
>
> Ah thanks,
>
>    What I was missing is that the requirement on 'resize(size_type)' is t=
o
> do *value-initialization*. The default-construction will actually do what
> is being asked for (a default constructed 'int' has an unspecified value,
> likewise for 'struct S { int a, b; };') I imagine that the requirement is
> there to maintain the same semantics present in C++03 (where the default
> value for the second argument is *value-initialized*).
>
> David
>
>
> On Tue, Dec 31, 2013 at 1:07 PM, Billy O'Neal <billy.oneal@gmail.com>wrot=
e:
>
> It was split, but it still does default-construction of the elements in
> the vector. The behavior desired by other posters here is that the conten=
ts
> of the vector are garbage-init'd.
>
>  Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
>   On Tue, Dec 31, 2013 at 8:58 AM, David Rodr=EDguez Ibeas <dibeas@ieee.o=
rg>wrote:
>
>
> On Tue, Dec 10, 2013 at 6:53 PM, Bengt Gustafsson <
> bengt.gustafsson@beamways.com> wrote:
>
> Has anyone really proposed an uninitialized_resize() which would only mov=
e
> the end pointer for any T? I know I haven't, which is why I called it
> resize_default_constructed().
>
>   Isn't this  what 'resize(size_type)' already does?
>
> Note that since C++11 the original 'resize(size_type,const T& =3D T() )' =
was
> split into two signatures, one without an argument that will default
> construct the new elements and another with an argument that will
> copy-construct from the second argument.
>
>    David
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>   --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>  --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.or=
g/d/topic/std-proposals/5BnNHEr07QM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-pro=
posals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--=20

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

--_338fc70b-3165-425c-80e0-3b46e1ede9b1_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
</head>
<body>
<div>
<div style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">I think it'=
s no.. If we have them, less new[] will be used.<br>
<br>
Sent from my Windows Phone</div>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGH=
T: bold">From:
</span><span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><a =
href=3D"mailto:billy.oneal@gmail.com">Billy O'Neal</a></span><br>
<span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGH=
T: bold">Sent:
</span><span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">201=
4/1/1 9:52</span><br>
<span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGH=
T: bold">To:
</span><span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif"><a =
href=3D"mailto:std-proposals@isocpp.org">std-proposals</a></span><br>
<span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGH=
T: bold">Subject:
</span><span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif">Re:=
 [std-proposals] proposal to add vector::push_back_()</span><br>
<br>
</div>
<div>
<div dir=3D"ltr">You misunderstand the criticism. It isn't that this would =
never be useful, it is that there are plenty of workarounds to get the beha=
vior you want without modifying vector; and that the utility is relatively =
small.</div>
<div class=3D"x_gmail_extra"><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>Billy O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:=
//github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div class=3D"x_gmail_quote">On Tue, Dec 31, 2013 at 5:39 PM, wsdwsd <span =
dir=3D"ltr">
&lt;<a href=3D"mailto:euloanty@live.com" target=3D"_blank">euloanty@live.co=
m</a>&gt;</span> wrote:<br>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0 0 0 .8ex; border-left=
:1px #ccc solid; padding-left:1ex">
<div>
<div>
<div style=3D"font-size:11pt; font-family:Calibri,sans-serif">You may misun=
derstand my means. I mean unsafe_resize unsafe_push_back etc operations wil=
l make vector more useful. Some people need these operations. Although&nbsp=
; these operations shouldn't be used frequently.
 We should use vectors to avoid new/malloc arrays.<br>
<br>
Sent from my Windows Phone</div>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"font-size:11pt; font-family:Calibri,sans-serif; font-weight:=
bold">From:
</span><span style=3D"font-size:11pt; font-family:Calibri,sans-serif"><a hr=
ef=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">Billy O'Neal</a></spa=
n><br>
<span style=3D"font-size:11pt; font-family:Calibri,sans-serif; font-weight:=
bold">Sent:
</span><span style=3D"font-size:11pt; font-family:Calibri,sans-serif">2014/=
1/1 3:33</span><br>
<span style=3D"font-size:11pt; font-family:Calibri,sans-serif; font-weight:=
bold">To:
</span><span style=3D"font-size:11pt; font-family:Calibri,sans-serif"><a hr=
ef=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals</a><=
/span><br>
<span style=3D"font-size:11pt; font-family:Calibri,sans-serif; font-weight:=
bold">Subject:
</span><span style=3D"font-size:11pt; font-family:Calibri,sans-serif">Re: [=
std-proposals] proposal to add vector::push_back_()</span><br>
<br>
</div>
<div>
<div dir=3D"ltr">Sorry, I was speaking informally. The values do get initia=
lized. They do not get garbage-init.</div>
<div><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>Billy O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:=
//github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div>
</div>
</div>
<br>
<br>
<div>On Tue, Dec 31, 2013 at 11:16 AM, David Rodr=EDguez Ibeas <span dir=3D=
"ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.=
org</a>&gt;</span> wrote:<br>
<blockquote style=3D"margin:0 0 0 .8ex; border-left:1px #ccc solid; padding=
-left:1ex">
<div dir=3D"ltr">Ah thanks,<br>
<br>
&nbsp; &nbsp;What I was missing is that the requirement on 'resize(size_typ=
e)' is to do *value-initialization*. The default-construction will actually=
 do what is being asked for (a default constructed 'int' has an unspecified=
 value, likewise for 'struct S { int a, b;
 };') I imagine that the requirement is there to maintain the same semantic=
s present in C&#43;&#43;03 (where the default value for the second argument=
 is *value-initialized*).<span><font color=3D"#888888"><br>
<br>
David</font></span></div>
<div>
<div>
<div><br>
<br>
<div>On Tue, Dec 31, 2013 at 1:07 PM, Billy O'Neal <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail.=
com</a>&gt;</span> wrote:<br>
<blockquote style=3D"margin:0px 0px 0px 0.8ex; padding-left:1ex; border-lef=
t-color:rgb(204,204,204); border-left-width:1px; border-left-style:solid">
<div dir=3D"ltr">It was split, but it still does default-construction of th=
e elements in the vector. The behavior desired by other posters here is tha=
t the contents of the vector are garbage-init'd.</div>
<div>
<div><br clear=3D"all">
<div>
<div dir=3D"ltr">
<div>Billy O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:=
//github.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div>
</div>
</div>
<br>
<br>
</div>
<div>
<div>
<div>On Tue, Dec 31, 2013 at 8:58 AM, David Rodr=EDguez Ibeas <span dir=3D"=
ltr">&lt;<a href=3D"mailto:dibeas@ieee.org" target=3D"_blank">dibeas@ieee.o=
rg</a>&gt;</span> wrote:<br>
</div>
</div>
<blockquote style=3D"margin:0px 0px 0px 0.8ex; padding-left:1ex; border-lef=
t-color:rgb(204,204,204); border-left-width:1px; border-left-style:solid">
<div>
<div>
<div dir=3D"ltr">
<div><br>
<div>On Tue, Dec 10, 2013 at 6:53 PM, Bengt Gustafsson <span dir=3D"ltr">&l=
t;<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.=
gustafsson@beamways.com</a>&gt;</span> wrote:<br>
<blockquote style=3D"margin:0px 0px 0px 0.8ex; padding-left:1ex; border-lef=
t-color:rgb(204,204,204); border-left-width:1px; border-left-style:solid">
<div dir=3D"ltr">Has anyone really proposed an uninitialized_resize() which=
 would only move the end pointer for any T? I know I haven't, which is why =
I called it resize_default_constructed().
<div><br>
</div>
</div>
</blockquote>
<div>Isn't this &nbsp;what 'resize(size_type)' already does? <br>
<br>
Note that since C&#43;&#43;11 the original 'resize(size_type,const T&amp; =
=3D T() )' was split into two signatures, one without an argument that will=
 default construct the new elements and another with an argument that will =
copy-construct from the second argument.<span><font color=3D"#888888"><br>
<br>
&nbsp; &nbsp;David</font></span></div>
</div>
</div>
</div>
</div>
</div>
<span><font color=3D"#888888">
<p></p>
-- <br>
<div>&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C&#43;&#43; 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&#43;unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</font></span></blockquote>
</div>
<br>
</div>
<div>
<div>
<p></p>
-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C&#43;&#43; 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&#43;unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<p></p>
-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C&#43;&#43; 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&#43;unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<span class=
=3D"x_HOEnZb"><font color=3D"#888888"><br>
</font></span></div>
<span class=3D"x_HOEnZb"><font color=3D"#888888"></font></span></div>
<span class=3D"x_HOEnZb"><font color=3D"#888888"></font></span></blockquote=
>
<span class=3D"x_HOEnZb"><font color=3D"#888888"></font></span></div>
<span class=3D"x_HOEnZb"><font color=3D"#888888"><br>
</font></span></div>
<span class=3D"x_HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C&#43;&#43; Standard - Future Proposals&quot; group.<br=
>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe" target=3D"_blan=
k">
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/un=
subscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">
std-proposals&#43;unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</font></span></div>
<span class=3D"x_HOEnZb"><font color=3D"#888888"></font></span></div>
<span class=3D"x_HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C&#43;&#43; 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&#43;unsubscribe@isocpp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</font></span></blockquote>
</div>
<br>
</div>
<p></p>
-- <br>
&nbsp;<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C&#43;&#43; Standard - Future Proposals&quot; group.<br=
>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/unsubscribe">
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/un=
subscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to std-pro=
posals&#43;unsubscribe@isocpp.org.<br>
To post to this group, send email to std-proposals@isocpp.org.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</div>
</body>
</html>

<p></p>

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

--_338fc70b-3165-425c-80e0-3b46e1ede9b1_--

.