------=_Part_272_1248810086.1412092060288
Content-Type: text/plain; charset=UTF-8

Now that we have string_view, it might be a good idea to have overloads of
atoX and strtoX which take string_view arguments.

double atof(string_view str);

int atoi(string_view str);
long atol(string_view str);
long long atoll(string_view str);

long strtol(string_view str, string_view& tail, int base);
long strtol(string_view str, int base);

long long strtoll(string_view str, string_view& tail, int base);
long long strtoll(string_view str, int base);

long strtoul(string_view str, string_view& tail, int base);
long strtoul(string_view str, int base);

long long strtoull(string_view str, string_view& tail, int base);
long long strtoull(string_view str, int base);

std::intmax_t strtoimax(string_view str, string_view& tail, int base);
std::intmax_t strtoimax(string_view str, int base);

std::uintmax_t strtoumax(string_view str, string_view& tail, int base);
std::uintmax_t strtoumax(string_view str, int base);

float strtof(string_view str, string_view& tail);
float strtof(string_view str);

double strtof(string_view str);
double strtof(string_view str, string_view& tail);

long double strtof(string_view str);
long double strtof(string_view str, string_view& tail);



Why?

   1. strtod(const char*, char**) assumes null termination, making it
   unusable with an arbitrary string_view
   2. Many implementations of strtod(const char*, char**) call strlen(). In
   some of my applications which do a lot of string -> float conversion, I
   have found this to have a measurable impact on performance. By passing in a
   string_view, we can avoid these stupid redundant calls to strlen().
   3. Converting std::string to int / float becomes more natural (no
   calling .c_str()) and efficient (no ridiculous strlen calls inside) because
   it converts to string_view.

The alternative is redesigning a completely new str to number API and there
was a big discussion about this a while ago with debates about return
values, out parameters, optional, expected, and exceptions. That's probably
the best solution in the long run but it might take a long time to get it
right. In the meantime, we could at least maintain status quo and have some
way of doing str to number conversions using string_view.

These could also be built on top of lower level primitives like this:


float atof_l(const char* str, size_t len);

The above could also be added to the C standard, allowing anyone building a
higher level language ontop of C to use non-null terminated strings.

--

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

<div dir=3D"ltr">Now that we have string_view, it might be a good idea to h=
ave overloads of atoX and strtoX which take string_view arguments.<br><br><=
div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bo=
rder-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; wor=
d-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #008;" class=3D"styled-by-prettify"></span>double=
 atof(string_view str);<br><br>int atoi(string_view str);<br>long atol(stri=
ng_view str);<br>long long atoll(string_view str);<br><br>long strtol(strin=
g_view str, string_view&amp; tail, int base);<br>long strtol(string_view st=
r, int base);<br><br>long long strtoll(string_view str, string_view&amp; ta=
il, int base);<br>long long strtoll(string_view str, int base);<br><code cl=
ass=3D"prettyprint"><br>long strtoul(string_view str, string_view&amp; tail=
, int base);<br>long strtoul(string_view str, int base);<br><br>long long s=
trtoull(string_view str, string_view&amp; tail, int base);<br>long long str=
toull(string_view str, int base);</code><br><code class=3D"prettyprint"><co=
de class=3D"prettyprint"><br>std::intmax_t strtoimax(string_view str, strin=
g_view&amp; tail, int base);<br>std::intmax_t strtoimax(string_view str, in=
t base);<br><br>std::uintmax_t strtoumax(string_view str, string_view&amp; =
tail, int base);<br>std::uintmax_t strtoumax(string_view str, int base);</c=
ode></code><br><br><span style=3D"color: #008;" class=3D"styled-by-prettify=
"><code class=3D"prettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">float</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> strtof</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">stri=
ng_view str</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> string_=
view</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> tail</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></code>float<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> strtof</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">string_view str</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"></span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><br><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">double</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> strtof</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">string_view str</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">double</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> strtof</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">string_view str</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> string_view</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> tail</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></sp=
an></code></span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><code class=3D"prettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">long double</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> strtof</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">string_view str</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">long double</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> strtof</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">strin=
g_view str</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> string_v=
iew</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> tail</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br></span></code=
></span></code></span></div></code></div><br>Why?<br><ol><li>strtod(const c=
har*, char**) assumes null termination, making it unusable with an arbitrar=
y string_view</li><li>Many implementations of strtod(const char*, char**) c=
all strlen(). In some of my applications which do a lot of string -&gt; flo=
at conversion, I have found this to have a measurable impact on performance=
.. By passing in a string_view, we can avoid these stupid redundant calls to=
 strlen().</li><li>Converting std::string to int / float becomes more natur=
al (no calling .c_str()) and efficient (no ridiculous strlen calls inside) =
because it converts to string_view. <br></li></ol><p>The alternative is red=
esigning a completely new str to number API and there was a big discussion =
about this a while ago with debates about return values, out parameters, op=
tional, expected, and exceptions. That's probably the best solution in the =
long run but it might take a long time to get it right. In the meantime, we=
 could at least maintain status quo and have some way of doing str to numbe=
r conversions using string_view. <br></p><p>These could also be built on to=
p of lower level primitives like this:</p><p><br></p><div class=3D"prettypr=
int" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, =
187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">float atof_l(const char* str, size=
_t len);</span><span style=3D"color: #660;" class=3D"styled-by-prettify"></=
span></div></code></div><p></p><p>The above could also be added to the C st=
andard, allowing anyone building a higher level language ontop of C to use =
non-null terminated strings.<br></p></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_272_1248810086.1412092060288--

.

On 2014-09-30 17:47, Matthew Fioravante wrote:
> Now that we have string_view, it might be a good idea to have overloads
> of atoX and strtoX which take string_view arguments.
>
> |
> double atof(string_view str);
>
> int atoi(string_view str);
> long atol(string_view str);
> long long atoll(string_view str);
>
> long strtol(string_view str, string_view& tail, int base);
> long strtol(string_view str, int base);
>
> long long strtoll(string_view str, string_view& tail, int base);
> long long strtoll(string_view str, int base);
> |
> long strtoul(string_view str, string_view& tail, int base);
> long strtoul(string_view str, int base);
>
> long long strtoull(string_view str, string_view& tail, int base);
> long long strtoull(string_view str, int base);|
> ||
> std::intmax_t strtoimax(string_view str, string_view& tail, int base);
> std::intmax_t strtoimax(string_view str, int base);
>
> std::uintmax_t strtoumax(string_view str, string_view& tail, int base);
> std::uintmax_t strtoumax(string_view str, int base);||
>
> |floatstrtof(string_view str,string_view&tail);
> |floatstrtof(string_view str);
>
> |doublestrtof(string_view str);
> doublestrtof(string_view str,string_view&tail);
>
> |||long doublestrtof(string_view str);
> long doublestrtof(string_view str,string_view&tail);
>
>
> ||
> |
>
> Why?
>

Yes, Why?

The counter argument being that there are WAY too many overloads
already. Is adding even more of them an improvement?


Bo Persson



--

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

.

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

Yes, it is an improvement, because string_view is semantically different
(not null-terminated) from all of the existing overloads. Shall I incur the
significant cost of std::string conversion instead?

All string manipulation functions that can be plausibly supported should
have a string_view version.



On Tue, Sep 30, 2014 at 11:33 AM, Bo Pesson <bop@gmb.dk> wrote:

> On 2014-09-30 17:47, Matthew Fioravante wrote:
>
>> Now that we have string_view, it might be a good idea to have overloads
>> of atoX and strtoX which take string_view arguments.
>>
>> |
>> double atof(string_view str);
>>
>> int atoi(string_view str);
>> long atol(string_view str);
>> long long atoll(string_view str);
>>
>> long strtol(string_view str, string_view& tail, int base);
>> long strtol(string_view str, int base);
>>
>> long long strtoll(string_view str, string_view& tail, int base);
>> long long strtoll(string_view str, int base);
>> |
>> long strtoul(string_view str, string_view& tail, int base);
>> long strtoul(string_view str, int base);
>>
>> long long strtoull(string_view str, string_view& tail, int base);
>> long long strtoull(string_view str, int base);|
>> ||
>> std::intmax_t strtoimax(string_view str, string_view& tail, int base);
>> std::intmax_t strtoimax(string_view str, int base);
>>
>> std::uintmax_t strtoumax(string_view str, string_view& tail, int base);
>> std::uintmax_t strtoumax(string_view str, int base);||
>>
>> |floatstrtof(string_view str,string_view&tail);
>> |floatstrtof(string_view str);
>>
>> |doublestrtof(string_view str);
>> doublestrtof(string_view str,string_view&tail);
>>
>> |||long doublestrtof(string_view str);
>> long doublestrtof(string_view str,string_view&tail);
>>
>>
>> ||
>> |
>>
>> Why?
>>
>>
> Yes, Why?
>
> The counter argument being that there are WAY too many overloads already.
> Is adding even more of them an improvement?
>
>
> Bo Persson
>
>
>
>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
> proposals/.
>

--

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

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

<div dir=3D"ltr">Yes, it is an improvement, because string_view is semantic=
ally different (not null-terminated) from all of the existing overloads. Sh=
all I incur the significant cost of std::string conversion instead?<div><br=
></div><div>All string manipulation functions that can be plausibly support=
ed should have a string_view version.<br><div><br></div><div><br></div></di=
v></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, S=
ep 30, 2014 at 11:33 AM, Bo Pesson <span dir=3D"ltr">&lt;<a href=3D"mailto:=
bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 2014-09-30=
 17:47, Matthew Fioravante wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Now that we have string_view, it might be a good idea to have overloads<br>
of atoX and strtoX which take string_view arguments.<br>
<br>
|<br>
double atof(string_view str);<br>
<br>
int atoi(string_view str);<br>
long atol(string_view str);<br>
long long atoll(string_view str);<br>
<br>
long strtol(string_view str, string_view&amp; tail, int base);<br>
long strtol(string_view str, int base);<br>
<br>
long long strtoll(string_view str, string_view&amp; tail, int base);<br>
long long strtoll(string_view str, int base);<br>
|<br>
long strtoul(string_view str, string_view&amp; tail, int base);<br>
long strtoul(string_view str, int base);<br>
<br>
long long strtoull(string_view str, string_view&amp; tail, int base);<br>
long long strtoull(string_view str, int base);|<br>
||<br>
std::intmax_t strtoimax(string_view str, string_view&amp; tail, int base);<=
br>
std::intmax_t strtoimax(string_view str, int base);<br>
<br>
std::uintmax_t strtoumax(string_view str, string_view&amp; tail, int base);=
<br>
std::uintmax_t strtoumax(string_view str, int base);||<br>
<br>
|floatstrtof(string_view str,string_view&amp;tail);<br>
|floatstrtof(string_view str);<br>
<br>
|doublestrtof(string_view str);<br>
doublestrtof(string_view str,string_view&amp;tail);<br>
<br>
|||long doublestrtof(string_view str);<br>
long doublestrtof(string_view str,string_view&amp;tail);<br>
<br>
<br>
||<br>
|<br>
<br>
Why?<br>
<br>
</blockquote>
<br></div></div>
Yes, Why?<br>
<br>
The counter argument being that there are WAY too many overloads already. I=
s adding even more of them an improvement?<br>
<br>
<br>
Bo Persson<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></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 />

--001a11c2daf0861f0405044b24d9--

.

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

On 30 September 2014 10:47, Matthew Fioravante <fmatthew5876@gmail.com>
wrote:

> Now that we have string_view, it might be a good idea to have overloads of
> atoX and strtoX which take string_view arguments.
>

If you want to add something like this, please propose a templated function
instead, as in

template<typename N>
N to_number(string_view str);

That way it works with all the typedefs (such as uint32_t) for the numeric
types.
--
 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/.

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

<div dir=3D"ltr">On 30 September 2014 10:47, Matthew Fioravante <span dir=
=3D"ltr">&lt;<a href=3D"mailto:fmatthew5876@gmail.com" target=3D"_blank">fm=
atthew5876@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><d=
iv 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">No=
w that we have string_view, it might be a good idea to have overloads of at=
oX and strtoX which take string_view arguments.<br></div></blockquote><div>=
<br></div><div>If you want to add something like this, please propose a tem=
plated function instead, as in</div><div><br></div><div>template&lt;typenam=
e N&gt;</div><div>N to_number(string_view str);</div><div><br></div><div>Th=
at way it works with all the typedefs (such as uint32_t) for the numeric ty=
pes.</div></div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<=
a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlo=
rd.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 />

