------=_Part_657_468509676.1413570959945
Content-Type: text/plain; charset=UTF-8



Consider the to_string library of functions such as:

std::string to_string(int value);

This interface while convenient is horribly inefficient. Every time you
call this function you will allocate memory for a temporary string. If you
plan to do this operation multiple times (which is common for use cases
such as file parsing routines) you cannot avoid these memory allocations
with move semantics or return value optimization. The performance
implications of to_string make it unusable for high performance parsing
routines.

I would propose 2 additional overloads.

string_view to_string(std::string& dest, int value);
string_view to_string(std::array_view<char> dest, int value);

The first version allows you to still parse the data into a memory buffer
backed by a std::string but allows you to reuse the same string object and
save on memory allocations. The second version is available if you
absolutely don't want to allocate memory at all and just store the results
(possibly truncated) into a fixed size buffer. Since int to string
conversions always have a maximum length on the resulting string, we can
easily create a fixed size buffer on the stack. Not only does creating a
buffer on the stack avoid memory allocation, the stack space itself is
likely to be hot in the cache already whereas a random buffer returned by
operator new will not be.

Compare the following 3 code fragments:

std::cout << to_string(i); //memory allocation
std::cout << to_string(j); //memory allocation
std::cout << to_string(k); //memory allocation

std::string s;
std::cout << to_string(s, i); //memory allocation
std::cout << to_string(s, j); //likely no memory allocation, reuse the
buffer
std::cout << to_string(s, k); //likely no memory allocation, reuse the
buffer


char s[64]; //Chose some size big enough for the maximal string
representation for decltype(i), delctype(j), and decltype(k)
std::cout << to_string(s, i); //no memory allocation
std::cout << to_string(s, j); //no memory allocation
std::cout << to_string(s, k); //no memory allocation

The implementation of each of these can be built on top of one another and
without optimization can be trivially implemented using snprintf
string_view to_string(array_view<char> s, int value) {
  int len = snprintf(s.data(), s.length(), "%d", value);
  return string_view(s.data(), len);
}



string_view to_string(string& s, int value) {
  char buf[32];
  auto sv = to_string(buf, value);
  s = sv;
  return sv;
}

string to_string(int value) {
  string s;
  to_string(s, value);
  return s;
}



--

---
You received this message because you are 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_657_468509676.1413570959945
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Consider the to_string library of functions such as:</p=
><p><div style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-wo=
rd; background-color: rgb(250, 250, 250);" class=3D"prettyprint"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: rgb(0=
, 0, 0);" class=3D"styled-by-prettify">std</span><span style=3D"color: rgb(=
102, 102, 0);" class=3D"styled-by-prettify">::</span><span style=3D"color: =
rgb(0, 0, 136);" class=3D"styled-by-prettify">string</span><span style=3D"c=
olor: rgb(0, 0, 0);" class=3D"styled-by-prettify"> to_string</span><span st=
yle=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">int</span><s=
pan style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> value</spa=
n><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">);<=
/span></div></code></div><p></p><p>This interface while convenient is horri=
bly inefficient. Every time you call this function you will allocate memory=
 for a temporary string. If you plan to do this operation multiple times (w=
hich is common for use cases such as file parsing routines) you cannot avoi=
d these memory allocations with move semantics or return value optimization=
.. The performance implications of to_string make it unusable for high perfo=
rmance parsing routines.</p><p>I would propose 2 additional overloads.</p><=
p><div style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word=
; background-color: rgb(250, 250, 250);" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: rgb(0,=
 0, 0);" class=3D"styled-by-prettify">string_view to_string</span><span sty=
le=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">(</span><span =
style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">std</span><span=
 style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">::</span><=
span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">string</=
span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">=
&amp;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettif=
y"> dest</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-=
prettify">,</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-=
prettify">int</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by=
-prettify"> value</span><span style=3D"color: rgb(102, 102, 0);" class=3D"s=
tyled-by-prettify">);</span><span style=3D"color: rgb(0, 0, 0);" class=3D"s=
tyled-by-prettify"><br>string_view to_string</span><span style=3D"color: rg=
b(102, 102, 0);" class=3D"styled-by-prettify">(</span><span style=3D"color:=
 rgb(0, 0, 0);" class=3D"styled-by-prettify">std</span><span style=3D"color=
: rgb(102, 102, 0);" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: rgb(0, 0, 0);" class=3D"styled-by-prettify">array_view</span><span st=
yle=3D"color: rgb(0, 136, 0);" class=3D"styled-by-prettify">&lt;char&gt;</s=
pan><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> dest=
</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify=
">,</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"=
> </span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify=
">int</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettif=
y"> value</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by=
-prettify">);</span></div></code></div><br><p></p><p>The first version allo=
ws you to still parse the data into a memory buffer backed by a std::string=
 but allows you to reuse the same string object and save on memory allocati=
ons. The second version is available if you absolutely don't want to alloca=
te memory at all and just store the results (possibly truncated) into a fix=
ed size buffer. Since int to string conversions always have a maximum lengt=
h on the resulting string, we can easily create a fixed size buffer on the =
stack. Not only does creating a buffer on the stack avoid memory allocation=
, the stack space itself is likely to be hot in the cache already whereas a=
 random buffer returned by operator new will not be.</p><p>Compare the foll=
owing 3 code fragments:</p><p><div style=3D"border: 1px solid rgb(187, 187,=
 187); word-wrap: break-word; background-color: rgb(250, 250, 250);" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">std</span=
><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">::</=
span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">cout=
 </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettif=
y">&lt;&lt;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-p=
rettify"> to_string</span><span style=3D"color: rgb(102, 102, 0);" class=3D=
"styled-by-prettify">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"=
styled-by-prettify">i</span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"styled-by-prettify">);</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"> </span><span style=3D"color: rgb(136, 0, 0);" clas=
s=3D"styled-by-prettify">//memory allocation</span><span style=3D"color: rg=
b(0, 0, 0);" class=3D"styled-by-prettify"><br>std</span><span style=3D"colo=
r: rgb(102, 102, 0);" class=3D"styled-by-prettify">::</span><span style=3D"=
color: rgb(0, 0, 0);" class=3D"styled-by-prettify">cout </span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">&lt;&lt;</span><=
span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> to_string=
</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify=
">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"=
>j</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pretti=
fy">);</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: rgb(136, 0, 0);" class=3D"styled-by-prett=
ify">//memory allocation</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"><br>std</span><span style=3D"color: rgb(102, 102, 0=
);" class=3D"styled-by-prettify">::</span><span style=3D"color: rgb(0, 0, 0=
);" class=3D"styled-by-prettify">cout </span><span style=3D"color: rgb(102,=
 102, 0);" class=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color=
: rgb(0, 0, 0);" class=3D"styled-by-prettify"> to_string</span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">k</span><span sty=
le=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">);</span><span=
 style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span =
style=3D"color: rgb(136, 0, 0);" class=3D"styled-by-prettify">//memory allo=
cation</span></div></code></div><br><div style=3D"border: 1px solid rgb(187=
, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);" =
class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettypr=
int"><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">std<=
/span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify"=
>::</span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettif=
y">string</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pre=
ttify"> s</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by=
-prettify">;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-=
prettify"><br>std</span><span style=3D"color: rgb(102, 102, 0);" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: rgb(0, 0, 0);" class=3D"s=
tyled-by-prettify">cout </span><span style=3D"color: rgb(102, 102, 0);" cla=
ss=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: rgb(0, 0, 0)=
;" class=3D"styled-by-prettify"> to_string</span><span style=3D"color: rgb(=
102, 102, 0);" class=3D"styled-by-prettify">(</span><span style=3D"color: r=
gb(0, 0, 0);" class=3D"styled-by-prettify">s</span><span style=3D"color: rg=
b(102, 102, 0);" class=3D"styled-by-prettify">,</span><span style=3D"color:=
 rgb(0, 0, 0);" class=3D"styled-by-prettify"> i</span><span style=3D"color:=
 rgb(102, 102, 0);" class=3D"styled-by-prettify">);</span><span style=3D"co=
lor: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: rgb(136, 0, 0);" class=3D"styled-by-prettify">//memory allocation</span=
><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>std<=
/span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify"=
>::</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"=
>cout </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pr=
ettify">&lt;&lt;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled=
-by-prettify"> to_string</span><span style=3D"color: rgb(102, 102, 0);" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: rgb(0, 0, 0);" clas=
s=3D"styled-by-prettify">s</span><span style=3D"color: rgb(102, 102, 0);" c=
lass=3D"styled-by-prettify">,</span><span style=3D"color: rgb(0, 0, 0);" cl=
ass=3D"styled-by-prettify"> j</span><span style=3D"color: rgb(102, 102, 0);=
" class=3D"styled-by-prettify">);</span><span style=3D"color: rgb(0, 0, 0);=
" class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(136, 0, 0)=
;" class=3D"styled-by-prettify">//likely no memory allocation, reuse the bu=
ffer</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify=
"><br>std</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by=
-prettify">::</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by=
-prettify">cout </span><span style=3D"color: rgb(102, 102, 0);" class=3D"st=
yled-by-prettify">&lt;&lt;</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"> to_string</span><span style=3D"color: rgb(102, 102=
, 0);" class=3D"styled-by-prettify">(</span><span style=3D"color: rgb(0, 0,=
 0);" class=3D"styled-by-prettify">s</span><span style=3D"color: rgb(102, 1=
02, 0);" class=3D"styled-by-prettify">,</span><span style=3D"color: rgb(0, =
0, 0);" class=3D"styled-by-prettify"> k</span><span style=3D"color: rgb(102=
, 102, 0);" class=3D"styled-by-prettify">);</span><span style=3D"color: rgb=
(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(=
136, 0, 0);" class=3D"styled-by-prettify">//likely no memory allocation, re=
use the buffer</span></div></code></div><br><br><div style=3D"border: 1px s=
olid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, =
250, 250);" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-=
prettify">char</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-b=
y-prettify"> s</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styl=
ed-by-prettify">[</span><span style=3D"color: rgb(0, 102, 102);" class=3D"s=
tyled-by-prettify">64</span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"styled-by-prettify">];</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"> </span><span style=3D"color: rgb(136, 0, 0);" clas=
s=3D"styled-by-prettify">//Chose some size big enough for the maximal strin=
g representation for decltype(i), delctype(j), and decltype(k)</span><span =
style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>std</span><=
span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">cout <=
/span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify"=
>&lt;&lt;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pre=
ttify"> to_string</span><span style=3D"color: rgb(102, 102, 0);" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"st=
yled-by-prettify">s</span><span style=3D"color: rgb(102, 102, 0);" class=3D=
"styled-by-prettify">,</span><span style=3D"color: rgb(0, 0, 0);" class=3D"=
styled-by-prettify"> i</span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"styled-by-prettify">);</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"> </span><span style=3D"color: rgb(136, 0, 0);" clas=
s=3D"styled-by-prettify">//no memory allocation</span><span style=3D"color:=
 rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>std</span><span style=3D"c=
olor: rgb(102, 102, 0);" class=3D"styled-by-prettify">::</span><span style=
=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">cout </span><span st=
yle=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">&lt;&lt;</spa=
n><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> to_str=
ing</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pretti=
fy">s</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pre=
ttify">,</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pret=
tify"> j</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-=
prettify">);</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-=
prettify"> </span><span style=3D"color: rgb(136, 0, 0);" class=3D"styled-by=
-prettify">//no memory allocation</span><span style=3D"color: rgb(0, 0, 0);=
" class=3D"styled-by-prettify"><br>std</span><span style=3D"color: rgb(102,=
 102, 0);" class=3D"styled-by-prettify">::</span><span style=3D"color: rgb(=
0, 0, 0);" class=3D"styled-by-prettify">cout </span><span style=3D"color: r=
gb(102, 102, 0);" class=3D"styled-by-prettify">&lt;&lt;</span><span style=
=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> to_string</span><sp=
an style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">s</span><=
span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> k</spa=
n><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">);<=
/span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </=
span><span style=3D"color: rgb(136, 0, 0);" class=3D"styled-by-prettify">//=
no memory allocation</span></div></code></div><br><p></p><p>The implementat=
ion of each of these can be built on top of one another and without optimiz=
ation can be trivially implemented using snprintf</p><div style=3D"border: =
1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(=
250, 250, 250);" class=3D"prettyprint"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-=
by-prettify">string_view to_string</span><span style=3D"color: rgb(102, 102=
, 0);" class=3D"styled-by-prettify">(</span><span style=3D"color: rgb(0, 0,=
 0);" class=3D"styled-by-prettify">array_view</span><span style=3D"color: r=
gb(0, 136, 0);" class=3D"styled-by-prettify">&lt;char&gt;</span><span style=
=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> s</span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">int</span><span =
style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> value</span><s=
pan style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">)</span=
><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">{</sp=
an><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>&n=
bsp; </span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prett=
ify">int</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pret=
tify"> len </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-=
by-prettify">=3D</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled=
-by-prettify"> snprintf</span><span style=3D"color: rgb(102, 102, 0);" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify">s</span><span style=3D"color: rgb(102, 102, 0);" cl=
ass=3D"styled-by-prettify">.</span><span style=3D"color: rgb(0, 0, 0);" cla=
ss=3D"styled-by-prettify">data</span><span style=3D"color: rgb(102, 102, 0)=
;" class=3D"styled-by-prettify">(),</span><span style=3D"color: rgb(0, 0, 0=
);" class=3D"styled-by-prettify"> s</span><span style=3D"color: rgb(102, 10=
2, 0);" class=3D"styled-by-prettify">.</span><span style=3D"color: rgb(0, 0=
, 0);" class=3D"styled-by-prettify">length</span><span style=3D"color: rgb(=
102, 102, 0);" class=3D"styled-by-prettify">(),</span><span style=3D"color:=
 rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"color: =
