On 18 November 2013 22:41,  <amluto@gmail.com> wrote:
> If basic_string had a method like resize_uninitialized that changed the size
> of the underlying array but did *not* construct the elements (with similar
> semantics to declaring an uninitialized local variable of type char).  This
> would only be allowed for sufficiently trivial character types.
>
> (std::vector has much the same issue.)
>
> Thoughts?

There are multiple previous threads proposing such facilities for vector.

The answer is no.

--

---
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_651_25305173.1384807891209
Content-Type: text/plain; charset=ISO-8859-1

On Monday, November 18, 2013 12:43:29 PM UTC-8, Ville Voutilainen wrote:
>
> On 18 November 2013 22:41,  <aml...@gmail.com <javascript:>> wrote:
> > If basic_string had a method like resize_uninitialized that changed the
> size
> > of the underlying array but did *not* construct the elements (with
> similar
> > semantics to declaring an uninitialized local variable of type char).
>  This
> > would only be allowed for sufficiently trivial character types.
> >
> > (std::vector has much the same issue.)
> >
> > Thoughts?
>
> There are multiple previous threads proposing such facilities for vector.
>
> The answer is no.
>

Do you have a link?  The closest I can come up with is:

https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/discussion

which is rather different.


--

---
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_651_25305173.1384807891209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, November 18, 2013 12:43:29 PM UTC-8, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 18 November 2=
013 22:41, &nbsp;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"WwwOHIOWudkJ">aml...@gmail.com</a>&gt; wrote:
<br>&gt; If basic_string had a method like resize_uninitialized that change=
d the size
<br>&gt; of the underlying array but did *not* construct the elements (with=
 similar
<br>&gt; semantics to declaring an uninitialized local variable of type cha=
r). &nbsp;This
<br>&gt; would only be allowed for sufficiently trivial character types.
<br>&gt;
<br>&gt; (std::vector has much the same issue.)
<br>&gt;
<br>&gt; Thoughts?
<br>
<br>There are multiple previous threads proposing such facilities for vecto=
r.
<br>
<br>The answer is no.
<br></blockquote><div><br>Do you have a link?&nbsp; The closest I can come =
up with is:<br><br>https://groups.google.com/a/isocpp.org/d/topic/std-propo=
sals/5BnNHEr07QM/discussion<br><br>which is rather different.<br>&nbsp;</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_651_25305173.1384807891209--

.

On 18 November 2013 22:51,  <amluto@gmail.com> wrote:
> On Monday, November 18, 2013 12:43:29 PM UTC-8, Ville Voutilainen wrote:
>>
>> On 18 November 2013 22:41,  <aml...@gmail.com> wrote:
>> > If basic_string had a method like resize_uninitialized that changed the
>> > size
>> > of the underlying array but did *not* construct the elements (with
>> > similar
>> > semantics to declaring an uninitialized local variable of type char).
>> > This
>> > would only be allowed for sufficiently trivial character types.
>> >
>> > (std::vector has much the same issue.)
>> >
>> > Thoughts?
>>
>> There are multiple previous threads proposing such facilities for vector.
>>
>> The answer is no.
>
>
> Do you have a link?  The closest I can come up with is:
>
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/discussion
>
> which is rather different.


What's the difference?

--

---
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_665_13521772.1384809043730
Content-Type: text/plain; charset=ISO-8859-1



On Monday, November 18, 2013 1:05:43 PM UTC-8, Ville Voutilainen wrote:
>
> On 18 November 2013 22:51,  <aml...@gmail.com <javascript:>> wrote:
> > On Monday, November 18, 2013 12:43:29 PM UTC-8, Ville Voutilainen wrote:
> >>
> >> On 18 November 2013 22:41,  <aml...@gmail.com> wrote:
> >> > If basic_string had a method like resize_uninitialized that changed
> the
> >> > size
> >> > of the underlying array but did *not* construct the elements (with
> >> > similar
> >> > semantics to declaring an uninitialized local variable of type char).
> >> > This
> >> > would only be allowed for sufficiently trivial character types.
> >> >
> >> > (std::vector has much the same issue.)
> >> >
> >> > Thoughts?
> >>
> >> There are multiple previous threads proposing such facilities for
> vector.
> >>
> >> The answer is no.
> >
> >
> > Do you have a link?  The closest I can come up with is:
> >
> >
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/5BnNHEr07QM/discussion
> >
> > which is rather different.
>
>
> What's the difference?
>


That thread is proposing an unchecked or somehow optimized variant of
push_back.  I'm proposing a way to change the *size* (not the capacity) of
a basic_string in constant time.  With resize_uninitialized, the string
would be in a completely valid state after resize_uninitialize; the
contents would just be arbitrary.  (On platforms that have trap values for
characters, the implementation might still have to initialize the data.
I'm not sure that such a platform exists, though.  In any case, there's
precedent for similar semantics to what I'm proposing: malloc and
get_temporary_buffer.)

--

---
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_665_13521772.1384809043730
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, November 18, 2013 1:05:43 PM UTC-8, Vil=
le Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 18 Nov=
ember 2013 22:51, &nbsp;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"wdR9aYlxcNYJ">aml...@gmail.com</a>&gt; wrote:
<br>&gt; On Monday, November 18, 2013 12:43:29 PM UTC-8, Ville Voutilainen =
wrote:
<br>&gt;&gt;
<br>&gt;&gt; On 18 November 2013 22:41, &nbsp;&lt;<a>aml...@gmail.com</a>&g=
t; wrote:
<br>&gt;&gt; &gt; If basic_string had a method like resize_uninitialized th=
at changed the
<br>&gt;&gt; &gt; size
<br>&gt;&gt; &gt; of the underlying array but did *not* construct the eleme=
nts (with
<br>&gt;&gt; &gt; similar
<br>&gt;&gt; &gt; semantics to declaring an uninitialized local variable of=
 type char).
<br>&gt;&gt; &gt; This
<br>&gt;&gt; &gt; would only be allowed for sufficiently trivial character =
types.
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; (std::vector has much the same issue.)
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; Thoughts?
<br>&gt;&gt;
<br>&gt;&gt; There are multiple previous threads proposing such facilities =
for vector.
<br>&gt;&gt;
<br>&gt;&gt; The answer is no.
<br>&gt;
<br>&gt;
<br>&gt; Do you have a link? &nbsp;The closest I can come up with is:
<br>&gt;
<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-prop=
osals/5BnNHEr07QM/discussion" target=3D"_blank">https://groups.google.com/a=
/<wbr>isocpp.org/d/topic/std-<wbr>proposals/5BnNHEr07QM/<wbr>discussion</a>
<br>&gt;
<br>&gt; which is rather different.
<br>
<br>
<br>What's the difference?
<br></blockquote><div><br><br>That thread is proposing an unchecked or some=
how optimized variant of push_back.&nbsp; I'm proposing a way to change the=
 *size* (not the capacity) of a basic_string in constant time.&nbsp; With r=