--047d7bae47b023ee7805044bae28--

.

------=_Part_4730_187749601.1412098345036
Content-Type: text/plain; charset=UTF-8



On Tuesday, September 30, 2014 1:26:16 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On 30 September 2014 10:47, Matthew Fioravante <fmatth...@gmail.com
> <javascript:>> wrote:
>
>> Now that we have string_view, it might be a good idea to have overloads
>> of atoX and strtoX which take string_view arguments.
>>
>
> If you want to add something like this, please propose a templated
> function instead, as in
>
> template<typename N>
> N to_number(string_view str);
>
> That way it works with all the typedefs (such as uint32_t) for the numeric
> types.
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404
>

strto<T>() might be a better name, but that's getting into bikeshed
territory.


string_view s = /*something */
auto i = strto<int>(s);
auto f = strto<float>(s);


If we go this route, then all of the questions about return values, out
parameters, how to return an error status and a value, exceptions, etc...
all come back. I guess we can revisit that discussion again. I'll write up
a basic proposal sketch to start the discussion.


--

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

<div dir=3D"ltr"><br><br>On Tuesday, September 30, 2014 1:26:16 PM UTC-4, N=
evin ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">On 30 September 2014 10:47, Matthew Fioravante <span dir=3D"ltr">=
&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"a5Fn=
J1wFHzoJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D=
"this.href=3D'javascript:';return true;">fmatth...@gmail.com</a>&gt;</span>=
 wrote:<br><div><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">Now that we have string_view, it might be a good idea to ha=
ve overloads of atoX and strtoX which take string_view arguments.<br></div>=
</blockquote><div><br></div><div>If you want to add something like this, pl=
ease propose a templated function instead, as in</div><div><br></div><div>t=
emplate&lt;typename N&gt;</div><div>N to_number(string_view str);</div><div=
><br></div><div>That way it works with all the typedefs (such as uint32_t) =
for the numeric types.</div></div>-- <br>&nbsp;Nevin ":-)" Liber&nbsp; &lt;=
mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"a=
5FnJ1wFHzoJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">ne...@eviloverlord.com</a><wbr>=
&gt;&nbsp; (847) 691-1404
</div></div></blockquote><div><br>strto&lt;T&gt;() might be a better name, =
but that's getting into bikeshed territory.<br><br><div class=3D"prettyprin=
t" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 18=
7, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>string_view s </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;=
" class=3D"styled-by-prettify">/*something */</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> i </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> strto</span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">&lt;int&gt;</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> f </span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> strto</span><span style=3D"color: #080;" cla=
ss=3D"styled-by-prettify">&lt;float&gt;</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">s</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br><br></span></div></code></div><br>If we go this route, then all of t=
he questions about return values, out parameters, how to return an error st=
atus and a value, exceptions, etc... all come back. I guess we can revisit =
that discussion again. I'll write up a basic proposal sketch to start the d=
iscussion.<br>&nbsp;<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_4730_187749601.1412098345036--

.

------=_Part_2471_422946246.1412098989473
Content-Type: text/plain; charset=UTF-8

That would be a useful addition in my opinion.

Regarding the name, considering that we have std::to_string() which
converts a number into a string, I believe calling the operation which
converts a string into a number std::to_number() would be more appropriate.

Kind regards,

Andy

--

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

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

<div dir=3D"ltr">That would be a useful addition in my opinion.<br><br>Rega=
rding the name, considering that we have std::to_string() which converts a =
number into a string, I believe calling the operation which converts a stri=
ng into a number std::to_number() would be more appropriate.<br><br>Kind re=
gards,<br><br>Andy</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_2471_422946246.1412098989473--

.

------=_Part_752_674754395.1412102103946
Content-Type: text/plain; charset=UTF-8

I'll write up a formal draft with the details, but here's a basic sketch of
what I'm thinking:

//Parses str as a base base integer and stores the result in target.
//tail will point to the tail of the string after the last character
//If successful, returns a default constructed error_code.
//If an error occurs, the error will be stored in the error code
(Specification TBD) and target will be left unmodified.
template <typename Integral>
error_code to_number(Integral& target, string_view& tail, string_view str,
int base);

template <typename Integral>
error_code to_number(Integral& target, string_view str, int base) {
  string_view tail;
  return to_number(target, tail, str, base);
}

template <typename Integral>
Integral to_number(error_code& ec, string_view& tail, string_view str, int
base, Integral ret_on_error = Integral{}) {
  Integral val = ret_on_error;
  ec = to_number(val, tail, str, base);
  return val;
}

template <typename Integral>
Integral to_number(string_view& tail, string_view str, int base, Integral
ret_on_error = Integral{}) {
  error_code ec; return to_number(ec, tail, str, base, ret_on_error);
}

template <typename Integral>
Integral to_number(error_code& ec, string_view str, int base, Integral
ret_on_error = Integral{}) {
  string_view tail; return to_number(ec, tail, str, base, ret_on_error);
}

template <typename Integral>
Integral to_number(string_view str, int base, Integral ret_on_error =
Integral{}) {
  string_view tail;
  error_code ec;
  return to_number(ec, tail, str, base, ret_on_error);
}

The out parameter version is useful when you want to use overloading to
deduce the type. Its also very natural for error checking.

string_view s = "1234,5678";

int x, y;
if(auto ec = to_number(x, s, s, 10)) {
  //handle error
}
s.remove_prefix(1); //skip the ,
if(auto ec = to_number(y, s, s, 10)) {
  //handle error
}
assert(s.empty());

Returning the value instead of the error code lets you use auto. Its also
more handy if you don't care so much about checking errors and just want to
use the default value if parsing failed.


//x is set to the parsed integer on success, or -1 on failure
auto x = to_number<int>(s, 10, -1);

The floating point variants would look identical, just without the base
argument.


--

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

<div dir=3D"ltr">I'll write up a formal draft with the details, but here's =
a basic sketch of what I'm thinking:<br><br><div class=3D"prettyprint" styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; word-wrap: break-word;"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800=
;" class=3D"styled-by-prettify">//Parses str as a base base integer and sto=
res the result in target.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">//tail will point to the tail of the string after the last charact=
er</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #800;" class=3D"styled-by-prettify">//If successfu=
l, returns a default constructed error_code.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" c=
lass=3D"styled-by-prettify">//If an error occurs, the error will be stored =
in the error code (Specification TBD) and target will be left unmodified.</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Integral</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>error_code to_number</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">Integral</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> target</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> string_view</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> tail</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> stri=
ng_view str</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">base</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">template</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">In=
tegral</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>error_=
code to_number</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Integ=
ral</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> target</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> string_view str</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">base</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp=
; string_view tail</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> to_=
number</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">target</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> tail</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> str</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">base</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">Integral</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #606;" class=3D"styled-=
by-prettify">Integral</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> to_number</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">error_code</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ec=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> string_view</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> tail</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> string_view str</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">base</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Integral<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ret_on_err=
or </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">Integral</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{})</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Integral</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> val </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> ret_on_error</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> &nbsp;<br>&nbsp; ec </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> to_number</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>val</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> tail</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> str</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">base</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> val</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">template</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Integral</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Integral</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> to_number</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>string_view</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ta=
il</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> string_view str<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">base</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Integral</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> ret_on_error </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Integra=
l</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{})</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>&nbsp; error_code ec</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> to_number</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">ec</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> tail</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> str</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">base</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> ret_on_error</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">template</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typenam=
e</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">Integral</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">Integral</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> to_number</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">error_code</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> ec</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> string_view str</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">base</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">Integral</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> ret_on_error </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Integral</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{})</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; string_view tail</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> to_number</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">ec</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> tail</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> str</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
base</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> ret_on_error</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Integral</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #606;" class=3D"styled-by-prettify">Inte=
gral</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> to_nu=
mber</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">string_view str=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">base</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Integral</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> ret_on_error </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Integra=
l</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{})</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>&nbsp; string_view tail</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; error_code ec</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> to_number</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">ec</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> tail</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> str</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">base</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> ret_on_error</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span></div></code></div><br>The out parame=
ter version is useful when you want to use overloading to deduce the type. =
Its also very natural for error checking.<br><br><div class=3D"prettyprint"=
 style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187,=
 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
 #000;" class=3D"styled-by-prettify">string_view s </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" clas=
s=3D"styled-by-prettify">"1234,5678"</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> ec </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> to_number</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> s</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> s</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-b=
y-prettify">10</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">))</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">//handle error</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>s</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">remove_prefix</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
skip the ,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> ec </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> to_number</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">y</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #066;" class=3D"styled-by-prettify">10</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">))</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>&nbsp; </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">//handle error</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">assert</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">s</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">empty</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">());</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>Returning the val=
ue instead of the error code lets you use auto. Its also more handy if you =
don't care so much about checking errors and just want to use the default v=
alue if parsing failed.<br><br><div class=3D"prettyprint" style=3D"backgrou=
nd-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-styl=
e: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"styled-=
by-prettify">//x is set to the parsed integer on success, or -1 on failure<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> to_number</span><span style=3D"col=
or: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">s</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">10</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">-</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> <br></span></div></code></div><br>The floati=
ng point variants would look identical, just without the base argument.<br>=
<br><br></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_752_674754395.1412102103946--

.

This is a multi-part message in MIME format.
--------------050503090408030208080403
Content-Type: text/plain; charset=UTF-8; format=flowed

Then why not go the whole route and make it to_string/from_string and
not limit it just to numbers?

Btw "it might take a long time to get it right": the next standard is at
least another three years out.

Am 30.09.2014 um 19:43 schrieb Andy Prowl:
> That would be a useful addition in my opinion.
>
> Regarding the name, considering that we have std::to_string() which
> converts a number into a string, I believe calling the operation which
> converts a string into a number std::to_number() would be more
> appropriate.
>
> Kind regards,
>
> Andy
> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto: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/.

--------------050503090408030208080403
Content-Type: text/html; charset=UTF-8

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Then why not go the whole route and make it to_string/from_string
    and not limit it just to numbers?<br>
    <br>
    Btw "it might take a long time to get it right": the next standard
    is at least another three years out.<br>
    <br>
    <div class="moz-cite-prefix">Am 30.09.2014 um 19:43 schrieb Andy
      Prowl:<br>
    </div>
    <blockquote
      cite="mid:d5d64236-370b-419d-b19f-1252edca3f0d@isocpp.org"
      type="cite">
      <div dir="ltr">That would be a useful addition in my opinion.<br>
        <br>
        Regarding the name, considering that we have std::to_string()
        which converts a number into a string, I believe calling the
        operation which converts a string into a number std::to_number()
        would be more appropriate.<br>
        <br>
        Kind regards,<br>
        <br>
        Andy</div>
      -- <br>
      <br>
      --- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a moz-do-not-send="true"
        href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
      To post to this group, send email to <a moz-do-not-send="true"
        href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
      Visit this group at <a moz-do-not-send="true"
        href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
    </blockquote>
    <br>
  </body>
</html>

<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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--------------050503090408030208080403--

.

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

On Tue, Sep 30, 2014 at 3:03 PM, Miro Knejp <miro.knejp@gmail.com> wrote:

>  Then why not go the whole route and make it to_string/from_string and not
> limit it just to numbers?
>

`to_string` is not really an efficient interface to me.  Writing to an
output iterator
should be the generic interface for formatting individual objects to
strings.

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

--

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

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

<div dir=3D"ltr">On Tue, Sep 30, 2014 at 3:03 PM, Miro Knejp <span dir=3D"l=
tr">&lt;<a href=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro.knej=
p@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div class=3D"h5">
    Then why not go the whole route and make it to_string/from_string
    and not limit it just to numbers?<br></div></blockquote></div><br>`to_s=
tring` is not really an efficient interface to me.=C2=A0 Writing to an outp=
ut iterator<br></div><div class=3D"gmail_extra">should be the generic inter=
face for formatting individual objects to strings.<br clear=3D"all"></div><=
div class=3D"gmail_extra"><br>-- <br>Zhihao Yuan, ID lichray<br>The best wa=
y to predict the future is to invent it.<br>_______________________________=
____________________<br>4BSD -- <a href=3D"http://bit.ly/blog4bsd" target=
=3D"_blank">http://bit.ly/blog4bsd</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 />