rgb(0, 136, 0);" class=3D"styled-by-prettify">"%d"</span><span style=3D"col=
or: rgb(102, 102, 0);" class=3D"styled-by-prettify">,</span><span style=3D"=
color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> value</span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">);</span><span s=
tyle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>&nbsp; </spa=
n><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">retur=
n</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> =
string_view</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-=
by-prettify">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-b=
y-prettify">s</span><span style=3D"color: rgb(102, 102, 0);" class=3D"style=
d-by-prettify">.</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled=
-by-prettify">data</span><span style=3D"color: rgb(102, 102, 0);" class=3D"=
styled-by-prettify">(),</span><span style=3D"color: rgb(0, 0, 0);" class=3D=
"styled-by-prettify"> len</span><span style=3D"color: rgb(102, 102, 0);" cl=
ass=3D"styled-by-prettify">);</span><span style=3D"color: rgb(0, 0, 0);" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: rgb(102, 102, 0=
);" class=3D"styled-by-prettify">}</span><span style=3D"color: rgb(0, 0, 0)=
;" class=3D"styled-by-prettify"><br><br><br><br>string_view to_string</span=
><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">str=
ing</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prett=
ify">&amp;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pr=
ettify"> s</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by=
-prettify"> </span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-b=
y-prettify">int</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-=
by-prettify"> value</span><span style=3D"color: rgb(102, 102, 0);" class=3D=
"styled-by-prettify">)</span><span style=3D"color: rgb(0, 0, 0);" class=3D"=
styled-by-prettify"> </span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"styled-by-prettify">{</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: rgb(0, 0, 1=
36);" class=3D"styled-by-prettify">char</span><span style=3D"color: rgb(0, =
0, 0);" class=3D"styled-by-prettify"> buf</span><span style=3D"color: rgb(1=
02, 102, 0);" class=3D"styled-by-prettify">[</span><span style=3D"color: rg=
b(0, 102, 102);" class=3D"styled-by-prettify">32</span><span style=3D"color=
: rgb(102, 102, 0);" class=3D"styled-by-prettify">];</span><span style=3D"c=
olor: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>&nbsp; </span><span s=
tyle=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">auto</span><sp=
an style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> sv </span><=
span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> to_s=
tring</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pret=
tify">buf</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by=
-prettify">,</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-=
prettify"> value</span><span style=3D"color: rgb(102, 102, 0);" class=3D"st=
yled-by-prettify">);</span><span style=3D"color: rgb(0, 0, 0);" class=3D"st=
yled-by-prettify"><br>&nbsp; s </span><span style=3D"color: rgb(102, 102, 0=
);" class=3D"styled-by-prettify">=3D</span><span style=3D"color: rgb(0, 0, =
0);" class=3D"styled-by-prettify"> sv</span><span style=3D"color: rgb(102, =
102, 0);" class=3D"styled-by-prettify">;</span><span style=3D"color: rgb(0,=
 0, 0);" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"colo=
r: rgb(0, 0, 136);" class=3D"styled-by-prettify">return</span><span style=
=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> sv</span><span styl=
e=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">}</span><s=
pan style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br><br></s=
pan><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">str=
ing</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"=
> to_string</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-=
by-prettify">(</span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled=
-by-prettify">int</span><span style=3D"color: rgb(0, 0, 0);" class=3D"style=
d-by-prettify"> value</span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"styled-by-prettify">)</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"> </span><span style=3D"color: rgb(102, 102, 0);" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: rgb(0, 0, 0);" cla=
ss=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: rgb(0, 0,=
 136);" class=3D"styled-by-prettify">string</span><span style=3D"color: rgb=
(0, 0, 0);" class=3D"styled-by-prettify"> s</span><span style=3D"color: rgb=
(102, 102, 0);" class=3D"styled-by-prettify">;</span><span style=3D"color: =
rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>&nbsp; to_string</span><spa=
n style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">(</span><=
span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">s</span><s=
pan style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">,</span=
><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> value</=
span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">=
);</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">=
<br>&nbsp; </span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-by=
-prettify">return</span><span style=3D"color: rgb(0, 0, 0);" class=3D"style=
d-by-prettify"> s</span><span style=3D"color: rgb(102, 102, 0);" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"styled-by-prettify">}</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"><br></span></div></code></div><br><p>&nbsp;</p></di=
v>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_657_468509676.1413570959945--

.

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

On 17 October 2014 13:35, Matthew Fioravante <fmatthew5876@gmail.com> wrote:

> Consider the to_string library of functions such as:
>
> std::string to_string(int value);
>
> This interface while convenient
>

Which is the point of this interface.


> is horribly inefficient.
>

Really?  I would expect that most numbers would fit within the small object
optimization of std::string.

Of course, no one would mention something like "horribly inefficient"
without measurements to back it up.  Where are your benchmarks?  Is your
std::string implementation C++11/14 conforming?

> Every time you call this function you will allocate memory for a temporary
> string.
>
Only for really large numbers.

> If you plan to do this operation multiple times (which is common for use
> cases such as file parsing routines)
>
On what platform is file I/O not slow compared with 0-1 allocations?

> you cannot avoid these memory allocations with move semantics or return
> value optimization.
>
You can avoid them most of the time with a decent std::string
implementation.

> The performance implications of to_string make it unusable for high
> performance parsing routines.
>
I really cannot wait to see your benchmarks.
--
 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/.

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

<div dir=3D"ltr">On 17 October 2014 13:35, Matthew Fioravante <span dir=3D"=
ltr">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatth=
ew5876@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><p>Con=
sider the to_string library of functions such as:</p><p></p><div style=3D"b=
order:1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(=
250,250,250)"><code><div><span style=3D"color:rgb(0,0,0)">std</span><span s=
tyle=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,136)">s=
tring</span><span style=3D"color:rgb(0,0,0)"> to_string</span><span style=
=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,136)">int</s=
pan><span style=3D"color:rgb(0,0,0)"> value</span><span style=3D"color:rgb(=
102,102,0)">);</span></div></code></div><p></p><p>This interface while conv=
enient </p></div></blockquote><div><br></div><div>Which is the point of thi=
s interface.</div><div>=C2=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"><p>is horribly inefficient. </p></div></blockquote><div><br></div>=
<div>Really?=C2=A0 I would expect that most numbers would fit within the sm=
all object optimization of std::string.</div><div><br></div><div>Of course,=
 no one would mention something like &quot;horribly inefficient&quot; witho=
ut measurements to back it up.=C2=A0 Where are your benchmarks?=C2=A0 Is yo=
ur std::string implementation C++11/14 conforming?</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><p>Every time you call this function you wil=
l allocate memory for a temporary string. </p></div></blockquote><div>Only =
for really large numbers.</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><p>If you plan to do this operation multiple times (which is common for=
 use cases such as file parsing routines)</p></div></blockquote><div>On wha=
t platform is file I/O not slow compared with 0-1 allocations?</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><p> you cannot avoid these memory =
allocations with move semantics or return value optimization.</p></div></bl=
ockquote><div>You can avoid them most of the time with a decent std::string=
 implementation.</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"><p>Th=
e performance implications of to_string make it unusable for high performan=
ce parsing routines.</p></div></blockquote><div>I really cannot wait to see=
 your benchmarks.=C2=A0</div></div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=
=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blan=
k">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--f46d043d673f400b050505a2cbc4--

.

--089e0158bfb82bfc4d0505a43566
Content-Type: text/plain; charset=UTF-8

On Friday, October 17, 2014, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 17 October 2014 13:35, Matthew Fioravante <fmatthew5876@gmail.com
> <javascript:_e(%7B%7D,'cvml','fmatthew5876@gmail.com');>> wrote:
>
>> Consider the to_string library of functions such as:
>>
>> std::string to_string(int value);
>>
>> This interface while convenient
>>
>
> Which is the point of this interface.
>

Indeed and i think its great to have by default an easy to use and
impossible to screw up interface which is good enough most of the time.

>
>
>> is horribly inefficient.
>>
>
> Really?  I would expect that most numbers would fit within the small
> object optimization of std::string.
>

If your domain of numbers are randomly generated ids or hashes the small
string optimization does not help you. Also, I don't believe the standard
mandates the size for sso, so your performance can vary between
implementations.

>
> Of course, no one would mention something like "horribly inefficient"
> without measurements to back it up.  Where are your benchmarks?  Is your
> std::string implementation C++11/14 conforming?
>

I agree benchmarks should be provided. One example to consider is andrei
alexandrescu's optimization talk where he optimizes a simple int to string
routine which was a major hot spot of his entire application. He uses char*
and i doubt he would change it to return strings by value.

> Every time you call this function you will allocate memory for a temporary
>> string.
>>
> Only for really large numbers.
>

Sometimes we need to work with large numbers.

> If you plan to do this operation multiple times (which is common for use
>> cases such as file parsing routines)
>>
> On what platform is file I/O not slow compared with 0-1 allocations?
>

This is a tempting conclusion to make but its not always correct. I've had
production code where optimizing a csv file parser more than tripled the
performance of a data loading routine. The application was cpu bound not io
bound. If you or the os is doing asychronous io the io delay is even
further mitigated.

Finally int to string is used in a lot more places than writing to files.

> you cannot avoid these memory allocations with move semantics or return
>> value optimization.
>>
> You can avoid them most of the time with a decent std::string
> implementation.
>

Summarizing my earlier points thats highly dependent on many factors and in
some scenarios it does not work.

> The performance implications of to_string make it unusable for high
>> performance parsing routines.
>>
> I really cannot wait to see your benchmarks.
>

Sure


> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com
> <javascript:_e(%7B%7D,'cvml','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/OHF7J9jU1gc/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org
> <javascript:_e(%7B%7D,'cvml','std-proposals%2Bunsubscribe@isocpp.org');>.
> To post to this group, send email to std-proposals@isocpp.org
> <javascript:_e(%7B%7D,'cvml','std-proposals@isocpp.org');>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>


--
Sent from my phone, please ignore spelling and grammar.

--

---
You received this message because you are 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/.

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

<br><br>On Friday, October 17, 2014, Nevin Liber &lt;<a href=3D"mailto:nevi=
n@eviloverlord.com">nevin@eviloverlord.com</a>&gt; wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">On 17 October 2014 13:35, Matthew Fiorava=
nte <span dir=3D"ltr">&lt;<a href=3D"javascript:_e(%7B%7D,&#39;cvml&#39;,&#=
39;fmatthew5876@gmail.com&#39;);" target=3D"_blank">fmatthew5876@gmail.com<=
/a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><p>Consider the to_stri=
ng library of functions such as:</p><p></p><div style=3D"border:1px solid r=
gb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><co=
de><div><span style=3D"color:rgb(0,0,0)">std</span><span style=3D"color:rgb=
(102,102,0)">::</span><span style=3D"color:rgb(0,0,136)">string</span><span=
 style=3D"color:rgb(0,0,0)"> to_string</span><span style=3D"color:rgb(102,1=
02,0)">(</span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"=
color:rgb(0,0,0)"> value</span><span style=3D"color:rgb(102,102,0)">);</spa=
n></div></code></div><p></p><p>This interface while convenient </p></div></=
blockquote><div><br></div><div>Which is the point of this interface.</div><=
/div></div></div></blockquote><div><br></div><div>Indeed and i think its gr=
eat to have by default an easy to use and impossible to screw up interface =
which is good enough most of the time.<span></span>=C2=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 class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div>=C2=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"><p>is horribly inefficient. </p></div></blockquote><div><br></div>=
<div>Really?=C2=A0 I would expect that most numbers would fit within the sm=
all object optimization of std::string.</div></div></div></div></blockquote=
><div><br></div><div>If your domain of numbers are randomly generated ids o=
r hashes the small string optimization does not help you. Also, I don&#39;t=
 believe the standard mandates the size for sso, so your performance can va=
ry between implementations.=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br>=
</div><div>Of course, no one would mention something like &quot;horribly in=
efficient&quot; without measurements to back it up.=C2=A0 Where are your be=
nchmarks?=C2=A0 Is your std::string implementation C++11/14 conforming?</di=
v></div></div></div></blockquote><div><br></div><div>I agree benchmarks sho=
uld be provided. One example to consider is andrei alexandrescu&#39;s optim=
ization talk where he optimizes a simple int to string routine which was a =
major hot spot of his entire application. He uses char* and i doubt he woul=
d change it to return strings by value.=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><p>Every time you call t=
his function you will allocate memory for a temporary string. </p></div></b=
lockquote><div>Only for really large numbers.</div></div></div></div></bloc=
kquote><div><br></div><div>Sometimes we need to work with large numbers.=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_extra"><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 dir=
=3D"ltr"><p>If you plan to do this operation multiple times (which is commo=
n for use cases such as file parsing routines)</p></div></blockquote><div>O=
n what platform is file I/O not slow compared with 0-1 allocations?</div></=
div></div></div></blockquote><div><br></div><div>This is a tempting conclus=
ion to make but its not always correct. I&#39;ve had production code where =
optimizing a csv file parser more than tripled=C2=A0the performance=C2=A0of=
 a data loading routine. The application was cpu bound not io bound. If you=
 or the os is doing asychronous io the io delay is even further mitigated.<=
/div><div><br></div><div>Finally int to string=C2=A0is used in a lot more p=
laces than writing to files.</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 class=3D"gmail_extra"><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 dir=3D"ltr"><p> you cannot avoid these memory alloc=
ations with move semantics or return value optimization.</p></div></blockqu=
ote><div>You can avoid them most of the time with a decent std::string impl=
ementation.</div></div></div></div></blockquote><div><br></div><div>Summari=
zing my earlier points thats highly dependent on many factors and in some s=
cenarios it does not work.=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><p>The performance implications of to=
_string make it unusable for high performance parsing routines.</p></div></=
blockquote><div>I really cannot wait to see your benchmarks.=C2=A0</div></d=
iv></div></div></blockquote><div><br></div><div>Sure</div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"></div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=
=C2=A0 &lt;mailto:<a href=3D"javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;nevin=
@eviloverlord.com&#39;);" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/OHF7J9jU1gc/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/OHF7J9jU1gc=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;std-proposals%2Bunsubscribe@is=
ocpp.org&#39;);" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>=
..<br>
To post to this group, send email to <a href=3D"javascript:_e(%7B%7D,&#39;c=
vml&#39;,&#39;std-proposals@isocpp.org&#39;);" target=3D"_blank">std-propos=
als@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>
</blockquote><br><br>-- <br>Sent from my phone, please ignore spelling and =
grammar.<br>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--089e0158bfb82bfc4d0505a43566--

.

As an example I recently ran into, trying to format a simple set of floats =
to display on screen in a game was taking almost a fourth of a millisecond =
(you have 16.6 at most, assuming you're not targeting a 120hz display or do=
ing stereoscopic 3D) using any dtsndstd library routine. I switched to an i=
nterface that didn't return a std::string; basically, snprintf to a locsl b=
uffer I explicitly made large enough. It now completes in barely more than =
a few microseconds and most of that is building the render queue commands. =
No IO involved.

Allocations are expensive. Especially in implementations that have debug he=
aps, or constrained environments that have to worry more about totsl slloca=
tipn size or fragmentation than latency, etc.

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

.

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

On 17 October 2014 15:28, Matthew Fioravante <fmatthew5876@gmail.com> wrote:

>
> Really?  I would expect that most numbers would fit within the small
> object optimization of std::string.
>
> If your domain of numbers are randomly generated ids or hashes the small
> string optimization does not help you.
>

Yes, every single idea on this mailing list has at least one theoretical
use case.  That doesn't mean every single idea on this mailing list belongs
in the standard.

How big is that audience?  If you are parsing that many ids/hashes for the
performance to matter, what are you doing with them which doesn't require
storing the strings?  Why do you need/want std::string as an intermediary
at all?


