On Tue, Sep 24, 2013 at 11:51 PM,  <germandiago@gmail.com> wrote:
> I think, in my opinion, that the correct way to do it is to format a string
> and to return a string formatted that could be output later.

C printf is locale aware, and the most confirming way to
achieve locale awareness is to target streams.

However, we got a strong consensus to have a new,
non-printf compatible formatting facility in addition to
the printf compatible one.  For the new one, I plan to
do a string(_view) to string formatting.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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

.

------=_Part_4364_11633163.1380651193472
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, September 24, 2013 8:51:07 PM UTC-7, germa...@gmail.com wrote:

> Hello everyone,
>
> Taking a look at this proposal, I was just wondering why we would want to
> add a printf-like interface to the iostreams library.
> When something has to be formatted, it must be sent to the output.
>
> I think, in my opinion, that the correct way to do it is to format a
> string and to return a string formatted that could be output later.
>
> Why? Because this way you can format strings in memory easily. This is
> what python3 string formatting<http://www.diveinto.org/python3/strings.html> does
> AFAIK and it has proved to
> work very well in my experience using it.
>
> Is there anything I am overlooking?
>

One thing I would argue is performance.  There are two things that are
clear, obvious, low-handing fruit to "fix" (by simply avoiding).  One is
memory allocation overhead.  The other is I/O.  If one is, say, logging
output in the midst of a soft-real-time server for a physically-driven
simulation (a multiplayer action game), the overhead of the logging is
significant and a real performance problem.  Exacerbating this by forcing a
chunk of memory allocations for every line logged would just make things
worse.

I'm all for having the 'sprintf' facility (it'd be useful in tools and
other non-performance-sensitive work even in my industry), but there's
still a clear need for a more direct 'printf' facility.  Or better would be
a more flexible formatting facility that didn't place any requirements on
how memory is used or where the formatting text is sent.

One way to handle both of these would be to simply allow the formatting
library to work with stream buffers, such that a stringbuffer, a cached I/O
buffer, or a non-cached I/O manager can be used as appropriate for the
application and problem domain.  I think the blog post linked by isocpp.org
recently on the topic is a good read relevant to any future formatting
library work:
http://marcoarena.wordpress.com/2013/09/13/dont-couple-streams-with-devices/


> Thanks
>

--

---
You received this message because you are 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_4364_11633163.1380651193472
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, September 24, 2013 8:51:07 PM UTC-7, germa...@=
gmail.com wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Hello everyone,<div><br></div><div>Taking a look at this proposal,=
 I was just wondering why we would want to add a printf-like interface to t=
he iostreams library.</div><div>When something has to be formatted, it must=
 be sent to the output.</div><div><br></div><div>I think, in my opinion, th=
at the correct way to do it is to format a string and to return a string fo=
rmatted that could be output later.&nbsp;</div><div><br></div><div>Why? Bec=
ause this way you can format strings in memory easily. This is what&nbsp;<a=
 href=3D"http://www.diveinto.org/python3/strings.html" target=3D"_blank">py=
thon3 string formatting</a>&nbsp;does AFAIK and it has proved to</div><div>=
work very well in my experience using it.</div><div><br></div><div>Is there=
 anything I am overlooking?</div></div></blockquote><div><br></div><div>One=
 thing I would argue is performance. &nbsp;There are two things that are cl=
ear, obvious, low-handing fruit to "fix" (by simply avoiding). &nbsp;One is=
 memory allocation overhead. &nbsp;The other is I/O. &nbsp;If one is, say, =
logging output in the midst of a soft-real-time server for a physically-dri=
ven simulation (a multiplayer action game), the overhead of the logging is =
significant and a real performance problem. &nbsp;Exacerbating this by forc=
ing a chunk of memory allocations for every line logged would just make thi=
ngs worse.</div><div><br></div><div>I'm all for having the 'sprintf' facili=
ty (it'd be useful in tools and other non-performance-sensitive work even i=
n my industry), but there's still a clear need for a more direct 'printf' f=
acility. &nbsp;Or better would be a more flexible formatting facility that =
didn't place any requirements on how memory is used or where the formatting=
 text is sent.</div><div><br></div><div>One way to handle both of these wou=
ld be to simply allow the formatting library to work with stream buffers, s=
uch that a stringbuffer, a cached I/O buffer, or a non-cached I/O manager c=
an be used as appropriate for the application and problem domain. &nbsp;I t=
hink the blog post linked by isocpp.org recently on the topic is a good rea=
d relevant to any future formatting library work:&nbsp;<a href=3D"http://ma=
rcoarena.wordpress.com/2013/09/13/dont-couple-streams-with-devices/">http:/=
/marcoarena.wordpress.com/2013/09/13/dont-couple-streams-with-devices/</a><=
/div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><br></div><div>Thanks</div></div></blockquote></div>

<p></p>

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

------=_Part_4364_11633163.1380651193472--

.

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

Are you certain that the formatting aspects of iostreams are the cause of
the performance loss there? I think locale / codecvt and similar would have
a larger effect.

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