--047d7b3a926456568d05044dc5d4--

.

------=_Part_829_1596922351.1412108110408
Content-Type: text/plain; charset=UTF-8

On Tuesday, September 30, 2014 3:56:28 PM UTC-4, Zhihao Yuan wrote:
>
> On Tue, Sep 30, 2014 at 3:03 PM, Miro Knejp <miro....@gmail.com
> <javascript:>> wrote:
>
>>  Then why not go the whole route and make it to_string/from_string and
>> not limit it just to numbers?
>>
>
> `to_string` is not really an efficient interface to me.  Writing to an
> output iterator
> should be the generic interface for formatting individual objects to
> strings.
>
>
I agree. I don't use this function very often at all. I usually wind up
doing an snprintf() into a buffer on the stack or something else.

Even with move semantics its not efficient to return a newly created string
because you are forced to allocate new memory for the returned object every
time.
Using an out parameter is better, similar to std::getline() because you can
reuse one string object for multiple conversions and only do the memory
allocation once. This issue has been discussed several times before at C++
talks and on blog posts.

Using a std::string& out parameter is still not good enough though because
you are forced to use a std::string as your destination buffer to store the
characters. Many times you don't want to use a std::string.

There are several common cases:

   - Fixed size character array (char[N], std::array<char,N>,
   std::array_view<char>, (char*, char*), (char*, size_t)) with truncate
   semantics, possibly which lives on on the stack
   - Dynamically growing buffer (std::string, std::vector<char>, user
   defined string class)
   - A container which pre-allocates a fixed size buffer on the stack and
   falls back to growing heap allocation after that.

Building an interface based on output iterators could allow for and
abstract all of these possibilities.

--

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

<div dir=3D"ltr">On Tuesday, September 30, 2014 3:56:28 PM UTC-4, Zhihao Yu=
an wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On T=
ue, Sep 30, 2014 at 3:03 PM, Miro Knejp <span dir=3D"ltr">&lt;<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"oRyfoSngdH4J" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">miro....@gmail.com</a>&gt;</span> wrote:<br><div><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div>
    Then why not go the whole route and make it to_string/from_string
    and not limit it just to numbers?<br></div></blockquote></div><br>`to_s=
tring` is not really an efficient interface to me.&nbsp; Writing to an outp=
ut iterator<br></div><div>should be the generic interface for formatting in=
dividual objects to strings.<br clear=3D"all"></div><div><br></div></div></=
blockquote><div><br>I agree. I don't use this function very often at all. I=
 usually wind up doing an snprintf() into a buffer on the stack or somethin=
g else.<br><br>Even with move semantics its not efficient to return a newly=
 created string because you are forced to allocate new memory for the retur=
ned object every time. <br>Using an out parameter is better, similar to std=
::getline() because you can reuse one string object for multiple conversion=
s and only do the memory allocation once. This issue has been discussed sev=
eral times before at C++ talks and on blog posts.<br><br>Using a std::strin=
g&amp; out parameter is still not good enough though because you are forced=
 to use a std::string as your destination buffer to store the characters. M=
any times you don't want to use a std::string.<br><br>There are several com=
mon cases:<br><ul><li>Fixed size character array (char[N], std::array&lt;ch=
ar,N&gt;, std::array_view&lt;char&gt;, (char*, char*), (char*, size_t)) wit=
h truncate semantics, possibly which lives on on the stack</li><li>Dynamica=
lly growing buffer (std::string, std::vector&lt;char&gt;, user defined stri=
ng class)</li><li>A container which pre-allocates a fixed size buffer on th=
e stack and falls back to growing heap allocation after that.<br></li></ul>=
Building an interface based on output iterators could allow for and abstrac=
t all of these possibilities.<br><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_829_1596922351.1412108110408--

.

Am 30.09.2014 um 22:15 schrieb Matthew Fioravante:
> Building an interface based on output iterators could allow for and
> abstract all of these possibilities.
>
The out iterator approach has been discussed a lot in the formatting
thread and it boiled down to character encodings and not having to
provide the entire implementation in header files and still keep it
efficient. At some point you have to start thinking about locale support
(in both directions).

--

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

.

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

On Tue, Sep 30, 2014 at 4:53 PM, Miro Knejp <miro.knejp@gmail.com> wrote:

>
> Am 30.09.2014 um 22:15 schrieb Matthew Fioravante:
>
>> Building an interface based on output iterators could allow for and
>> abstract all of these possibilities.
>>
>>  The out iterator approach has been discussed a lot in the formatting
> thread and it boiled down to character encodings and not having to provide
> the entire implementation in header files and still keep it efficient. At
> some point you have to start thinking about locale support (in both
> directions).
>

We can have two sets of overloads, one for locale-unaware, one
for locale-aware, and the later one converts the output iterator
into any_iterator for being used with non-inlined implementations.
To speed up some output iterators known by the library, like char*,
string::iterator, etc, we can bypassing such a conversion by
adding more overloads in an implementation.  It does not look like
a blocking issue to me.

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

--

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

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

<div dir=3D"ltr">On Tue, Sep 30, 2014 at 4:53 PM, Miro Knejp <span dir=3D"l=
tr">&lt;<a href=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro.knej=
p@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Am 30.09.2014 um 22:15 schrieb Matthew Fioravante:<span class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Building an interface based on output iterators could allow for and abstrac=
t all of these possibilities.<br>
<br>
</blockquote></span>
The out iterator approach has been discussed a lot in the formatting thread=
 and it boiled down to character encodings and not having to provide the en=
tire implementation in header files and still keep it efficient. At some po=
int you have to start thinking about locale support (in both directions).<b=
r></blockquote></div><br></div><div class=3D"gmail_extra">We can have two s=
ets of overloads, one for locale-unaware, one<br>for locale-aware, and the =
later one converts the output iterator<br>into any_iterator for being used =
with non-inlined implementations.<br>To speed up some output iterators know=
n by the library, like char*,<br>string::iterator, etc, we can bypassing su=
ch a conversion by<br>adding more overloads in an implementation.=C2=A0 It =
does not look like<br>a blocking issue to me.<br></div><div class=3D"gmail_=
extra"><br>-- <br>Zhihao Yuan, ID lichray<br>The best way to predict the fu=
ture is to invent it.<br>__________________________________________________=
_<br>4BSD -- <a href=3D"http://bit.ly/blog4bsd" target=3D"_blank">http://bi=
t.ly/blog4bsd</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 />

--089e013a1e1238947605044f8ac6--

.

On Tuesday 30 September 2014 12:25:34 Nevin Liber wrote:
> On 30 September 2014 10:47, Matthew Fioravante <fmatthew5876@gmail.com>
>
> wrote:
> > Now that we have string_view, it might be a good idea to have overloads of
> > atoX and strtoX which take string_view arguments.
>
> If you want to add something like this, please propose a templated function
> instead, as in
>
> template<typename N>
> N to_number(string_view str);
>
> That way it works with all the typedefs (such as uint32_t) for the numeric
> types.

Make that:

template <typename N>
optional<N> to_integral(string_view str, int base = 10,
 const char **endptr = nullptr);
template <typename N>
optional<N> to_floating_point(string_view str, const char **endptr = nullptr);

The conversion can fail and bases don't make sense for floating-point.

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

.

Am 01.10.2014 um 02:41 schrieb Thiago Macieira:
> On Tuesday 30 September 2014 12:25:34 Nevin Liber wrote:
>> On 30 September 2014 10:47, Matthew Fioravante <fmatthew5876@gmail.com>
>>
>> wrote:
>>> Now that we have string_view, it might be a good idea to have overloads=
 of
>>> atoX and strtoX which take string_view arguments.
>> If you want to add something like this, please propose a templated funct=
ion
>> instead, as in
>>
>> template<typename N>
>> N to_number(string_view str);
>>
>> That way it works with all the typedefs (such as uint32_t) for the numer=
ic
>> types.
> Make that:
>
> template <typename N>
> optional<N> to_integral(string_view str, int base =3D 10,
>  const char **endptr =3D nullptr);
> template <typename N>
> optional<N> to_floating_point(string_view str, const char **endptr =3D nu=
llptr);
>
> The conversion can fail and bases don't make sense for floating-point.
>
Actually, at least 16 does. With printf("%a") one can produce numbers in=20
the form [-]0xh.hhhp=B1d which is better suited as exact lossless=20
round-tripping representation.

--=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 Wednesday 01 October 2014 03:12:31 Miro Knejp wrote:
> Actually, at least 16 does. With printf("%a") one can produce numbers in=
=20
> the form [-]0xh.hhhp=B1d which is better suited as exact lossless=20
> round-tripping representation.

That's very uncommon. Whoever is doing that probably has specialised functi=
ons=20
anyway.

--=20
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

--=20

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

.

------=_Part_9_249947564.1412129620267
Content-Type: text/plain; charset=UTF-8



On Tuesday, September 30, 2014 8:41:50 PM UTC-4, Thiago Macieira wrote:
>
> template <typename N>
> optional<N> to_integral(string_view str, int base = 10,
>         const char **endptr = nullptr);
> template <typename N>
> optional<N> to_floating_point(string_view str, const char **endptr =
> nullptr);
>
> I have a few issues with optional:

   1. You lose the ability to check specific error conditions like ERANGE.
   I'm not sure how useful this is as I've never done an ERANGE check on a
   number parse but that functionality is available with the legacy functions.
   2. If you want to enable a throwing interface by just calling
   optional::value() and letting it throw on error, you'll be throwing a
   std::bad_optional_access. It would be better to throw an exception class
   which is more specifically related to parsing numbers and has information
   on what went wrong.

Also I think its better to use a string_view& for the tail instead of a
char**. The tail string itself is not null terminated so using a character
pointer with which we usually associate null termination is a big
misleading. Also converting the char** endptr back into a string_view is
clumsy and error prone as it will call strlen() on the non-null terminated
buffer unless the programmer carefully computes and specifies the new
length.

I'd also like to try to make the integer conversions constexpr so setting
errno is out.


> The conversion can fail and bases don't make sense for floating-point.
>
>
Bases don't make sense but parsing a hex float might.

--

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

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

<div dir=3D"ltr"><br><br>On Tuesday, September 30, 2014 8:41:50 PM UTC-4, T=
hiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">template =
&lt;typename N&gt;
<br>optional&lt;N&gt; to_integral(string_view str, int base =3D 10,=20
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;const char **endptr =3D=
 nullptr);
<br>template &lt;typename N&gt;
<br>optional&lt;N&gt; to_floating_point(string_view str, const char **endpt=
r =3D nullptr);
<br>
<br></blockquote><div>I have a few issues with optional:</div><div><ol><li>=
<span style=3D"font-size: 13px;">You lose the ability to check specific err=
or conditions like ERANGE. I'm not sure how useful this is as I've never do=
ne an ERANGE check on a number parse but that functionality is available wi=
th the legacy functions.</span><br></li><li><span style=3D"font-size: 13px;=
">If you want to enable a throwing interface by just calling optional::valu=
e() and letting it throw on error, you'll be throwing a std::bad_optional_a=
ccess. It would be better to throw an exception class which is more specifi=
cally related to parsing numbers and has information on what went wrong.&nb=
sp;</span></li></ol></div><div>Also I think its better to use a string_view=
&amp; for the tail instead of a char**. The tail string itself is not null =
terminated so using a character pointer with which we usually associate nul=
l termination is a big misleading. Also converting the char** endptr back i=
nto a string_view is clumsy and error prone as it will call strlen() on the=
 non-null terminated buffer unless the programmer carefully computes and sp=
ecifies the new length.</div><div><br></div><div>I'd also like to try to ma=
ke the integer conversions constexpr so setting errno is out.<br></div><div=
>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The conversion ca=
n fail and bases don't make sense for floating-point.
<br>
<br></blockquote><br><div>Bases don't make sense but parsing a hex float mi=
ght.</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_9_249947564.1412129620267--

.