> Also, I don't believe the standard mandates the size for sso, so your
> performance can vary between implementations.
>

That goes for most things in the standard library.  If the performance
matters that much, why would you even have the dependency on the standard
library?

After all, it isn't terribly hard to write a to_array() clone fills in a
std::array (possibly internal to a custom class that also keeps track of
the length) of the maximum number of digits the conversion can make.  I
might even be weakly for such a function, as opposed to overloading the
interface of to_string().
--
 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/.

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

<div dir=3D"ltr">On 17 October 2014 15:28, Matthew Fioravante <span dir=3D"=
ltr">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatth=
ew5876@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>Re=
ally?=C2=A0 I would expect that most numbers would fit within the small obj=
ect optimization of std::string.<br></span><span class=3D""><div><br></div>=
</span><div>If your domain of numbers are randomly generated ids or hashes =
the small string optimization does not help you.</div></blockquote><div><br=
></div><div>Yes, every single idea on this mailing list has at least one th=
eoretical use case.=C2=A0 That doesn&#39;t mean every single idea on this m=
ailing list belongs in the standard.</div><div><br></div><div>How big is th=
at audience?=C2=A0 If you are parsing that many ids/hashes for the performa=
nce to matter, what are you doing with them which doesn&#39;t require stori=
ng the strings?=C2=A0 Why do you need/want std::string as an intermediary a=
t all?</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> Also,=
 I don&#39;t believe the standard mandates the size for sso, so your perfor=
mance can vary between implementations.=C2=A0</div></blockquote><div><br></=
div><div>That goes for most things in the standard library.=C2=A0 If the pe=
rformance matters that much, why would you even have the dependency on the =
standard library?</div><div><br></div><div>After all, it isn&#39;t terribly=
 hard to write a to_array() clone fills in a std::array (possibly internal =
to a custom class that also keeps track of the length) of the maximum numbe=
r of digits the conversion can make.=C2=A0 I might even be weakly for such =
a function, as opposed to overloading the interface of to_string().</div></=
div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&g=
t;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--f46d04389087716e0a0505a47e07--

.

--089e0103ea3218de9d0505a4b1ad
Content-Type: text/plain; charset=UTF-8

On Friday, October 17, 2014, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 17 October 2014 15:28, Matthew Fioravante <fmatthew5876@gmail.com
> <javascript:_e(%7B%7D,'cvml','fmatthew5876@gmail.com');>> wrote:
>
>>
>> Really?  I would expect that most numbers would fit within the small
>> object optimization of std::string.
>>
>> If your domain of numbers are randomly generated ids or hashes the small
>> string optimization does not help you.
>>
>
> Yes, every single idea on this mailing list has at least one theoretical
> use case.  That doesn't mean every single idea on this mailing list belongs
> in the standard.
>
> How big is that audience?  If you are parsing that many ids/hashes for the
> performance to matter, what are you doing with them which doesn't require
> storing the strings?  Why do you need/want std::string as an intermediary
> at all?
>

Maybe you have your own string class. Maybe you are using the data for a
while on the stack and then throwing it away. Maybe you have some other
storage mechanism. There are many possibilites which I've seen used in
production code. Snprintf is still very popular and with good reason.

Std::string is often useful but its wrong to impose it on everyone. The
array_view interface puts no restrictions on where the target string bytes
will end up and is optimally effecient.



>
>
>> Also, I don't believe the standard mandates the size for sso, so your
>> performance can vary between implementations.
>>
>
> That goes for most things in the standard library.  If the performance
> matters that much, why would you even have the dependency on the standard
> library?
>

Converting ints to strings is about as generic a programming tool one can
have. These things should be in the standard library and they should be as
efficent as possible.


>
> After all, it isn't terribly hard to write a to_array() clone fills in a
> std::array (possibly internal to a custom class that also keeps track of
> the length) of the maximum number of digits the conversion can make.  I
> might even be weakly for such a function, as opposed to overloading the
> interface of to_string().
>

Thats exactly what the array_view overload does without creating more
string types. If people would rather it had a name other than to_string im
fine with that.