On Tue, Oct 1, 2013 at 11:13 AM, Sean Middleditch <
sean.middleditch@gmail.com> wrote:

> On Tuesday, September 24, 2013 8:51:07 PM UTC-7, germa...@gmail.com wrote:
>
>> Hello everyone,
>>
>> Taking a look at this proposal, I was just wondering why we would want to
>> add a printf-like interface to the iostreams library.
>> When something has to be formatted, it must be sent to the output.
>>
>> I think, in my opinion, that the correct way to do it is to format a
>> string and to return a string formatted that could be output later.
>>
>> Why? Because this way you can format strings in memory easily. This is
>> what python3 string formatting<http://www.diveinto.org/python3/strings.html> does
>> AFAIK and it has proved to
>> work very well in my experience using it.
>>
>> Is there anything I am overlooking?
>>
>
> One thing I would argue is performance.  There are two things that are
> clear, obvious, low-handing fruit to "fix" (by simply avoiding).  One is
> memory allocation overhead.  The other is I/O.  If one is, say, logging
> output in the midst of a soft-real-time server for a physically-driven
> simulation (a multiplayer action game), the overhead of the logging is
> significant and a real performance problem.  Exacerbating this by forcing a
> chunk of memory allocations for every line logged would just make things
> worse.
>
> I'm all for having the 'sprintf' facility (it'd be useful in tools and
> other non-performance-sensitive work even in my industry), but there's
> still a clear need for a more direct 'printf' facility.  Or better would be
> a more flexible formatting facility that didn't place any requirements on
> how memory is used or where the formatting text is sent.
>
> One way to handle both of these would be to simply allow the formatting
> library to work with stream buffers, such that a stringbuffer, a cached I/O
> buffer, or a non-cached I/O manager can be used as appropriate for the
> application and problem domain.  I think the blog post linked by
> isocpp.org recently on the topic is a good read relevant to any future
> formatting library work:
> http://marcoarena.wordpress.com/2013/09/13/dont-couple-streams-with-devices/
>
>
>> Thanks
>>
>  --
>
> ---
> You received this message because you are 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/.

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

<div dir=3D"ltr">Are you certain that the formatting aspects of iostreams a=
re the cause of the performance loss there? I think locale / codecvt and si=
milar would have a larger effect.</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 Tue, Oct 1, 2013 at 11:13 AM, Sean Mi=
ddleditch <span dir=3D"ltr">&lt;<a href=3D"mailto:sean.middleditch@gmail.co=
m" target=3D"_blank">sean.middleditch@gmail.com</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">

<div dir=3D"ltr">On Tuesday, September 24, 2013 8:51:07 PM UTC-7, <a href=
=3D"mailto:germa...@gmail.com" target=3D"_blank">germa...@gmail.com</a> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;b=
order-left-style:solid">

<div dir=3D"ltr">Hello everyone,<div><br></div><div>Taking a look at this p=
roposal, I was just wondering why we would want to add a printf-like interf=
ace to the iostreams library.</div><div>When something has to be formatted,=
 it must be sent to the output.</div>

<div><br></div><div>I think, in my opinion, that the correct way to do it i=
s to format a string and to return a string formatted that could be output =
later.=A0</div><div><br></div><div>Why? Because this way you can format str=
ings in memory easily. This is what=A0<a href=3D"http://www.diveinto.org/py=
thon3/strings.html" target=3D"_blank">python3 string formatting</a>=A0does =
AFAIK and it has proved to</div>

<div>work very well in my experience using it.</div><div><br></div><div>Is =
there anything I am overlooking?</div></div></blockquote><div><br></div><di=
v>One thing I would argue is performance. =A0There are two things that are =
clear, obvious, low-handing fruit to &quot;fix&quot; (by simply avoiding). =
=A0One is memory allocation overhead. =A0The other is I/O. =A0If one is, sa=
y, logging output in the midst of a soft-real-time server for a physically-=
driven simulation (a multiplayer action game), the overhead of the logging =
is significant and a real performance problem. =A0Exacerbating this by forc=
ing a chunk of memory allocations for every line logged would just make thi=
ngs worse.</div>

<div><br></div><div>I&#39;m all for having the &#39;sprintf&#39; facility (=
it&#39;d be useful in tools and other non-performance-sensitive work even i=
n my industry), but there&#39;s still a clear need for a more direct &#39;p=
rintf&#39; facility. =A0Or better would be a more flexible formatting facil=
ity that didn&#39;t place any requirements on how memory is used or where t=
he formatting text is sent.</div>

<div><br></div><div>One way to handle both of these would be to simply allo=
w the formatting library to work with stream buffers, such that a stringbuf=
fer, a cached I/O buffer, or a non-cached I/O manager can be used as approp=
riate for the application and problem domain. =A0I think the blog post link=
ed by <a href=3D"http://isocpp.org" target=3D"_blank">isocpp.org</a> recent=
ly on the topic is a good read relevant to any future formatting library wo=
rk:=A0<a href=3D"http://marcoarena.wordpress.com/2013/09/13/dont-couple-str=
eams-with-devices/" target=3D"_blank">http://marcoarena.wordpress.com/2013/=
09/13/dont-couple-streams-with-devices/</a></div>