------=_Part_1148_2105879641.1412130251630
Content-Type: text/plain; charset=UTF-8



On Tuesday, September 30, 2014 3:03:06 PM UTC-4, Miro Knejp wrote:
>
>  Then why not go the whole route and make it to_string/from_string and not
> limit it just to numbers?
>

Instead of from_string<T>, I like the name template <typename T>
string_to<T>, as it reads directly as "string to T" when invoked in the
code.

--

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

<div dir=3D"ltr"><br><br>On Tuesday, September 30, 2014 3:03:06 PM UTC-4, M=
iro Knejp wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    Then why not go the whole route and make it to_string/from_string
    and not limit it just to numbers?<br><span style=3D"font-size: 13px;"><=
/span></div></blockquote><div><br></div><div><span style=3D"font-size: 13px=
;">Instead of from_string&lt;T&gt;, I like the name template &lt;typename T=
&gt; string_to&lt;T&gt;, as it reads directly as "string to T" when invoked=
 in the code.</span><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_1148_2105879641.1412130251630--

.

------=_Part_4725_639648995.1412130402467
Content-Type: text/plain; charset=UTF-8

On Tuesday, September 30, 2014 11:13:40 PM UTC-3, Matthew Fioravante wrote:
>
> I have a few issues with optional:
>
>    1. You lose the ability to check specific error conditions like
>    ERANGE. I'm not sure how useful this is as I've never done an ERANGE check
>    on a number parse but that functionality is available with the legacy
>    functions.
>    2. If you want to enable a throwing interface by just calling
>    optional::value() and letting it throw on error, you'll be throwing a
>    std::bad_optional_access. It would be better to throw an exception class
>    which is more specifically related to parsing numbers and has information
>    on what went wrong.
>
> You can use expected instead of optional, if that gets accepted.

--

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

<div dir=3D"ltr">On Tuesday, September 30, 2014 11:13:40 PM UTC-3, Matthew =
Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>I have a few issues with optional:</div><div><ol><li><span style=
=3D"font-size:13px">You lose the ability to check specific error conditions=
 like ERANGE. I'm not sure how useful this is as I've never done an ERANGE =
check on a number parse but that functionality is available with the legacy=
 functions.</span><br></li><li><span style=3D"font-size:13px">If you want t=
o enable a throwing interface by just calling optional::value() and letting=
 it throw on error, you'll be throwing a std::bad_optional_access. It would=
 be better to throw an exception class which is more specifically related t=
o parsing numbers and has information on what went wrong.&nbsp;</span></li>=
</ol></div></div></blockquote><div>You can use expected instead of optional=
, if that gets accepted.<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_4725_639648995.1412130402467--

.

On Tuesday 30 September 2014 19:13:40 Matthew Fioravante wrote:
>    1. You lose the ability to check specific error conditions like ERANGE.
>    I'm not sure how useful this is as I've never done an ERANGE check on a
>    number parse but that functionality is available with the legacy
> functions.

I don't see how that relates to the optional. In fact, I don't see how you
came to this conclusion.

If the parsing failed, the function will return a disengaged optional and set
errno to ERANGE or EINVAL. If it worked, it will return an engaged optional
and errno is unspecified.

That's much better than strtoul, which returns zero when it fails and that's
undistinguishable from a successful parsing of a number zero.

> 2. If you want to enable a throwing interface by just calling
>    optional::value() and letting it throw on error, you'll be throwing a
>    std::bad_optional_access. It would be better to throw an exception class
>    which is more specifically related to parsing numbers and has information
> on what went wrong.

I again don't understand why that is a problem. What's stopping you from
throwing an exception if the returned optional is disengaged?

> Also I think its better to use a string_view& for the tail instead of a
> char**. The tail string itself is not null terminated so using a character
> pointer with which we usually associate null termination is a big
> misleading. Also converting the char** endptr back into a string_view is
> clumsy and error prone as it will call strlen() on the non-null terminated
> buffer unless the programmer carefully computes and specifies the new
> length.

Yeah, that makes sense. I was pondering that when I wrote the suggestion, but
didn't go through with it.

> I'd also like to try to make the integer conversions constexpr so setting
> errno is out.

Forget it. Non-inline functions can't be constexpr and those functions
shouldn't be inline.

At best, they could be an inline wrapper to the real parser, such as:

template <typename T> optional<T>
to_integral(string_view str, int base = 10, string_view *tail = nullptr)
{
 typedef typename conditional<is_unsigned<T>::value,
  unsigned long long, long long>::type U;
 U min = numeric_limits<T>::min();
 U max = numeric_limits<T>::max();
 optional<U> result =
  to_integral_helper(str, base, tail, min, max);
 return result ? optional<T>(result.value()) : optional<T>();
}

This will require two only out-of-line functions, one for long long (for
signed conversions) and one for unsigned long long (for unsigned ones).

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

.

------=_Part_4843_723143168.1412132242717
Content-Type: text/plain; charset=UTF-8



On Tuesday, September 30, 2014 10:40:50 PM UTC-4, Thiago Macieira wrote:
>
> On Tuesday 30 September 2014 19:13:40 Matthew Fioravante wrote:
> >    1. You lose the ability to check specific error conditions like
> ERANGE.
> >    I'm not sure how useful this is as I've never done an ERANGE check on
> a
> >    number parse but that functionality is available with the legacy
> > functions.
>
> I don't see how that relates to the optional. In fact, I don't see how you
> came to this conclusion.
>

Optional only gives you a boolean yes/no answer as to whether or not
parsing failed. You have to get the reason for failure using some other
mechanism.


>
> If the parsing failed, the function will return a disengaged optional and
> set
> errno to ERANGE or EINVAL. If it worked, it will return an engaged
> optional
> and errno is unspecified.
>

Are we sure we want to continue using global errno in new interfaces? Is
this still a good way to specify errors? Maybe its ok for checking return
codes, but definitely not for exceptions.

If the optional object throws an exception, and then during the unwinding
process something resets errno you lose the error information. The error
code must be embedded in the exception object itself.


>
> That's much better than strtoul, which returns zero when it fails and
> that's
> undistinguishable from a successful parsing of a number zero.
>

Agree completely. Trying to indicate an error by hijacking a valid value
such as 0, INT_MIN, INT_MAX, or anything else is a really terrible design.

>
> > 2. If you want to enable a throwing interface by just calling
> >    optional::value() and letting it throw on error, you'll be throwing a
> >    std::bad_optional_access. It would be better to throw an exception
> class
> >    which is more specifically related to parsing numbers and has
> information
> > on what went wrong.
>
> I again don't understand why that is a problem. What's stopping you from
> throwing an exception if the returned optional is disengaged?
>

Why impose the boilerplate of throwing onto the user? Isn't that one of the
things optional and expected are supposed to do for us? It would be better
if such an exception is baked into the interface, with error codes / error
messages already available.

try {
  auto x = string_to<int>(s);
  foo(x.value());
}
catch(std::range_error& e) { /* do something */ }
catch(std::invalid_argument& e) { /*do something else*/ }


Or like this:

try {
  auto x = string_to<int>(s);
  foo(x.value());
}
catch(std::system_error& e) {
  if(e.code() == ERANGE) { /* do something */ }
  else if(e.code() == EINVAL) { /* do something else */ }
}




>
> > Also I think its better to use a string_view& for the tail instead of a
> > char**. The tail string itself is not null terminated so using a
> character
> > pointer with which we usually associate null termination is a big
> > misleading. Also converting the char** endptr back into a string_view is
> > clumsy and error prone as it will call strlen() on the non-null
> terminated
> > buffer unless the programmer carefully computes and specifies the new
> > length.
>
> Yeah, that makes sense. I was pondering that when I wrote the suggestion,
> but
> didn't go through with it.
>
> > I'd also like to try to make the integer conversions constexpr so
> setting
> > errno is out.
>
> Forget it. Non-inline functions can't be constexpr and those functions
> shouldn't be inline.
>

I agree about the floating point conversions. But does it really have to be
this way for integer conversions? Parsing ints is not that complex.


>
> At best, they could be an inline wrapper to the real parser, such as:
>
> template <typename T> optional<T>
> to_integral(string_view str, int base = 10, string_view *tail = nullptr)
> {
>         typedef typename conditional<is_unsigned<T>::value,
>                 unsigned long long, long long>::type U;
>         U min = numeric_limits<T>::min();
>         U max = numeric_limits<T>::max();
>         optional<U> result =
>                 to_integral_helper(str, base, tail, min, max);
>         return result ? optional<T>(result.value()) : optional<T>();
> }
>
> This will require two only out-of-line functions, one for long long (for
> signed conversions) and one for unsigned long long (for unsigned ones).
>
> --
> 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/.

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

<div dir=3D"ltr"><br><br>On Tuesday, September 30, 2014 10:40:50 PM UTC-4, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesd=
ay 30 September 2014 19:13:40 Matthew Fioravante wrote:
<br>&gt; &nbsp; &nbsp;1. You lose the ability to check specific error condi=
tions like ERANGE.
<br>&gt; &nbsp; &nbsp;I'm not sure how useful this is as I've never done an=
 ERANGE check on a
<br>&gt; &nbsp; &nbsp;number parse but that functionality is available with=
 the legacy
<br>&gt; functions.=20
<br>
<br>I don't see how that relates to the optional. In fact, I don't see how =
you=20
<br>came to this conclusion.
<br></blockquote><div><br></div><div>Optional only gives you a boolean yes/=
no answer as to whether or not parsing failed. You have to get the reason f=
or failure using some other mechanism.</div><div>&nbsp;</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">
<br>If the parsing failed, the function will return a disengaged optional a=
nd set=20
<br>errno to ERANGE or EINVAL. If it worked, it will return an engaged opti=
onal=20
<br>and errno is unspecified.
<br></blockquote><div><br></div><div>Are we sure we want to continue using =
global errno in new interfaces? Is this still a good way to specify errors?=
 Maybe its ok for checking return codes, but definitely not for exceptions.=
</div><div><br></div><div>If the optional object throws an exception, and t=
hen during the unwinding process something resets errno you lose the error =
information. The error code must be embedded in the exception object itself=
..</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>That's much better than strtoul, which returns zero when it fails and t=
hat's=20
<br>undistinguishable from a successful parsing of a number zero.
<br></blockquote><div><br></div><div>Agree completely. Trying to indicate a=
n error by hijacking a valid value such as 0, INT_MIN, INT_MAX, or anything=
 else is a really terrible design.&nbsp;</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">
<br>&gt; 2. If you want to enable a throwing interface by just calling
<br>&gt; &nbsp; &nbsp;optional::value() and letting it throw on error, you'=
ll be throwing a
<br>&gt; &nbsp; &nbsp;std::bad_optional_access. It would be better to throw=
 an exception class
<br>&gt; &nbsp; &nbsp;which is more specifically related to parsing numbers=
 and has information
<br>&gt; on what went wrong.
<br>
<br>I again don't understand why that is a problem. What's stopping you fro=
m=20
<br>throwing an exception if the returned optional is disengaged?
<br></blockquote><div><br></div><div>Why impose the boilerplate of throwing=
 onto the user? Isn't that one of the things optional and expected are supp=
osed to do for us?&nbsp;<span style=3D"font-size: 13px;">It would be better=
 if such an exception is baked into the interface, with error codes / error=
 messages already available.</span></div><div><br></div><div><div class=3D"=
prettyprint" style=3D"background-color: rgb(250, 250, 250); border: 1px sol=
id rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">try</span><font color=3D"#666600"><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span></font><span style=3D"color: #000;" class=3D"styled-=
by-prettify">&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> string_to=
</span><font color=3D"#666600"><span style=3D"color: #080;" class=3D"styled=
-by-prettify">&lt;int&gt;</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; =
foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">value</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">());</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">catch</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">range_error</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> e</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">/* do something */</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">catch</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">invalid_argument</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> e</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">/*=
do something else*/</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp=
;</span></font></div></code></div><br>Or like this:</div><div><br></div><di=
v><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250);=
 border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">try</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> string_to</s=