--
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com
> <javascript:_e(%7B%7D,'cvml','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/OHF7J9jU1gc/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org
> <javascript:_e(%7B%7D,'cvml','std-proposals%2Bunsubscribe@isocpp.org');>.
> To post to this group, send email to std-proposals@isocpp.org
> <javascript:_e(%7B%7D,'cvml','std-proposals@isocpp.org');>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>


--
Sent from my phone, please pardon my spelling and grammar.

--

---
You received this message because you are 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/.

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

<br><br>On Friday, October 17, 2014, Nevin Liber &lt;<a href=3D"mailto:nevi=
n@eviloverlord.com">nevin@eviloverlord.com</a>&gt; wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">On 17 October 2014 15:28, Matthew Fiorava=
nte <span dir=3D"ltr">&lt;<a href=3D"javascript:_e(%7B%7D,&#39;cvml&#39;,&#=
39;fmatthew5876@gmail.com&#39;);" target=3D"_blank">fmatthew5876@gmail.com<=
/a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><span><br>Really?=C2=A0 I would expect t=
hat most numbers would fit within the small object optimization of std::str=
ing.<br></span><span><div><br></div></span><div>If your domain of numbers a=
re randomly generated ids or hashes the small string optimization does not =
help you.</div></blockquote><div><br></div><div>Yes, every single idea on t=
his mailing list has at least one theoretical use case.=C2=A0 That doesn&#3=
9;t mean every single idea on this mailing list belongs in the standard.</d=
iv><div><br></div><div>How big is that audience?=C2=A0 If you are parsing t=
hat many ids/hashes for the performance to matter, what are you doing with =
them which doesn&#39;t require storing the strings?=C2=A0 Why do you need/w=
ant std::string as an intermediary at all?</div></div></div></div></blockqu=
ote><div><br></div><div>Maybe you have your own string class.=C2=A0Maybe yo=
u are using the data for=C2=A0a while on the stack and then throwing it awa=
y.=C2=A0Maybe you have some other storage mechanism. There are many possibi=
lites which I&#39;ve seen used in production code. Snprintf is still very p=
opular and with good reason.</div><div><br></div><div>Std::string is often =
useful but its wrong to impose it on everyone. The array_view interface put=
s no restrictions on where=C2=A0the target string bytes will end up and is =
optimally effecient.</div><div><br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> Also, I=
 don&#39;t believe the standard mandates the size for sso, so your performa=
nce can vary between implementations.=C2=A0</div></blockquote><div><br></di=
v><div>That goes for most things in the standard library.=C2=A0 If the perf=
ormance matters that much, why would you even have the dependency on the st=
andard library?</div></div></div></div></blockquote><div><br></div><div>Con=
verting ints to strings is about as generic a programming tool one can have=
.. These things should be in the standard library and they should be as effi=
cent as possible.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br=
></div><div>After all, it isn&#39;t terribly hard to write a to_array() clo=
ne fills in a std::array (possibly internal to a custom class that also kee=
ps track of the length) of the maximum number of digits the conversion can =
make.=C2=A0 I might even be weakly for such a function, as opposed to overl=
oading the interface of to_string().</div></div></div></div></blockquote><d=
iv><br></div><div>Thats exactly what the array_view overload does without c=
reating more string types. If people would rather it had a name other than =
to_string im fine=C2=A0with that.=C2=A0</div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"></div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto=
:<a href=3D"javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;nevin@eviloverlord.com=
&#39;);" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1=
404
</div></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/OHF7J9jU1gc/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/OHF7J9jU1gc=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;std-proposals%2Bunsubscribe@is=
ocpp.org&#39;);" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>=
..<br>
To post to this group, send email to <a href=3D"javascript:_e(%7B%7D,&#39;c=
vml&#39;,&#39;std-proposals@isocpp.org&#39;);" target=3D"_blank">std-propos=
als@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>
</blockquote><br><br>-- <br>Sent from my phone, please pardon my spelling a=
nd grammar.<br>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--089e0103ea3218de9d0505a4b1ad--

.

--047d7bdc8f5a0ae7280505ace1cc
Content-Type: text/plain; charset=UTF-8

On 17 October 2014 15:28, Matthew Fioravante <fmatthew5876@gmail.com> wrote:

>
>
> If your domain of numbers are randomly generated ids or hashes the small
> string optimization does not help you.
>

So you are parsing large numbers from binary into a textual
representation?  That seems like the opposite of what most parsing
algorithms do, because manipulating binary numbers is far faster than
manipulating text.

If I'm in that domain, I can think of other optimizations I may want.  For
instance, if I have a exact number of digits that I can left-fill with '0's
when the number is occasionally smaller, my entire conversion loop can be
unrolled w/o any pesky "if" checks in the code.

I can always come up with pathological cases that your interface is
sub-optimal for.


> One example to consider is andrei alexandrescu's optimization talk where
> he optimizes a simple int to string routine which was a major hot spot of
> his entire application. He uses char* and i doubt he would change it to
> return strings by value.
>

I also doubt he would replace his code with the standard library one you
propose, because it is unlikely you can even guarantee things like whether
or not the call will or will not be inlined.


> This is a tempting conclusion to make but its not always correct. I've had
> production code where optimizing a csv file parser


A CSV file parser with binary numbers in it??

Summarizing my earlier points thats highly dependent on many factors and in
> some scenarios it does not work.


So will anything you come up with.
--
 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/.

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

<div dir=3D"ltr">On 17 October 2014 15:28, Matthew Fioravante <span dir=3D"=
ltr">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fmatth=
ew5876@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br><b=
r></span><div>If your domain of numbers are randomly generated ids or hashe=
s the small string optimization does not help you.</div></blockquote><div><=
br></div><div>So you are parsing large numbers from binary into a textual r=
epresentation?=C2=A0 That seems like the opposite of what most parsing algo=
rithms do, because manipulating binary numbers is far faster than manipulat=
ing text.=C2=A0</div><div><br></div><div>If I&#39;m in that domain, I can t=
hink of other optimizations I may want.=C2=A0 For instance, if I have a exa=
ct number of digits that I can left-fill with &#39;0&#39;s when the number =
is occasionally smaller, my entire conversion loop can be unrolled w/o any =
pesky &quot;if&quot; checks in the code.</div><div><br></div><div>I can alw=
ays come up with pathological cases that your interface is sub-optimal for.=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>One example to c=
onsider is andrei alexandrescu&#39;s optimization talk where he optimizes a=
 simple int to string routine which was a major hot spot of his entire appl=
ication. He uses char* and i doubt he would change it to return strings by =
value.=C2=A0<br></div></blockquote><div><br></div><div>I also doubt he woul=
d replace his code with the standard library one you propose, because it is=
 unlikely you can even guarantee things like whether or not the call will o=
r will not be inlined.</div><div>=C2=A0</div><div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This is =
a tempting conclusion to make but its not always correct. I&#39;ve had prod=
uction code where optimizing a csv file parser</blockquote><div><br></div><=
div>A CSV file parser with binary numbers in it??</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">Summarizing my earlier points thats highly dependent on many fa=
ctors and in some scenarios it does not work.=C2=A0</blockquote><div><br></=
div><div>So will anything you come up with.</div></div></div>-- <br>=C2=A0N=
evin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evilove=
rlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691=
-1404
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--047d7bdc8f5a0ae7280505ace1cc--

.

On 10/17/2014 10:48 PM, Nevin Liber wrote:
> How big is that audience?  If you are parsing that many ids/hashes
> for the performance to matter, what are you doing with them which
> doesn't require storing the strings?  Why do you need/want
> std::string as an intermediary at all?

I agree extending the std::string-based interfaces in the standard
library is probably too special.

> ... If the
> performance matters that much, why would you even have the dependency
> on the standard library?

I disagree: I think the standard library should provide
non-allocating fast binary-to-string (and reverse)
conversions.   What we currently have for binary-to-string
(even with direct streambuf access) is factors slower than
hand-written code.  This is mostly due to over-generalization,
e.g. using locales.  We should also offer different functions
for differences currently hidden in formatting flags, e.g.
fill (right align) vs. left align, since the choice of your
application is often a fixed one at compile time.

(See c++std-lib-ext-1088 and c++std-lib-ext-1128 for sample
code for integers and benchmarks.)

Jens

--

---
You received this message because you are 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_501_1680356862.1413743902331
Content-Type: text/plain; charset=UTF-8



On Monday, October 20, 2014 7:31:20 AM UTC+13, Jens Maurer wrote:
>
> On 10/17/2014 10:48 PM, Nevin Liber wrote:
> > How big is that audience?  If you are parsing that many ids/hashes
> > for the performance to matter, what are you doing with them which
> > doesn't require storing the strings?  Why do you need/want
> > std::string as an intermediary at all?
>
> I agree extending the std::string-based interfaces in the standard
> library is probably too special.
>
> > ... If the
> > performance matters that much, why would you even have the dependency
> > on the standard library?
>
> I disagree: I think the standard library should provide
> non-allocating fast binary-to-string (and reverse)
> conversions.   What we currently have for binary-to-string
> (even with direct streambuf access) is factors slower than
> hand-written code.  This is mostly due to over-generalization,
> e.g. using locales.  We should also offer different functions
> for differences currently hidden in formatting flags, e.g.
> fill (right align) vs. left align, since the choice of your
> application is often a fixed one at compile time.
>
> (See c++std-lib-ext-1088 and c++std-lib-ext-1128 for sample
> code for integers and benchmarks.)
>
> Jens
>

+1

--

---
You received this message because you are 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_501_1680356862.1413743902331
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, October 20, 2014 7:31:20 AM UTC+13, Jens Maurer wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding=
-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; =
border-left-style: solid;">On 10/17/2014 10:48 PM, Nevin Liber wrote:
<br>&gt; How big is that audience? &nbsp;If you are parsing that many ids/h=
ashes
<br>&gt; for the performance to matter, what are you doing with them which
<br>&gt; doesn't require storing the strings? &nbsp;Why do you need/want
<br>&gt; std::string as an intermediary at all?
<br>
<br>I agree extending the std::string-based interfaces in the standard
<br>library is probably too special.
<br>
<br>&gt; ... If the
<br>&gt; performance matters that much, why would you even have the depende=
ncy
<br>&gt; on the standard library?
<br>
<br>I disagree: I think the standard library should provide
<br>non-allocating fast binary-to-string (and reverse)
<br>conversions. &nbsp; What we currently have for binary-to-string
<br>(even with direct streambuf access) is factors slower than
<br>hand-written code. &nbsp;This is mostly due to over-generalization,
<br>e.g. using locales. &nbsp;We should also offer different functions
<br>for differences currently hidden in formatting flags, e.g.
<br>fill (right align) vs. left align, since the choice of your
<br>application is often a fixed one at compile time.
<br>
<br>(See c++std-lib-ext-1088 and c++std-lib-ext-1128 for sample
<br>code for integers and benchmarks.)
<br>
<br>Jens
<br></blockquote><div><br></div><div>+1&nbsp;</div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_501_1680356862.1413743902331--

.

On Sun, Oct 19, 2014 at 3:31 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:
> On 10/17/2014 10:48 PM, Nevin Liber wrote:
>> How big is that audience?  If you are parsing that many ids/hashes
>> for the performance to matter, what are you doing with them which
>> doesn't require storing the strings?  Why do you need/want
>> std::string as an intermediary at all?
>
> I agree extending the std::string-based interfaces in the standard
> library is probably too special.
>
>> ... If the
>> performance matters that much, why would you even have the dependency
>> on the standard library?
>
> I disagree: I think the standard library should provide
> non-allocating fast binary-to-string (and reverse)
> conversions.   What we currently have for binary-to-string
> (even with direct streambuf access) is factors slower than
> hand-written code.  This is mostly due to over-generalization,
> e.g. using locales.  We should also offer different functions
> for differences currently hidden in formatting flags, e.g.
> fill (right align) vs. left align, since the choice of your
> application is often a fixed one at compile time.

Absolutely agree.
BTW, locales is often useless in embedded systems, specially those
that have zero human interaction at all, and that's another issue to
address (it was very hard to get rid of so far in some
implementations).

>
> (See c++std-lib-ext-1088 and c++std-lib-ext-1128 for sample
> code for integers and benchmarks.)
>
> Jens
>
> --
>
> ---
> You received this message because you are 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-propo=
sals/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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 Sunday 19 October 2014 15:45:30 dgutson . wrote:
> BTW, locales is often useless in embedded systems, specially those
> that have zero human interaction at all, and that's another issue to
> address (it was very hard to get rid of so far in some
> implementations).

I wouldn't say locales are useless, even in embedded systems. If they have a
screen, they should understand locales.

However, locales are useless in data interchange. The data should not depend
on locale and that's one of the most fatal mistakes in the standard C library,
that things like strtol and sprintf are locale-dependent. You simply cannot
write a localised application that can do proper interchange.

In other words, there's room for both: a locale-bearing API for displaying
information to the user and a non-locale API for data interchange. Though they
can also be one and the same (cf. strtol_l and sprintf_l).

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

.

On Sun, Oct 19, 2014 at 8:51 PM, Thiago Macieira <thiago@macieira.org> wrot=
e:
> On Sunday 19 October 2014 15:45:30 dgutson . wrote:
>> BTW, locales is often useless in embedded systems, specially those
>> that have zero human interaction at all, and that's another issue to
>> address (it was very hard to get rid of so far in some
>> implementations).
>
> I wouldn't say locales are useless, even in embedded systems. If they hav=
e a
> screen, they should understand locales.

That's greater than zero human interaction :)

>
> However, locales are useless in data interchange. The data should not dep=
end
> on locale and that's one of the most fatal mistakes in the standard C lib=
rary,
> that things like strtol and sprintf are locale-dependent. You simply cann=
ot
> write a localised application that can do proper interchange.
>
> In other words, there's room for both: a locale-bearing API for displayin=
g
> information to the user and a non-locale API for data interchange. Though=
 they
> can also be one and the same (cf. strtol_l and sprintf_l).
>
> --
> 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-propo=
sals/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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 Mon, Oct 20, 2014 at 07:51:46AM +0800, Thiago Macieira wrote:
> On Sunday 19 October 2014 15:45:30 dgutson . wrote:
> > BTW, locales is often useless in embedded systems, specially those
> > that have zero human interaction at all, and that's another issue to
> > address (it was very hard to get rid of so far in some
> > implementations).
>
> I wouldn't say locales are useless, even in embedded systems. If they have a
> screen, they should understand locales.
>
> However, locales are useless in data interchange. The data should not depend
> on locale and that's one of the most fatal mistakes in the standard C library,
> that things like strtol and sprintf are locale-dependent. You simply cannot
> write a localised application that can do proper interchange.
>
> In other words, there's room for both: a locale-bearing API for displaying
> information to the user and a non-locale API for data interchange. Though they
> can also be one and the same (cf. strtol_l and sprintf_l).

I disagree - if you allow the interfaces to be the same ones and just add a
locale parameter then you end up with iostreams and those do suffer from
always having to pay the localization cost, even when localization isn't
needed.

With that said the _l functions do have uses, but beeing quick isn't the
among them.

This is by the way what have gnawed on me through the whole to_string thread,
what do the gain over a stringstream?

The one useful addition could be a stringrefstream that you initialize with
a reference to a string variable that will be updated:

string s;
stringrefstream(s) << a_number;

appends a_number to the end of s and gives you the whole range of iostream
operations, not just numbers.

Please make new interfaces better than that if you want to use speed as an
argument for them.

/MF

--

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

.

--047d7bfced1c5428520505dc4405
Content-Type: text/plain; charset=UTF-8

On 19 October 2014 13:31, Jens Maurer <Jens.Maurer@gmx.net> wrote:

> We should also offer different functions
> for differences currently hidden in formatting flags, e.g.
> fill (right align) vs. left align, since the choice of your
> application is often a fixed one at compile time.
>

Most formatting is fixed at compile time.  I just don't believe that
breaking down each possible way to format a number into its own function is
the right way to proceed; usablilty-wise, it doesn't scale.

The problem is, every single choice you offer at least *doubles* the number
of functions you need.

1.  Locale vs. no-locale. x2
2.  Exceptions vs. return codes for error handling. x2
3.  No padding vs right align vs left align. x3
4.  String vs. array_view. x2

24 functions *per number type* (well, you could combine some, with a
possible loss in performance, as long as the type promotion isn't losing
information) so far, and I'm sure if I went through what snprintf and
ostream offer, I could get a lot more.

And that is just converting *one* number.  With formatting, I typically
have to do a lot more than that.

We can, of course, mitigate this with template policies or defer it to
runtime with defaulted parameters, but those both have their own issues.

If someone wishes to write up and present a paper on this design space, I'm
certainly not against it, but is seems almost as ambitious as revamping
ostreams.
--
 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/.

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

<div dir=3D"ltr">On 19 October 2014 13:31, Jens Maurer <span dir=3D"ltr">&l=
t;<a href=3D"mailto:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maurer@gmx.=
net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">We should also offer different funct=
ions<br>
for differences currently hidden in formatting flags, e.g.<br>
fill (right align) vs. left align, since the choice of your<br>
application is often a fixed one at compile time.<br></blockquote><div><br>=
</div><div>Most formatting is fixed at compile time.=C2=A0 I just don&#39;t=
 believe that breaking down each possible way to format a number into its o=
wn function is the right way to proceed; usablilty-wise, it doesn&#39;t sca=
le.</div><div><br></div><div>The problem is, every single choice you offer =
at least=C2=A0<i>doubles</i>=C2=A0the number of functions you need.</div><d=
iv><br></div><div>1.=C2=A0 Locale vs. no-locale. x2</div><div>2.=C2=A0 Exce=
ptions vs. return codes for error handling. x2</div><div>3.=C2=A0 No paddin=
g vs right align vs left align. x3</div><div>4.=C2=A0 String vs. array_view=
.. x2</div><div><br></div><div>24 functions <i>per number type</i>=C2=A0(wel=
l, you could combine some, with a possible loss in performance, as long as =
the type promotion isn&#39;t losing information) so far, and I&#39;m sure i=
f I went through what snprintf and ostream offer, I could get a lot more.</=
div><div><br></div><div>And that is just converting <i>one</i>=C2=A0number.=
=C2=A0 With formatting, I typically have to do a lot more than that.</div><=
div><br></div><div>We can, of course, mitigate this with template policies =
or defer it to runtime with defaulted parameters, but those both have their=
 own issues.</div><div><br></div><div>If someone wishes to write up and pre=
sent a paper on this design space, I&#39;m certainly not against it, but is=
 seems almost as ambitious as revamping ostreams.</div></div>-- <br>=C2=A0N=
evin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evilove=
rlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 <a href=
=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(847=
) 691-1404</a>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--047d7bfced1c5428520505dc4405--

.

On Mon, Oct 20, 2014 at 8:20 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 19 October 2014 13:31, Jens Maurer <Jens.Maurer@gmx.net> wrote:
>>
>> We should also offer different functions
>> for differences currently hidden in formatting flags, e.g.
>> fill (right align) vs. left align, since the choice of your
>> application is often a fixed one at compile time.
>
>
> Most formatting is fixed at compile time.  I just don't believe that
> breaking down each possible way to format a number into its own function is
> the right way to proceed; usablilty-wise, it doesn't scale.
>
> The problem is, every single choice you offer at least doubles the number of
> functions you need.

Not at all. Default arguments or a "conversion context" parameter
(again, defaulting to the most common behavior) removes the need for
umpteen function variants. The result type can't be handled without a
little duplication, but this is mostly a layering issue. e.g. the
std::string version can just be a facade over the array_view version.

This isn't free, of course, but it has other advantages.

For instance, see all the various "type-safe printf" libraries for C++
(a frequently-desired library feature). They need to call out to
someone to do the final formatting. Today that's usually snprintf;
with a conversion-context-based to_string, it could become that
instead. (std::stringstream is very rarely used due to its large
performance overhead compared to alternatives.)

I'm of the belief that the library can never be a complete tool for
every use case. I'd argue that it should aim for generalization (in a
way that keeps its simplicity for the common case, which a
context-based version would, since the context would be optional)
rather than minimalness or even maximal efficiency (though it should
aim for as much efficiency as it can while serving the other needs).

>
> 1.  Locale vs. no-locale. x2
> 2.  Exceptions vs. return codes for error handling. x2
> 3.  No padding vs right align vs left align. x3

All three of these can be handled via a context object, with at worst
a little branching overhead in the implementation (which is cheaper
than either the exception or the locales themselves, at least).

> 4.  String vs. array_view. x2

I'm thinking this is more of a +1 interface rather than a x2, since
you would be adding a facade over the existing functions.

I think it might just be four interfaces per type at worst. That could
even be reduced to a set of four templates for most related types like
all the builtin numeric types (one for signed, one for unsigned, one
for floating point).

void to_string(array_view, value, context);
void to_string(array_view, value); // default context
string to_string(context, value) // forward to array_view version
string to_string(value) // forward to array_view version

--

---
You received this message because you are 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/.

.

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

On 20 October 2014 13:15, Sean Middleditch <sean@middleditch.us> wrote:

> Not at all. Default arguments or a "conversion context" parameter
> (again, defaulting to the most common behavior) removes the need for
> umpteen function variants. The result type can't be handled without a
> little duplication, but this is mostly a layering issue. e.g. the
> std::string version can just be a facade over the array_view version.
>
> This isn't free, of course, but it has other advantages.
>

In other words, not high performance.  It seems like the goal posts keep
moving...

Like I said, if you wish to write a paper and come to a couple of meetings
to try and push it through, go for 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/.

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

<div dir=3D"ltr">On 20 October 2014 13:15, Sean Middleditch <span dir=3D"lt=
r">&lt;<a href=3D"mailto:sean@middleditch.us" target=3D"_blank">sean@middle=
ditch.us</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">Not at all. Default arguments o=
r a &quot;conversion context&quot; parameter<br>
(again, defaulting to the most common behavior) removes the need for<br>
umpteen function variants. The result type can&#39;t be handled without a<b=
r>
little duplication, but this is mostly a layering issue. e.g. the<br>
std::string version can just be a facade over the array_view version.<br>
<br>
This isn&#39;t free, of course, but it has other advantages.<br></blockquot=
e><div><br></div><div>In other words, not high performance.=C2=A0 It seems =
like the goal posts keep moving...</div><div><br></div><div>Like I said, if=
 you wish to write a paper and come to a couple of meetings to try and push=
 it through, go for it...</div></div>-- <br>=C2=A0Nevin &quot;:-)&quot; Lib=
er=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_bl=
ank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--f46d043d673fed4bd00505dedbd3--

.

On 10/20/2014 05:20 PM, Nevin Liber wrote:
> On 19 October 2014 13:31, Jens Maurer <Jens.Maurer@gmx.net <mailto:Jens.Maurer@gmx.net>> wrote:
>
>     We should also offer different functions
>     for differences currently hidden in formatting flags, e.g.
>     fill (right align) vs. left align, since the choice of your
>     application is often a fixed one at compile time.
>
>
> Most formatting is fixed at compile time.  I just don't believe that breaking down each possible way to format a number into its own function is the right way to proceed; usablilty-wise, it doesn't scale.

Random thoughts in this direction:
 - I agree this is a usability concern.
 - This space should be explored afresh with C++14 expressive power.
 - Whole-program optimizations can certainly propagate constant arguments
into function calls, making a seemingly-runtime "if" a compile-time choice.
With state modifications (such as in iostreams) or virtual functions,
this gets more difficult.

> The problem is, every single choice you offer at least /doubles/ the number of functions you need.
>
> 1.  Locale vs. no-locale. x2

No locales.  If you want locales, use iostreams.

> 2.  Exceptions vs. return codes for error handling. x2

No exceptions.  This is low-level bare-bones functionality.
If you want exceptions, use a wrapper template.

> 3.  No padding vs right align vs left align. x3

Yes.  (Left align with padding is probably uninteresting.)

> 4.  String vs. array_view. x2

No, "char *".  If you want strings/array_view/whatever on top, use
a wrapper template.

5. base (octal vs. hexadecimal vs. decimal vs. binary vs. arbitrary base)

We want to differentiate these at compile-time, because conversion to
hex has a different implementation strategy than conversion to decimal.
Plus, convert-to-hex right-justified, zero-filled is so fast the additional
"if" will certainly hurt you.

> 24 functions /per number type/

3*5 = 15

>  and I'm sure if I went through what
> snprintf and ostream offer, I could get a lot more.

What else is there?

> And that is just converting /one/ number. With formatting, I
> typically have to do a lot more than that.

Are you somehow mixing the library implementation effort
(providing all the overloads) with the usage effort?
What would "a lot more than that" be?

> If someone wishes to write up and present a paper on this design
> space, I'm certainly not against it, but is seems almost as ambitious
> as revamping ostreams.

The trick is carving out a small enough subset that provides useful
building blocks, but remains manageable.

Jens

--

---
You received this message because you are 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/.

.

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

On 20 October 2014 13:32, Jens Maurer <Jens.Maurer@gmx.net> wrote:

> > 3.  No padding vs right align vs left align. x3
>
> Yes.  (Left align with padding is probably uninteresting.)
>