<div><br></div><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><br></div><div>Thanks=
</div>

</div></blockquote></div><span class=3D"HOEnZb"><font color=3D"#888888">

<p></p>

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

<p></p>

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

--047d7bd756e22fda0004e7b414f5--

.

------=_Part_1370_32721653.1380946315940
Content-Type: text/plain; charset=ISO-8859-1

Honestly I don't know that I like this idea just yet.
What I would dream about is one formatting solution to rule them all.
Right now we have printf and oprerator<<() and complex reasons to choose
one or the other.

Now with putf(), we have 3. If putf is efficient and can do everything, its
a no brainer for sure.

If its more readable, type safe, easy to use, allows extra semantics like
locking, then operator<<() can be retired.
If its not as fast as printf however, there is still a valid reason to use
printf. Especially for people who run
into situations where the logging subsystem is the botttleneck. I've it
happen because of allocating strings to contruct
messages and dealing with iostreams. Second, we MUST have the ability to
format into a memory buffer,
I do this all of the time with snprintf.

If putf has to use a stringstream or other iostream operations to print
user defined types, it may be impossible
to match or beat printf.

My nightmare is the only thing gained from this is now we have 3 options
which are all insufficient in different ways.

I believe strongly that variadic templates are the correct solution for a
printf/operator<<() marraige. I don't think
it should be mixed with operator<<(). operator<<() should be legacy because
operator overloading is unnessary an clumsy
for this task compared to variadic templates.

cout << putf(/*stuff*/); //bad, we leave a dependency on iostreams. There
is rumblings of a replacement. Also the << is unnessesary cruft
putf(cout, /*stuff*/); //better, works well with iostream but not dependent
on operator<<(), easily could support more
destination objects like std::string, std::vector<char>, char*/size_t, etc..

--

---
You received this message because you are 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_1370_32721653.1380946315940
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Honestly I don't know that I like this idea just yet.<br>W=
hat I would dream about is one formatting solution to rule them all.<div>Ri=
ght now we have printf and oprerator&lt;&lt;() and complex reasons to choos=
e one or the other.</div><div><br></div><div>Now with putf(), we have 3. If=
 putf is efficient and can do everything, its a no brainer for sure.</div><=
div><br>If its more readable, type safe, easy to use, allows extra semantic=
s like locking, then operator&lt;&lt;() can be retired.</div><div>If its no=
t as fast as printf however, there is still a valid reason to use printf. E=
specially for people who run</div><div>into situations where the logging su=
bsystem is the botttleneck. I've it happen because of allocating strings to=
 contruct</div><div>messages&nbsp;<span style=3D"font-size: 13px;">and deal=
ing with iostreams. Second, we MUST have the ability to format into a memor=
y buffer,</span></div><div><span style=3D"font-size: 13px;">I do this all o=
f the time with snprintf.</span></div><div><span style=3D"font-size: 13px;"=
><br></span></div><div>If putf has to use a stringstream or other iostream =
operations to print user defined types, it may be impossible</div><div>to m=
atch or beat printf.</div><div><span style=3D"font-size: 13px;"><br></span>=
</div><div><span style=3D"font-size: 13px;">My nightmare is the only thing =
gained from this is now we have 3 options which are all insufficient in dif=
ferent ways.</span></div><div><span style=3D"font-size: 13px;"><br></span><=
/div><div><span style=3D"font-size: 13px;">I believe strongly that variadic=
 templates are the correct solution for a printf/operator&lt;&lt;() marraig=
e. I don't think</span></div><div><span style=3D"font-size: 13px;">it shoul=
d be mixed with operator&lt;&lt;(). operator&lt;&lt;() should be legacy bec=
ause operator overloading is unnessary an clumsy</span></div><div><span sty=
le=3D"font-size: 13px;">for this task compared to variadic templates.</span=
></div><div><span style=3D"font-size: 13px;"><br></span></div><div><span st=
yle=3D"font-size: 13px;">cout &lt;&lt; putf(/*stuff*/); //bad, we leave a d=
ependency on iostreams. There is rumblings of a replacement. Also the &lt;&=
lt; is unnessesary cruft</span></div><div><span style=3D"font-size: 13px;">=
putf(cout, /*stuff*/); //better, works well with iostream but not dependent=
 on operator&lt;&lt;(), easily could support more</span></div><div><span st=
yle=3D"font-size: 13px;">destination objects like std::string, std::vector&=
lt;char&gt;, char*/size_t, etc..</span></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_1370_32721653.1380946315940--

.

On Sat, Oct 5, 2013 at 12:11 AM,  <fmatthew5876@gmail.com> wrote:
> My nightmare is the only thing gained from this is now we have 3 options
> which are all insufficient in different ways.

We are going to have 4.  Read threads.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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

.