pan><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">s</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; foo</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">x</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">value</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">());</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">catch</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">system_error</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> e</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">e</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">code</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> ERANGE</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">/* do something */</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">else</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">if</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">code</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D=3D</span><font color=3D"#000000">=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> EINVAL</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">/* do something else */</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">}</span></font></div></code></div><br><br></div><div>&nbsp;</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; Also I think its better to use a string_view&amp; for the tail ins=
tead of a
<br>&gt; char**. The tail string itself is not null terminated so using a c=
haracter
<br>&gt; pointer with which we usually associate null termination is a big
<br>&gt; misleading. Also converting the char** endptr back into a string_v=
iew is
<br>&gt; clumsy and error prone as it will call strlen() on the non-null te=
rminated
<br>&gt; buffer unless the programmer carefully computes and specifies the =
new
<br>&gt; length.
<br>
<br>Yeah, that makes sense. I was pondering that when I wrote the suggestio=
n, but=20
<br>didn't go through with it.
<br>
<br>&gt; I'd also like to try to make the integer conversions constexpr so =
setting
<br>&gt; errno is out.
<br>
<br>Forget it. Non-inline functions can't be constexpr and those functions=
=20
<br>shouldn't be inline.
<br></blockquote><div><br></div><div>I agree about the floating point conve=
rsions. But does it really have to be this way for integer conversions? Par=
sing ints is not that complex.</div><div>&nbsp;</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">
<br>At best, they could be an inline wrapper to the real parser, such as:
<br>
<br>template &lt;typename T&gt; optional&lt;T&gt;=20
<br>to_integral(string_view str, int base =3D 10, string_view *tail =3D nul=
lptr)
<br>{
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;typedef typename condit=
ional&lt;is_unsigned&lt;T&gt;::<wbr>value,
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;unsigned long long, long long&gt;::type U;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;U min =3D numeric_limit=
s&lt;T&gt;::min();
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;U max =3D numeric_limit=
s&lt;T&gt;::max();
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;optional&lt;U&gt; resul=
t =3D
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;to_integral_<wbr>helper(str, base, tail, min, max)=
;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return result ? optiona=
l&lt;T&gt;(result.value()) : optional&lt;T&gt;();
<br>}
<br>
<br>This will require two only out-of-line functions, one for long long (fo=
r=20
<br>signed conversions) and one for unsigned long long (for unsigned ones).
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></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_4843_723143168.1412132242717--

.

------=_Part_2181_2020946045.1412132812802
Content-Type: text/plain; charset=UTF-8



On Tuesday, September 30, 2014 10:57:22 PM UTC-4, Matthew Fioravante wrote:
>
>
>
> On Tuesday, September 30, 2014 10:40:50 PM UTC-4, Thiago Macieira wrote:
>>
>>
>> Forget it. Non-inline functions can't be constexpr and those functions
>> shouldn't be inline.
>>
>
> I agree about the floating point conversions. But does it really have to
> be this way for integer conversions? Parsing ints is not that complex.
>
>

One use case for constexpr is that it would enable these functions to be
used for creating user defined literals.

--

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

<div dir=3D"ltr"><br><br>On Tuesday, September 30, 2014 10:57:22 PM UTC-4, =
Matthew Fioravante wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><br><br>On Tuesday, September 30, 2014 10:40:50 PM UTC-4, Thiag=
o Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>Forget it. Non-inline functions can't be constexpr and those functions=
=20
<br>shouldn't be inline.
<br></blockquote><div><br></div><div>I agree about the floating point conve=
rsions. But does it really have to be this way for integer conversions? Par=
sing ints is not that complex.</div><div>&nbsp;</div></div></blockquote><di=
v><br></div><div>One use case for constexpr is that it would enable these f=
unctions to be used for creating user defined literals.&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_2181_2020946045.1412132812802--

.

On Tuesday 30 September 2014 19:57:22 Matthew Fioravante wrote:
> > I don't see how that relates to the optional. In fact, I don't see how you
> > came to this conclusion.
>
> Optional only gives you a boolean yes/no answer as to whether or not
> parsing failed. You have to get the reason for failure using some other
> mechanism.

Right, but:

> Are we sure we want to continue using global errno in new interfaces? Is
> this still a good way to specify errors? Maybe its ok for checking return
> codes, but definitely not for exceptions.

Why not? I don't see the problem with errno (which is actually thread-specific,
not global).

> If the optional object throws an exception, and then during the unwinding
> process something resets errno you lose the error information. The error
> code must be embedded in the exception object itself.

If something threw an exception, whether it was by consumption of the
disengaged optional or something else, the number conversion is long
forgotten. How useful is the "number out of range" information three frames up
the stack?

No, if there was a failure in converting, the code that may want to throw
needs to inspect errno and decide which meaningful exception it will throw.

> > > 2. If you want to enable a throwing interface by just calling
> > >
> > >    optional::value() and letting it throw on error, you'll be throwing a
> > >    std::bad_optional_access. It would be better to throw an exception
> >
> > class
> >
> > >    which is more specifically related to parsing numbers and has
> >
> > information
> >
> > > on what went wrong.
> >
> > I again don't understand why that is a problem. What's stopping you from
> > throwing an exception if the returned optional is disengaged?
>
> Why impose the boilerplate of throwing onto the user?

Simple: so that people who don't use exceptions can still use this function.

Despite the direction the standard committee wants to go in, practice is that
there are large and well-known C++ projects that don't use exceptions (see the
Google coding guidelines, applying to Chrome/Chromium, Blink, V8, the Mozilla
coding guidelines, Qt, etc.).

You can easily turn code that uses errno into one that throws in case of
failure, but you can't compile code reporting errors via exceptions with -fno-
exceptions and still report the errors.

> > Forget it. Non-inline functions can't be constexpr and those functions
> > shouldn't be inline.
>
> I agree about the floating point conversions. But does it really have to be
> this way for integer conversions? Parsing ints is not that complex.

It's not just about complexity. And yes, it is complex. Have you looked at the
source code for your strtoul?

And even if it weren't about the complexity, the point is that this is a
performance-critical function. It should be hand-tuned by the implementation
for most performance (given space availability), which may make use of
processor or compiler features that violate the rules of constexprness.

Another reason is code bloat: this function should not be inline, even if it
were constexpr'able. Converting non-literal strings to integers happens
everywhere, and we don't need the source for this function duplicated
everywhere, either via inlining or via out-of-line copies in each object file
and each shared library.

I think that trying to make them constexpr is optimising for the corner-case
to the detriment of the vast majority of the common-case.

> One use case for constexpr is that it would enable these functions to be
> used for creating user defined literals.

That's an extreme corner-case. If someone wants to do a UDL for ternary or
duodecimal, they can write the function for that by themselves. As I said,
let's optimise for the vast majority of the common case.

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

.

Am 01.10.2014 um 05:31 schrieb Thiago Macieira:
> Simple: so that people who don't use exceptions can still use this function.
>
> Despite the direction the standard committee wants to go in, practice is that
> there are large and well-known C++ projects that don't use exceptions (see the
> Google coding guidelines, applying to Chrome/Chromium, Blink, V8, the Mozilla
> coding guidelines, Qt, etc.).
>
> You can easily turn code that uses errno into one that throws in case of
> failure, but you can't compile code reporting errors via exceptions with -fno-
> exceptions and still report the errors.
As far as I remember the latest expected<> wasn't hardwired to
exceptions but templated on the type to hold in case of errors.

--

---
You received this message because you are subscribed to the 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_5322_1984937613.1412169728101
Content-Type: text/plain; charset=UTF-8



On Tuesday, September 30, 2014 11:31:40 PM UTC-4, Thiago Macieira wrote:
>
>
> > Are we sure we want to continue using global errno in new interfaces? Is
> > this still a good way to specify errors? Maybe its ok for checking
> return
> > codes, but definitely not for exceptions.
>
> Why not? I don't see the problem with errno (which is actually
> thread-specific,
> not global).
>

The alternative to errno is to use std::error_code and return it somehow
either via an out parameter, return value (using out param for the int), or
packaged as part of something like optional / expected / pair / tuple.

There are so many possibilities here. I have not yet figured out which one
is best.

error_code string_to(int& i, string_view& tail, string_view s);
int string_to(error_code& ec, string_view& tail, string_view s);
expected<int,error_code> string_to(string_view& tail, string_view s);

bool string_to(int& i, string_view& tail, string_view s); //sets errno on
failure
int string_to(string_view& tail, string_view s); //sets errno on failure
optional<int> string_to(string_view& tail, string_view s); //sets errno on
failure



> > If the optional object throws an exception, and then during the
> unwinding
> > process something resets errno you lose the error information. The error
> > code must be embedded in the exception object itself.
>
> If something threw an exception, whether it was by consumption of the
> disengaged optional or something else, the number conversion is long
> forgotten. How useful is the "number out of range" information three
> frames up
> the stack?
>

If my program crashes due to an uncaught exception, "Number of out range"
is a lot more useful to me than "disengaged optional".

The ERANGE may not be as useful three frames up in catch blocks, but a
parsing API which uses exceptions should throw something related to
parsing, not something generic. If we're returning something like optional
which can throw, then we are already introducing exceptions into the entire
API as a whole and at that point we must spend some effort to provide a
quality throwing interface. The return type optional is part of the API.
It's behavior must be considered as an essential part of the whole package.

>
> No, if there was a failure in converting, the code that may want to throw
> needs to inspect errno and decide which meaningful exception it will
> throw.
>
> At least by default throwing something like std::conversion_error or
std::system_error with ERANGE error_code embedded into it would be a great
improvement over std::bad_optional_access. These small changes make the
interface a little bit easier to use and more expressive for free. They
also make debugging (my uncaught exception example above) easier. The user
can still inspect the error code manually and choose to throw something
else if they want.

>
> > Why impose the boilerplate of throwing onto the user?
>
> Simple: so that people who don't use exceptions can still use this
> function.
>
> Despite the direction the standard committee wants to go in, practice is
> that
> there are large and well-known C++ projects that don't use exceptions (see
> the
> Google coding guidelines, applying to Chrome/Chromium, Blink, V8, the
> Mozilla
> coding guidelines, Qt, etc.).
>
> You can easily turn code that uses errno into one that throws in case of
> failure, but you can't compile code reporting errors via exceptions with
> -fno-
> exceptions and still report the errors.
>

This is the beauty of optional and expected. It makes exception handling
optional. I'm aware of many projects who decide not to use exception
handling for different reasons. I have a few of my own.

If you use something like std::expected and always check for errors before
retrieving the value, it will never throw and even better all of the
exception throwing logic can be optimized away. You should be able to use
it in any project with -fno-exceptions. A compiler could even generate a
warning if there exists a code path which might make optional/expected
throw when -fno-exceptions is enabled. This essentially makes the compiler
check that you handled all of the possible errors. For projects which do
want to use exceptions, you get them for free and don't have to write the
throwing code yourself unless you don't like the exceptions provided by the
library.

>
> I think that trying to make them constexpr is optimising for the
> corner-case
> to the detriment of the vast majority of the common-case.
>

We can drop constexpr. If later someone decides its good to have they can
always write a followup proposal.

--

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

<div dir=3D"ltr"><br><br>On Tuesday, September 30, 2014 11:31:40 PM UTC-4, =
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>&gt;=
 Are we sure we want to continue using global errno in new interfaces? Is
<br>&gt; this still a good way to specify errors? Maybe its ok for checking=
 return
<br>&gt; codes, but definitely not for exceptions.
<br>
<br>Why not? I don't see the problem with errno (which is actually thread-s=
pecific,=20
<br>not global).
<br></blockquote><div><br></div><div>The alternative to errno is to use std=
::error_code and return it somehow either via an out parameter, return valu=
e (using out param for the int), or packaged as part of something like opti=
onal / expected / pair / tuple.&nbsp;</div><div><br></div><div>There are so=
 many possibilities here. I have not yet figured out which one is best.</di=
v><div><br></div><div><div class=3D"prettyprint" style=3D"background-color:=
 rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break=