I wish. :-(  Some third party protocols I deal with have this requirement.


> > 4.  String vs. array_view. x2
>
> No, "char *".  If you want strings/array_view/whatever on top, use
> a wrapper template.
>

Why would I want an unsafe C type interface?


> 5. base (octal vs. hexadecimal vs. decimal vs. binary vs. arbitrary base)
>
> We want to differentiate these at compile-time, because conversion to
> hex has a different implementation strategy than conversion to decimal.
> Plus, convert-to-hex right-justified, zero-filled is so fast the additional
> "if" will certainly hurt you.
>

Then comes the choice of lower case vs. upper case.  More and more
choices...


> Are you somehow mixing the library implementation effort
> (providing all the overloads) with the usage effort?
> What would "a lot more than that" be?
>

In every discussion about this, people want more and more customization.
And we haven't even started discussing floating point formatting...


> > If someone wishes to write up and present a paper on this design
> > space, I'm certainly not against it, but is seems almost as ambitious
> > as revamping ostreams.
>
> The trick is carving out a small enough subset that provides useful
> building blocks, but remains manageable.
>

And getting consensus on that subset.
--
 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/.

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

<div dir=3D"ltr">On 20 October 2014 13:32, Jens Maurer <span dir=3D"ltr">&l=
t;<a href=3D"mailto:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maurer@gmx.=
net</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><span class=3D"">&gt; 3.=C2=A0 No pa=
dding vs right align vs left align. x3<br>
<br>
</span>Yes.=C2=A0 (Left align with padding is probably uninteresting.)<br><=
/blockquote><div><br></div><div>I wish. :-( =C2=A0Some third party protocol=
s I deal with have this requirement.</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><span class=3D"">&gt; 4.=C2=A0 String vs. array_view. x2<br>
<br>
</span>No, &quot;char *&quot;.=C2=A0 If you want strings/array_view/whateve=
r on top, use<br>
a wrapper template.<br></blockquote><div><br></div><div>Why would I want an=
 unsafe C type interface?</div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">5. base (octal vs. hexadecimal vs. decimal vs. binary vs. arbitrary bas=
e)<br>
<br>
We want to differentiate these at compile-time, because conversion to<br>
hex has a different implementation strategy than conversion to decimal.<br>
Plus, convert-to-hex right-justified, zero-filled is so fast the additional=
<br>
&quot;if&quot; will certainly hurt you.<br></blockquote><div><br></div><div=
>Then comes the choice of lower case vs. upper case.=C2=A0 More and more ch=
oices...</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are you someh=
ow mixing the library implementation effort<br>
(providing all the overloads) with the usage effort?<br>
What would &quot;a lot more than that&quot; be?<br></blockquote><div><br></=
div><div>In every discussion about this, people want more and more customiz=
ation.=C2=A0 And we haven&#39;t even started discussing floating point form=
atting...</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">&gt; If someone wishes to write up and present a paper on this design=
<br>
&gt; space, I&#39;m certainly not against it, but is seems almost as ambiti=
ous<br>
&gt; as revamping ostreams.<br>
<br>
</span>The trick is carving out a small enough subset that provides useful<=
br>
building blocks, but remains manageable.<br></blockquote><div><br></div><di=
v>And getting consensus on that subset.</div></div>-- <br>=C2=A0Nevin &quot=
;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com"=
 target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--f46d043d673fb637640505df2795--

.

On 10/20/2014 08:47 PM, Nevin Liber wrote:
> On 20 October 2014 13:32, Jens Maurer <Jens.Maurer@gmx.net <mailto:Jens.Maurer@gmx.net>> wrote:

>     > 4.  String vs. array_view. x2
>
>     No, "char *".  If you want strings/array_view/whatever on top, use
>     a wrapper template.
>
>
> Why would I want an unsafe C type interface?

Because it's the most fundamental interface choice that
can be adapted to everything else.

I would not expect anyone to actually use that interface
in application-level code, but use wrappers that have the
right safety / performance / flexibility trade-off for the
problem at hand.  Currently, the standard library
does not provide ANY fast building blocks for formatting.

(array_view might work as well, and probably has the same
safety issues.)

Jens

--

---
You received this message because you are 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_402_997838125.1413831773826
Content-Type: text/plain; charset=UTF-8


On Monday, October 20, 2014 2:54:50 PM UTC-4, Jens Maurer wrote:
>
> On 10/20/2014 08:47 PM, Nevin Liber wrote:
> > On 20 October 2014 13:32, Jens Maurer <Jens....@gmx.net <javascript:>
> <mailto:Jens....@gmx.net <javascript:>>> wrote:
>
> >     > 4.  String vs. array_view. x2
> >
> >     No, "char *".  If you want strings/array_view/whatever on top, use
> >     a wrapper template.
> >
> >
> > Why would I want an unsafe C type interface?
>
> Because it's the most fundamental interface choice that
> can be adapted to everything else.
>


Unless you want strict C compatibility, (char*, size_t) is not necessary
and only makes the interface more clumsy to use and easier to write buffer
overflows. Instead you should use array_view because the pointer and length
are stored together within the type. You can directly pass a C array or a
std::array (or anything else thats contiguous) without having to do careful
sizeof() calls. In short, I see absolutely no advantage to sticking with
char*.

See this blog post for a motivating example as to why (char*, size_t) is
bad:
https://randomascii.wordpress.com/2014/09/24/a-crash-of-great-opportunity/

Also the function needs to return the length of the string that was written
to the array. You can either just return an int / size_t or return a
string_view. The later offers additional flexibility in that you can
immediately compose to_string with something else which operates on string
data, such as cout.

string_view to_string(array_view<char> buf, int val /* other params*/);



--

---
You received this message because you are 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_402_997838125.1413831773826
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Monday, October 20, 2014 2:54:50 PM UTC-4, Jens Mau=
rer wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex=
; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-lef=
t-style: solid;" class=3D"gmail_quote">On 10/20/2014 08:47 PM, Nevin Liber =
wrote:
<br>&gt; On 20 October 2014 13:32, Jens Maurer &lt;<a onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;" href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"F=
uRAPEXgld8J">Jens....@gmx.net</a> &lt;mailto:<a onmousedown=3D"this.href=3D=
'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;" href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"FuRAPEX=
gld8J">Jens....@gmx.net</a>&gt;&gt; wrote:
<br>
<br>&gt; &nbsp; &nbsp; &gt; 4. &nbsp;String vs. array_view. x2
<br>&gt;=20
<br>&gt; &nbsp; &nbsp; No, "char *". &nbsp;If you want strings/array_view/w=
hatever on top, use
<br>&gt; &nbsp; &nbsp; a wrapper template.
<br>&gt;=20
<br>&gt;=20
<br>&gt; Why would I want an unsafe C type interface?
<br>
<br>Because it's the most fundamental interface choice that
<br>can be adapted to everything else.
<br></blockquote><div>&nbsp;</div><div>&nbsp;</div><div>Unless you want str=
ict C compatibility, (char*, size_t) is not necessary and only makes the in=
terface more clumsy to use and easier to write buffer overflows. Instead yo=
u should use array_view because the pointer and length are stored together =
within the type. You can directly pass a C array or a std::array (or anythi=
ng else thats contiguous) without having to do careful sizeof() calls. In s=
hort, I see absolutely no advantage to sticking with char*.</div><div>&nbsp=
;</div><div>See this blog post for a motivating example as to why (char*, s=
ize_t) is bad:</div><div><a href=3D"https://randomascii.wordpress.com/2014/=
09/24/a-crash-of-great-opportunity/">https://randomascii.wordpress.com/2014=
/09/24/a-crash-of-great-opportunity/</a></div><div>&nbsp;</div><div>Also th=
e function needs to return the length of the string that was written to the=
 array. You can either just return an int / size_t or return a string_view.=
 The later offers additional flexibility in that you can immediately compos=
e to_string with something else which operates on string data, such as cout=
..</div><div>&nbsp;</div><div><div style=3D"border: 1px solid rgb(187, 187, =
187); word-wrap: break-word; background-color: rgb(250, 250, 250);" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">string_vi=
ew to_string</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled=
-by-prettify">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-=
by-prettify">array_view</span><span style=3D"color: rgb(0, 136, 0);" class=
=3D"styled-by-prettify">&lt;char&gt;</span><span style=3D"color: rgb(0, 0, =
0);" class=3D"styled-by-prettify"> buf</span><span style=3D"color: rgb(102,=
 102, 0);" class=3D"styled-by-prettify">,</span><span style=3D"color: rgb(0=
, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(0,=
 0, 136);" class=3D"styled-by-prettify">int</span><span style=3D"color: rgb=
(0, 0, 0);" class=3D"styled-by-prettify"> val </span><span style=3D"color: =
rgb(136, 0, 0);" class=3D"styled-by-prettify">/* other params*/</span><span=
 style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">);</span><=
/div></code></div><br></div><div>&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_402_997838125.1413831773826--

.

------=_Part_3744_1105652654.1413835350303
Content-Type: text/plain; charset=UTF-8


On Saturday, October 18, 2014 2:49:13 AM UTC-4, Nevin ":-)" Liber wrote:
>
>
> A CSV file parser with binary numbers in it??
>
>

No, its just an example demonstrating that serialization is not always IO
bound.


On Monday, October 20, 2014 11:21:22 AM UTC-4, Nevin ":-)" Liber wrote:
>
>
> The problem is, every single choice you offer at least *doubles* the
> number of functions you need.
>
> 1. Locale vs. no-locale. x2
>

This idea is a separate proposal in and of itself. In order to have
programmer specified locale parsing routines / IO one would first need to
formalize how to specify locales. Using "string" names with runtime lookup
would be too slow and also mandate runtime error handling. We would need a
set of locale tags either via an enum, type traits, a set of global
constexpr tags, or some other mechanism. That means the standard would need
to specify a list of locales with which it supports, optionally allowing
implementations to supply additional platform specific ones.


> 2. Exceptions vs. return codes for error handling. x2
>

In general yes, but for int to string we can sidestep this question. What
kinds of errors can occur for int to string? The input is a binary integer
/ float and all 2^(sizeof(T)*CHAR_BIT) values have some valid string
representation. The only errors I can think of are related to the
destination buffer where we either run of out of space (truncation), or are
unable to allocate string memory (throw / crash).


> 3. No padding vs right align vs left align. x3
>

A higher level interface overtop of the int to string primitive could be
written to do column alignment.


> 4. String vs. array_view. x2
>

array_view should be the primitive, with string being a convenience
overload.


>
> If someone wishes to write up and present a paper on this design space,
> I'm certainly not against it, but is seems almost as ambitious as revamping
> ostreams.
>

The problem is that with all of the possible variations people could want
we end up with a long discussion and no results. One could also argue that
if you have such specialized needs then you may want to write such a
routine yourself which builds ontop of the int to string primitive provided
by the standard library.

At a minimum, what I'd just be proposing an array_view overload for
improved efficiency. A small incremental improvement over trying to solve
the huge problem of all possible int to string conversions. If the real
desire is for a full featured cover all possible scenarios interface, then
why was to_string() created in the first place?


On Monday, October 20, 2014 2:32:17 PM UTC-4, Jens Maurer wrote:
>
>
>  - Whole-program optimizations can certainly propagate constant arguments
> into function calls, making a seemingly-runtime "if" a compile-time choice.
> With state modifications (such as in iostreams) or virtual functions,
> this gets more difficult.
>


Compile and link times are already very long in C++ and enabling LTO makes
them even longer. One approach is for the implementation to do the
configuration branching inline, and then call helpers do the actual parsing
work out of line. Then when the function is called with compile time
configuration arguments the branching is optimized out, and when you really
want to decide at runtime whether to pad left or pad right the branch
is added to do the decision.




--

---
You received this message because you are 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_3744_1105652654.1413835350303
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br>On Saturday, October 18, 2014 2:49:13 AM UTC-4, N=
evin ":-)" Liber wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;" class=3D"gmail_quote"><div dir=3D"ltr"><div><=
div class=3D"gmail_quote"><div>&nbsp;</div><div><div>A CSV file parser with=
 binary numbers in it??</div><div class=3D"GBT2DCHDFLB"><div>&nbsp;</div></=
div></div></div></div></div></blockquote><div>&nbsp;</div><div>No, its just=
 an example demonstrating that serialization is not always IO bound.</div><=
div>&nbsp;</div><div><br>On Monday, October 20, 2014 11:21:22 AM UTC-4, Nev=
in ":-)" Liber wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; paddin=
g-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px;=
 border-left-style: solid;" class=3D"gmail_quote"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote"><div>&nbsp;</div><div>The problem is, every single =
choice you offer at least <i>doubles</i> the number of functions you need.<=
/div><div><br></div><div>1.  Locale vs. no-locale. x2</div></div></div></di=
v></blockquote><div>&nbsp;</div><div>This idea is a separate proposal in an=
d of itself. In order to&nbsp;have programmer specified locale&nbsp;parsing=
 routines / IO&nbsp;one would first need to formalize how to specify locale=
s. Using "string" names with runtime lookup would be too slow and also mand=
ate runtime error handling. We would need a set of locale&nbsp;tags either =
via an enum, type traits, a set of global constexpr tags, or some other mec=
hanism. That means the standard would need to specify a list of locales wit=
h which it supports, optionally allowing implementations to supply addition=
al platform specific ones.</div><div>&nbsp;</div><blockquote style=3D"margi=
n: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 2=
04); border-left-width: 1px; border-left-style: solid;" class=3D"gmail_quot=
e"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>2.  Exceptions vs.=
 return codes for error handling. x2</div></div></div></div></blockquote><d=
iv>&nbsp;</div><div>In general yes, but for int to string we can sidestep t=
his question. What kinds of errors can occur for int to string? The input i=
s a binary integer / float and all 2^(sizeof(T)*CHAR_BIT) values have some =
valid string representation. The only errors I can think of are related to =
the destination buffer where we either run of out of space (truncation), or=
 are unable to allocate string memory (throw / crash).</div><div>&nbsp;</di=
v><blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border=
-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style:=
 solid;" class=3D"gmail_quote"><div dir=3D"ltr"><div><div class=3D"gmail_qu=
ote"><div>3.  No padding vs right align vs left align. x3</div></div></div>=
</div></blockquote><div>&nbsp;</div><div>A higher level interface overtop o=
f the int to string primitive could be written to do column alignment.</div=
><div>&nbsp;</div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-l=
eft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bo=
rder-left-style: solid;" class=3D"gmail_quote"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote"><div>4.  String vs. array_view. x2</div></div></div></=
div></blockquote><div>&nbsp;</div><div>array_view should be the primitive,&=
nbsp;with string being a convenience overload.</div><div>&nbsp;</div><block=
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;"=
 class=3D"gmail_quote"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><di=
v><br></div><div>If someone wishes to write up and present a paper on this =
design space, I'm certainly not against it, but is seems almost as ambitiou=
s as revamping ostreams.</div></div></div></div></blockquote><div>&nbsp;</d=
iv><div>The problem is that with all of the possible variations people coul=
d want we end up with a long discussion and no results. One could also argu=
e that if you have such specialized needs then you may want to write such a=
 routine yourself which builds ontop of the int to string primitive provide=