esize_uninitialized, the string would be in a completely valid state after =
resize_uninitialize; the contents would just be arbitrary.&nbsp; (On platfo=
rms that have trap values for characters, the implementation might still ha=
ve to initialize the data.&nbsp; I'm not sure that such a platform exists, =
though.&nbsp; In any case, there's precedent for similar semantics to what =
I'm proposing: malloc and get_temporary_buffer.)<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_665_13521772.1384809043730--

.

On 18 November 2013 23:10,  <amluto@gmail.com> wrote:
>> What's the difference?
> That thread is proposing an unchecked or somehow optimized variant of
> push_back.  I'm proposing a way to change the *size* (not the capacity) of a
> basic_string in constant time.  With resize_uninitialized, the string would
> be in a completely valid state after resize_uninitialize; the contents would
> just be arbitrary.  (On platforms that have trap values for characters, the
> implementation might still have to initialize the data.  I'm not sure that
> such a platform exists, though.  In any case, there's precedent for similar
> semantics to what I'm proposing: malloc and get_temporary_buffer.)


Yes? The thread proposes almost exactly that:
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/5BnNHEr07QM/3-6IBGwMWSQJ

--

---
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/.

.

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

Plenty of variants of a similar design were discussed there, too. In fact,
the exact name discussed was "uninitialized_resize"

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, Nov 18, 2013 at 1:10 PM, <amluto@gmail.com> wrote:

>
>
> On Monday, November 18, 2013 1:05:43 PM UTC-8, Ville Voutilainen wrote:
>
>> On 18 November 2013 22:51,  <aml...@gmail.com> wrote:
>> > On Monday, November 18, 2013 12:43:29 PM UTC-8, Ville Voutilainen
>> wrote:
>> >>
>> >> On 18 November 2013 22:41,  <aml...@gmail.com> wrote:
>> >> > If basic_string had a method like resize_uninitialized that changed
>> the
>> >> > size
>> >> > of the underlying array but did *not* construct the elements (with
>> >> > similar
>> >> > semantics to declaring an uninitialized local variable of type
>> char).
>> >> > This
>> >> > would only be allowed for sufficiently trivial character types.
>> >> >
>> >> > (std::vector has much the same issue.)
>> >> >
>> >> > Thoughts?
>> >>
>> >> There are multiple previous threads proposing such facilities for
>> vector.
>> >>
>> >> The answer is no.
>> >
>> >
>> > Do you have a link?  The closest I can come up with is:
>> >
>> > https://groups.google.com/a/isocpp.org/d/topic/std-
>> proposals/5BnNHEr07QM/discussion
>> >
>> > which is rather different.
>>
>>
>> What's the difference?
>>
>
>
> That thread is proposing an unchecked or somehow optimized variant of
> push_back.  I'm proposing a way to change the *size* (not the capacity) of
> a basic_string in constant time.  With resize_uninitialized, the string
> would be in a completely valid state after resize_uninitialize; the
> contents would just be arbitrary.  (On platforms that have trap values for
> characters, the implementation might still have to initialize the data.
> I'm not sure that such a platform exists, though.  In any case, there's
> precedent for similar semantics to what I'm proposing: malloc and
> get_temporary_buffer.)
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">Plenty of variants of a similar design were discussed ther=
e, too. In fact, the exact name discussed was &quot;uninitialized_resize&qu=
ot;</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/" ta=
rget=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"htt=
p://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://sta=
ckoverflow.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, Nov 18, 2013 at 1:10 PM,  <span =
dir=3D"ltr">&lt;<a href=3D"mailto:amluto@gmail.com" target=3D"_blank">amlut=
o@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><br><br>On Monday, November 18, 2013 1:05:43 PM UTC-8, Vil=
le Voutilainen wrote:<div class=3D"im"><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">

On 18 November 2013 22:51, =A0&lt;<a>aml...@gmail.com</a>&gt; wrote:
<br>&gt; On Monday, November 18, 2013 12:43:29 PM UTC-8, Ville Voutilainen =
wrote:
<br>&gt;&gt;
<br>&gt;&gt; On 18 November 2013 22:41, =A0&lt;<a>aml...@gmail.com</a>&gt; =
wrote:
<br>&gt;&gt; &gt; If basic_string had a method like resize_uninitialized th=
at changed the
<br>&gt;&gt; &gt; size
<br>&gt;&gt; &gt; of the underlying array but did *not* construct the eleme=
nts (with
<br>&gt;&gt; &gt; similar
<br>&gt;&gt; &gt; semantics to declaring an uninitialized local variable of=
 type char).
<br>&gt;&gt; &gt; This
<br>&gt;&gt; &gt; would only be allowed for sufficiently trivial character =
types.
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; (std::vector has much the same issue.)
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; Thoughts?
<br>&gt;&gt;
<br>&gt;&gt; There are multiple previous threads proposing such facilities =
for vector.
<br>&gt;&gt;
<br>&gt;&gt; The answer is no.
<br>&gt;
<br>&gt;
<br>&gt; Do you have a link? =A0The closest I can come up with is:
<br>&gt;
<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-prop=
osals/5BnNHEr07QM/discussion" target=3D"_blank">https://groups.google.com/a=
/<u></u>isocpp.org/d/topic/std-<u></u>proposals/5BnNHEr07QM/<u></u>discussi=
on</a>
<br>&gt;
<br>&gt; which is rather different.
<br>
<br>
<br>What&#39;s the difference?
<br></blockquote></div><div><br><br>That thread is proposing an unchecked o=
r somehow optimized variant of push_back.=A0 I&#39;m proposing a way to cha=
nge the *size* (not the capacity) of a basic_string in constant time.=A0 Wi=
th resize_uninitialized, the string would be in a completely valid state af=
ter resize_uninitialize; the contents would just be arbitrary.=A0 (On platf=
orms that have trap values for characters, the implementation might still h=
ave to initialize the data.=A0 I&#39;m not sure that such a platform exists=
, though.=A0 In any case, there&#39;s precedent for similar semantics to wh=
at I&#39;m proposing: malloc and get_temporary_buffer.)<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 />

--089e013d0dc0ca6ba304eb7a2513--

.

------=_Part_2049_30447326.1384809770907
Content-Type: text/plain; charset=ISO-8859-1

On Monday, November 18, 2013 1:18:58 PM UTC-8, Ville Voutilainen wrote:
>
> On 18 November 2013 23:10,  <aml...@gmail.com <javascript:>> wrote:
> >> What's the difference?
> > That thread is proposing an unchecked or somehow optimized variant of
> > push_back.  I'm proposing a way to change the *size* (not the capacity)
> of a
> > basic_string in constant time.  With resize_uninitialized, the string
> would
> > be in a completely valid state after resize_uninitialize; the contents
> would
> > just be arbitrary.  (On platforms that have trap values for characters,
> the
> > implementation might still have to initialize the data.  I'm not sure
> that
> > such a platform exists, though.  In any case, there's precedent for
> similar
> > semantics to what I'm proposing: malloc and get_temporary_buffer.)
>
>
> Yes? The thread proposes almost exactly that:
>
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/5BnNHEr07QM/3-6IBGwMWSQJ
>


That seems to have been a short aside in the thread, and it didn't mention
restricting it to trivial types.  There's certainly a problem with having a
vector that contains unconstructed values of non-trivial type.  On the
other hand, there's probably nothing wrong with arbitrary values of trivial
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_2049_30447326.1384809770907
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, November 18, 2013 1:18:58 PM UTC-8, Ville Vouti=
lainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 18 November 20=
13 23:10, &nbsp;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"e1ypZaOZpKwJ">aml...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; What's the difference?
<br>&gt; That thread is proposing an unchecked or somehow optimized variant=
 of
<br>&gt; push_back. &nbsp;I'm proposing a way to change the *size* (not the=
 capacity) of a
<br>&gt; basic_string in constant time. &nbsp;With resize_uninitialized, th=
e string would
<br>&gt; be in a completely valid state after resize_uninitialize; the cont=
ents would
<br>&gt; just be arbitrary. &nbsp;(On platforms that have trap values for c=
haracters, the
<br>&gt; implementation might still have to initialize the data. &nbsp;I'm =
not sure that
<br>&gt; such a platform exists, though. &nbsp;In any case, there's precede=
nt for similar
<br>&gt; semantics to what I'm proposing: malloc and get_temporary_buffer.)
<br>
<br>
<br>Yes? The thread proposes almost exactly that:
<br><a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/5=
BnNHEr07QM/3-6IBGwMWSQJ" target=3D"_blank">https://groups.google.com/a/<wbr=
>isocpp.org/d/msg/std-<wbr>proposals/5BnNHEr07QM/3-<wbr>6IBGwMWSQJ</a>
<br></blockquote><div><br><br>That seems to have been a short aside in the =
thread, and it didn't mention restricting it to trivial types.&nbsp; There'=
s certainly a problem with having a vector that contains unconstructed valu=
es of non-trivial type.&nbsp; On the other hand, there's probably nothing w=
rong with arbitrary values of trivial types. <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_2049_30447326.1384809770907--

.

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

The aside of the previous thread ended (I think) with my suggestion of a=20
new method vector::resize_default_constructed(). This method would call the=
=20
default constructor just like new T; does, not the value constructor like=
=20
new T() does. As these two new calls only differ for trivial types the new=
=20
resize method would be safe for any type (as safe as having an array of=20
that type at least). This thinking would of course carry over to=20
basic_string<T> as well.

The reasoning behind allowing calls to resize_default_constructed for any T=
=20
is to avoid having to specialize template code using vector<T> depending on=
=20
if the method is available or not for the T at hand.

When it comes to the quite common use case of composing a string using=20
several operator+() concatenations I have toyed with the idea of letting=20
the operator+() return a helper object which refers to its lhs and rhs and=
=20
only when all of the concatenations have been done and the result is=20
somehow used as a string does the references get resolved, the total=20
character count tallied, a suitably sized malloc block allocated and=20
finally the characters copied into it. I have not attempted to implement=20
such a thing, however, as I think there would be countless corner cases to=
=20
take care of. One of them would be auto x =3D string1 + string2; where ther=
e=20
is nothing to "drive" the actual concatenation before x is used, at which=
=20
time the strings may have changed value. The suggested operator auto() in=
=20
another thread would fix this particular issue, but there are probably many=
=20
worse ones involving functions being called that change values of strings=
=20
also partaking in the concatenation. Has anyone tried anything in this=20
direction at home?=20

Den m=E5ndagen den 18:e november 2013 kl. 22:22:50 UTC+1 skrev=20
aml...@gmail.com:
>
> On Monday, November 18, 2013 1:18:58 PM UTC-8, Ville Voutilainen wrote:
>>
>> On 18 November 2013 23:10,  <aml...@gmail.com> wrote:=20
>> >> What's the difference?=20
>> > That thread is proposing an unchecked or somehow optimized variant of=
=20
>> > push_back.  I'm proposing a way to change the *size* (not the capacity=
)=20
>> of a=20
>> > basic_string in constant time.  With resize_uninitialized, the string=
=20
>> would=20
>> > be in a completely valid state after resize_uninitialize; the contents=
=20
>> would=20
>> > just be arbitrary.  (On platforms that have trap values for characters=
,=20
>> the=20
>> > implementation might still have to initialize the data.  I'm not sure=
=20
>> that=20
>> > such a platform exists, though.  In any case, there's precedent for=20
>> similar=20
>> > semantics to what I'm proposing: malloc and get_temporary_buffer.)=20
>>
>>
>> Yes? The thread proposes almost exactly that:=20
>>
>> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/5BnNHEr07QM/3=
-6IBGwMWSQJ=20
>>
>
>
> That seems to have been a short aside in the thread, and it didn't mentio=
n=20
> restricting it to trivial types.  There's certainly a problem with having=
 a=20
> vector that contains unconstructed values of non-trivial type.  On the=20
> other hand, there's probably nothing wrong with arbitrary values of trivi=
al=20
> types.=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_2_14707738.1384814967632
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The aside of the previous thread ended (I think) with my s=
uggestion of a new method vector::resize_default_constructed(). This method=
 would call the default constructor just like new T; does, not the value co=
nstructor like new T() does. As these two new calls only differ for trivial=
 types the new resize method would be safe for any type (as safe as having =
an array of that type at least). This thinking would of course carry over t=
o basic_string&lt;T&gt; as well.<div><br></div><div>The reasoning behind al=
lowing calls to resize_default_constructed for any T is to avoid having to =
specialize template code using vector&lt;T&gt; depending on if the method i=
s available or not for the T at hand.</div><div><br></div><div>When it come=
s to the quite common use case of composing a string using several operator=
+() concatenations I have toyed with the idea of letting the operator+() re=
turn a helper object which refers to its lhs and rhs and only when all of t=
he concatenations have been done and the result is somehow used as a string=
 does the references get resolved, the total character count tallied, a sui=
tably sized malloc block allocated and finally the characters copied into i=
t. I have not attempted to implement such a thing, however, as I think ther=
e would be countless corner cases to take care of. One of them would be aut=
o x =3D string1 + string2; where there is nothing to "drive" the actual con=
catenation before x is used, at which time the strings may have changed val=
ue. The suggested operator auto() in another thread would fix this particul=
ar issue, but there are probably many worse ones involving functions being =
called that change values of strings also partaking in the concatenation. H=
as anyone tried anything in this direction at home?&nbsp;</div><div><br>Den=
 m=E5ndagen den 18:e november 2013 kl. 22:22:50 UTC+1 skrev aml...@gmail.co=
m:<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">On Monday, =
November 18, 2013 1:18:58 PM UTC-8, Ville Voutilainen wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex">On 18 November 2013 23:10, &nbsp;&lt;<a>aml...@gma=
il.com</a>&gt; wrote:
<br>&gt;&gt; What's the difference?
<br>&gt; That thread is proposing an unchecked or somehow optimized variant=
 of
<br>&gt; push_back. &nbsp;I'm proposing a way to change the *size* (not the=
 capacity) of a
<br>&gt; basic_string in constant time. &nbsp;With resize_uninitialized, th=
e string would
<br>&gt; be in a completely valid state after resize_uninitialize; the cont=
ents would
<br>&gt; just be arbitrary. &nbsp;(On platforms that have trap values for c=
haracters, the
<br>&gt; implementation might still have to initialize the data. &nbsp;I'm =
not sure that
<br>&gt; such a platform exists, though. &nbsp;In any case, there's precede=
nt for similar
<br>&gt; semantics to what I'm proposing: malloc and get_temporary_buffer.)
<br>
<br>
<br>Yes? The thread proposes almost exactly that:
<br><a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/5=
BnNHEr07QM/3-6IBGwMWSQJ" target=3D"_blank">https://groups.google.com/a/<wbr=
>isocpp.org/d/msg/std-<wbr>proposals/5BnNHEr07QM/3-<wbr>6IBGwMWSQJ</a>
<br></blockquote><div><br><br>That seems to have been a short aside in the =
thread, and it didn't mention restricting it to trivial types.&nbsp; There'=
s certainly a problem with having a vector that contains unconstructed valu=
es of non-trivial type.&nbsp; On the other hand, there's probably nothing w=
rong with arbitrary values of trivial types. <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_2_14707738.1384814967632--

.

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

It sounds like what you want should be a specialized type, not built in to
basic_string.

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, Nov 18, 2013 at 2:49 PM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> The aside of the previous thread ended (I think) with my suggestion of a
> new method vector::resize_default_constructed(). This method would call t=
he
> default constructor just like new T; does, not the value constructor like
> new T() does. As these two new calls only differ for trivial types the ne=
w
> resize method would be safe for any type (as safe as having an array of
> that type at least). This thinking would of course carry over to
> basic_string<T> as well.
>
> The reasoning behind allowing calls to resize_default_constructed for any
> T is to avoid having to specialize template code using vector<T> dependin=
g
> on if the method is available or not for the T at hand.
>
> When it comes to the quite common use case of composing a string using
> several operator+() concatenations I have toyed with the idea of letting
> the operator+() return a helper object which refers to its lhs and rhs an=
d
> only when all of the concatenations have been done and the result is
> somehow used as a string does the references get resolved, the total
> character count tallied, a suitably sized malloc block allocated and
> finally the characters copied into it. I have not attempted to implement
> such a thing, however, as I think there would be countless corner cases t=
o
> take care of. One of them would be auto x =3D string1 + string2; where th=
ere
> is nothing to "drive" the actual concatenation before x is used, at which
> time the strings may have changed value. The suggested operator auto() in
> another thread would fix this particular issue, but there are probably ma=
ny
> worse ones involving functions being called that change values of strings
> also partaking in the concatenation. Has anyone tried anything in this
> direction at home?
>
> Den m=E5ndagen den 18:e november 2013 kl. 22:22:50 UTC+1 skrev
> aml...@gmail.com:
>>
>> On Monday, November 18, 2013 1:18:58 PM UTC-8, Ville Voutilainen wrote:
>>>
>>> On 18 November 2013 23:10,  <aml...@gmail.com> wrote:
>>> >> What's the difference?
>>> > That thread is proposing an unchecked or somehow optimized variant of
>>> > push_back.  I'm proposing a way to change the *size* (not the
>>> capacity) of a
>>> > basic_string in constant time.  With resize_uninitialized, the string
>>> would
>>> > be in a completely valid state after resize_uninitialize; the content=
s
>>> would
>>> > just be arbitrary.  (On platforms that have trap values for
>>> characters, the
>>> > implementation might still have to initialize the data.  I'm not sure
>>> that
>>> > such a platform exists, though.  In any case, there's precedent for
>>> similar
>>> > semantics to what I'm proposing: malloc and get_temporary_buffer.)
>>>
>>>
>>> Yes? The thread proposes almost exactly that:
>>> https://groups.google.com/a/isocpp.org/d/msg/std-
>>> proposals/5BnNHEr07QM/3-6IBGwMWSQJ
>>>
>>
>>
>> That seems to have been a short aside in the thread, and it didn't
>> mention restricting it to trivial types.  There's certainly a problem wi=
th
>> having a vector that contains unconstructed values of non-trivial type. =
 On
>> the other hand, there's probably nothing wrong with arbitrary values of
>> trivial 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/.
>

--=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/.

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

<div dir=3D"ltr">It sounds like what you want should be a specialized type,=
 not built in to basic_string.</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"http=
s://bitbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyON=
eal/</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, Nov 18, 2013 at 2:49 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">The aside of the previous t=
hread ended (I think) with my suggestion of a new method vector::resize_def=
ault_constructed(). This method would call the default constructor just lik=
e new T; does, not the value constructor like new T() does. As these two ne=
w calls only differ for trivial types the new resize method would be safe f=
or any type (as safe as having an array of that type at least). This thinki=
ng would of course carry over to basic_string&lt;T&gt; as well.<div>

<br></div><div>The reasoning behind allowing calls to resize_default_constr=
ucted for any T is to avoid having to specialize template code using vector=
&lt;T&gt; depending on if the method is available or not for the T at hand.=
</div>

<div><br></div><div>When it comes to the quite common use case of composing=
 a string using several operator+() concatenations I have toyed with the id=
ea of letting the operator+() return a helper object which refers to its lh=
s and rhs and only when all of the concatenations have been done and the re=
sult is somehow used as a string does the references get resolved, the tota=
l character count tallied, a suitably sized malloc block allocated and fina=
lly the characters copied into it. I have not attempted to implement such a=
 thing, however, as I think there would be countless corner cases to take c=
are of. One of them would be auto x =3D string1 + string2; where there is n=
othing to &quot;drive&quot; the actual concatenation before x is used, at w=
hich time the strings may have changed value. The suggested operator auto()=
 in another thread would fix this particular issue, but there are probably =
many worse ones involving functions being called that change values of stri=
ngs also partaking in the concatenation. Has anyone tried anything in this =
direction at home?=A0</div>

<div><br>Den m=E5ndagen den 18:e november 2013 kl. 22:22:50 UTC+1 skrev <a =
href=3D"mailto:aml...@gmail.com" target=3D"_blank">aml...@gmail.com</a>:<bl=
ockquote 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;border-left=
-style:solid">

<div dir=3D"ltr">On Monday, November 18, 2013 1:18:58 PM UTC-8, Ville Vouti=
lainen 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">

On 18 November 2013 23:10, =A0&lt;<a>aml...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; What&#39;s the difference?
<br>&gt; That thread is proposing an unchecked or somehow optimized variant=
 of
<br>&gt; push_back. =A0I&#39;m proposing a way to change the *size* (not th=
e capacity) of a
<br>&gt; basic_string in constant time. =A0With resize_uninitialized, the s=
tring would
<br>&gt; be in a completely valid state after resize_uninitialize; the cont=
ents would
<br>&gt; just be arbitrary. =A0(On platforms that have trap values for char=
acters, the
<br>&gt; implementation might still have to initialize the data. =A0I&#39;m=
 not sure that
<br>&gt; such a platform exists, though. =A0In any case, there&#39;s preced=
ent for similar
<br>&gt; semantics to what I&#39;m proposing: malloc and get_temporary_buff=
er.)
<br>
<br>
<br>Yes? The thread proposes almost exactly that:
<br><a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/5=
BnNHEr07QM/3-6IBGwMWSQJ" target=3D"_blank">https://groups.google.com/a/<u><=
/u>isocpp.org/d/msg/std-<u></u>proposals/5BnNHEr07QM/3-<u></u>6IBGwMWSQJ</a=
>
<br></blockquote><div><br><br>That seems to have been a short aside in the =
thread, and it didn&#39;t mention restricting it to trivial types.=A0 There=
&#39;s certainly a problem with having a vector that contains unconstructed=
 values of non-trivial type.=A0 On the other hand, there&#39;s probably not=
hing wrong with arbitrary values of trivial types. <br>

</div></div></blockquote></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 />

--089e01228cb69fcfad04eb7b6412--

.

------=_Part_14_27128271.1384815250428
Content-Type: text/plain; charset=ISO-8859-1

On Monday, November 18, 2013 2:49:27 PM UTC-8, Bengt Gustafsson wrote:
>
> The aside of the previous thread ended (I think) with my suggestion of a
> new method vector::resize_default_constructed(). This method would call the
> default constructor just like new T; does, not the value constructor like
> new T() does. As these two new calls only differ for trivial types the new
> resize method would be safe for any type (as safe as having an array of
> that type at least). This thinking would of course carry over to
> basic_string<T> as well.
>
> The reasoning behind allowing calls to resize_default_constructed for any
> T is to avoid having to specialize template code using vector<T> depending
> on if the method is available or not for the T at hand.
>
> When it comes to the quite common use case of composing a string using
> several operator+() concatenations I have toyed with the idea of letting
> the operator+() return a helper object which refers to its lhs and rhs and
> only when all of the concatenations have been done and the result is
> somehow used as a string does the references get resolved, the total
> character count tallied, a suitably sized malloc block allocated and
> finally the characters copied into it. I have not attempted to implement
> such a thing, however, as I think there would be countless corner cases to
> take care of. One of them would be auto x = string1 + string2; where there
> is nothing to "drive" the actual concatenation before x is used, at which
> time the strings may have changed value. The suggested operator auto() in
> another thread would fix this particular issue, but there are probably many
> worse ones involving functions being called that change values of strings
> also partaking in the concatenation. Has anyone tried anything in this
> direction at home?
>

There are plenty of expression trees and such out there (mainly for things
like linear algebra).  The tricky case is when you want to concatenate
things that aren't strings into strings.

--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_14_27128271.1384815250428
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, November 18, 2013 2:49:27 PM UTC-8, Bengt Gusta=
fsson 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">T=
he aside of the previous thread ended (I think) with my suggestion of a new=
 method vector::resize_default_<wbr>constructed(). This method would call t=
he default constructor just like new T; does, not the value constructor lik=
e new T() does. As these two new calls only differ for trivial types the ne=
w resize method would be safe for any type (as safe as having an array of t=
hat type at least). This thinking would of course carry over to basic_strin=
g&lt;T&gt; as well.<div><br></div><div>The reasoning behind allowing calls =
to resize_default_constructed for any T is to avoid having to specialize te=
mplate code using vector&lt;T&gt; depending on if the method is available o=
r not for the T at hand.</div><div><br></div><div>When it comes to the quit=
e common use case of composing a string using several operator+() concatena=
tions I have toyed with the idea of letting the operator+() return a helper=
 object which refers to its lhs and rhs and only when all of the concatenat=
ions have been done and the result is somehow used as a string does the ref=
erences get resolved, the total character count tallied, a suitably sized m=
alloc block allocated and finally the characters copied into it. I have not=
 attempted to implement such a thing, however, as I think there would be co=
untless corner cases to take care of. One of them would be auto x =3D strin=
g1 + string2; where there is nothing to "drive" the actual concatenation be=
fore x is used, at which time the strings may have changed value. The sugge=
sted operator auto() in another thread would fix this particular issue, but=
 there are probably many worse ones involving functions being called that c=
hange values of strings also partaking in the concatenation. Has anyone tri=
ed anything in this direction at home?&nbsp;</div></div></blockquote><div><=
br>There are plenty of expression trees and such out there (mainly for thin=
gs like linear algebra).&nbsp; The tricky case is when you want to concaten=
ate things that aren't strings into strings.<br><br>--Andy</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_14_27128271.1384815250428--

.

------=_Part_2121_32478918.1384815379971
Content-Type: text/plain; charset=ISO-8859-1

On Monday, November 18, 2013 2:51:08 PM UTC-8, Billy O'Neal wrote:
>
> It sounds like what you want should be a specialized type, not built in to
> basic_string.
>
>
If you want that type to efficiently convert (or move-convert) to
basic_string, though, then you're stuck -- basic_string doesn't offer the
necessary facilities.  (That's the whole point of this thread.  I *have* a
specialized type for composing strings.  There's just no good way to get a
basic_string out of it.)

--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_2121_32478918.1384815379971
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, November 18, 2013 2:51:08 PM UTC-8, Billy O'Nea=
l 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">It so=
unds like what you want should be a specialized type, not built in to basic=
_string.</div><div><br clear=3D"all"></div></blockquote><div><br>If you wan=
t that type to efficiently convert (or move-convert) to basic_string, thoug=
h, then you're stuck -- basic_string doesn't offer the necessary facilities=
..&nbsp; (That's the whole point of this thread.&nbsp; I *have* a specialize=
d type for composing strings.&nbsp; There's just no good way to get a basic=
_string out of it.)<br><br>--Andy</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_2121_32478918.1384815379971--

.

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

Except everything you propose can be implemented in terms if .reserve() +
..insert()/.append(), so you do in fact have the necessary facilities. Sure,
those may be difficult to use in comparison, but they have the advantage
that 1. they don't break basic_string's invariants, and 2. they are already
in the standard and you can use them today.

If someone can show profiling data for a real world application where any
kind of conversion like this mattered, then perhaps it would make sense to
consider an application where a basic_string could "capture" a buffer
already allocated by a user. But this uninitialized_resize thing, IMHO,
induces far too many caveats.

It seems like for most of those cases where you would see a significant
perf win, you'd be better off avoiding the conversion back into
basic_string in the first place.

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, Nov 18, 2013 at 2:56 PM, <amluto@gmail.com> wrote:

> On Monday, November 18, 2013 2:51:08 PM UTC-8, Billy O'Neal wrote:
>>
>> It sounds like what you want should be a specialized type, not built in
>> to basic_string.
>>
>>
> If you want that type to efficiently convert (or move-convert) to
> basic_string, though, then you're stuck -- basic_string doesn't offer the
> necessary facilities.  (That's the whole point of this thread.  I *have* a
> specialized type for composing strings.  There's just no good way to get a
> basic_string out of it.)
>
> --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/.
>

--

---
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/.

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

<div dir=3D"ltr"><div>Except everything you propose can be implemented in t=
erms if .reserve() + .insert()/.append(), so you do in fact have the necess=
ary facilities. Sure, those may be difficult to use in comparison, but they=
 have the advantage that 1. they don&#39;t break basic_string&#39;s invaria=
nts, and 2. they are already in the standard and you can use them today.</d=
iv>

<div><br></div><div>If someone can show profiling data for a real world app=
lication where any kind of conversion like this mattered, then perhaps it w=
ould make sense to consider an application where a basic_string could &quot=
;capture&quot; a buffer already allocated by a user. But this uninitialized=
_resize thing, IMHO, induces far too many caveats.</div>

<div><br></div><div>It seems like for most of those cases where you would s=
ee a significant perf win, you&#39;d be better off avoiding the conversion =
back into basic_string in the first place.</div></div><div class=3D"gmail_e=
xtra">

<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 Mon, Nov 18, 2013 at 2:56 PM,  <span =
dir=3D"ltr">&lt;<a href=3D"mailto:amluto@gmail.com" target=3D"_blank">amlut=
o@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"im">On Monday, November 18, 2013 2:51:08 PM =
UTC-8, Billy O&#39;Neal wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: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 sounds like what you want should be a specialized type,=
 not built in to basic_string.</div><div><br clear=3D"all"></div></blockquo=
te></div><div><br>If you want that type to efficiently convert (or move-con=
vert) to basic_string, though, then you&#39;re stuck -- basic_string doesn&=
#39;t offer the necessary facilities.=A0 (That&#39;s the whole point of thi=
s thread.=A0 I *have* a specialized type for composing strings.=A0 There&#3=
9;s just no good way to get a basic_string out of it.)<br>

<br>--Andy</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 />

--089e013a10369af14004eb7b8700--

.

------=_Part_2053_28769986.1384816991550
Content-Type: text/plain; charset=ISO-8859-1

On Monday, November 18, 2013 3:00:54 PM UTC-8, Billy O'Neal wrote:
>
> Except everything you propose can be implemented in terms if .reserve() +
> .insert()/.append(), so you do in fact have the necessary facilities. Sure,
> those may be difficult to use in comparison, but they have the advantage
> that 1. they don't break basic_string's invariants, and 2. they are already
> in the standard and you can use them today.
>


I admit I haven't real every post on the other thread, but how is this
supposed to work now?  Suppose I want to do something as simple as:

string s;
s.reserve(BIG_ENOUGH);
char buf[BIG_ENOUGH];
sprintf(buf, "%.6f", something);

I can copy the data from buf to s using insert, or I could rewrite sprintf
to stick each character in using push_back (and hope that the optimizer is
really, really good), but neither of those is a real solution.  I want to
be able to do:

auto orig_size = s.size();
s.resize_default_initialized(orig_size + BIG_ENOUGH);  /* or whatever it's
called */
s.resize(orig_size + sprintf(&s[orig_size], "%.6f", something));  /*
snprintf in real code */

This avoids copying and avoids rewriting sprintf.


> If someone can show profiling data for a real world application where any
> kind of conversion like this mattered, then perhaps it would make sense to
> consider an application where a basic_string could "capture" a buffer
> already allocated by a user. But this uninitialized_resize thing, IMHO,
> induces far too many caveats.
>

What are the caveats to having a way to resize a string or a vector such
that the newly-added elements are default-initialized?


>
> It seems like for most of those cases where you would see a significant
> perf win, you'd be better off avoiding the conversion back into
> basic_string in the first place.
>

I would argue that the main reason that basic_string is useful is that it's
a string type that's widely used.  A lot of APIs accept basic_string as
input (and, with move semantics, the ability to std::move a string into
some library is a big win).  You can't solve a deficiency in creating
basic_strings by creating a new type.

--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_2053_28769986.1384816991550
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, November 18, 2013 3:00:54 PM UTC-8, Billy O'Nea=
l 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>=
Except everything you propose can be implemented in terms if .reserve() + .=
insert()/.append(), so you do in fact have the necessary facilities. Sure, =
those may be difficult to use in comparison, but they have the advantage th=
at 1. they don't break basic_string's invariants, and 2. they are already i=
n the standard and you can use them today.</div></div></blockquote><div><br=
><br>I admit I haven't real every post on the other thread, but how is this=
 supposed to work now?&nbsp; Suppose I want to do something as simple as:<b=
r><br>string s;<br>s.reserve(BIG_ENOUGH);<br>char buf[BIG_ENOUGH];<br>sprin=
tf(buf, "%.6f", something);<br><br>I can copy the data from buf to s using =
insert, or I could rewrite sprintf to stick each character in using push_ba=
ck (and hope that the optimizer is really, really good), but neither of tho=
se is a real solution.&nbsp; I want to be able to do:<br><br>auto orig_size=
 =3D s.size();<br>s.resize_default_initialized(orig_size + BIG_ENOUGH);&nbs=
p; /* or whatever it's called */<br>s.resize(orig_size + sprintf(&amp;s[ori=
g_size], "%.6f", something));&nbsp; /* snprintf in real code */<br><br>This=
 avoids copying and avoids rewriting sprintf.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr">

<div><br></div><div>If someone can show profiling data for a real world app=
lication where any kind of conversion like this mattered, then perhaps it w=
ould make sense to consider an application where a basic_string could "capt=
ure" a buffer already allocated by a user. But this uninitialized_resize th=
ing, IMHO, induces far too many caveats.</div></div></blockquote><div><br>W=
hat are the caveats to having a way to resize a string or a vector such tha=
t the newly-added elements are default-initialized?<br>&nbsp;</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">

<div><br></div><div>It seems like for most of those cases where you would s=
ee a significant perf win, you'd be better off avoiding the conversion back=
 into basic_string in the first place.</div></div></blockquote><div><br>I w=
ould argue that the main reason that basic_string is useful is that it's a =
string type that's widely used.&nbsp; A lot of APIs accept basic_string as =
input (and, with move semantics, the ability to std::move a string into som=
e library is a big win).&nbsp; You can't solve a deficiency in creating bas=
ic_strings by creating a new type.<br>&nbsp;<br>--Andy</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_2053_28769986.1384816991550--

.

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

>string s;
>s.reserve(BIG_ENOUGH);
>char buf[BIG_ENOUGH];
>sprintf(buf, "%.6f", something);
>I can copy the data from buf to s using insert, or I could rewrite sprintf
to stick each character in using push_back (and hope that the optimizer is
really, really good), but neither of those is a real solution.
Someone who cares about formatting performance isn't going to be using
sprint; they're going to use a formatting function designed for their
destination type.

In the specific case of sprintf, I suspect the cost of parsing the format
string is going to be far greater than copying the couple of characters
from a stack buffer into a heap buffer.

> What are the caveats to having a way to resize a string or a vector such
that the newly-added elements are default-initialized?
You expose garbage-init data to the user, the observation of which results
in undefined behavior. And you do it in such a way that existing code, not
prepared to deal with this case, can be broken.

>I would argue that the main reason that basic_string is useful is that
it's a string type that's widely used.  A lot of APIs accept basic_string
as input (and, with move semantics, the ability to std::move a string into
some library is a big win).  You can't solve a deficiency in creating
basic_strings by creating a new type.
I have yet to see a library where the translation into or out of the
library for a case like this resulted in significant performance
differences. (I've seen it for the innards of a library, but for the
innards of a library you can use your own type)

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, Nov 18, 2013 at 3:23 PM, <amluto@gmail.com> wrote:

> On Monday, November 18, 2013 3:00:54 PM UTC-8, Billy O'Neal wrote:
>>
>> Except everything you propose can be implemented in terms if .reserve() +
>> .insert()/.append(), so you do in fact have the necessary facilities. Sure,
>> those may be difficult to use in comparison, but they have the advantage
>> that 1. they don't break basic_string's invariants, and 2. they are already
>> in the standard and you can use them today.
>>
>
>
> I admit I haven't real every post on the other thread, but how is this
> supposed to work now?  Suppose I want to do something as simple as:
>
> string s;
> s.reserve(BIG_ENOUGH);
> char buf[BIG_ENOUGH];
> sprintf(buf, "%.6f", something);
>
> I can copy the data from buf to s using insert, or I could rewrite sprintf
> to stick each character in using push_back (and hope that the optimizer is
> really, really good), but neither of those is a real solution.  I want to
> be able to do:
>
> auto orig_size = s.size();
> s.resize_default_initialized(orig_size + BIG_ENOUGH);  /* or whatever it's
> called */
> s.resize(orig_size + sprintf(&s[orig_size], "%.6f", something));  /*
> snprintf in real code */
>
> This avoids copying and avoids rewriting sprintf.
>
>
>> If someone can show profiling data for a real world application where any
>> kind of conversion like this mattered, then perhaps it would make sense to
>> consider an application where a basic_string could "capture" a buffer
>> already allocated by a user. But this uninitialized_resize thing, IMHO,
>> induces far too many caveats.
>>
>
> What are the caveats to having a way to resize a string or a vector such
> that the newly-added elements are default-initialized?
>
>
>>
>> It seems like for most of those cases where you would see a significant
>> perf win, you'd be better off avoiding the conversion back into
>> basic_string in the first place.
>>
>
> I would argue that the main reason that basic_string is useful is that
> it's a string type that's widely used.  A lot of APIs accept basic_string
> as input (and, with move semantics, the ability to std::move a string into
> some library is a big win).  You can't solve a deficiency in creating
> basic_strings by creating a new type.
>
> --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/.
>

--

---
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/.

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

<div dir=3D"ltr"><div>&gt;string s;<br>&gt;s.reserve(BIG_ENOUGH);<br>&gt;ch=
ar buf[BIG_ENOUGH];<br>&gt;sprintf(buf, &quot;%.6f&quot;, something);<br>&g=
t;I can copy the data from buf to s using insert, or I could rewrite sprint=
f to stick each character in using push_back (and hope that the optimizer i=
s really, really good), but neither of those is a real solution.</div>

<div>Someone who cares about formatting performance isn&#39;t going to be u=
sing sprint; they&#39;re going to use a formatting function designed for th=
eir destination type.</div><div><br></div><div>In the specific case of spri=
ntf, I suspect the cost of parsing the format string is going to be far gre=
ater than copying the couple of characters from a stack buffer into a heap =
buffer.</div>

<div><br></div><div>&gt; What are the caveats to having a way to resize a s=
tring or a vector such that the newly-added elements are default-initialize=
d?</div><div>You expose garbage-init data to the user, the observation of w=
hich results in undefined behavior. And you do it in such a way that existi=
ng code, not prepared to deal with this case, can be broken.</div>

<div><br></div><div>&gt;I would argue that the main reason that basic_strin=
g is useful is that it&#39;s a string type that&#39;s widely used.=A0 A lot=
 of APIs accept basic_string as input (and, with move semantics, the abilit=
y to std::move a string into some library is a big win).=A0 You can&#39;t s=
olve a deficiency in creating basic_strings by creating a new type.</div>

<div>I have yet to see a library where the translation into or out of the l=
ibrary for a case like this resulted in significant performance differences=
.. (I&#39;ve seen it for the innards of a library, but for the innards of a =
library you can use your own type)</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 Mon, Nov 18, 2013 at 3:23 PM,  <span =
dir=3D"ltr">&lt;<a href=3D"mailto:amluto@gmail.com" target=3D"_blank">amlut=
o@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"im">On Monday, November 18, 2013 3:00:54 PM =
UTC-8, Billy O&#39;Neal wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: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>Except everything you propose can be implemented in t=
erms if .reserve() + .insert()/.append(), so you do in fact have the necess=
ary facilities. Sure, those may be difficult to use in comparison, but they=
 have the advantage that 1. they don&#39;t break basic_string&#39;s invaria=
nts, and 2. they are already in the standard and you can use them today.</d=
iv>

</div></blockquote></div><div><br><br>I admit I haven&#39;t real every post=
 on the other thread, but how is this supposed to work now?=A0 Suppose I wa=
nt to do something as simple as:<br><br>string s;<br>s.reserve(BIG_ENOUGH);=
<br>

char buf[BIG_ENOUGH];<br>sprintf(buf, &quot;%.6f&quot;, something);<br><br>=
I can copy the data from buf to s using insert, or I could rewrite sprintf =
to stick each character in using push_back (and hope that the optimizer is =
really, really good), but neither of those is a real solution.=A0 I want to=
 be able to do:<br>

<br>auto orig_size =3D s.size();<br>s.resize_default_initialized(orig_size =
+ BIG_ENOUGH);=A0 /* or whatever it&#39;s called */<br>s.resize(orig_size +=
 sprintf(&amp;s[orig_size], &quot;%.6f&quot;, something));=A0 /* snprintf i=
n real code */<br>

<br>This avoids copying and avoids rewriting sprintf.<br><br></div><div cla=
ss=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1p=
x;border-left-style:solid">

<div dir=3D"ltr">

<div><br></div><div>If someone can show profiling data for a real world app=
lication where any kind of conversion like this mattered, then perhaps it w=
ould make sense to consider an application where a basic_string could &quot=
;capture&quot; a buffer already allocated by a user. But this uninitialized=
_resize thing, IMHO, induces far too many caveats.</div>

</div></blockquote></div><div><br>What are the caveats to having a way to r=
esize a string or a vector such that the newly-added elements are default-i=
nitialized?<br>=A0</div><div class=3D"im"><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(2=
04,204,204);border-left-width:1px;border-left-style:solid">

<div dir=3D"ltr">

<div><br></div><div>It seems like for most of those cases where you would s=
ee a significant perf win, you&#39;d be better off avoiding the conversion =
back into basic_string in the first place.</div></div></blockquote></div>

<div><br>I would argue that the main reason that basic_string is useful is =
that it&#39;s a string type that&#39;s widely used.=A0 A lot of APIs accept=
 basic_string as input (and, with move semantics, the ability to std::move =
a string into some library is a big win).=A0 You can&#39;t solve a deficien=
cy in creating basic_strings by creating a new type.<br>

=A0<br>--Andy</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 />

--089e011830f457253e04eb7c4304--

.

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

On 18 November 2013 17:23, <amluto@gmail.com> wrote:

 but how is this supposed to work now?  Suppose I want to do something as
> simple as:
>
> string s;
> s.reserve(BIG_ENOUGH);
> char buf[BIG_ENOUGH];
> sprintf(buf, "%.6f", something);
>
> I can copy the data from buf to s using insert, or I could rewrite sprintf
> to stick each character in using push_back (and hope that the optimizer is
> really, really good), but neither of those is a real solution.
>

Or you could just use s,resize(BIG_ENOUGH) instead of
s.reserve(BIG_ENOUGH).  Do you have any benchmarks to show that the zero
filling is a performance bottleneck?

 I want to be able to do:
>
> auto orig_size = s.size();
> s.resize_default_initialized(orig_size + BIG_ENOUGH);  /* or whatever it's
> called */
> s.resize(orig_size + sprintf(&s[orig_size], "%.6f", something));  /*
> snprintf in real code */
>
> This avoids copying and avoids rewriting sprintf.
>

If you really need this level of performance (which seems doubtful if you
are using sprintf), use a basic_string with a different allocator that does
default initialization.  Problem solved.


>
> If someone can show profiling data for a real world application where any
>> kind of conversion like this mattered, then perhaps it would make sense to
>> consider an application where a basic_string could "capture" a buffer
>> already allocated by a user. But this uninitialized_resize thing, IMHO,
>> induces far too many caveats.
>>
>
> What are the caveats to having a way to resize a string or a vector such
> that the newly-added elements are default-initialized?
>

It's a large change to the standard library without any evidence it makes
any bit of difference in 99% of real world code.


>  I would argue that the main reason that basic_string is useful is that
> it's a string type that's widely used.  A lot of APIs accept basic_string
> as input (and, with move semantics, the ability to std::move a string into
> some library is a big win).  You can't solve a deficiency in creating
> basic_strings by creating a new type.
>

As long as they accept basic_string (as you allege) instead of std::string,
this problem is easily solvable with a different 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/.

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

<div dir=3D"ltr">On 18 November 2013 17:23,  <span dir=3D"ltr">&lt;<a href=
=3D"mailto:amluto@gmail.com" target=3D"_blank">amluto@gmail.com</a>&gt;</sp=
an> wrote:<br><div class=3D"gmail_extra"><div><br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">


<div dir=3D"ltr"><div> but how is this supposed to work now?=A0 Suppose I w=
ant to do something as simple as:<br><br>string s;<br>s.reserve(BIG_ENOUGH)=
;<br>char buf[BIG_ENOUGH];<br>sprintf(buf, &quot;%.6f&quot;, something);<br=
>


<br>I can copy the data from buf to s using insert, or I could rewrite spri=
ntf to stick each character in using push_back (and hope that the optimizer=
 is really, really good), but neither of those is a real solution.=A0</div>


</div></blockquote><br>Or you could just use s,resize(BIG_ENOUGH) instead o=
f s.reserve(BIG_ENOUGH).=A0 Do you have any benchmarks to show that the zer=
o filling is a performance bottleneck?<br> <br></div><div class=3D"gmail_qu=
ote">

<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>I want to be able to do:<br><br>auto orig_size =3D s.=
size();<br>s.resize_default_initialized(orig_size + BIG_ENOUGH);=A0 /* or w=
hatever it&#39;s called */<br>s.resize(orig_size + sprintf(&amp;s[orig_size=
], &quot;%.6f&quot;, something));=A0 /* snprintf in real code */<br>


<br>This avoids copying and avoids rewriting sprintf.<br></div></div></bloc=
kquote><div><br></div><div>If you really need this level of performance (wh=
ich seems doubtful if you are using sprintf), use a basic_string with a dif=
ferent allocator that does default initialization.=A0 Problem solved.<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><b=
r></div><div><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">If someone can show profiling data for a real world applic=
ation where any kind of conversion like this mattered, then perhaps it woul=
d make sense to consider an application where a basic_string could &quot;ca=
pture&quot; a buffer already allocated by a user. But this uninitialized_re=
size thing, IMHO, induces far too many caveats.</div>


</blockquote></div><div><br>What are the caveats to having a way to resize =
a string or a vector such that the newly-added elements are default-initial=
ized?<br></div></div></blockquote><div><br></div><div>It&#39;s a large chan=
ge to the standard library without any evidence it makes any bit of differe=
nce in 99% of real world code.<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>=
=A0I would argue that the main reason that basic_string is useful is that i=
t&#39;s a string type that&#39;s widely used.=A0 A lot of APIs accept basic=
_string as input (and, with move semantics, the ability to std::move a stri=
ng into some library is a big win).=A0 You can&#39;t solve a deficiency in =
creating basic_strings by creating a new type.<br>


</div></div></blockquote><div><br></div><div>As long as they accept basic_s=
tring (as you allege) instead of std::string, this problem is easily solvab=
le with a different allocator.<br clear=3D"all"></div></div>-- <br>=A0Nevin=
 &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.c=
om" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 <a href=3D"tel:%288=
47%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 />

--f46d04428ca07cd48004eb7c6acf--

.

------=_Part_2109_17621223.1384820106104
Content-Type: text/plain; charset=ISO-8859-1

On Monday, November 18, 2013 4:04:21 PM UTC-8, Nevin ":-)" Liber wrote:
>
> On 18 November 2013 17:23, <aml...@gmail.com <javascript:>> wrote:
>
>  but how is this supposed to work now?  Suppose I want to do something as
>> simple as:
>>
>> string s;
>> s.reserve(BIG_ENOUGH);
>> char buf[BIG_ENOUGH];
>> sprintf(buf, "%.6f", something);
>>
>> I can copy the data from buf to s using insert, or I could rewrite
>> sprintf to stick each character in using push_back (and hope that the
>> optimizer is really, really good), but neither of those is a real solution.
>>
>
> Or you could just use s,resize(BIG_ENOUGH) instead of
> s.reserve(BIG_ENOUGH).  Do you have any benchmarks to show that the zero
> filling is a performance bottleneck?
>

I'm sure I can come up with one.  I'm equally sure that someone will tell
me that my benchmark is too artificial or is otherwise irrelevant.  If STL
doesn't care about performance on this level, then why is reserve() there?


>
>  I want to be able to do:
>>
>> auto orig_size = s.size();
>> s.resize_default_initialized(orig_size + BIG_ENOUGH);  /* or whatever
>> it's called */
>> s.resize(orig_size + sprintf(&s[orig_size], "%.6f", something));  /*
>> snprintf in real code */
>>
>> This avoids copying and avoids rewriting sprintf.
>>
>
> If you really need this level of performance (which seems doubtful if you
> are using sprintf), use a basic_string with a different allocator that does
> default initialization.  Problem solved.
>

I could have pasted in a super-highly-optimized number-to-string
converter,  but that would have just cluttered the thread.

(std::ostream is already unusably slow for a lot of applications.
std::string is nowhere near as bad, but there's a factor of two available
here for long strings.)

As long as they accept basic_string (as you allege) instead of std::string,
> this problem is easily solvable with a different allocator.
>


I thought the conclusion from the other thread was that basic_strings with
different allocators don't interoperate.  Realistically, libraries except
std::string, not arbitrary instantiations of basic_string.

--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_2109_17621223.1384820106104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, November 18, 2013 4:04:21 PM UTC-8, Nevin ":-)"=
 Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
On 18 November 2013 17:23,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"KMvGhKcDSpkJ">aml...@gmail.com</a=
>&gt;</span> wrote:<br><div><div><br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir=3D"ltr"><div> but how is this supposed to work now?&nbsp; Suppose =
I want to do something as simple as:<br><br>string s;<br>s.reserve(BIG_ENOU=
GH);<br>char buf[BIG_ENOUGH];<br>sprintf(buf, "%.6f", something);<br>


<br>I can copy the data from buf to s using insert, or I could rewrite spri=
ntf to stick each character in using push_back (and hope that the optimizer=
 is really, really good), but neither of those is a real solution.&nbsp;</d=
iv>


</div></blockquote><br>Or you could just use s,resize(BIG_ENOUGH) instead o=
f s.reserve(BIG_ENOUGH).&nbsp; Do you have any benchmarks to show that the =
zero filling is a performance bottleneck?<br></div></div></div></blockquote=
><div><br>I'm sure I can come up with one.&nbsp; I'm equally sure that some=
one will tell me that my benchmark is too artificial or is otherwise irrele=
vant.&nbsp; If STL doesn't care about performance on this level, then why i=
s reserve() there?<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"><div><div> <br></div><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"><div>I want to be able to do:<br><br>auto orig_size =3D s.=
size();<br>s.resize_default_initialized(<wbr>orig_size + BIG_ENOUGH);&nbsp;=
 /* or whatever it's called */<br>s.resize(orig_size + sprintf(&amp;s[orig_=
size], "%.6f", something));&nbsp; /* snprintf in real code */<br>


<br>This avoids copying and avoids rewriting sprintf.<br></div></div></bloc=
kquote><div><br></div><div>If you really need this level of performance (wh=
ich seems doubtful if you are using sprintf), use a basic_string with a dif=
ferent allocator that does default initialization.&nbsp; Problem solved.<br=
></div></div></div></div></blockquote><div><br>I could have pasted in a sup=
er-highly-optimized number-to-string converter,&nbsp; but that would have j=
ust cluttered the thread.<br><br>(std::ostream is already unusably slow for=
 a lot of applications.&nbsp; std::string is nowhere near as bad, but there=
's a factor of two available here for long strings.)<br></div><br><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><div class=3D"gma=
il_quote"><div>As long as they accept basic_string (as you allege) instead =
of std::string, this problem is easily solvable with a different allocator.=
<br clear=3D"all"></div></div></div></div></blockquote><div><br><br>I thoug=
ht the conclusion from the other thread was that=20
basic_strings with different allocators don't interoperate.&nbsp;=20
Realistically, libraries except std::string, not arbitrary=20
instantiations of basic_string. <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_2109_17621223.1384820106104--

.

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

> I'm sure I can come up with one.  I'm equally sure that someone will tell
me that my benchmark is too artificial or is otherwise irrelevant.  If STL
doesn't care about performance on this level, then why is reserve() there?

Reserve is about optimizing memory allocations, not object initialization.

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, Nov 18, 2013 at 4:15 PM, <amluto@gmail.com> wrote:

> On Monday, November 18, 2013 4:04:21 PM UTC-8, Nevin ":-)" Liber wrote:
>
>> On 18 November 2013 17:23, <aml...@gmail.com> wrote:
>>
>>  but how is this supposed to work now?  Suppose I want to do something as
>>> simple as:
>>>
>>> string s;
>>> s.reserve(BIG_ENOUGH);
>>> char buf[BIG_ENOUGH];
>>> sprintf(buf, "%.6f", something);
>>>
>>> I can copy the data from buf to s using insert, or I could rewrite
>>> sprintf to stick each character in using push_back (and hope that the
>>> optimizer is really, really good), but neither of those is a real solution.
>>>
>>
>> Or you could just use s,resize(BIG_ENOUGH) instead of
>> s.reserve(BIG_ENOUGH).  Do you have any benchmarks to show that the zero
>> filling is a performance bottleneck?
>>
>
> I'm sure I can come up with one.  I'm equally sure that someone will tell
> me that my benchmark is too artificial or is otherwise irrelevant.  If STL
> doesn't care about performance on this level, then why is reserve() there?
>
>
>>
>>  I want to be able to do:
>>>
>>> auto orig_size = s.size();
>>> s.resize_default_initialized(orig_size + BIG_ENOUGH);  /* or whatever
>>> it's called */
>>> s.resize(orig_size + sprintf(&s[orig_size], "%.6f", something));  /*
>>> snprintf in real code */
>>>
>>> This avoids copying and avoids rewriting sprintf.
>>>
>>
>> If you really need this level of performance (which seems doubtful if you
>> are using sprintf), use a basic_string with a different allocator that does
>> default initialization.  Problem solved.
>>
>
> I could have pasted in a super-highly-optimized number-to-string
> converter,  but that would have just cluttered the thread.
>
> (std::ostream is already unusably slow for a lot of applications.
> std::string is nowhere near as bad, but there's a factor of two available
> here for long strings.)
>
> As long as they accept basic_string (as you allege) instead of
>> std::string, this problem is easily solvable with a different allocator.
>>
>
>
> I thought the conclusion from the other thread was that basic_strings with
> different allocators don't interoperate.  Realistically, libraries except
> std::string, not arbitrary instantiations of basic_string.
>
> --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/.
>

--

---
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/.

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

<div dir=3D"ltr"><div>&gt; I&#39;m sure I can come up with one.=A0 I&#39;m =
equally sure that someone will tell me that my benchmark is too artificial =
or is otherwise irrelevant.=A0 If STL doesn&#39;t care about performance on=
 this level, then why is reserve() there?</div>

<div><br></div><div>Reserve is about optimizing memory allocations, not obj=
ect initialization.</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://b=
itbucket.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 Mon, Nov 18, 2013 at 4:15 PM,  <span =
dir=3D"ltr">&lt;<a href=3D"mailto:amluto@gmail.com" target=3D"_blank">amlut=
o@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr">On Monday, November 18, 2013 4:04:21 PM UTC-8, Nevin &quot=
;:-)&quot; Liber wrote:<div class=3D"im"><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">On 18 November 2013 17:23,  <span dir=3D"ltr">&lt;<a>aml..=
..@gmail.com</a>&gt;</span> wrote:<br><div><div><br><blockquote class=3D"gma=
il_quote" 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">




<div dir=3D"ltr"><div> but how is this supposed to work now?=A0 Suppose I w=
ant to do something as simple as:<br><br>string s;<br>s.reserve(BIG_ENOUGH)=
;<br>char buf[BIG_ENOUGH];<br>sprintf(buf, &quot;%.6f&quot;, something);<br=
>




<br>I can copy the data from buf to s using insert, or I could rewrite spri=
ntf to stick each character in using push_back (and hope that the optimizer=
 is really, really good), but neither of those is a real solution.=A0</div>




</div></blockquote><br>Or you could just use s,resize(BIG_ENOUGH) instead o=
f s.reserve(BIG_ENOUGH).=A0 Do you have any benchmarks to show that the zer=
o filling is a performance bottleneck?<br></div></div></div></blockquote>

</div><div><br>I&#39;m sure I can come up with one.=A0 I&#39;m equally sure=
 that someone will tell me that my benchmark is too artificial or is otherw=
ise irrelevant.=A0 If STL doesn&#39;t care about performance on this level,=
 then why is reserve() there?<br>

=A0</div><div class=3D"im"><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"><div><div> <br=
></div>

<div class=3D"gmail_quote">

<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>I want to be able to do:<br><br>auto orig_size =3D s.=
size();<br>s.resize_default_initialized(<u></u>orig_size + BIG_ENOUGH);=A0 =
/* or whatever it&#39;s called */<br>s.resize(orig_size + sprintf(&amp;s[or=
ig_size], &quot;%.6f&quot;, something));=A0 /* snprintf in real code */<br>




<br>This avoids copying and avoids rewriting sprintf.<br></div></div></bloc=
kquote><div><br></div><div>If you really need this level of performance (wh=
ich seems doubtful if you are using sprintf), use a basic_string with a dif=
ferent allocator that does default initialization.=A0 Problem solved.<br>

</div></div></div></div></blockquote></div><div><br>I could have pasted in =
a super-highly-optimized number-to-string converter,=A0 but that would have=
 just cluttered the thread.<br><br>(std::ostream is already unusably slow f=
or a lot of applications.=A0 std::string is nowhere near as bad, but there&=
#39;s a factor of two available here for long strings.)<br>

</div><div class=3D"im"><br><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"><div><div cla=
ss=3D"gmail_quote">

<div>As long as they accept basic_string (as you allege) instead of std::st=
ring, this problem is easily solvable with a different allocator.<br clear=
=3D"all"></div></div></div></div></blockquote></div><div><br><br>I thought =
the conclusion from the other thread was that=20
basic_strings with different allocators don&#39;t interoperate.=A0=20
Realistically, libraries except std::string, not arbitrary=20
instantiations of basic_string. <br><br>--Andy<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 />

--001a11c2fcb82fe1ae04eb7c94b5--

.

------=_Part_2286_22479761.1384820360283
Content-Type: text/plain; charset=ISO-8859-1

On Monday, November 18, 2013 3:53:25 PM UTC-8, Billy O'Neal wrote:
>
>
> > What are the caveats to having a way to resize a string or a vector such
> that the newly-added elements are default-initialized?
> You expose garbage-init data to the user, the observation of which results
> in undefined behavior. And you do it in such a way that existing code, not
> prepared to deal with this case, can be broken.
>
>
Note that I proposed this for *basic_string*, which is almost always
instantiated for char or wchar_t.  It would be straightforward to specify
the new resize function as filling the newly-available space with
indeterminate but well-defined values.  IOW reading would be explicitly
allowed.  (This might result in odd interactions with custom allocators.)

There's already new char[len], which has *exactly* the semantics I want.  I
don't see why the string class needs to hold users' hands more tightly than
operator new.

--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_2286_22479761.1384820360283
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, November 18, 2013 3:53:25 PM UTC-8, Billy O'Nea=
l 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>&gt; What are the caveats to having a way to resize a string or a vecto=
r such that the newly-added elements are default-initialized?</div><div>You=
 expose garbage-init data to the user, the observation of which results in =
undefined behavior. And you do it in such a way that existing code, not pre=
pared to deal with this case, can be broken.</div>

<div><br></div></div></blockquote><div><br>Note that I proposed this for *b=
asic_string*, which is almost always instantiated for char or wchar_t.&nbsp=
; It would be straightforward to specify the new resize function as filling=
 the newly-available space with indeterminate but well-defined values.&nbsp=
; IOW reading would be explicitly allowed.&nbsp; (This might result in odd =
interactions with custom allocators.)<br><br>There's already new char[len],=
 which has *exactly* the semantics I want.&nbsp; I don't see why the string=
 class needs to hold users' hands more tightly than operator new.<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_2286_22479761.1384820360283--

.

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

>I don't see why the string class needs to hold users' hands more tightly
than operator new.

Because the built in container classes are generally designed to prevent
the user from breaking their invariants. A piece of code can get passed a
std::basic_string and assume, without any other information, that the data
inside is not garbage. That is a useful invariant to people passing around
std::strings, particularly over an ability which is only useful in
specialized text processing domains (which shouldn't be passing around
strings anyway).

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, Nov 18, 2013 at 4:19 PM, <amluto@gmail.com> wrote:

> On Monday, November 18, 2013 3:53:25 PM UTC-8, Billy O'Neal wrote:
>>
>>
>> > What are the caveats to having a way to resize a string or a vector
>> such that the newly-added elements are default-initialized?
>> You expose garbage-init data to the user, the observation of which
>> results in undefined behavior. And you do it in such a way that existing
>> code, not prepared to deal with this case, can be broken.
>>
>>
> Note that I proposed this for *basic_string*, which is almost always
> instantiated for char or wchar_t.  It would be straightforward to specify
> the new resize function as filling the newly-available space with
> indeterminate but well-defined values.  IOW reading would be explicitly
> allowed.  (This might result in odd interactions with custom allocators.)
>
> There's already new char[len], which has *exactly* the semantics I want.
> I don't see why the string class needs to hold users' hands more tightly
> than operator new.
>
> --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/.
>

--

---
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/.

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

<div dir=3D"ltr"><div>&gt;I don&#39;t see why the string class needs to hol=
d users&#39; hands more tightly than operator new.</div><div><br></div><div=
>Because the built in container classes are generally designed to prevent t=
he user from breaking their invariants. A piece of code can get passed a st=
d::basic_string and assume, without any other information, that the data in=
side is not garbage. That is a useful invariant to people passing around st=
d::strings, particularly over an ability which is only useful in specialize=
d text processing domains (which shouldn&#39;t be passing around strings an=
yway).</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 Mon, Nov 18, 2013 at 4:19 PM,  <span =
dir=3D"ltr">&lt;<a href=3D"mailto:amluto@gmail.com" target=3D"_blank">amlut=
o@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"im">On Monday, November 18, 2013 3:53:25 PM =
UTC-8, Billy O&#39;Neal wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: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><div>&gt; What are the caveats to having a way to resi=
ze a string or a vector such that the newly-added elements are default-init=
ialized?</div><div>You expose garbage-init data to the user, the observatio=
n of which results in undefined behavior. And you do it in such a way that =
existing code, not prepared to deal with this case, can be broken.</div>



<div><br></div></div></blockquote></div><div><br>Note that I proposed this =
for *basic_string*, which is almost always instantiated for char or wchar_t=
..=A0 It would be straightforward to specify the new resize function as fill=
ing the newly-available space with indeterminate but well-defined values.=
=A0 IOW reading would be explicitly allowed.=A0 (This might result in odd i=
nteractions with custom allocators.)<br>

<br>There&#39;s already new char[len], which has *exactly* the semantics I =
want.=A0 I don&#39;t see why the string class needs to hold users&#39; hand=
s more tightly than operator new.<br><br>--Andy<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 />

--001a11c2fcb89c358f04eb7cb768--

.

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

On Monday, November 18, 2013 4:16:01 PM UTC-8, Billy O'Neal wrote:
>
> > I'm sure I can come up with one.  I'm equally sure that someone will=20
> tell me that my benchmark is too artificial or is otherwise irrelevant.  =
If=20
> STL doesn't care about performance on this level, then why is reserve()=
=20
> there?
>
> Reserve is about optimizing memory allocations, not object initialization=
..
>

This is, IMO, completely ridiculous.  It's benchmark time:

template<typename Func>
void benchmark(const char *desc, Func &&f)
{
    auto start =3D std::chrono::steady_clock::now();
    constexpr int iters =3D 10000;
    for (int i =3D 0; i < iters; i++)
        f();
    auto end =3D std::chrono::steady_clock::now();

    std::cout << desc << ": " <<=20
std::chrono::duration_cast<std::chrono::duration<double>>(end-start).count(=
)=20
* 1e6 / iters << " =B5s/iter\n";
}

benchmark("new + delete", [] { delete[] new char[1024]; });
benchmark("new + memset + delete", [] {
    auto array =3D new char[1024];
    memset(array, 0, 1024);
    delete[] array;
});
benchmark("string", [] { std::string s; s.resize(1024); });

prints (using tcmalloc):

ew + delete: 0.0118636 =B5s/iter
new + memset + delete: 0.0311982 =B5s/iter
string: 0.0514658 =B5s/iter

With a 1KiB string, initialization takes over three times as long as=20
allocation.


Re: containers protecting users from garbage values, if I write a function=
=20
that returns an std::string that contains garbage (which is easy to do with=
=20
or without fancy resize functions), then the caller will receive garbage. =
=20
This isn't STL's fault.
=20

>
> 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, Nov 18, 2013 at 4:15 PM, <aml...@gmail.com <javascript:>> wrote:
>
>> On Monday, November 18, 2013 4:04:21 PM UTC-8, Nevin ":-)" Liber wrote:
>>
>>> On 18 November 2013 17:23, <aml...@gmail.com> wrote:
>>>
>>>  but how is this supposed to work now?  Suppose I want to do something=
=20
>>>> as simple as:
>>>>
>>>> string s;
>>>> s.reserve(BIG_ENOUGH);
>>>> char buf[BIG_ENOUGH];
>>>> sprintf(buf, "%.6f", something);
>>>>
>>>> I can copy the data from buf to s using insert, or I could rewrite=20
>>>> sprintf to stick each character in using push_back (and hope that the=
=20
>>>> optimizer is really, really good), but neither of those is a real solu=
tion.=20
>>>>
>>>
>>> Or you could just use s,resize(BIG_ENOUGH) instead of=20
>>> s.reserve(BIG_ENOUGH).  Do you have any benchmarks to show that the zer=
o=20
>>> filling is a performance bottleneck?
>>>
>>
>> I'm sure I can come up with one.  I'm equally sure that someone will tel=
l=20
>> me that my benchmark is too artificial or is otherwise irrelevant.  If S=
TL=20
>> doesn't care about performance on this level, then why is reserve() ther=
e?
>> =20
>>
>>>
>>>  I want to be able to do:
>>>>
>>>> auto orig_size =3D s.size();
>>>> s.resize_default_initialized(orig_size + BIG_ENOUGH);  /* or whatever=
=20
>>>> it's called */
>>>> s.resize(orig_size + sprintf(&s[orig_size], "%.6f", something));  /*=
=20
>>>> snprintf in real code */
>>>>
>>>> This avoids copying and avoids rewriting sprintf.
>>>>
>>>
>>> If you really need this level of performance (which seems doubtful if=
=20
>>> you are using sprintf), use a basic_string with a different allocator t=
hat=20
>>> does default initialization.  Problem solved.
>>>
>>
>> I could have pasted in a super-highly-optimized number-to-string=20
>> converter,  but that would have just cluttered the thread.
>>
>> (std::ostream is already unusably slow for a lot of applications. =20
>> std::string is nowhere near as bad, but there's a factor of two availabl=
e=20
>> here for long strings.)
>>
>> As long as they accept basic_string (as you allege) instead of=20
>>> std::string, this problem is easily solvable with a different allocator=
..
>>>
>>
>>
>> I thought the conclusion from the other thread was that basic_strings=20
>> with different allocators don't interoperate.  Realistically, libraries=
=20
>> except std::string, not arbitrary instantiations of basic_string.=20
>>
>> --Andy
>>
>> --=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_2133_19847223.1384820918840
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, November 18, 2013 4:16:01 PM UTC-8, Billy O'Nea=
l 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>=
&gt; I'm sure I can come up with one.&nbsp; I'm equally sure that someone w=
ill tell me that my benchmark is too artificial or is otherwise irrelevant.=
&nbsp; If STL doesn't care about performance on this level, then why is res=
erve() there?</div>

<div><br></div><div>Reserve is about optimizing memory allocations, not obj=
ect initialization.</div></div></blockquote><div><br>This is, IMO, complete=
ly ridiculous.&nbsp; It's benchmark time:<br><br>template&lt;typename Func&=
gt;<br>void benchmark(const char *desc, Func &amp;&amp;f)<br>{<br>&nbsp;&nb=
sp;&nbsp; auto start =3D std::chrono::steady_clock::now();<br>&nbsp;&nbsp;&=
nbsp; constexpr int iters =3D 10000;<br>&nbsp;&nbsp;&nbsp; for (int i =3D 0=
; i &lt; iters; i++)<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; f();<br>&nbsp=
;&nbsp;&nbsp; auto end =3D std::chrono::steady_clock::now();<br><br>&nbsp;&=
nbsp;&nbsp; std::cout &lt;&lt; desc &lt;&lt; ": " &lt;&lt; std::chrono::dur=
ation_cast&lt;std::chrono::duration&lt;double&gt;&gt;(end-start).count() * =
1e6 / iters &lt;&lt; " =B5s/iter\n";<br>}<br><br>benchmark("new + delete", =
[] { delete[] new char[1024]; });<br>benchmark("new + memset + delete", [] =
{<br>&nbsp;&nbsp;&nbsp; auto array =3D new char[1024];<br>&nbsp;&nbsp;&nbsp=
; memset(array, 0, 1024);<br>&nbsp;&nbsp;&nbsp; delete[] array;<br>});<br>b=
enchmark("string", [] { std::string s; s.resize(1024); });<br><br>prints (u=
sing tcmalloc):<br><br>ew + delete: 0.0118636 =B5s/iter<br>new + memset + d=
elete: 0.0311982 =B5s/iter<br>string: 0.0514658 =B5s/iter<br><br>With a 1Ki=
B string, initialization takes over three times as long as allocation.<br><=
br><br>Re: containers protecting users from garbage values, if I write a fu=
nction that returns an std::string that contains garbage (which is easy to =
do with or without fancy resize functions), then the caller will receive ga=
rbage.&nbsp; This isn't STL's fault.<br>&nbsp;</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly 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/<wbr>users/82320/billy-oneal</a></div><di=
v>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Nov 18, 2013 at 4:15 PM,  <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"vH6FZziBwj8J">aml...@gmail.com</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">

<div dir=3D"ltr">On Monday, November 18, 2013 4:04:21 PM UTC-8, Nevin ":-)"=
 Liber 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">

<div dir=3D"ltr">On 18 November 2013 17:23,  <span dir=3D"ltr">&lt;<a>aml..=
..@gmail.com</a>&gt;</span> wrote:<br><div><div><br><blockquote class=3D"gma=
il_quote" 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">




<div dir=3D"ltr"><div> but how is this supposed to work now?&nbsp; Suppose =
I want to do something as simple as:<br><br>string s;<br>s.reserve(BIG_ENOU=
GH);<br>char buf[BIG_ENOUGH];<br>sprintf(buf, "%.6f", something);<br>




<br>I can copy the data from buf to s using insert, or I could rewrite spri=
ntf to stick each character in using push_back (and hope that the optimizer=
 is really, really good), but neither of those is a real solution.&nbsp;</d=
iv>




</div></blockquote><br>Or you could just use s,resize(BIG_ENOUGH) instead o=
f s.reserve(BIG_ENOUGH).&nbsp; Do you have any benchmarks to show that the =
zero filling is a performance bottleneck?<br></div></div></div></blockquote=
>

</div><div><br>I'm sure I can come up with one.&nbsp; I'm equally sure that=
 someone will tell me that my benchmark is too artificial or is otherwise i=
rrelevant.&nbsp; If STL doesn't care about performance on this level, then =
why is reserve() there?<br>

&nbsp;</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-w=
idth:1px;border-left-style:solid"><div dir=3D"ltr"><div><div> <br></div>

<div class=3D"gmail_quote">

<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>I want to be able to do:<br><br>auto orig_size =3D s.=
size();<br>s.resize_default_initialized(<u></u>o<wbr>rig_size + BIG_ENOUGH)=
;&nbsp; /* or whatever it's called */<br>s.resize(orig_size + sprintf(&amp;=
s[orig_size], "%.6f", something));&nbsp; /* snprintf in real code */<br>




<br>This avoids copying and avoids rewriting sprintf.<br></div></div></bloc=
kquote><div><br></div><div>If you really need this level of performance (wh=
ich seems doubtful if you are using sprintf), use a basic_string with a dif=
ferent allocator that does default initialization.&nbsp; Problem solved.<br=
>

</div></div></div></div></blockquote></div><div><br>I could have pasted in =
a super-highly-optimized number-to-string converter,&nbsp; but that would h=
ave just cluttered the thread.<br><br>(std::ostream is already unusably slo=
w for a lot of applications.&nbsp; std::string is nowhere near as bad, but =
there's a factor of two available here for long strings.)<br>

</div><div><br><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 dir=3D"ltr"><div><div class=3D"gmail_q=
uote">

<div>As long as they accept basic_string (as you allege) instead of std::st=
ring, this problem is easily solvable with a different allocator.<br clear=
=3D"all"></div></div></div></div></blockquote></div><div><br><br>I thought =
the conclusion from the other thread was that=20
basic_strings with different allocators don't interoperate.&nbsp;=20
Realistically, libraries except std::string, not arbitrary=20
instantiations of basic_string. <br><br>--Andy<br></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"=
vH6FZziBwj8J">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"vH6FZziBwj8J">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_2133_19847223.1384820918840--

.

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

1. Your example allocates once. The intent is to avoid use cases where a
string allocates 1, then allocates 2, then allocates 4, then allocates 8,
then allocates 16 .... Nothing in either of your examples shows a case that
reserve was intended to speed up.
2. You are probably benchmarking on a platform which does lazy commit, so
you actually don't pay for much of the allocation costs until you actually
write to the memory in question.
3. Considering there is no legal way to get to any of the memory between
size() and capacity() I can't see how this is in any way an optimization
for initializing the array.

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, Nov 18, 2013 at 4:28 PM, <amluto@gmail.com> wrote:

> On Monday, November 18, 2013 4:16:01 PM UTC-8, Billy O'Neal wrote:
>>
>> > I'm sure I can come up with one.  I'm equally sure that someone will
>> tell me that my benchmark is too artificial or is otherwise irrelevant. =
 If
>> STL doesn't care about performance on this level, then why is reserve()
>> there?
>>
>> Reserve is about optimizing memory allocations, not object initializatio=
n.
>>
>
> This is, IMO, completely ridiculous.  It's benchmark time:
>
> template<typename Func>
> void benchmark(const char *desc, Func &&f)
> {
>     auto start =3D std::chrono::steady_clock::now();
>     constexpr int iters =3D 10000;
>     for (int i =3D 0; i < iters; i++)
>         f();
>     auto end =3D std::chrono::steady_clock::now();
>
>     std::cout << desc << ": " <<
> std::chrono::duration_cast<std::chrono::duration<double>>(end-start).coun=
t()
> * 1e6 / iters << " =B5s/iter\n";
> }
>
> benchmark("new + delete", [] { delete[] new char[1024]; });
> benchmark("new + memset + delete", [] {
>     auto array =3D new char[1024];
>     memset(array, 0, 1024);
>     delete[] array;
> });
> benchmark("string", [] { std::string s; s.resize(1024); });
>
> prints (using tcmalloc):
>
> ew + delete: 0.0118636 =B5s/iter
> new + memset + delete: 0.0311982 =B5s/iter
> string: 0.0514658 =B5s/iter
>
> With a 1KiB string, initialization takes over three times as long as
> allocation.
>
>
> Re: containers protecting users from garbage values, if I write a functio=
n
> that returns an std::string that contains garbage (which is easy to do wi=
th
> or without fancy resize functions), then the caller will receive garbage.
> This isn't STL's fault.
>
>
>>
>> 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, Nov 18, 2013 at 4:15 PM, <aml...@gmail.com> wrote:
>>
>>>  On Monday, November 18, 2013 4:04:21 PM UTC-8, Nevin ":-)" Liber wrote=
:
>>>
>>>> On 18 November 2013 17:23, <aml...@gmail.com> wrote:
>>>>
>>>>  but how is this supposed to work now?  Suppose I want to do something
>>>>> as simple as:
>>>>>
>>>>> string s;
>>>>> s.reserve(BIG_ENOUGH);
>>>>> char buf[BIG_ENOUGH];
>>>>> sprintf(buf, "%.6f", something);
>>>>>
>>>>> I can copy the data from buf to s using insert, or I could rewrite
>>>>> sprintf to stick each character in using push_back (and hope that the
>>>>> optimizer is really, really good), but neither of those is a real sol=
ution.
>>>>>
>>>>
>>>> Or you could just use s,resize(BIG_ENOUGH) instead of
>>>> s.reserve(BIG_ENOUGH).  Do you have any benchmarks to show that the ze=
ro
>>>> filling is a performance bottleneck?
>>>>
>>>
>>> I'm sure I can come up with one.  I'm equally sure that someone will
>>> tell me that my benchmark is too artificial or is otherwise irrelevant.=
  If
>>> STL doesn't care about performance on this level, then why is reserve()
>>> there?
>>>
>>>
>>>>
>>>>  I want to be able to do:
>>>>>
>>>>> auto orig_size =3D s.size();
>>>>> s.resize_default_initialized(orig_size + BIG_ENOUGH);  /* or whatever
>>>>> it's called */
>>>>> s.resize(orig_size + sprintf(&s[orig_size], "%.6f", something));  /*
>>>>> snprintf in real code */
>>>>>
>>>>> This avoids copying and avoids rewriting sprintf.
>>>>>
>>>>
>>>> If you really need this level of performance (which seems doubtful if
>>>> you are using sprintf), use a basic_string with a different allocator =
that
>>>> does default initialization.  Problem solved.
>>>>
>>>
>>> I could have pasted in a super-highly-optimized number-to-string
>>> converter,  but that would have just cluttered the thread.
>>>
>>> (std::ostream is already unusably slow for a lot of applications.
>>> std::string is nowhere near as bad, but there's a factor of two availab=
le
>>> here for long strings.)
>>>
>>> As long as they accept basic_string (as you allege) instead of
>>>> std::string, this problem is easily solvable with a different allocato=
r.
>>>>
>>>
>>>
>>> I thought the conclusion from the other thread was that basic_strings
>>> with different allocators don't interoperate.  Realistically, libraries
>>> except std::string, not arbitrary instantiations of basic_string.
>>>
>>> --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-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/.
>>>
>>
>>  --
>
> ---
> 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/.

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

<div dir=3D"ltr"><div>1. Your example allocates once. The intent is to avoi=
d use cases where a string allocates 1, then allocates 2, then allocates 4,=
 then allocates 8, then allocates 16 .... Nothing in either of your example=
s shows a case that reserve was intended to speed up.</div>

<div>2. You are probably benchmarking on a platform which does lazy commit,=
 so you actually don&#39;t pay for much of the allocation costs until you a=
ctually write to the memory in question.</div><div>3. Considering there is =
no legal way to get to any of the memory between size() and capacity() I ca=
n&#39;t see how this is in any way an optimization for initializing the arr=
ay.</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 Mon, Nov 18, 2013 at 4:28 PM,  <span =
dir=3D"ltr">&lt;<a href=3D"mailto:amluto@gmail.com" target=3D"_blank">amlut=
o@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"im">On Monday, November 18, 2013 4:16:01 PM =
UTC-8, Billy O&#39;Neal wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: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>&gt; I&#39;m sure I can come up with one.=A0 I&#39;m =
equally sure that someone will tell me that my benchmark is too artificial =
or is otherwise irrelevant.=A0 If STL doesn&#39;t care about performance on=
 this level, then why is reserve() there?</div>



<div><br></div><div>Reserve is about optimizing memory allocations, not obj=
ect initialization.</div></div></blockquote></div><div><br>This is, IMO, co=
mpletely ridiculous.=A0 It&#39;s benchmark time:<br><br>template&lt;typenam=
e Func&gt;<br>

void benchmark(const char *desc, Func &amp;&amp;f)<br>{<br>=A0=A0=A0 auto s=
tart =3D std::chrono::steady_clock::now();<br>=A0=A0=A0 constexpr int iters=
 =3D 10000;<br>=A0=A0=A0 for (int i =3D 0; i &lt; iters; i++)<br>=A0=A0=A0 =
=A0=A0=A0 f();<br>=A0=A0=A0 auto end =3D std::chrono::steady_clock::now();<=
br>

<br>=A0=A0=A0 std::cout &lt;&lt; desc &lt;&lt; &quot;: &quot; &lt;&lt; std:=
:chrono::duration_cast&lt;std::chrono::duration&lt;double&gt;&gt;(end-start=
).count() * 1e6 / iters &lt;&lt; &quot; =B5s/iter\n&quot;;<br>}<br><br>benc=
hmark(&quot;new + delete&quot;, [] { delete[] new char[1024]; });<br>

benchmark(&quot;new + memset + delete&quot;, [] {<br>=A0=A0=A0 auto array =
=3D new char[1024];<br>=A0=A0=A0 memset(array, 0, 1024);<br>=A0=A0=A0 delet=
e[] array;<br>});<br>benchmark(&quot;string&quot;, [] { std::string s; s.re=
size(1024); });<br>

<br>prints (using tcmalloc):<br><br>ew + delete: 0.0118636 =B5s/iter<br>new=
 + memset + delete: 0.0311982 =B5s/iter<br>string: 0.0514658 =B5s/iter<br><=
br>With a 1KiB string, initialization takes over three times as long as all=
ocation.<br>

<br><br>Re: containers protecting users from garbage values, if I write a f=
unction that returns an std::string that contains garbage (which is easy to=
 do with or without fancy resize functions), then the caller will receive g=
arbage.=A0 This isn&#39;t STL&#39;s fault.<br>

=A0</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-width:1px=
;border-left-style:solid"><div><div class=3D"im"><br clear=3D"all"><div><di=
v 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/<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"><div><div class=3D"h5">On Mon, Nov=
 18, 2013 at 4:15 PM,  <span dir=3D"ltr">&lt;<a>aml...@gmail.com</a>&gt;</s=
pan> wrote:<br></div></div><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><div class=3D"h5">

<div dir=3D"ltr">On Monday, November 18, 2013 4:04:21 PM UTC-8, Nevin &quot=
;:-)&quot; Liber wrote:<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);bo=
rder-left-width:1px;border-left-style:solid">



<div dir=3D"ltr">On 18 November 2013 17:23,  <span dir=3D"ltr">&lt;<a>aml..=
..@gmail.com</a>&gt;</span> wrote:<br><div><div><br><blockquote class=3D"gma=
il_quote" 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">






<div dir=3D"ltr"><div> but how is this supposed to work now?=A0 Suppose I w=
ant to do something as simple as:<br><br>string s;<br>s.reserve(BIG_ENOUGH)=
;<br>char buf[BIG_ENOUGH];<br>sprintf(buf, &quot;%.6f&quot;, something);<br=
>






<br>I can copy the data from buf to s using insert, or I could rewrite spri=
ntf to stick each character in using push_back (and hope that the optimizer=
 is really, really good), but neither of those is a real solution.=A0</div>






</div></blockquote><br>Or you could just use s,resize(BIG_ENOUGH) instead o=
f s.reserve(BIG_ENOUGH).=A0 Do you have any benchmarks to show that the zer=
o filling is a performance bottleneck?<br></div></div></div></blockquote>



</div><div><br>I&#39;m sure I can come up with one.=A0 I&#39;m equally sure=
 that someone will tell me that my benchmark is too artificial or is otherw=
ise irrelevant.=A0 If STL doesn&#39;t care about performance on this level,=
 then why is reserve() there?<br>



=A0</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-widt=
h:1px;border-left-style:solid"><div dir=3D"ltr"><div><div> <br></div>

<div class=3D"gmail_quote">

<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>I want to be able to do:<br><br>auto orig_size =3D s.=
size();<br>s.resize_default_initialized(<u></u>o<u></u>rig_size + BIG_ENOUG=
H);=A0 /* or whatever it&#39;s called */<br>s.resize(orig_size + sprintf(&a=
mp;s[orig_size], &quot;%.6f&quot;, something));=A0 /* snprintf in real code=
 */<br>






<br>This avoids copying and avoids rewriting sprintf.<br></div></div></bloc=
kquote><div><br></div><div>If you really need this level of performance (wh=
ich seems doubtful if you are using sprintf), use a basic_string with a dif=
ferent allocator that does default initialization.=A0 Problem solved.<br>



</div></div></div></div></blockquote></div><div><br>I could have pasted in =
a super-highly-optimized number-to-string converter,=A0 but that would have=
 just cluttered the thread.<br><br>(std::ostream is already unusably slow f=
or a lot of applications.=A0 std::string is nowhere near as bad, but there&=
#39;s a factor of two available here for long strings.)<br>



</div><div><br><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 dir=3D"ltr"><div><div class=3D"gmail_q=
uote">



<div>As long as they accept basic_string (as you allege) instead of std::st=
ring, this problem is easily solvable with a different allocator.<br clear=
=3D"all"></div></div></div></div></blockquote></div><div><br><br>I thought =
the conclusion from the other thread was that=20
basic_strings with different allocators don&#39;t interoperate.=A0=20
Realistically, libraries except std::string, not arbitrary=20
instantiations of basic_string. <br><br>--Andy<br></div></div></div></div><=
div><div><div><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></div></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 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 />

--089e013cba508b5dba04eb7cd605--

.

------=_Part_778_31089973.1384821703649
Content-Type: text/plain; charset=ISO-8859-1

On Monday, November 18, 2013 4:34:34 PM UTC-8, Billy O'Neal wrote:
>
> 1. Your example allocates once. The intent is to avoid use cases where a
> string allocates 1, then allocates 2, then allocates 4, then allocates 8,
> then allocates 16 .... Nothing in either of your examples shows a case that
> reserve was intended to speed up.
> 2. You are probably benchmarking on a platform which does lazy commit, so
> you actually don't pay for much of the allocation costs until you actually
> write to the memory in question.
>

Nope.  This is my production allocator.  It allocates (at least) 2MB of
real, mlocked backing store every time it needs more.  That memory is
real.  It just gets reused (as it should), so it's fast.  (tcmalloc is a
really nice piece of software.)

Regardless, my point stands: the costs of allocation is not wildly higher
than the cost of zero-filling.  This is also on a Sandy Bridge machine with
a monstrous cache -- I suspect that lots of embedded systems will have much
lower available cache/memory bandwidth for initialization, whereas
allocation may have a similar cost (it's dominated by latency).


> 3. Considering there is no legal way to get to any of the memory between
> size() and capacity() I can't see how this is in any way an optimization
> for initializing the array.
>

Huh?  Every caller of resize is filling the string with a bunch of copies
of the same character.  I suspect that almost none of them actually want
that character there, so they'll overwrite it, so they're paying this cost.

--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_778_31089973.1384821703649
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, November 18, 2013 4:34:34 PM UTC-8, Billy O'Nea=
l 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>=
1. Your example allocates once. The intent is to avoid use cases where a st=
ring allocates 1, then allocates 2, then allocates 4, then allocates 8, the=
n allocates 16 .... Nothing in either of your examples shows a case that re=
serve was intended to speed up.</div>

<div>2. You are probably benchmarking on a platform which does lazy commit,=
 so you actually don't pay for much of the allocation costs until you actua=
lly write to the memory in question.</div></div></blockquote><div><br>Nope.=
&nbsp; This is my production allocator.&nbsp; It allocates (at least) 2MB o=
f real, mlocked backing store every time it needs more.&nbsp; That memory i=
s real.&nbsp; It just gets reused (as it should), so it's fast.&nbsp; (tcma=
lloc is a really nice piece of software.)<br><br>Regardless, my point stand=
s: the costs of allocation is not wildly higher than the cost of zero-filli=
ng.&nbsp; This is also on a Sandy Bridge machine with a monstrous cache -- =
I suspect that lots of embedded systems will have much lower available cach=
e/memory bandwidth for initialization, whereas allocation may have a simila=
r cost (it's dominated by latency).<br>&nbsp;</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div>3. Considering there is no legal=
 way to get to any of the memory between size() and capacity() I can't see =
how this is in any way an optimization for initializing the array.</div></d=
iv></blockquote><div><br>Huh?&nbsp; Every caller of resize is filling the s=
tring with a bunch of copies of the same character.&nbsp; I suspect that al=
most none of them actually want that character there, so they'll overwrite =
it, so they're paying this cost.<br>&nbsp;<br>--Andy</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_778_31089973.1384821703649--

.

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

> Huh?  Every caller of resize is filling the string with a bunch of copies
of the same character.  I suspect that almost none of them actually want
that character there, so they'll overwrite it, so they're paying this cost.

You said "reserve", not "resize". Resize always initializes the memory in
question. Resize does not create space between size() and capacity().

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, Nov 18, 2013 at 4:41 PM, <amluto@gmail.com> wrote:

> On Monday, November 18, 2013 4:34:34 PM UTC-8, Billy O'Neal wrote:
>>
>> 1. Your example allocates once. The intent is to avoid use cases where a
>> string allocates 1, then allocates 2, then allocates 4, then allocates 8,
>> then allocates 16 .... Nothing in either of your examples shows a case that
>> reserve was intended to speed up.
>> 2. You are probably benchmarking on a platform which does lazy commit, so
>> you actually don't pay for much of the allocation costs until you actually
>> write to the memory in question.
>>
>
> Nope.  This is my production allocator.  It allocates (at least) 2MB of
> real, mlocked backing store every time it needs more.  That memory is
> real.  It just gets reused (as it should), so it's fast.  (tcmalloc is a
> really nice piece of software.)
>
> Regardless, my point stands: the costs of allocation is not wildly higher
> than the cost of zero-filling.  This is also on a Sandy Bridge machine with
> a monstrous cache -- I suspect that lots of embedded systems will have much
> lower available cache/memory bandwidth for initialization, whereas
> allocation may have a similar cost (it's dominated by latency).
>
>
>> 3. Considering there is no legal way to get to any of the memory between
>> size() and capacity() I can't see how this is in any way an optimization
>> for initializing the array.
>>
>
> Huh?  Every caller of resize is filling the string with a bunch of copies
> of the same character.  I suspect that almost none of them actually want
> that character there, so they'll overwrite it, so they're paying this cost.
>
> --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/.
>

--

---
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/.

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

<div dir=3D"ltr"><div>&gt; Huh?=A0 Every caller of resize is filling the st=
ring with a bunch of copies of the same character.=A0 I suspect that almost=
 none of them actually want that character there, so they&#39;ll overwrite =
it, so they&#39;re paying this cost.</div>

<div><br></div><div>You said &quot;reserve&quot;, not &quot;resize&quot;. R=
esize always initializes the memory in question. Resize does not create spa=
ce between size() and capacity().</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://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, Nov 18, 2013 at 4:41 PM,  <span =
dir=3D"ltr">&lt;<a href=3D"mailto:amluto@gmail.com" target=3D"_blank">amlut=
o@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div class=3D"im">On Monday, November 18, 2013 4:34:34 PM =
UTC-8, Billy O&#39;Neal wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: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>1. Your example allocates once. The intent is to avoi=
d use cases where a string allocates 1, then allocates 2, then allocates 4,=
 then allocates 8, then allocates 16 .... Nothing in either of your example=
s shows a case that reserve was intended to speed up.</div>



<div>2. You are probably benchmarking on a platform which does lazy commit,=
 so you actually don&#39;t pay for much of the allocation costs until you a=
ctually write to the memory in question.</div></div></blockquote></div>

<div><br>Nope.=A0 This is my production allocator.=A0 It allocates (at leas=
t) 2MB of real, mlocked backing store every time it needs more.=A0 That mem=
ory is real.=A0 It just gets reused (as it should), so it&#39;s fast.=A0 (t=
cmalloc is a really nice piece of software.)<br>

<br>Regardless, my point stands: the costs of allocation is not wildly high=
er than the cost of zero-filling.=A0 This is also on a Sandy Bridge machine=
 with a monstrous cache -- I suspect that lots of embedded systems will hav=
e much lower available cache/memory bandwidth for initialization, whereas a=
llocation may have a similar cost (it&#39;s dominated by latency).<br>

=A0</div><div class=3D"im"><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"><div>3. Consid=
ering there is no legal way to get to any of the memory between size() and =
capacity() I can&#39;t see how this is in any way an optimization for initi=
alizing the array.</div>

</div></blockquote></div><div><br>Huh?=A0 Every caller of resize is filling=
 the string with a bunch of copies of the same character.=A0 I suspect that=
 almost none of them actually want that character there, so they&#39;ll ove=
rwrite it, so they&#39;re paying this cost.<br>

=A0<br>--Andy</div></div><div class=3D"im HOEnZb">

<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><div class=
=3D"HOEnZb"><div class=3D"h5">
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 />

--001a11c1db34da067204eb7cf6d6--

.

On Mon, Nov 18, 2013 at 4:04 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>> I want to be able to do:
>>
>> auto orig_size = s.size();
>> s.resize_default_initialized(orig_size + BIG_ENOUGH);  /* or whatever it's
>> called */
>> s.resize(orig_size + sprintf(&s[orig_size], "%.6f", something));  /*
>> snprintf in real code */
>>
>> This avoids copying and avoids rewriting sprintf.
>
>
> If you really need this level of performance (which seems doubtful if you
> are using sprintf), use a basic_string with a different allocator that does
> default initialization.  Problem solved.

I'd welcome a proposal to add this allocator to the standard. We keep
saying it's possible in order to ward off "foo_uninitialized"
proposals, but we've never really proven it works. If it does work,
having it in the standard might reduce the number of
"foo_uninitialized" proposals we need to ward off.

Jeffrey

--

---
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_2239_33178282.1384824082246
Content-Type: text/plain; charset=ISO-8859-1

On Monday, November 18, 2013 4:57:16 PM UTC-8, Jeffrey Yasskin wrote:
>
> On Mon, Nov 18, 2013 at 4:04 PM, Nevin Liber <ne...@eviloverlord.com<javascript:>>
> wrote:
> >> I want to be able to do:
> >>
> >> auto orig_size = s.size();
> >> s.resize_default_initialized(orig_size + BIG_ENOUGH);  /* or whatever
> it's
> >> called */
> >> s.resize(orig_size + sprintf(&s[orig_size], "%.6f", something));  /*
> >> snprintf in real code */
> >>
> >> This avoids copying and avoids rewriting sprintf.
> >
> >
> > If you really need this level of performance (which seems doubtful if
> you
> > are using sprintf), use a basic_string with a different allocator that
> does
> > default initialization.  Problem solved.
>
> I'd welcome a proposal to add this allocator to the standard. We keep
> saying it's possible in order to ward off "foo_uninitialized"
> proposals, but we've never really proven it works. If it does work,
> having it in the standard might reduce the number of
> "foo_uninitialized" proposals we need to ward off.
>

Even better than having it ward off proposals: it might actually work.

That being said, I doubt it will work: the move constructors and move
assignment operators aren't templates.

--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_2239_33178282.1384824082246
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, November 18, 2013 4:57:16 PM UTC-8, Jeffrey Yas=
skin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Nov 18, 201=
3 at 4:04 PM, Nevin Liber &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"30T_oejRZQ0J">ne...@eviloverlord.com</a>&gt; wrote:
<br>&gt;&gt; I want to be able to do:
<br>&gt;&gt;
<br>&gt;&gt; auto orig_size =3D s.size();
<br>&gt;&gt; s.resize_default_initialized(<wbr>orig_size + BIG_ENOUGH); &nb=
sp;/* or whatever it's
<br>&gt;&gt; called */
<br>&gt;&gt; s.resize(orig_size + sprintf(&amp;s[orig_size], "%.6f", someth=
ing)); &nbsp;/*
<br>&gt;&gt; snprintf in real code */
<br>&gt;&gt;
<br>&gt;&gt; This avoids copying and avoids rewriting sprintf.
<br>&gt;
<br>&gt;
<br>&gt; If you really need this level of performance (which seems doubtful=
 if you
<br>&gt; are using sprintf), use a basic_string with a different allocator =
that does
<br>&gt; default initialization. &nbsp;Problem solved.
<br>
<br>I'd welcome a proposal to add this allocator to the standard. We keep
<br>saying it's possible in order to ward off "foo_uninitialized"
<br>proposals, but we've never really proven it works. If it does work,
<br>having it in the standard might reduce the number of
<br>"foo_uninitialized" proposals we need to ward off.
<br></blockquote><div><br>Even better than having it ward off proposals: it=
 might actually work.<br><br>That being said, I doubt it will work: the mov=
e constructors and move assignment operators aren't templates.<br><br>--And=
y</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_2239_33178282.1384824082246--

.

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

On 18 November 2013 18:57, Jeffrey Yasskin <jyasskin@google.com> wrote:

> I'd welcome a proposal to add this allocator to the standard. We keep
> saying it's possible in order to ward off "foo_uninitialized"
> proposals, but we've never really proven it works.
>

Actually I'm already working on it in my spare time; I have an
implementation and am writing up the proposal. I'll make more announcements
when I'm further along.
--
 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/.

--f46d0438907923f7d504eb7dd5b0
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 18 November 2013 18:57, Jeffrey Yasskin <span dir=3D"ltr">&lt;<a href=3D=
"mailto:jyasskin@google.com" target=3D"_blank">jyasskin@google.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 style=3D"overflow:hidden">I&#39;d welco=
me a proposal to add this allocator to the standard. We keep<br>
saying it&#39;s possible in order to ward off &quot;foo_uninitialized&quot;=
<br>
proposals, but we&#39;ve never really proven it works.</div></blockquote></=
div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Actuall=
y I&#39;m already working on it in my spare time; I have an implementation =
and am writing up the proposal. I&#39;ll make more announcements when I&#39=
;m further along.</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 h=
ref=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 />

--f46d0438907923f7d504eb7dd5b0--

.

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

On 18 November 2013 19:21, <amluto@gmail.com> wrote:

> That being said, I doubt it will work: the move constructors and move
> assignment operators aren't templates.
>

Could you elaborate?  Move constructors and assignment operators aren't
templates pretty much by definition.  I fail to see the relevancy, let
alone an issue.
--
 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1=
8 November 2013 19:21,  <span dir=3D"ltr">&lt;<a href=3D"mailto:amluto@gmai=
l.com" target=3D"_blank">amluto@gmail.com</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>That being said, I doubt it will work: the move constructors and move =
assignment operators aren&#39;t templates.<br></div></blockquote></div><br>=
Could you elaborate? =A0Move constructors and assignment operators aren&#39=
;t templates pretty much by definition. =A0I fail to see the relevancy, let=
 alone an issue.<br>

-- <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 />

--f46d043890793d965604eb7ddd79--

.

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

On Nov 18, 2013 5:48 PM, "Nevin Liber" <nevin@eviloverlord.com> wrote:
>
> On 18 November 2013 19:21, <amluto@gmail.com> wrote:
>>
>> That being said, I doubt it will work: the move constructors and move
assignment operators aren't templates.
>
>
> Could you elaborate?  Move constructors and assignment operators aren't
templates pretty much by definition.  I fail to see the relevancy, let
alone an issue.
>

How can a fancy allocator be used to create an std::string?

> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
> --
>
> ---
> 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/XIO4KbBTxl0/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/.

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

<p dir=3D"ltr"><br>
On Nov 18, 2013 5:48 PM, &quot;Nevin Liber&quot; &lt;<a href=3D"mailto:nevi=
n@eviloverlord.com">nevin@eviloverlord.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On 18 November 2013 19:21, &lt;<a href=3D"mailto:amluto@gmail.com">aml=
uto@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; That being said, I doubt it will work: the move constructors and m=
ove assignment operators aren&#39;t templates.<br>
&gt;<br>
&gt;<br>
&gt; Could you elaborate? =A0Move constructors and assignment operators are=
n&#39;t templates pretty much by definition. =A0I fail to see the relevancy=
, let alone an issue.<br>
&gt;</p>
<p dir=3D"ltr">How can a fancy allocator be used to create an std::string?<=
/p>
<p dir=3D"ltr">&gt; -- <br>
&gt; =A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@e=
viloverlord.com">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404<br>
&gt;<br>
&gt; -- <br>
&gt; =A0<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to a topic in the=
 Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this topic, visit <a href=3D"https://groups.google=
..com/a/isocpp.org/d/topic/std-proposals/XIO4KbBTxl0/unsubscribe">https://gr=
oups.google.com/a/isocpp.org/d/topic/std-proposals/XIO4KbBTxl0/unsubscribe<=
/a>.<br>

&gt; To unsubscribe from this group and all its topics, send an email to <a=
 href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsub=
scribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<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 />

--089e012279a2f9d45604eb7de5b5--

.

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

It wouldn't be a std::string. It would be a std::basic_string<char,
no_init_allocator<char>>.

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, Nov 18, 2013 at 5:51 PM, Andrew Lutomirski <andy@luto.us> wrote:

>
> On Nov 18, 2013 5:48 PM, "Nevin Liber" <nevin@eviloverlord.com> wrote:
> >
> > On 18 November 2013 19:21, <amluto@gmail.com> wrote:
> >>
> >> That being said, I doubt it will work: the move constructors and move
> assignment operators aren't templates.
> >
> >
> > Could you elaborate?  Move constructors and assignment operators aren't
> templates pretty much by definition.  I fail to see the relevancy, let
> alone an issue.
> >
>
> How can a fancy allocator be used to create an std::string?
>
> > --
> >  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
> >
> > --
> >
> > ---
> > 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/XIO4KbBTxl0/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/.

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

<div dir=3D"ltr">It wouldn&#39;t be a std::string. It would be a std::basic=
_string&lt;char, no_init_allocator&lt;char&gt;&gt;.</div><div class=3D"gmai=
l_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 Mon, Nov 18, 2013 at 5:51 PM, Andrew =
Lutomirski <span dir=3D"ltr">&lt;<a href=3D"mailto:andy@luto.us" target=3D"=
_blank">andy@luto.us</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">

<div class=3D"im"><p dir=3D"ltr"><br>
On Nov 18, 2013 5:48 PM, &quot;Nevin Liber&quot; &lt;<a href=3D"mailto:nevi=
n@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt; wrote:=
<br>
&gt;<br>
&gt; On 18 November 2013 19:21, &lt;<a href=3D"mailto:amluto@gmail.com" tar=
get=3D"_blank">amluto@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; That being said, I doubt it will work: the move constructors and m=
ove assignment operators aren&#39;t templates.<br>
&gt;<br>
&gt;<br>
&gt; Could you elaborate? =A0Move constructors and assignment operators are=
n&#39;t templates pretty much by definition. =A0I fail to see the relevancy=
, let alone an issue.<br>
&gt;</p>
</div><p dir=3D"ltr">How can a fancy allocator be used to create an std::st=
ring?</p>
<p dir=3D"ltr"><div class=3D"im">&gt; -- <br>
&gt; =A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@e=
viloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 <a hre=
f=3D"tel:%28847%29%20691-1404" target=3D"_blank" value=3D"+18476911404">(84=
7) 691-1404</a><br>


&gt;<br>
&gt; -- <br>
&gt; =A0<br>
&gt; --- <br></div>
&gt; You received this message because you are subscribed to a topic in the=
 Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this topic, visit <a href=3D"https://groups.google=
..com/a/isocpp.org/d/topic/std-proposals/XIO4KbBTxl0/unsubscribe" target=3D"=
_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/XIO4Kb=
BTxl0/unsubscribe</a>.<br>



&gt; 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">s=
td-proposals+unsubscribe@isocpp.org</a>.<div class=3D"im"><br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.or=
g/group/std-proposals/</a>.<br>
</div><p></p><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></p></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 />

--047d7b5d42f8e163de04eb7df393--

.

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

On 18 November 2013 19:51, Andrew Lutomirski <andy@luto.us> wrote:

> How can a fancy allocator be used to create an std::string?
>
Oh; I'm not trying to solve that problem.  In general, it is unsolvable w/o
a type erased allocator (which are coming along in
N3525<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3525.pdf>,
but obviously not to the current std::string).

If others wish to make a far more complicated and less likely to pass
proposal to cover the .0001% of cases where they have high performance /
low latency needs not to 0-fill a buffer but still are required to use
std::string and vector<char> to accomplish it, they are more than welcome
to implement it, write it up and come to a few meetings to champion 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/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On 18 November 2013 19:51, Andr=
ew Lutomirski <span dir=3D"ltr">&lt;<a href=3D"mailto:andy@luto.us" target=
=3D"_blank">andy@luto.us</a>&gt;</span> wrote:<br><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">

<div class=3D"im"><p dir=3D"ltr"><span class=3D"Apple-style-span" style=3D"=
color:rgb(34,34,34)">How can a fancy allocator be used to create an std::st=
ring?</span></p></div></blockquote><div>Oh; I&#39;m not trying to solve tha=
t problem. =A0In general, it is unsolvable w/o a type erased allocator (whi=
ch are coming along in=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2013/n3525.pdf">N3525</a>, but obviously not to the current std=
::string).</div>

<div><br></div><div>If others wish to make a far more complicated and less =
likely to pass proposal to cover the .0001% of cases where they have high p=
erformance / low latency needs not to 0-fill a buffer but still are require=
d to use std::string and vector&lt;char&gt; to accomplish it, they are more=
 than welcome to implement it, write it up and come to a few meetings to ch=
ampion 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 />

--f46d04428ca01ff17d04eb7e0a2a--

.

On segunda-feira, 18 de novembro de 2013 16:25:55, Billy O'Neal wrote:
> Because the built in container classes are generally designed to prevent
> the user from breaking their invariants. A piece of code can get passed a
> std::basic_string and assume, without any other information, that the data
> inside is not garbage. That is a useful invariant to people passing around
> std::strings, particularly over an ability which is only useful in
> specialized text processing domains (which shouldn't be passing around
> strings anyway).

Garbage is in the eye of the beholder.

 string s;
 s.resize(10);

Might be garbage if the receiver isn't expecting a string full of nulls.
--
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

--

---
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/.

.

El 19/11/2013 2:45, Nevin Liber escribi=F3:
>
> On 18 November 2013 18:57, Jeffrey Yasskin <jyasskin@google.com
> <mailto:jyasskin@google.com>> wrote:
>
>     I'd welcome a proposal to add this allocator to the standard. We keep
>     saying it's possible in order to ward off "foo_uninitialized"
>     proposals, but we've never really proven it works.
>
>
> Actually I'm already working on it in my spare time; I have an
> implementation and am writing up the proposal. I'll make more
> announcements when I'm further along.

Just to start doing some measurements after reading "proposal to add=20
vector::push_back_()" thread, I added (silently) in Boost.Container the=20
following extensions:

vector::vector(size_type, default_init_t);
void vector::resize(size_type, default_init_t);

Those functions are available in recently released Boost 1.55 only for=20
internal testing. The documentation is wrong (it says stored objects are=20
value initialized instead of "default initialized"), but it will be=20
correctly documented and tested for Boost 1.56. I plan to add it also to=20
basic_string as the best way to know if it's useful is to have a working=20
implementation and real-world measurements.

The implementation is simple, boost::container::allocator_traits is=20
extended to detect if

   a.construct(boost::container::default_init_t)
   [where 'a' is the container allocator]

is callable. If not, the default implementation from allocator_traits is=20
used:

   ::new((void*)p) T;

Hope this helps,

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/.

.

On Tue, Nov 19, 2013 at 12:25 AM, Ion Gazta=F1aga <igaztanaga@gmail.com> wr=
ote:
> El 19/11/2013 2:45, Nevin Liber escribi=F3:
>>
>>
>> On 18 November 2013 18:57, Jeffrey Yasskin <jyasskin@google.com
>> <mailto:jyasskin@google.com>> wrote:
>>
>>     I'd welcome a proposal to add this allocator to the standard. We kee=
p
>>     saying it's possible in order to ward off "foo_uninitialized"
>>     proposals, but we've never really proven it works.
>>
>>
>> Actually I'm already working on it in my spare time; I have an
>> implementation and am writing up the proposal. I'll make more
>> announcements when I'm further along.
>
>
> Just to start doing some measurements after reading "proposal to add
> vector::push_back_()" thread, I added (silently) in Boost.Container the
> following extensions:
>
> vector::vector(size_type, default_init_t);
> void vector::resize(size_type, default_init_t);
>
> Those functions are available in recently released Boost 1.55 only for
> internal testing. The documentation is wrong (it says stored objects are
> value initialized instead of "default initialized"), but it will be
> correctly documented and tested for Boost 1.56. I plan to add it also to
> basic_string as the best way to know if it's useful is to have a working
> implementation and real-world measurements.

That sounds useful.

Random thoughts:

1. The standard talks about "default-initialized" and
"value-initialized".  I wonder if any non-standard-reading programmers
would understand those terms.  I would certainly think of char() (i.e.
0) as the "default" char, but that's not at all what it means.  Would
something like "weak_init_t" be better?

2. I wonder how far this can be pushed.  Would it make sense for char
x{default_init_t()} to result in an uninitialized char?  Should new
char(default_init_t()) result in a pointer to an uninitialized char?
Should a struct like "struct Foo { char x; };" imply the creation of
Foo::Foo(default_init_t) (assuming that Foo has no user-defined
constructors or destructors and all of its members are either scalar
or have default_init_t constuctors)?  I think that there's value in
having an operation "initialize to a state that's safe to copy and
destruct but otherwise minimize the extent of initialization".

--Andy

>
> The implementation is simple, boost::container::allocator_traits is exten=
ded
> to detect if
>
>   a.construct(boost::container::default_init_t)
>   [where 'a' is the container allocator]
>
> is callable. If not, the default implementation from allocator_traits is
> used:
>
>   ::new((void*)p) T;
>
> Hope this helps,
>
> Ion
>
>
> --
>
> --- You received this message because you are subscribed to a topic in th=
e
> 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/XIO4KbBTxl0/=
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/.

.

------=_Part_1028_18004533.1385290824650
Content-Type: text/plain; charset=ISO-8859-1

Is basic_string required to use its allocator to construct/destruct
elements?
As I understand the standard, it is not (allocator is used only for
allocating/deallocating memory), i.e. allocator is not enough to achieve
the desired effect for basic_string (but it is enough for e.g. vector).

>>::new((void*)p) T
BTW, I tested this approach with Visual C++ 2012 and, sadly, such a
construct in allocator isn't properly eliminated/optimized out for
primitive types and gives no performance gain compared to value
initialization ::new((void*)p) T()
How other compilers behave in this situation?

--

---
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_1028_18004533.1385290824650
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is basic_string required to use its allocator to construct=
/destruct elements?<br>As I understand the standard, it is not (allocator i=
s used only for allocating/deallocating memory), i.e. allocator is not enou=
gh to achieve the desired effect for basic_string (but it is enough for e.g=
.. vector).<br><br>&gt;&gt;::new((void*)p) T<br>BTW, I tested this approach =
with Visual C++ 2012 and, sadly, such a construct in allocator isn't proper=
ly eliminated/optimized out for primitive types and gives no performance ga=
in compared to value initialization ::new((void*)p) T()<br>How other compil=
ers behave in this situation?<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_1028_18004533.1385290824650--

.