-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">error_code string_to</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> string_view</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> tail</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> string_view s</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> string_to</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">error_code</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> ec</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> string_view</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> tail</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> string_view s</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>expected</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">int</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">error_co=
de</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> string_to</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">string_view</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> tail</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> string_view s</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> string_to</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><font color=3D"#000000"><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> string_view</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> tail</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> string=
_view s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">//sets errno on fail=
ure</span></font><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> string_to</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">string_view</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> tail</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> string_view s</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">//sets errno on failure</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br>optional</span><span style=3D"colo=
r: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> string_to</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">string_view</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> tail</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> string_view s</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span><font color=3D"#880000"><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">//sets errno on failure</span></font></div></code=
></div><br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; If the optional object throws an exception, and then during the un=
winding
<br>&gt; process something resets errno you lose the error information. The=
 error
<br>&gt; code must be embedded in the exception object itself.
<br>
<br>If something threw an exception, whether it was by consumption of the=
=20
<br>disengaged optional or something else, the number conversion is long=20
<br>forgotten. How useful is the "number out of range" information three fr=
ames up=20
<br>the stack?
<br></blockquote><div><br></div><div>If my program crashes due to an uncaug=
ht exception, "Number of out range" is a lot more useful to me than "diseng=
aged optional".&nbsp;</div><div><br></div><div>The ERANGE may not be as use=
ful three frames up in catch blocks, but a parsing API which uses exception=
s should throw something related to parsing, not something generic. If we'r=
e returning something like optional which can throw, then we are already in=
troducing exceptions into the entire API as a whole and at that point we mu=
st spend some effort to provide a quality throwing interface. The return ty=
pe optional is part of the API. It's behavior must be considered as an esse=
ntial part of the whole package.</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">
<br>No, if there was a failure in converting, the code that may want to thr=
ow=20
<br>needs to inspect errno and decide which meaningful exception it will th=
row.
<br>
<br></blockquote><div>At least by default throwing something like std::conv=
ersion_error or std::system_error with ERANGE error_code embedded into it w=
ould be a great improvement over std::bad_optional_access. These small chan=
ges make the interface a little bit easier to use and more expressive for f=
ree. They also make debugging (my uncaught exception example above) easier.=
 The user can still inspect the error code manually and choose to throw som=
ething else if they want.</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><br>&gt; Why impose the boilerplate of throwing onto the user?=20
<br>
<br>Simple: so that people who don't use exceptions can still use this func=
tion.
<br>
<br>Despite the direction the standard committee wants to go in, practice i=
s that=20
<br>there are large and well-known C++ projects that don't use exceptions (=
see the=20
<br>Google coding guidelines, applying to Chrome/Chromium, Blink, V8, the M=
ozilla=20
<br>coding guidelines, Qt, etc.).
<br>
<br>You can easily turn code that uses errno into one that throws in case o=
f=20
<br>failure, but you can't compile code reporting errors via exceptions wit=
h -fno-
<br>exceptions and still report the errors.
<br></blockquote><div><br></div><div><span style=3D"font-size: 13px;">This =
is the beauty of optional and expected. It makes exception handling optiona=
l. I'm aware of many projects who decide not to use exception handling for =
different reasons. I have a few of my own.</span></div><div><br></div><div>=
If you use something like std::expected and always check for errors before =
retrieving the value, it will never throw and even better all of the except=
ion throwing logic can be optimized away. You should be able to use it in a=
ny project with -fno-exceptions. A compiler could even generate a warning i=
f there exists a code path which might make optional/expected throw when -f=
no-exceptions is enabled. This essentially makes the compiler check that yo=
u handled all of the possible errors. For projects which do want to use exc=
eptions, you get them for free and don't have to write the throwing code yo=
urself unless you don't like the exceptions provided by the library.</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><br>I think that trying to make=
 them constexpr is optimising for the corner-case=20
<br>to the detriment of the vast majority of the common-case.
<br></blockquote><div><br></div><div>We can drop constexpr. If later someon=
e decides its good to have they can always write a followup proposal.</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_5322_1984937613.1412169728101--

.

On 2014-09-30 22:12, Thiago Macieira wrote:
> On Wednesday 01 October 2014 03:12:31 Miro Knejp wrote:
>> Actually, at least 16 does. With printf("%a") one can produce numbers in=
=20
>> the form [-]0xh.hhhp=C2=B1d which is better suited as exact lossless=20
>> round-tripping representation.
>=20
> That's very uncommon. Whoever is doing that probably has specialised func=
tions=20
> anyway.

Of course they are... because there *are* no standard functions (that
I'm aware of) to convert base-16 floating point strings back into
numbers. Therefore they don't have a choice.

I would also use / like to see this.

--=20
Matthew

--=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_549_1351812405.1412176859995
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wednesday, October 1, 2014 11:19:41 AM UTC-4, Matthew Woehlke wrote:
>
> On 2014-09-30 22:12, Thiago Macieira wrote:=20
> > On Wednesday 01 October 2014 03:12:31 Miro Knejp wrote:=20
> >> Actually, at least 16 does. With printf("%a") one can produce numbers=
=20
> in=20
> >> the form [-]0xh.hhhp=C2=B1d which is better suited as exact lossless=
=20
> >> round-tripping representation.=20
> >=20
> > That's very uncommon. Whoever is doing that probably has specialised=20
> functions=20
> > anyway.=20
>
> Of course they are... because there *are* no standard functions (that=20
> I'm aware of) to convert base-16 floating point strings back into=20
> numbers. Therefore they don't have a choice.=20
>
> I would also use / like to see this.=20
>

I am in this camp as well. Hex float parsing should be supported with the=
=20
new string_to functions.

--=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_549_1351812405.1412176859995
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, October 1, 2014 11:19:41 AM UTC-4, M=
atthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-0=
9-30 22:12, Thiago Macieira wrote:
<br>&gt; On Wednesday 01 October 2014 03:12:31 Miro Knejp wrote:
<br>&gt;&gt; Actually, at least 16 does. With printf("%a") one can produce =
numbers in=20
<br>&gt;&gt; the form [-]0xh.hhhp=C2=B1d which is better suited as exact lo=
ssless=20
<br>&gt;&gt; round-tripping representation.
<br>&gt;=20
<br>&gt; That's very uncommon. Whoever is doing that probably has specialis=
ed functions=20
<br>&gt; anyway.
<br>
<br>Of course they are... because there *are* no standard functions (that
<br>I'm aware of) to convert base-16 floating point strings back into
<br>numbers. Therefore they don't have a choice.
<br>
<br>I would also use / like to see this.
<br></blockquote><div><br>I am in this camp as well. Hex float parsing shou=
ld be supported with the new string_to functions.<br></div><br></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_549_1351812405.1412176859995--

.

On Wednesday 01 October 2014 06:22:08 Matthew Fioravante wrote:
> > Why not? I don't see the problem with errno (which is actually
> > thread-specific,
> > not global).
>
> The alternative to errno is to use std::error_code and return it somehow
> either via an out parameter, return value (using out param for the int), or
> packaged as part of something like optional / expected / pair / tuple.

Does this std::error_code exist already? If it doesn't exist, please don't
create it. Everyone and their mom already knows about errno codes and there
are entire operating systems based around them. Inventing a new error list
sounds counter-productive.

Though I think that having a class enum so we can properly separate errors
from other uses of integers would be nice. Just as long as the error codes
remain 1:1 with errno.

> error_code string_to(int& i, string_view& tail, string_view s);
> int string_to(error_code& ec, string_view& tail, string_view s);
> expected<int,error_code> string_to(string_view& tail, string_view s);
>
> bool string_to(int& i, string_view& tail, string_view s); //sets errno on
> failure
> int string_to(string_view& tail, string_view s); //sets errno on failure
> optional<int> string_to(string_view& tail, string_view s); //sets errno on
> failure

The tail should be optional. Therefore, it can't be a reference. All those
options are out in my book.

> > If something threw an exception, whether it was by consumption of the
> > disengaged optional or something else, the number conversion is long
> > forgotten. How useful is the "number out of range" information three
> > frames up
> > the stack?
>
> If my program crashes due to an uncaught exception, "Number of out range"
> is a lot more useful to me than "disengaged optional".

That assumes that you did not attempt to correct the error. That is, your code
has a bug: either you did not validate your input prior to the parsing or you
failed to handle the parser errors.

I was thinking of normal error conditions, when you did catch the possible
errors and report them properly. If the input is allowed to fail parsing to
integral value, then you need to report that in the right way to your caller.

> The ERANGE may not be as useful three frames up in catch blocks, but a
> parsing API which uses exceptions should throw something related to
> parsing, not something generic. If we're returning something like optional
> which can throw, then we are already introducing exceptions into the entire
> API as a whole and at that point we must spend some effort to provide a
> quality throwing interface. The return type optional is part of the API.
> It's behavior must be considered as an essential part of the whole package.

Agreed, but see what I wrote above: if your code can reasonably be expected to
fail the parsing, you should check whether it succeeded before proceeding
further. If you find out it failed parsing, then you throw your appropriate
exception.

Don't depend on to_integral doing your job for you. The exceptions it throws
and the conditions it finds may not match your API's requirements.

> > > Why impose the boilerplate of throwing onto the user?
> >
> > Simple: so that people who don't use exceptions can still use this
> > function.
> >
> > Despite the direction the standard committee wants to go in, practice is
> > that
> > there are large and well-known C++ projects that don't use exceptions (see
> > the
> > Google coding guidelines, applying to Chrome/Chromium, Blink, V8, the
> > Mozilla
> > coding guidelines, Qt, etc.).
> >
> > You can easily turn code that uses errno into one that throws in case of
> > failure, but you can't compile code reporting errors via exceptions with
> > -fno-
> > exceptions and still report the errors.
>
> This is the beauty of optional and expected. It makes exception handling
> optional. I'm aware of many projects who decide not to use exception
> handling for different reasons. I have a few of my own.

I was not aware of expected. If it solves both problems, then let's use it.

--
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 Wednesday 01 October 2014 05:48:04 Miro Knejp wrote:
> Am 01.10.2014 um 05:31 schrieb Thiago Macieira:
> > Simple: so that people who don't use exceptions can still use this
> > function.
> >
> > Despite the direction the standard committee wants to go in, practice is
> > that there are large and well-known C++ projects that don't use
> > exceptions (see the Google coding guidelines, applying to
> > Chrome/Chromium, Blink, V8, the Mozilla coding guidelines, Qt, etc.).
> >
> > You can easily turn code that uses errno into one that throws in case of
> > failure, but you can't compile code reporting errors via exceptions with
> > -fno- exceptions and still report the errors.
>
> As far as I remember the latest expected<> wasn't hardwired to
> exceptions but templated on the type to hold in case of errors.

How is that different from std::optional?
--
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/.

.

Le 01/10/2014 17:28, Thiago Macieira a =E9crit :
> On Wednesday 01 October 2014 06:22:08 Matthew Fioravante wrote:
>>> Why not? I don't see the problem with errno (which is actually
>>> thread-specific,
>>> not global).
>> The alternative to errno is to use std::error_code and return it somehow
>> either via an out parameter, return value (using out param for the int),=
 or
>> packaged as part of something like optional / expected / pair / tuple.
> Does this std::error_code exist already? If it doesn't exist, please don'=
t
> create it. Everyone and their mom already knows about errno codes and the=
re
> are entire operating systems based around them. Inventing a new error lis=
t
> sounds counter-productive.
>
> Though I think that having a class enum so we can properly separate error=
s
> from other uses of integers would be nice. Just as long as the error code=
s
> remain 1:1 with errno.
You might want to read the five articles about it :=20
http://blog.think-async.com/2010/04/system-error-support-in-c0x-part-1.html


--=20

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

.

On 01 Oct 2014, at 17:16 , Thiago Macieira <thiago@macieira.org> wrote:

> On Wednesday 01 October 2014 05:48:04 Miro Knejp wrote:
>> Am 01.10.2014 um 05:31 schrieb Thiago Macieira:
>>> Simple: so that people who don't use exceptions can still use this
>>> function.
>>>
>>> Despite the direction the standard committee wants to go in, practice is
>>> that there are large and well-known C++ projects that don't use
>>> exceptions (see the Google coding guidelines, applying to
>>> Chrome/Chromium, Blink, V8, the Mozilla coding guidelines, Qt, etc.).
>>>
>>> You can easily turn code that uses errno into one that throws in case of
>>> failure, but you can't compile code reporting errors via exceptions with
>>> -fno- exceptions and still report the errors.
>>
>> As far as I remember the latest expected<> wasn't hardwired to
>> exceptions but templated on the type to hold in case of errors.
>
> How is that different from std::optional?