d by the standard library.</div><div>&nbsp;</div><div>At a minimum, what I'=
d&nbsp;just be proposing&nbsp;an array_view overload for improved efficienc=
y.&nbsp;A small incremental improvement over trying to solve the huge probl=
em of all possible int to string conversions. If the real desire is for a f=
ull featured cover all possible scenarios interface, then why was to_string=
() created in the first place?</div><div>&nbsp;</div><div><br>On Monday, Oc=
tober 20, 2014 2:32:17 PM UTC-4, Jens Maurer wrote:<blockquote style=3D"mar=
gin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204,=
 204); border-left-width: 1px; border-left-style: solid;" class=3D"gmail_qu=
ote"><br>&nbsp;- Whole-program optimizations can certainly propagate consta=
nt arguments<br>into function calls, making a seemingly-runtime "if" a comp=
ile-time choice.<br>With state modifications (such as in iostreams) or virt=
ual functions,<br>this gets more difficult.<br>&nbsp;</blockquote><div>&nbs=
p;</div><div>Compile and link times are already very&nbsp;long in C++ and&n=
bsp;enabling LTO makes them even longer.&nbsp;One approach is&nbsp;for the =
implementation to do the configuration branching&nbsp;inline, and then call=
 helpers do the actual parsing work out of line. Then when the function is =
called with compile time configuration arguments the branching is optimized=
 out, and when you really want to decide at runtime whether to pad left or =
pad right the branch is&nbsp;added to do the decision.</div><div><code clas=
s=3D"prettyprint"><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-p=
rettify"><font color=3D"#222222" face=3D"Arial"></font></span>&nbsp;</code>=
</div><code class=3D"prettyprint"><div></div></code><div><br>&nbsp;</div></=
div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_3744_1105652654.1413835350303--

.

On 10/20/2014 09:02 PM, Matthew Fioravante wrote:
>
> On Monday, October 20, 2014 2:54:50 PM UTC-4, Jens Maurer wrote:

>     > Why would I want an unsafe C type interface?
>
>     Because it's the most fundamental interface choice that
>     can be adapted to everything else.
>
>
>
> Unless you want strict C compatibility, (char*, size_t) is not
> necessary and only makes the interface more clumsy to use and easier
> to write buffer overflows. Instead you should use array_view because
> the pointer and length are stored together within the type. You can
> directly pass a C array or a std::array (or anything else thats
> contiguous) without having to do careful sizeof() calls. In short, I
> see absolutely no advantage to sticking with char*.

I don't want a (char*, size_t) interface.  In my experience, this leads
to inefficient code, because you're incrementing your "current pointer"
as well as decrementing the "remaining size".  This takes up two
registers.  A range-style  (char*begin, char*end)  interface avoids
that.  (Look, it's not a C interface, it's a C++ iterator-based
interface.)

I've already said that array_view might be an interface option,
but I need to see the generated assembly to be convinced it's
zero-overhead compared to the  (char*begin, char*end)  interface.
One of the surprising aspects is that a "char *" can point to
anything, so any read/write through a "char *" pessimizes code
generation quite a bit, unless only local variables are involved
(see also 3.10p10).

Jens

--

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

.

On 10/20/2014 10:02 PM, Matthew Fioravante wrote:
>  If
> the real desire is for a full featured cover all possible scenarios
> interface, then why was to_string() created in the first place?

In my recollection, to_string() was created as a beginner-friendly
facility.  Using stringstreams is embarrassingly heavy on the syntax
for such a trivial task.

(Sometimes, I think WG21 focuses a bit too much on beginner-friendly
instead of considering the whole picture and finding the beginner-
friendly shim around a more useful, well-performing core functionality
that gets you the extra mile.)

Jens

--

---
You received this message because you are 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_3880_1199676580.1413837174393
Content-Type: text/plain; charset=UTF-8


On Monday, October 20, 2014 4:10:05 PM UTC-4, Jens Maurer wrote:
>
>
> I don't want a (char*, size_t) interface.  In my experience, this leads
> to inefficient code, because you're incrementing your "current pointer"
> as well as decrementing the "remaining size".  This takes up two
> registers.  A range-style  (char*begin, char*end)  interface avoids
> that.  (Look, it's not a C interface, it's a C++ iterator-based
> interface.)
>
> I've already said that array_view might be an interface option,
> but I need to see the generated assembly to be convinced it's
> zero-overhead compared to the  (char*begin, char*end)  interface.
> One of the surprising aspects is that a "char *" can point to
> anything, so any read/write through a "char *" pessimizes code
> generation quite a bit, unless only local variables are involved
> (see also 3.10p10).
>
>
This sounds like QoI to me. An implemenation can easily convert (char*,
size_t) into (char*, char*), an index based for loop, (char* restrict,
char* restrict), or whatever else depending on whatever is fastest on
that platform. array_view may be implemented using pointer pairs or pointer
/ length but it can be converted to whatever is most optimal.


--

---
You received this message because you are 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_3880_1199676580.1413837174393
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Monday, October 20, 2014 4:10:05 PM UTC-4, Jens Mau=
rer wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex=
; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-lef=
t-style: solid;" class=3D"gmail_quote"><br>I don't want a (char*, size_t) i=
nterface. &nbsp;In my experience, this leads
<br>to inefficient code, because you're incrementing your "current pointer"
<br>as well as decrementing the "remaining size". &nbsp;This takes up two
<br>registers. &nbsp;A range-style &nbsp;(char*begin, char*end) &nbsp;inter=
face avoids
<br>that. &nbsp;(Look, it's not a C interface, it's a C++ iterator-based
<br>interface.)
<br>
<br>I've already said that array_view might be an interface option,
<br>but I need to see the generated assembly to be convinced it's
<br>zero-overhead compared to the &nbsp;(char*begin, char*end) &nbsp;interf=
ace.
<br>One of the surprising aspects is that a "char *" can point to
<br>anything, so any read/write through a "char *" pessimizes code
<br>generation quite a bit, unless only local variables are involved
<br>(see also 3.10p10).
<br>
<br></blockquote><div>&nbsp;</div><div>This sounds like QoI to me. An imple=
menation can&nbsp;easily convert (char*, size_t) into (char*, char*), an in=
dex based for loop, (char* restrict, char* restrict), or whatever else&nbsp=
;depending on whatever is fastest on that&nbsp;platform. array_view may be =
implemented using pointer pairs or pointer / length but it can be converted=
 to whatever is most optimal.</div><div>&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_3880_1199676580.1413837174393--

.

------=_Part_1033_659328090.1413837431937
Content-Type: text/plain; charset=UTF-8



On Tuesday, October 21, 2014 9:15:24 AM UTC+13, Jens Maurer wrote:
>
> On 10/20/2014 10:02 PM, Matthew Fioravante wrote:
> >  If
> > the real desire is for a full featured cover all possible scenarios
> > interface, then why was to_string() created in the first place?
>
> In my recollection, to_string() was created as a beginner-friendly
> facility.



>  Using stringstreams is embarrassingly heavy on the syntax
> for such a trivial task.
>

Exactly.


> (Sometimes, I think WG21 focuses a bit too much on beginner-friendly
> instead of considering the whole picture and finding the beginner-
> friendly shim around a more useful, well-performing core functionality
> that gets you the extra mile.)
>
> Jens
>

We definitely need faster conversion routines.

I also think the exception only conversion functions were a mistake in my
opinion if that's all we have.

--

---
You received this message because you are 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_1033_659328090.1413837431937
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 21, 2014 9:15:24 AM UTC+13, Je=
ns Maurer 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 10/20/2014 10:02 PM, Matthe=
w Fioravante wrote:
<br>&gt; &nbsp;If
<br>&gt; the real desire is for a full featured cover all possible scenario=
s
<br>&gt; interface, then why was to_string() created in the first place?
<br>
<br>In my recollection, to_string() was created as a beginner-friendly
<br>facility.</blockquote><div>&nbsp;</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color:=
 rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"> &n=
bsp;Using stringstreams is embarrassingly heavy on the syntax
<br>for such a trivial task.
<br></blockquote><div><br></div><div>Exactly.</div><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: =
1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-=
left-style: solid;">
<br>(Sometimes, I think WG21 focuses a bit too much on beginner-friendly
<br>instead of considering the whole picture and finding the beginner-
<br>friendly shim around a more useful, well-performing core functionality
<br>that gets you the extra mile.)
<br>
<br>Jens
<br></blockquote><div><br></div><div>We definitely need&nbsp;faster convers=
ion routines.</div><div><br></div><div>I also think the exception only&nbsp=
;conversion functions were&nbsp;a mistake in my opinion if that's all we ha=
ve.</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_1033_659328090.1413837431937--

.

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

On Oct 20, 2014 11:26 AM, "Nevin Liber" <nevin@eviloverlord.com> wrote:
>
> On 20 October 2014 13:15, Sean Middleditch <sean@middleditch.us> wrote:
>>
>> Not at all. Default arguments or a "conversion context" parameter
>> (again, defaulting to the most common behavior) removes the need for
>> umpteen function variants. The result type can't be handled without a
>> little duplication, but this is mostly a layering issue. e.g. the
>> std::string version can just be a facade over the array_view version.
>>
>> This isn't free, of course, but it has other advantages.
>
>
> In other words, not high performance.  It seems like the goal posts keep
moving...

I don't know where you get that idea. "High performance" by itself is a
vague term, though. I can say with absolute certainty that a context
approach is more than sufficient for many soft-real-time needs; implemented
well it's identical in functionality and overhead to sprintf (and is how
some sorintf implementations work internally already), minus the format
parsing overhead.

You could also just make to_string take a format string parameter I
suppose, but that is... icky.

>
> Like I said, if you wish to write a paper and come to a couple of
meetings to try and push it through, go for it...

Or discuss it with other interested parties on the mailing list meant for
such discussion to help decide what such a paper should contain. :)

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

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

<p dir=3D"ltr"><br>
On Oct 20, 2014 11:26 AM, &quot;Nevin Liber&quot; &lt;<a href=3D"mailto:nev=
in@eviloverlord.com">nevin@eviloverlord.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On 20 October 2014 13:15, Sean Middleditch &lt;<a href=3D"mailto:sean@=
middleditch.us">sean@middleditch.us</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Not at all. Default arguments or a &quot;conversion context&quot; =
parameter<br>
&gt;&gt; (again, defaulting to the most common behavior) removes the need f=
or<br>
&gt;&gt; umpteen function variants. The result type can&#39;t be handled wi=
thout a<br>
&gt;&gt; little duplication, but this is mostly a layering issue. e.g. the<=
br>
&gt;&gt; std::string version can just be a facade over the array_view versi=
on.<br>
&gt;&gt;<br>
&gt;&gt; This isn&#39;t free, of course, but it has other advantages.<br>
&gt;<br>
&gt;<br>
&gt; In other words, not high performance.=C2=A0 It seems like the goal pos=
ts keep moving...</p>
<p dir=3D"ltr">I don&#39;t know where you get that idea. &quot;High perform=
ance&quot; by itself is a vague term, though. I can say with absolute certa=
inty that a context approach is more than sufficient for many soft-real-tim=
e needs; implemented well it&#39;s identical in functionality and overhead =
to sprintf (and is how some sorintf implementations work internally already=
), minus the format parsing overhead.</p>
<p dir=3D"ltr">You could also just make to_string take a format string para=
meter I suppose, but that is... icky.</p>
<p dir=3D"ltr">&gt;<br>
&gt; Like I said, if you wish to write a paper and come to a couple of meet=
ings to try and push it through, go for it...</p>
<p dir=3D"ltr">Or discuss it with other interested parties on the mailing l=
ist meant for such discussion to help decide what such a paper should conta=
in. :)</p>
<p dir=3D"ltr">&gt; -- <br>
&gt; =C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:n=
evin@eviloverlord.com">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404<=
br>
&gt;<br>
&gt; -- <br>
&gt;<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/OHF7J9jU1gc/unsubscribe">https://gr=
oups.google.com/a/isocpp.org/d/topic/std-proposals/OHF7J9jU1gc/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 />
<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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />

--f46d044280ca4f169c0505e0d1c7--

.

------=_Part_948_283211897.1413842503247
Content-Type: text/plain; charset=UTF-8


On Monday, October 20, 2014 4:47:07 PM UTC-4, Sean Middleditch wrote:
>
>
> On Oct 20, 2014 11:26 AM, "Nevin Liber" <ne...@eviloverlord.com
> <javascript:>> wrote:
> >
> > On 20 October 2014 13:15, Sean Middleditch <se...@middleditch.us
> <javascript:>> wrote:
> >>
> >> Not at all. Default arguments or a "conversion context" parameter
> >> (again, defaulting to the most common behavior) removes the need for
> >> umpteen function variants. The result type can't be handled without a
> >> little duplication, but this is mostly a layering issue. e.g. the
> >> std::string version can just be a facade over the array_view version.
> >>
> >> This isn't free, of course, but it has other advantages.
> >
> >
> > In other words, not high performance.  It seems like the goal posts keep
> moving...
>
> I don't know where you get that idea. "High performance" by itself is a
> vague term, though. I can say with absolute certainty that a context
> approach is more than sufficient for many soft-real-time needs; implemented
> well it's identical in functionality and overhead to sprintf (and is how
> some sorintf implementations work internally already), minus the format
> parsing overhead.
>
If we're going to go with the fully functional approach, the context or
configuration object approach is probably the best. The alternative is to
have an explosion of different functions / overloads or an explosion of
parameters. The first is not scalable and the second is very hard to use
and possibly has very poor performance from passing so much crap on the
stack. Both are hard to use.

As I mentioed earlier if you do the branching on the context parameters
inline, it can be optimized out when the defaults are used or non-default
compile time values are used.


> You could also just make to_string take a format string parameter I
> suppose, but that is... icky.
>
I don't think there's much value in replicating snprintf(). It also makes
it very hard to use this low level interface to build higher level parsing
abstractions.



> >
> > Like I said, if you wish to write a paper and come to a couple of
> meetings to try and push it through, go for it...
>
> Or discuss it with other interested parties on the mailing list meant for
> such discussion to help decide what such a paper should contain. :)
>
> > --
> >  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>
> (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/OHF7J9jU1gc/unsubscribe
> .
> > To unsubscribe from this group and all its topics, send an email to
> std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> > Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

------=_Part_948_283211897.1413842503247
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Monday, October 20, 2014 4:47:07 PM UTC-4, Sean Mid=
dleditch wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;" class=3D"gmail_quote"><p dir=3D"ltr"><br>
On Oct 20, 2014 11:26 AM, "Nevin Liber" &lt;<a onmousedown=3D"this.href=3D'=
javascript:';return true;" onclick=3D"this.href=3D'javascript:';return true=
;" href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"2nJBK_15=
bAoJ">ne...@eviloverlord.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On 20 October 2014 13:15, Sean Middleditch &lt;<a onmousedown=3D"this.=
href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';ret=
urn true;" href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
2nJBK_15bAoJ">se...@middleditch.us</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Not at all. Default arguments or a "conversion context" parameter<=
br>
&gt;&gt; (again, defaulting to the most common behavior) removes the need f=
or<br>
&gt;&gt; umpteen function variants. The result type can't be handled withou=
t a<br>
&gt;&gt; little duplication, but this is mostly a layering issue. e.g. the<=
br>
&gt;&gt; std::string version can just be a facade over the array_view versi=
on.<br>
&gt;&gt;<br>
&gt;&gt; This isn't free, of course, but it has other advantages.<br>
&gt;<br>
&gt;<br>
&gt; In other words, not high performance.&nbsp; It seems like the goal pos=
ts keep moving...</p>
<p dir=3D"ltr">I don't know where you get that idea. "High performance" by =
itself is a vague term, though. I can say with absolute certainty that a co=
ntext approach is more than sufficient for many soft-real-time needs; imple=
mented well it's identical in functionality and overhead to sprintf (and is=
 how some sorintf implementations work internally already), minus the forma=
t parsing overhead.</p></blockquote><div>If we're going to go with the full=
y functional approach, the context or configuration object approach is prob=
ably the best. The alternative is to have an explosion of different functio=
ns / overloads&nbsp;or an explosion of parameters. The first is not scalabl=
e and the second is very hard to use and possibly has very poor performance=
 from passing so much crap on the stack. Both are hard to use.</div><div>&n=
bsp;</div><div>As I mentioed earlier if you do the branching on the context=
 parameters inline, it can be optimized out when the defaults are used or n=
on-default compile time values are used.</div><div>&nbsp;</div><blockquote =
style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: r=
gb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class=
=3D"gmail_quote">
<p dir=3D"ltr">You could also just make to_string take a format string para=
meter I suppose, but that is... icky.</p></blockquote><div>I don't think th=
ere's much value in replicating snprintf(). It also makes it very hard to u=
se this low level interface to build higher level parsing abstractions.</di=
v><div>&nbsp;</div><div>&nbsp;</div><blockquote style=3D"margin: 0px 0px 0p=
x 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-l=
eft-width: 1px; border-left-style: solid;" class=3D"gmail_quote">
<p dir=3D"ltr">&gt;<br>
&gt; Like I said, if you wish to write a paper and come to a couple of meet=
ings to try and push it through, go for it...</p>
<p dir=3D"ltr">Or discuss it with other interested parties on the mailing l=
ist meant for such discussion to help decide what such a paper should conta=
in. :)</p>
<p dir=3D"ltr">&gt; -- <br>
&gt; &nbsp;Nevin ":-)" Liber&nbsp; &lt;mailto:<a onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;" href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"2nJB=
K_15bAoJ">ne...@eviloverlord.com</a><wbr>&gt;&nbsp; (847) 691-1404<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to a topic in the=
 Google Groups "ISO C++ Standard - Future Proposals" group.<br>
&gt; To unsubscribe from this topic, visit <a onmousedown=3D"this.href=3D'h=
ttps://groups.google.com/a/isocpp.org/d/topic/std-proposals/OHF7J9jU1gc/uns=
ubscribe';return true;" onclick=3D"this.href=3D'https://groups.google.com/a=
/isocpp.org/d/topic/std-proposals/OHF7J9jU1gc/unsubscribe';return true;" hr=
ef=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/OHF7J9jU=
1gc/unsubscribe" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.=
org/d/topic/std-<wbr>proposals/OHF7J9jU1gc/<wbr>unsubscribe</a>.<br>
&gt; To unsubscribe from this group and all its topics, send an email to <a=
 onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;" href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"2nJBK_15bAoJ">std-proposal...@<wbr>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;"=
 href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"2nJBK_15bA=
oJ">std-pr...@isocpp.org</a>.<br>
&gt; Visit this group at <a onmousedown=3D"this.href=3D'http://groups.googl=
e.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';return true=
;" href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/" targ=
et=3D"_blank">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>pro=
posals/</a>.<br>
</p>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_948_283211897.1413842503247--

.

On Monday 20 October 2014 22:10:00 Jens Maurer wrote:
> I've already said that array_view might be an interface option,
> but I need to see the generated assembly to be convinced it's
> zero-overhead compared to the  (char*begin, char*end)  interface.

Wouldn't this be a QoI issue depending on how array_view is internally
represented?

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

.

On 10/20/2014 10:32 PM, Matthew Fioravante wrote:
>=20
> On Monday, October 20, 2014 4:10:05 PM UTC-4, Jens Maurer wrote:
>=20
>=20
>     I don't want a (char*, size_t) interface.  In my experience, this lea=
ds
>     to inefficient code, because you're incrementing your "current pointe=
r"
>     as well as decrementing the "remaining size".  This takes up two
>     registers.  A range-style  (char*begin, char*end)  interface avoids
>     that.  (Look, it's not a C interface, it's a C++ iterator-based
>     interface.)
>=20
>     I've already said that array_view might be an interface option,
>     but I need to see the generated assembly to be convinced it's
>     zero-overhead compared to the  (char*begin, char*end)  interface.
>     One of the surprising aspects is that a "char *" can point to
>     anything, so any read/write through a "char *" pessimizes code
>     generation quite a bit, unless only local variables are involved
>     (see also 3.10p10).
>=20
> =20
> This sounds like QoI to me. An implemenation can easily convert (char*, s=
ize_t) into (char*, char*), an index based for loop, (char* restrict, char*=
 restrict), or whatever else depending on whatever is fastest on that platf=
orm. array_view may be implemented using pointer pairs or pointer / length =
but it can be converted to whatever is most optimal.

Partly, yes.  I start getting concerned when the interface
requires heroic compiler effort to make a function efficient.
I've failed to get any restrict-based version to optimize
properly with gcc.  But maybe I'm simply not understanding restrict.

A range-based interface also composes remarkably well:

Suppose you have conversion functions like this, returning the
new pointer past the consumed output range:

  char * convert(char * begin, char * end, unsigned int value);
  char * convert(char * begin, char * end, const std::string_view&);
  char * convert_hex(char * begin, char * end, unsigned int value);

Then you can do

   p =3D convert(p, end, 42);
   p =3D convert(p, end, "some string");
   p =3D convert_hex(p, end, 99);

etc.

This is as safe as iterator-based interfaces will get, and the
syntax complexity still looks manageable (yet not minimal, of
course).

What's the equivalent syntax using array_view?

Jens

--=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_4576_1156789468.1413891570994
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 21, 2014 7:46:28 AM UTC+2, Jens Maurer wrote:
>
> Partly, yes.  I start getting concerned when the interface
> requires heroic compiler effort to make a function efficient.
> I've failed to get any restrict-based version to optimize
> properly with gcc.  But maybe I'm simply not understanding restrict.
>
> A range-based interface also composes remarkably well:
>
> Suppose you have conversion functions like this, returning the
> new pointer past the consumed output range:
>
>   char * convert(char * begin, char * end, unsigned int value);
>   char * convert(char * begin, char * end, const std::string_view&);
>   char * convert_hex(char * begin, char * end, unsigned int value);
>
> Then you can do
>
>    p = convert(p, end, 42);
>    p = convert(p, end, "some string");
>    p = convert_hex(p, end, 99);
>
> etc.
>
> This is as safe as iterator-based interfaces will get, and the
> syntax complexity still looks manageable (yet not minimal, of
> course).
>
> What's the equivalent syntax using array_view?
>

void convert(array_view&, T);

convert(av, 42);
convert(av, "some string");
convert_hex(av, 99);

This probably requires two variants of convert, one taking array_view by
value and one by reference.

--

---
You received this message because you are 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_4576_1156789468.1413891570994
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 21, 2014 7:46:28 AM UTC+2, Jens Maurer=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Partly, yes. &nbsp;I st=
art getting concerned when the interface
<br>requires heroic compiler effort to make a function efficient.
<br>I've failed to get any restrict-based version to optimize
<br>properly with gcc. &nbsp;But maybe I'm simply not understanding restric=
t.
<br>
<br>A range-based interface also composes remarkably well:
<br>
<br>Suppose you have conversion functions like this, returning the
<br>new pointer past the consumed output range:
<br>
<br>&nbsp; char * convert(char * begin, char * end, unsigned int value);
<br>&nbsp; char * convert(char * begin, char * end, const std::string_view&=
amp;);
<br>&nbsp; char * convert_hex(char * begin, char * end, unsigned int value)=
;
<br>
<br>Then you can do
<br>
<br>&nbsp; &nbsp;p =3D convert(p, end, 42);
<br>&nbsp; &nbsp;p =3D convert(p, end, "some string");
<br>&nbsp; &nbsp;p =3D convert_hex(p, end, 99);
<br>
<br>etc.
<br>
<br>This is as safe as iterator-based interfaces will get, and the
<br>syntax complexity still looks manageable (yet not minimal, of
<br>course).
<br>
<br>What's the equivalent syntax using array_view?
<br></blockquote><div><br></div><div>void convert(array_view&amp;, T);&nbsp=
;</div><div><br></div><div>convert(av, 42);</div><div>convert(av, "some str=
ing");</div><div>convert_hex(av, 99);</div><div><br></div><div>This probabl=
y requires two variants of convert, one taking array_view by value and one =
by reference.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_4576_1156789468.1413891570994--

.

------=_Part_251_1381287392.1413891812629
Content-Type: text/plain; charset=UTF-8

On Monday, October 20, 2014 10:10:05 PM UTC+2, Jens Maurer wrote:
>
> I don't want a (char*, size_t) interface.  In my experience, this leads
> to inefficient code, because you're incrementing your "current pointer"
> as well as decrementing the "remaining size".  This takes up two
> registers.  A range-style  (char*begin, char*end)  interface avoids
> that.  (Look, it's not a C interface, it's a C++ iterator-based
> interface.)
>

Two registers are required anyway but a pointer pair saves you from having
to decrease the second one.
An even stronger argument against a (char*, size_t) overload is
correctness. It causes tons of security bugs (off by one errors 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_251_1381287392.1413891812629
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, October 20, 2014 10:10:05 PM UTC+2, Jens Maurer=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I don't want a (char*, =
size_t) interface. &nbsp;In my experience, this leads
<br>to inefficient code, because you're incrementing your "current pointer"
<br>as well as decrementing the "remaining size". &nbsp;This takes up two
<br>registers. &nbsp;A range-style &nbsp;(char*begin, char*end) &nbsp;inter=
face avoids
<br>that. &nbsp;(Look, it's not a C interface, it's a C++ iterator-based
<br>interface.)
<br></blockquote><div><br></div><div>Two registers are required anyway but =
a pointer pair saves you from having to decrease the second one.</div><div>=
An even stronger argument against a (char*, size_t) overload is correctness=
.. It causes tons of security bugs (off by one errors etc).</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_251_1381287392.1413891812629--

.

------=_Part_502_1692344202.1413903062143
Content-Type: text/plain; charset=UTF-8


On Tuesday, October 21, 2014 7:39:31 AM UTC-4, Olaf van der Spek wrote:
>
> On Tuesday, October 21, 2014 7:46:28 AM UTC+2, Jens Maurer wrote:
>>
>>
>> Suppose you have conversion functions like this, returning the
>> new pointer past the consumed output range:
>>
>>   char * convert(char * begin, char * end, unsigned int value);
>>   char * convert(char * begin, char * end, const std::string_view&);
>>   char * convert_hex(char * begin, char * end, unsigned int value);
>>
>> Then you can do
>>
>>    p = convert(p, end, 42);
>>    p = convert(p, end, "some string");
>>    p = convert_hex(p, end, 99);
>>
>> etc.
>>
>> This is as safe as iterator-based interfaces will get, and the
>> syntax complexity still looks manageable (yet not minimal, of
>> course).
>>
>> What's the equivalent syntax using array_view?
>>
>
> void convert(array_view&, T);
>
> convert(av, 42);
> convert(av, "some string");
> convert_hex(av, 99);
>
> This probably requires two variants of convert, one taking array_view by
> value and one by reference.
>

I'm not sure taking the array_view param by reference is a good idea. It
could lead to surprising results. Its also very clumsy for times when we
won't want to modify the lvalue array_view with which we are passing in.

Admitttedly, using a pair of pointers and returning the tail does make it
easier to cascade multiple calls together to parse a full string. To use my
example would be harder:

string_view convert(array_view<char> buf, T val)

size_t len = 0;
array_view<char> buf = /* something */;

len += convert(buf, 42).length();
len += convert({buf.begin() + len, buf.end()}, "something else").length();
len += convert({buf.begin() + len, buf.end()}, x).length();


Both Jen's example and my example do no checking on the size of the output
buffer.

My example works better for common cases where you want to convert one
thing and use the result right away as a string value type.

cout << convert(buf, 42) << endl;

The pointer pair version only works better for cascading because it returns
the tail instead of returning something representing the actual string that
was parsed (either a null terminated char* (bad idea imo, we should move
away from null termination), or a string_view (good idea imo)).

char buf[/*some size*/];
char* p = convert(begin(buf), end(buf), 42);
string_view sv = {buf, p - buf };
cout << sv;

//Very easy to do this by mistake
cout << convert(begin(buf), end(buf), 42);

Returning a pointer to the end of the buffer is much more clumsy for the
most common case. If you want a tail pointer, it might be better to make
the user compute it themselves or have an optional tail parameter (either
an array_view or char*) with which the user can pass in if they need it.

string_view convert(array_view<char> buf, T val);
string_view convert(array_view<char>& tail, array_view<char> buf, T val);


Even if a pointer pair version is adopted, an array_view convenience
overload would be good to have to avoid error prone size computations.
Since it accepts raw pointers only, begin() and end() may not be usable for
all source array types and thus we are put back into the C world of buffer
overflows with bugs in size computations.


--

---
You received this message because you are 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_502_1692344202.1413903062143
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Tuesday, October 21, 2014 7:39:31 AM UTC-4, Olaf va=
n der Spek wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-le=
ft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bor=
der-left-style: solid;" class=3D"gmail_quote"><div dir=3D"ltr">On Tuesday, =
October 21, 2014 7:46:28 AM UTC+2, Jens Maurer wrote:<blockquote style=3D"m=
argin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 20=
4, 204); border-left-width: 1px; border-left-style: solid;" class=3D"gmail_=
quote"><br>Suppose you have conversion functions like this, returning the
<br>new pointer past the consumed output range:
<br>
<br>&nbsp; char * convert(char * begin, char * end, unsigned int value);
<br>&nbsp; char * convert(char * begin, char * end, const std::string_view&=
amp;);
<br>&nbsp; char * convert_hex(char * begin, char * end, unsigned int value)=
;
<br>
<br>Then you can do
<br>
<br>&nbsp; &nbsp;p =3D convert(p, end, 42);
<br>&nbsp; &nbsp;p =3D convert(p, end, "some string");
<br>&nbsp; &nbsp;p =3D convert_hex(p, end, 99);
<br>
<br>etc.
<br>
<br>This is as safe as iterator-based interfaces will get, and the
<br>syntax complexity still looks manageable (yet not minimal, of
<br>course).
<br>
<br>What's the equivalent syntax using array_view?
<br></blockquote><div><br></div><div>void convert(array_view&amp;, T);&nbsp=
;</div><div><br></div><div>convert(av, 42);</div><div>convert(av, "some str=
ing");</div><div>convert_hex(av, 99);</div><div><br></div><div>This probabl=
y requires two variants of convert, one taking array_view by value and one =
by reference.</div></div></blockquote><div>&nbsp;</div><div>I'm not sure ta=
king the array_view param by reference is a good idea. It could lead to sur=
prising results. Its also very clumsy for times when we won't want to modif=
y the lvalue array_view with which we are passing in.</div><div>&nbsp;</div=
><div>Admitttedly, using a pair of pointers and returning the tail&nbsp;doe=
s make it easier to cascade multiple calls&nbsp;together to parse a full st=
ring. To use my example would be harder:</div><div>&nbsp;</div><div style=
=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; background=
-color: rgb(250, 250, 250);" class=3D"prettyprint"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: rgb(0, 0, 0);" clas=
s=3D"styled-by-prettify">string_view convert</span><span style=3D"color: rg=
b(102, 102, 0);" class=3D"styled-by-prettify">(</span><span style=3D"color:=
 rgb(0, 0, 0);" class=3D"styled-by-prettify">array_view</span><span style=
=3D"color: rgb(0, 136, 0);" class=3D"styled-by-prettify">&lt;char&gt;</span=
><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> buf</sp=
an><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> T =
val</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prett=
ify">)</span></div></code></div><div><br></div><div style=3D"border: 1px so=
lid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 2=
50, 250);" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><font color=3D"#000088"><span style=3D"color: rgb(0, 0, 0);=
" class=3D"styled-by-prettify">size_t len </span><span style=3D"color: rgb(=
102, 102, 0);" class=3D"styled-by-prettify">=3D</span><span style=3D"color:=
 rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"color: =