optional<T> either has a value of type T or it doesn't have anything.
expected<T, E> either has a value of type T or a value of type E to describe why the former isn't there (and it happens that E defaults to std::exception_ptr).

Maybe the details have changed again, I don't remember how long it's been that I read a proposal/draft/whatever.


--

---
You received this message because you are subscribed to the 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_312_1018908430.1412178106817
Content-Type: text/plain; charset=UTF-8



On Wednesday, October 1, 2014 11:30:10 AM UTC-4, Thiago Macieira wrote:
>
> On Wednesday 01 October 2014 06:22:08 Matthew Fioravante wrote:
> > > Why not? I don't see the problem with errno (which is actually
> > > thread-specific,
> > > not global).
> >
> > The alternative to errno is to use std::error_code and return it somehow
> > either via an out parameter, return value (using out param for the int),
> or
> > packaged as part of something like optional / expected / pair / tuple.
>
> Does this std::error_code exist already?


Its part of C++11 <system_error>


> Though I think that having a class enum so we can properly separate errors
> from other uses of integers would be nice. Just as long as the error codes
> remain 1:1 with errno.
>

Something like this would work fine too. Also if its an enum with only the
error tags which are possible, then the set of possible errors to check is
enforced by the type system. For example you can get a compiler warning if
you don't check them all in a switch statement.


>
> > error_code string_to(int& i, string_view& tail, string_view s);
> > int string_to(error_code& ec, string_view& tail, string_view s);
> > expected<int,error_code> string_to(string_view& tail, string_view s);
> >
> > bool string_to(int& i, string_view& tail, string_view s); //sets errno
> on
> > failure
> > int string_to(string_view& tail, string_view s); //sets errno on failure
> > optional<int> string_to(string_view& tail, string_view s); //sets errno
> on
> > failure
>
> The tail should be optional. Therefore, it can't be a reference. All those
> options are out in my book.
>

That's very easy to do with additional overloads:

int string_to<int>(string_view& tail, string_view s);
int string_to<int>(string_view s) { string_view tail; return string_to<int>(
tail, s); }



> > > If something threw an exception, whether it was by consumption of the
> > > disengaged optional or something else, the number conversion is long
> > > forgotten. How useful is the "number out of range" information three
> > > frames up
> > > the stack?
> >
> > If my program crashes due to an uncaught exception, "Number of out
> range"
> > is a lot more useful to me than "disengaged optional".
>
> That assumes that you did not attempt to correct the error. That is, your
> code
> has a bug: either you did not validate your input prior to the parsing or
> you
> failed to handle the parser errors.
>

Exactly, and it would be nice if the system would help me debug and fix
these bugs when they occur.


>
> I was thinking of normal error conditions, when you did catch the possible
> errors and report them properly. If the input is allowed to fail parsing
> to
> integral value, then you need to report that in the right way to your
> caller.
>

A reasonable default is not a bad thing and we're already accepting a
default exception policy if we adopt optional or expected. The user can
always check and throw their own exceptions specific to their API if needed.

--

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

<div dir=3D"ltr"><br><br>On Wednesday, October 1, 2014 11:30:10 AM UTC-4, T=
hiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wednes=
day 01 October 2014 06:22:08 Matthew Fioravante wrote:
<br>&gt; &gt; Why not? I don't see the problem with errno (which is actuall=
y
<br>&gt; &gt; thread-specific,
<br>&gt; &gt; not global).
<br>&gt;=20
<br>&gt; The alternative to errno is to use std::error_code and return it s=
omehow
<br>&gt; either via an out parameter, return value (using out param for the=
 int), or
<br>&gt; packaged as part of something like optional / expected / pair / tu=
ple.
<br>
<br>Does this std::error_code exist already?</blockquote><div><br>Its part =
of C++11 &lt;system_error&gt;<br><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">
<br>Though I think that having a class enum so we can properly separate err=
ors=20
<br>from other uses of integers would be nice. Just as long as the error co=
des=20
<br>remain 1:1 with errno.
<br></blockquote><div><br>Something like this would work fine too. Also if =
its an enum with only the error tags which are possible, then the set of po=
ssible errors to check is enforced by the type system. For example you can =
get a compiler warning if you don't check them all in a switch statement.<b=
r>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; error_code string_to(int&amp; i, string_view&amp; tail, string_vie=
w s);
<br>&gt; int string_to(error_code&amp; ec, string_view&amp; tail, string_vi=
ew s);
<br>&gt; expected&lt;int,error_code&gt; string_to(string_view&amp; tail, st=
ring_view s);
<br>&gt;=20
<br>&gt; bool string_to(int&amp; i, string_view&amp; tail, string_view s); =
//sets errno on
<br>&gt; failure
<br>&gt; int string_to(string_view&amp; tail, string_view s); //sets errno =
on failure
<br>&gt; optional&lt;int&gt; string_to(string_view&amp; tail, string_view s=
); //sets errno on
<br>&gt; failure
<br>
<br>The tail should be optional. Therefore, it can't be a reference. All th=
ose=20
<br>options are out in my book.
<br></blockquote><div><br>That's very easy to do with additional overloads:=
<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,=
 250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">int<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> string_to<=
/span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">string_view</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> tail</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> string_view s</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> string_to</span><span style=3D"color: #080;" class=3D=
"styled-by-prettify">&lt;int&gt;</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">string_view s</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> string_v=
iew tail</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> string_to</span><span s=
tyle=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">tail</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> s</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span></div></code></div><br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">
<br>&gt; &gt; If something threw an exception, whether it was by consumptio=
n of the
<br>&gt; &gt; disengaged optional or something else, the number conversion =
is long
<br>&gt; &gt; forgotten. How useful is the "number out of range" informatio=
n three
<br>&gt; &gt; frames up
<br>&gt; &gt; the stack?
<br>&gt;=20
<br>&gt; If my program crashes due to an uncaught exception, "Number of out=
 range"
<br>&gt; is a lot more useful to me than "disengaged optional".
<br>
<br>That assumes that you did not attempt to correct the error. That is, yo=
ur code=20
<br>has a bug: either you did not validate your input prior to the parsing =
or you=20
<br>failed to handle the parser errors.
<br></blockquote><div><br>Exactly, and it would be nice if the system would=
 help me debug and fix these bugs when they occur.<br>&nbsp;<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">
<br>I was thinking of normal error conditions, when you did catch the possi=
ble=20
<br>errors and report them properly. If the input is allowed to fail parsin=
g to=20
<br>integral value, then you need to report that in the right way to your c=
aller.
<br></blockquote><div><br>A reasonable default is not a bad thing and we're=
 already accepting a default exception policy if we adopt optional or expec=
ted. The user can always check and throw their own exceptions specific to t=
heir API if needed.<br><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_312_1018908430.1412178106817--

.

------=_Part_5518_1405464111.1412178845886
Content-Type: text/plain; charset=UTF-8



On Wednesday, October 1, 2014 11:36:50 AM UTC-4, Miro Knejp wrote:

>
> optional<T> either has a value of type T or it doesn't have anything.
> expected<T, E> either has a value of type T or a value of type E to
> describe why the former isn't there (and it happens that E defaults to
> std::exception_ptr).
>
> Maybe the details have changed again, I don't remember how long it's been
> that I read a proposal/draft/whatever.
>
>
This is the biggest problem I have with using expected. Its not finished
yet and I don't know what it will look like when done, or if it will even
be accepted. I also don't know what the performance implications will be.
Its difficult to write a new proposal based on such shaky foundations.

I'd also like to see the object thrown not necessarily be the same as the
error state. An exception object has a vtable and possibly other cruft. Why
do we need to return all of those bytes?

Something like this might be better:

template <typename T, typename Error, typename Exception>
struct expected {
  public:
  T& value() { if(has_error()) throw Exception(_error); return _val;}
  T value_or(T def) return has_error() ? def : _val; }

  //...

private:
  T _val;
  Error _err;
};


class conversion_error : public exception {};

template <typename T> using stoiret = expected<T,error_code,conversion_error
>;

template <typename T>
stoiret<T> string_to(string_view& tail, string_view s);

Of course inventing a whole new expected / optional like thing just for
these conversion functions is pretty heavy weight. Sticking to bools and
error_codes as return values / out parameters side steps this whole
question but may result in a more primitive interface.

--

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

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

<div dir=3D"ltr"><br><br>On Wednesday, October 1, 2014 11:36:50 AM UTC-4, M=
iro Knejp wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>optional&lt;T&gt; either has a value of type T or it doesn't have anyth=
ing.
<br>expected&lt;T, E&gt; either has a value of type T or a value of type E =
to describe why the former isn't there (and it happens that E defaults to s=
td::exception_ptr).
<br>
<br>Maybe the details have changed again, I don't remember how long it's be=
en that I read a proposal/draft/whatever.
<br>
<br></blockquote><div><br>This is the biggest problem I have with using exp=
ected. Its not finished yet and I don't know what it will look like when do=
ne, or if it will even be accepted. I also don't know what the performance =
implications will be. Its difficult to write a new proposal based on such s=
haky foundations.<br><br>I'd also like to see the object thrown not necessa=
rily be the same as the error state. An exception object has a vtable and p=
ossibly other cruft. Why do we need to return all of those bytes? <br><br>S=
omething like this might be better:<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">template</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">Error</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Exception</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> expected </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">public<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; T</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> value</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">if</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ha=
s_error</span><span style=3D"color: #660;" class=3D"styled-by-prettify">())=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">throw</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Exception</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">_error</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> _val</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; T value_or</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">def</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> has_error</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">?</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">d=
ef</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> _val</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br><br>&nbsp; </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">//...</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">private</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>&nbsp; T _val</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>&nbsp; </span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">Error</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
_err</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> conversion_error </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">public</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> exception </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">template</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">using</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> stoiret </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> expected</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">error_code</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">conversion_error</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&gt;;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">template</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typ=
ename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>stoiret</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> string_to</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">string_view</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> tail</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> string_view s</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span></div></code></div><br>Of course inventing a whole new exp=
ected / optional like thing just for these conversion functions is pretty h=
eavy weight. Sticking to bools and error_codes as return values / out param=
eters side steps this whole question but may result in a more primitive int=
erface.<br><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_5518_1405464111.1412178845886--

.

--Apple-Mail=_DA2DFA89-84AB-4DBD-9C3A-757F67CBDCC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 01 Oct 2014, at 17:54 , Matthew Fioravante <fmatthew5876@gmail.com> wrot=
e:

>=20
>=20
> On Wednesday, October 1, 2014 11:36:50 AM UTC-4, Miro Knejp wrote:
>=20
> optional<T> either has a value of type T or it doesn't have anything.=20
> expected<T, E> either has a value of type T or a value of type E to descr=
ibe why the former isn't there (and it happens that E defaults to std::exce=
ption_ptr).=20
>=20
> Maybe the details have changed again, I don't remember how long it's been=
 that I read a proposal/draft/whatever.=20
>=20
>=20
> This is the biggest problem I have with using expected. Its not finished =
yet and I don't know what it will look like when done, or if it will even b=
e accepted. I also don't know what the performance implications will be. It=
s difficult to write a new proposal based on such shaky foundations.
>=20
> I'd also like to see the object thrown not necessarily be the same as the=
 error state. An exception object has a vtable and possibly other cruft. Wh=
y do we need to return all of those bytes?=20
>=20
> Something like this might be better:
>=20
> template <typename T, typename Error, typename Exception>
> struct expected {
>   public:
>   T& value() { if(has_error()) throw Exception(_error); return _val;}
>   T value_or(T def) return has_error() ? def : _val; }
>=20
>   //...
>=20
> private:
>   T _val;
>   Error _err;
> };
>=20
>=20
> class conversion_error : public exception {};
>=20
> template <typename T> using stoiret =3D expected<T,error_code,conversion_=
error>;
>=20
> template <typename T>
> stoiret<T> string_to(string_view& tail, string_view s);
>=20
> Of course inventing a whole new expected / optional like thing just for t=
hese conversion functions is pretty heavy weight. Sticking to bools and err=
or_codes as return values / out parameters side steps this whole question b=
ut may result in a more primitive interface.
>=20
It's at least 3 years to the next standard, so no need to speedrun this.