rgb(0, 102, 102);" class=3D"styled-by-prettify">0</span><span style=3D"colo=
r: rgb(102, 102, 0);" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>array_view</span><spa=
n style=3D"color: rgb(0, 136, 0);" class=3D"styled-by-prettify">&lt;char&gt=
;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> =
buf </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: rgb(136, 0, 0);" class=3D"styled-by-pr=
ettify">/* something */</span><span style=3D"color: rgb(102, 102, 0);" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"><br><br>len </span><span style=3D"color: rgb(102, 1=
02, 0);" class=3D"styled-by-prettify">+=3D</span><span style=3D"color: rgb(=
0, 0, 0);" class=3D"styled-by-prettify"> convert</span><span style=3D"color=
: rgb(102, 102, 0);" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: rgb(0, 0, 0);" class=3D"styled-by-prettify">buf</span><span style=3D"c=
olor: rgb(102, 102, 0);" class=3D"styled-by-prettify">,</span><span style=
=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=
=3D"color: rgb(0, 102, 102);" class=3D"styled-by-prettify">42</span><span s=
tyle=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">).</span><sp=
an style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">length</span=
><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">();<=
/span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br=
>len </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pre=
ttify">+=3D</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-p=
rettify"> convert</span><span style=3D"color: rgb(102, 102, 0);" class=3D"s=
tyled-by-prettify">({</span><span style=3D"color: rgb(0, 0, 0);" class=3D"s=
tyled-by-prettify">buf</span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"styled-by-prettify">.</span><span style=3D"color: rgb(0, 0, 136);" clas=
s=3D"styled-by-prettify">begin</span><span style=3D"color: rgb(102, 102, 0)=
;" class=3D"styled-by-prettify">()</span><span style=3D"color: rgb(0, 0, 0)=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(102, 102,=
 0);" class=3D"styled-by-prettify">+</span><span style=3D"color: rgb(0, 0, =
0);" class=3D"styled-by-prettify"> len</span><span style=3D"color: rgb(102,=
 102, 0);" class=3D"styled-by-prettify">,</span><span style=3D"color: rgb(0=
, 0, 0);" class=3D"styled-by-prettify"> buf</span><span style=3D"color: rgb=
(102, 102, 0);" class=3D"styled-by-prettify">.</span><span style=3D"color: =
rgb(0, 0, 136);" class=3D"styled-by-prettify">end</span><span style=3D"colo=
r: rgb(102, 102, 0);" class=3D"styled-by-prettify">()},</span><span style=
=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=
=3D"color: rgb(0, 136, 0);" class=3D"styled-by-prettify">"something else"</=
span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">=
).</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">=
length</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pr=
ettify">();</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-p=
rettify"><br>len </span><span style=3D"color: rgb(102, 102, 0);" class=3D"s=
tyled-by-prettify">+=3D</span><span style=3D"color: rgb(0, 0, 0);" class=3D=
"styled-by-prettify"> convert</span><span style=3D"color: rgb(102, 102, 0);=
" class=3D"styled-by-prettify">({</span><span style=3D"color: rgb(0, 0, 0);=
" class=3D"styled-by-prettify">buf</span><span style=3D"color: rgb(102, 102=
, 0);" class=3D"styled-by-prettify">.</span><span style=3D"color: rgb(0, 0,=
 136);" class=3D"styled-by-prettify">begin</span><span style=3D"color: rgb(=
102, 102, 0);" class=3D"styled-by-prettify">()</span><span style=3D"color: =
rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"color: r=
gb(102, 102, 0);" class=3D"styled-by-prettify">+</span><span style=3D"color=
: rgb(0, 0, 0);" class=3D"styled-by-prettify"> len</span><span style=3D"col=
or: rgb(102, 102, 0);" class=3D"styled-by-prettify">,</span><span style=3D"=
color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> buf</span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">.</span><span st=
yle=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">end</span><span=
 style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">()},</span=
><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> x</span=
><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">).</=
span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">leng=
th</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pretti=
fy">();</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prett=
ify"><br></span></font><span style=3D"color: rgb(0, 0, 0);" class=3D"styled=
-by-prettify"><br></span></div></code></div><div><br>Both Jen's example and=
 my example do no checking on the size of the output buffer.</div><div>&nbs=
p;</div><div>My example works better for common cases where you want to con=
vert one thing and use the result right away as a string value type.</div><=
div>&nbsp;</div><div style=3D"border: 1px solid rgb(187, 187, 187); word-wr=
ap: break-word; background-color: rgb(250, 250, 250);" class=3D"prettyprint=
"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"=
color: rgb(0, 0, 0);" class=3D"styled-by-prettify">cout </span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">&lt;&lt;</span><=
span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> convert</=
span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">=
(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">b=
uf</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-pretti=
fy">,</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: rgb(0, 102, 102);" class=3D"styled-by-pret=
tify">42</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-=
prettify">)</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-b=
y-prettify">&lt;&lt;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"st=
yled-by-prettify"> endl</span><span style=3D"color: rgb(102, 102, 0);" clas=
s=3D"styled-by-prettify">;</span></div></code></div><div><br>The pointer pa=
ir version only works better for cascading because it returns the tail inst=
ead of returning something representing the actual string that was parsed (=
either a null terminated char* (bad idea imo, we should move away from null=
 termination), or a string_view (good idea imo)). </div><div>&nbsp;</div><d=
iv style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; ba=
ckground-color: rgb(250, 250, 250);" class=3D"prettyprint"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: rgb(0, 0, 1=
36);" class=3D"styled-by-prettify">char</span><span style=3D"color: rgb(0, =
0, 0);" class=3D"styled-by-prettify"> buf</span><span style=3D"color: rgb(1=
02, 102, 0);" class=3D"styled-by-prettify">[</span><span style=3D"color: rg=
b(136, 0, 0);" class=3D"styled-by-prettify">/*some size*/</span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">];</span><span s=
tyle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: rgb(0, 0, 136);" class=3D"styled-by-prettify">char</span><=
span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">*</spa=
n><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> p </sp=
an><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"=
> convert</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by=
-prettify">(</span><span style=3D"color: rgb(0, 0, 136);" class=3D"styled-b=
y-prettify">begin</span><span style=3D"color: rgb(102, 102, 0);" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"st=
yled-by-prettify">buf</span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"styled-by-prettify">),</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"> </span><span style=3D"color: rgb(0, 0, 136);" clas=
s=3D"styled-by-prettify">end</span><span style=3D"color: rgb(102, 102, 0);"=
 class=3D"styled-by-prettify">(</span><span style=3D"color: rgb(0, 0, 0);" =
class=3D"styled-by-prettify">buf</span><span style=3D"color: rgb(102, 102, =
0);" class=3D"styled-by-prettify">),</span><span style=3D"color: rgb(0, 0, =
0);" class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(0, 102,=
 102);" class=3D"styled-by-prettify">42</span><span style=3D"color: rgb(102=
, 102, 0);" class=3D"styled-by-prettify">);</span><span style=3D"color: rgb=
(0, 0, 0);" class=3D"styled-by-prettify"><br>string_view sv </span><span st=
yle=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">=3D</span><sp=
an style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">{</span><=
span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">buf</span>=
<span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> p </s=
pan><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">-=
</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> b=
uf </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prett=
ify">};</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prett=
ify"><br>cout </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styl=
ed-by-prettify">&lt;&lt;</span><span style=3D"color: rgb(0, 0, 0);" class=
=3D"styled-by-prettify"> sv</span><span style=3D"color: rgb(102, 102, 0);" =
class=3D"styled-by-prettify">;</span><span style=3D"color: rgb(0, 0, 0);" c=
lass=3D"styled-by-prettify"><br><br></span><span style=3D"color: rgb(136, 0=
, 0);" class=3D"styled-by-prettify">//Very easy to do this by mistake</span=
><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>cout=
 </span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettif=
y">&lt;&lt;</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-p=
rettify"> convert</span><span style=3D"color: rgb(102, 102, 0);" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: rgb(0, 0, 136);" class=3D"=
styled-by-prettify">begin</span><span style=3D"color: rgb(102, 102, 0);" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: rgb(0, 0, 0);" cla=
ss=3D"styled-by-prettify">buf</span><span style=3D"color: rgb(102, 102, 0);=
" class=3D"styled-by-prettify">),</span><span style=3D"color: rgb(0, 0, 0);=
" class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(0, 0, 136)=
;" class=3D"styled-by-prettify">end</span><span style=3D"color: rgb(102, 10=
2, 0);" class=3D"styled-by-prettify">(</span><span style=3D"color: rgb(0, 0=
, 0);" class=3D"styled-by-prettify">buf</span><span style=3D"color: rgb(102=
, 102, 0);" class=3D"styled-by-prettify">),</span><span style=3D"color: rgb=
(0, 0, 0);" class=3D"styled-by-prettify"> </span><span style=3D"color: rgb(=
0, 102, 102);" class=3D"styled-by-prettify">42</span><span style=3D"color: =
rgb(102, 102, 0);" class=3D"styled-by-prettify">);</span><span style=3D"col=
or: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br></span></div></code></d=
iv><div>&nbsp;</div><div>Returning a pointer to the end of the buffer is mu=
ch more clumsy for the most common case. If you want a tail pointer, it mig=
ht be better to make the user compute it themselves or have an optional tai=
l parameter (either an array_view or char*) with which the user can pass in=
 if they need it.</div><div>&nbsp;</div><div><div style=3D"border: 1px soli=
d rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250=
, 250);" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prett=
ify">string_view convert</span><span style=3D"color: rgb(102, 102, 0);" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: rgb(0, 0, 0);" clas=
s=3D"styled-by-prettify">array_view</span><span style=3D"color: rgb(0, 136,=
 0);" class=3D"styled-by-prettify">&lt;char&gt;</span><span style=3D"color:=
 rgb(0, 0, 0);" class=3D"styled-by-prettify"> buf</span><span style=3D"colo=
r: rgb(102, 102, 0);" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: rgb(0, 0, 0);" class=3D"styled-by-prettify"> T val</span><span style=
=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">);</span><span s=
tyle=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"><br>string_view =
convert</span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-pr=
ettify">array_view</span><span style=3D"color: rgb(0, 136, 0);" class=3D"st=
yled-by-prettify">&lt;char&gt;</span><span style=3D"color: rgb(102, 102, 0)=
;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: rgb(0, 0,=
 0);" class=3D"styled-by-prettify"> tail</span><span style=3D"color: rgb(10=
2, 102, 0);" class=3D"styled-by-prettify">,</span><span style=3D"color: rgb=
(0, 0, 0);" class=3D"styled-by-prettify"> array_view</span><span style=3D"c=
olor: rgb(0, 136, 0);" class=3D"styled-by-prettify">&lt;char&gt;</span><spa=
n style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> buf</span><s=
pan style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">,</span=
><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify"> T val</=
span><span style=3D"color: rgb(102, 102, 0);" class=3D"styled-by-prettify">=
);</span><span style=3D"color: rgb(0, 0, 0);" class=3D"styled-by-prettify">=
<br></span></div></code></div><br></div><div><br>Even if a pointer pair ver=
sion is adopted, an array_view convenience overload would be good to have t=
o avoid error prone size computations. Since it accepts raw pointers only, =
begin() and end() may not be usable for all source array types and thus we =
are put back into the C world of buffer overflows with bugs in size computa=
tions.</div><div>&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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_502_1692344202.1413903062143--

.

On 10/21/2014 04:51 PM, Matthew Fioravante wrote:
> string_view convert(array_view<char>buf,T val);
> string_view convert(array_view<char>&tail,array_view<char>buf,T val);
>=20
>=20
> Even if a pointer pair version is adopted, an array_view convenience over=
load would be good to have to avoid error prone size computations. Since it=
 accepts raw pointers only, begin() and end() may not be usable for all sou=
rce array types and thus we are put back into the C world of buffer overflo=
ws with bugs in size computations.

Absolutely.  The low-level interface (pointer pair?) need not be the
only interface we offer to users.  In fact, I envision quite a few
template wrappers that are a lot more convenient to use than the
pointer pair version.

Examples:

template<class T>
string_view convert(array_view<char> buf, T val);

template<class T>
std::string to_string(T val);   // might not work due to existing to_string=
()


and possibly even "iostreams light":

template<class T>
bufstream& operator<<(bufstream&, T val);


For these kinds of convenience wrappers, we need a good idea how to
pass the multitude of formatting options so that we can have a
handful of wrapper templates per idiom, at most.

template<class T, class ... Opt>
string_view convert(array_view<char> buf, T val, Opt... options);

might work.

Jens

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

.