In terms of performance: expected<int, std::error_code> has basically exact=
ly the same layout as your example + one bool (_val and _err even share spa=
ce in a union) and it's up to the user what to do with the error_code. opti=
onal<T> doesn't tell you what went wrong at all. You could write your own t=
hin wrapper that throws it on error etc. It's certainly easier to add excep=
tions to an exception-free design than the reverse.

My suggestion is to *carefully anticipate* the existence of expected and op=
tional in 3 years. If it turns out not to be the case halfway down the road=
 one can still design a helper type for the return values.

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

--Apple-Mail=_DA2DFA89-84AB-4DBD-9C3A-757F67CBDCC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dus-ascii"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode=
: space; -webkit-line-break: after-white-space;"><br><div><div>On 01 Oct 20=
14, at 17:54 , Matthew Fioravante &lt;<a href=3D"mailto:fmatthew5876@gmail.=
com">fmatthew5876@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-intercha=
nge-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><br><br>On Wednesda=
y, October 1, 2014 11:36:50 AM UTC-4, Miro Knejp wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">
<br>optional&lt;T&gt; either has a value of type T or it doesn't have anyth=
ing.
<br>expected&lt;T, E&gt; either has a value of type T or a value of type E =
to describe why the former isn't there (and it happens that E defaults to s=
td::exception_ptr).
<br>
<br>Maybe the details have changed again, I don't remember how long it's be=
en that I read a proposal/draft/whatever.
<br>
<br></blockquote><div><br>This is the biggest problem I have with using exp=
ected. Its not finished yet and I don't know what it will look like when do=
ne, or if it will even be accepted. I also don't know what the performance =
implications will be. Its difficult to write a new proposal based on such s=
haky foundations.<br><br>I'd also like to see the object thrown not necessa=
rily be the same as the error state. An exception object has a vtable and p=
ossibly other cruft. Why do we need to return all of those bytes? <br><br>S=
omething like this might be better:<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>template</span> <span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typena=
me</span> T<span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n> <span style=3D"color: #008;" class=3D"styled-by-prettify">typename</span=
> <span style=3D"color: #606;" class=3D"styled-by-prettify">Error</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">,</span> <span style=
=3D"color: #008;" class=3D"styled-by-prettify">typename</span> <span style=
=3D"color: #606;" class=3D"styled-by-prettify">Exception</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><br><span style=
=3D"color: #008;" class=3D"styled-by-prettify">struct</span> expected <span=
 style=3D"color: #660;" class=3D"styled-by-prettify">{</span><br>&nbsp; <sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">public</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">:</span><br>&nbsp; T<spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span> value<sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">()</span> <span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span> <span style=3D"col=
or: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span>has_error<span style=3D"color: #660=
;" class=3D"styled-by-prettify">())</span> <span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">throw</span> <span style=3D"color: #606;" class=
=3D"styled-by-prettify">Exception</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span>_error<span style=3D"color: #660;" class=3D=
"styled-by-prettify">);</span> <span style=3D"color: #008;" class=3D"styled=
-by-prettify">return</span> _val<span style=3D"color: #660;" class=3D"style=
d-by-prettify">;}</span><br>&nbsp; T value_or<span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span>T <span style=3D"color: #008;" class=3D=
"styled-by-prettify">def</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">)</span> <span style=3D"color: #008;" class=3D"styled-by-pret=
tify">return</span> has_error<span style=3D"color: #660;" class=3D"styled-b=
y-prettify">()</span> <span style=3D"color: #660;" class=3D"styled-by-prett=
ify">?</span> <span style=3D"color: #008;" class=3D"styled-by-prettify">def=
</span> <span style=3D"color: #660;" class=3D"styled-by-prettify">:</span> =
_val<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span> <spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">}</span><br><br>&nbsp=
; <span style=3D"color: #800;" class=3D"styled-by-prettify">//...</span><br=
><br><span style=3D"color: #008;" class=3D"styled-by-prettify">private</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><br>&nb=
sp; T _val<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><br>&nbsp; <span style=3D"color: #606;" class=3D"styled-by-prettify">Error=
</span> _err<span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><br><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><=
br><br><br><span style=3D"color: #008;" class=3D"styled-by-prettify">class<=
/span> conversion_error <span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">:</span> <span style=3D"color: #008;" class=3D"styled-by-prettify">p=
ublic</span> exception <span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{};</span><br><br><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">template</span> <span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
typename</span> T<span style=3D"color: #660;" class=3D"styled-by-prettify">=
&gt;</span> <span style=3D"color: #008;" class=3D"styled-by-prettify">using=
</span> stoiret <span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span> expected<span style=3D"color: #660;" class=3D"styled-by-prettify=
">&lt;</span>T<span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span>error_code<span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span>conversion_error<span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&gt;;</span><br><br><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">template</span> <span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>typename</span> T<span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&gt;</span><br>stoiret<span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&lt;</span>T<span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&gt;</span> string_to<span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span>string_view<span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&amp;</span> tail<span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">,</span> string_view s<span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span><br></code></div><br>Of course inventing a whole new e=
xpected / optional like thing just for these conversion functions is pretty=
 heavy weight. Sticking to bools and error_codes as return values / out par=
ameters side steps this whole question but may result in a more primitive i=
nterface.<br><br></div></div></blockquote>It's at least 3 years to the next=
 standard, so no need to speedrun this.</div><div><br></div><div>In terms o=
f performance: expected&lt;int, std::error_code&gt; has basically exactly t=
he same layout as your example + one bool (_val and _err even share space i=
n a union) and it's up to the user what to do with the error_code. optional=
&lt;T&gt; doesn't tell you what went wrong at all. You could write your own=
 thin wrapper that throws it on error etc. It's certainly easier to add exc=
eptions to an exception-free design than the reverse.</div><div><br></div><=
div>My suggestion is to *carefully anticipate* the existence of expected an=
d optional in 3 years. If it turns out not to be the case halfway down the =
road one can still design a helper type for the return values.</div><div><b=
r></div></body></html>

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

--Apple-Mail=_DA2DFA89-84AB-4DBD-9C3A-757F67CBDCC1--

.

------=_Part_5555_697527860.1412180074728
Content-Type: text/plain; charset=UTF-8



On Wednesday, October 1, 2014 12:04:52 PM UTC-4, Miro Knejp wrote:
>
>
> My suggestion is to *carefully anticipate* the existence of expected and
> optional in 3 years. If it turns out not to be the case halfway down the
> road one can still design a helper type for the return values.
>
>
I'll sketch a hypothetical return value class in my proposal and mention
that it can be implemented in terms of expected. This might also inform the
future design of the expected proposal as this will be a first class
example.

I believe Alexandrescu when he gave his talk about expected also used a
parsing API as an example..

Anyway I think at this point something needs to be written down and
formalized. Then we can debate and fine tune it.

--

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

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

<div dir=3D"ltr"><br><br>On Wednesday, October 1, 2014 12:04:52 PM UTC-4, M=
iro Knejp wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"=
word-wrap:break-word"><br><div>My suggestion is to *carefully anticipate* t=
he existence of expected and optional in 3 years. If it turns out not to be=
 the case halfway down the road one can still design a helper type for the =
return values.</div><div><br></div></div></blockquote><div><br>I'll sketch =
a hypothetical return value class in my proposal and mention that it can be=
 implemented in terms of expected. This might also inform the future design=
 of the expected proposal as this will be a first class example.<br><br>I b=
elieve Alexandrescu when he gave his talk about expected also used a parsin=
g API as an example..<br><br>Anyway I think at this point something needs t=
o be written down and formalized. Then we can debate and fine tune it.<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_5555_697527860.1412180074728--

.

------=_Part_140_1607208745.1446539403732
Content-Type: multipart/alternative;
 boundary="----=_Part_141_1066463876.1446539403732"

------=_Part_141_1066463876.1446539403732
Content-Type: text/plain; charset=UTF-8

Doesn't std::(i)strstream already handle these conversions quite nicely?
How about just un-deprecating that and maybe adding a (c)string_view
constructor?

--

---
You received this message because you are subscribed to the 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_141_1066463876.1446539403732
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Doesn&#39;t std::(i)strstream already handle these conversions quite nicely? How about just un-deprecating that and maybe adding a (c)string_view constructor?<br></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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_141_1066463876.1446539403732--
------=_Part_140_1607208745.1446539403732--

.

------=_Part_586_1088004538.1446555727919
Content-Type: multipart/alternative;
 boundary="----=_Part_587_1706085464.1446555727919"

------=_Part_587_1706085464.1446555727919
Content-Type: text/plain; charset=UTF-8

On Tuesday, November 3, 2015 at 3:30:03 AM UTC-5, wi...@schinmeyer.de wrote:
>
> Doesn't std::(i)strstream already handle these conversions quite nicely?
> How about just un-deprecating that and maybe adding a (c)string_view
> constructor?
>

We shouldn't undeprecate strstreams; it's deprecated for a good reason.
Instead, we should create viewstream classes that are *safe* versions of
the strstreams.

Even so, the basic `stof` and so forth functions are far too useful to not
make versions of for string_view.

--

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

<div dir=3D"ltr">On Tuesday, November 3, 2015 at 3:30:03 AM UTC-5, wi...@sc=
hinmeyer.de wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Doesn&#39;t std::(i)strstream already handle these conversions quite n=
icely? How about just un-deprecating that and maybe adding a (c)string_view=
 constructor?<br></div></blockquote><div><br>We shouldn&#39;t undeprecate s=
trstreams; it&#39;s deprecated for a good reason. Instead, we should create=
 viewstream classes that are <i>safe</i> versions of the strstreams. <br><b=
r>Even so, the basic `stof` and so forth functions are far too useful to no=
t make versions of for string_view.<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_587_1706085464.1446555727919--
------=_Part_586_1088004538.1446555727919--

.

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

You could also use variant<T, Error>.   Which is basically expected<>, but
variant is almost definitely going into the library.

I would use expected<>, and then fall-back to variant<> if expected doesn't
move forward.

On Wed, Oct 1, 2014 at 12:14 PM, Matthew Fioravante <fmatthew5876@gmail.com>
wrote:

>
>
> On Wednesday, October 1, 2014 12:04:52 PM UTC-4, Miro Knejp wrote:
>>
>>
>> My suggestion is to *carefully anticipate* the existence of expected and
>> optional in 3 years. If it turns out not to be the case halfway down the
>> road one can still design a helper type for the return values.
>>
>>
> I'll sketch a hypothetical return value class in my proposal and mention
> that it can be implemented in terms of expected. This might also inform the
> future design of the expected proposal as this will be a first class
> example.
>
> I believe Alexandrescu when he gave his talk about expected also used a
> parsing API as an example..
>
> Anyway I think at this point something needs to be written down and
> formalized. Then we can debate and fine tune it.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr"><div>You could also use variant&lt;T, Error&gt;.=C2=A0=C2=
=A0 Which is basically expected&lt;&gt;, but variant is almost definitely g=
oing into the library.<br><br></div>I would use expected&lt;&gt;, and then =
fall-back to variant&lt;&gt; if expected doesn&#39;t move forward.<br></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Oct 1, 2=
014 at 12:14 PM, Matthew Fioravante <span dir=3D"ltr">&lt;<a href=3D"mailto=
:fmatthew5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D""><br><br>On Wednesday, October 1, 2014 12:04:52 PM UTC-4, Miro Knejp w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-=
word"><br><div>My suggestion is to *carefully anticipate* the existence of =
expected and optional in 3 years. If it turns out not to be the case halfwa=
y down the road one can still design a helper type for the return values.</=
div><div><br></div></div></blockquote></span><div><br>I&#39;ll sketch a hyp=
othetical return value class in my proposal and mention that it can be impl=
emented in terms of expected. This might also inform the future design of t=
he expected proposal as this will be a first class example.<br><br>I believ=
e Alexandrescu when he gave his talk about expected also used a parsing API=
 as an example..<br><br>Anyway I think at this point something needs to be =
written down and formalized. Then we can debate and fine tune it.<br></div>=
</div><div class=3D"HOEnZb"><div class=3D"h5">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11c377a2d7f7bb0523af8cff--

.