------=_Part_327_125655239.1443799621170
Content-Type: multipart/alternative;
 boundary="----=_Part_328_1072875596.1443799621170"

------=_Part_328_1072875596.1443799621170
Content-Type: text/plain; charset=UTF-8

The C++ Standard includes a family of conversion functions like std::stoi,
std::stol, std::stoul and other similar functions.

They allow to convert a string to some arithmetic type.

However it is not always convinient to use them when you are going to apply
the function to a string starting from some non-zero position.

In this case you need to use either member function substr to get the
desired substring. or to use another member function c_str that to
apply the corresponding C function instead of the C++ function.

So I think you have already understood that I want to suggest overloading
functions that have one more parameter that specifies a position in the
string.

For example function stoi can now  look like

int stoi(const string& str, size_t* idx = 0, int base = 10);

int stoi(const string& str, std::string::size_type pos, size_t* idx = 0,
int base = 10);

What do you think about this?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_328_1072875596.1443799621170
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>The C++ Standard includes=C2=A0a family of conversion=
 functions like std::stoi, std::stol, std::stoul and other similar function=
s.</div><div><br></div><div>They allow to convert a string to some arithmet=
ic type.</div><div><br></div><div>However it is not always convinient to us=
e them when you are going to apply the function to a string starting from s=
ome non-zero position.</div><div><br></div><div>In this case you need to us=
e either member function substr to get the desired substring. or to use=C2=
=A0another member function c_str that to apply=C2=A0the corresponding C fun=
ction instead of the C++ function.</div><div><br></div><div>So I think you =
have already understood that I want to suggest overloading functions that h=
ave one more parameter that specifies a position in=C2=A0the string.</div><=
div><br></div><div>For example function stoi can now=C2=A0 look like</div><=
div><br></div><div>int stoi(const string&amp; str, size_t* idx =3D 0, int b=
ase =3D 10);</div><div><br></div><div>int stoi(const string&amp; str, std::=
string::size_type pos, size_t* idx =3D 0, int base =3D 10);<br><br></div><d=
iv>What do you think about this?</div><div><br></div></div>

<p></p>

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

------=_Part_328_1072875596.1443799621170--
------=_Part_327_125655239.1443799621170--

.

------=_Part_1058_518093865.1443800136697
Content-Type: multipart/alternative;
 boundary="----=_Part_1059_1309628599.1443800136697"

------=_Part_1059_1309628599.1443800136697
Content-Type: text/plain; charset=UTF-8

The string_view proposal adds overloads for these functions for
string_view, which would let you have everything you are asking for.
(http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3685.html#string.conversions)

Jared

On Friday, October 2, 2015 at 8:27:01 AM UTC-7, Vlad from Moscow wrote:
>
> The C++ Standard includes a family of conversion functions like std::stoi,
> std::stol, std::stoul and other similar functions.
>
> They allow to convert a string to some arithmetic type.
>
> However it is not always convinient to use them when you are going to
> apply the function to a string starting from some non-zero position.
>
> In this case you need to use either member function substr to get the
> desired substring. or to use another member function c_str that to
> apply the corresponding C function instead of the C++ function.
>
> So I think you have already understood that I want to suggest overloading
> functions that have one more parameter that specifies a position in the
> string.
>
> For example function stoi can now  look like
>
> int stoi(const string& str, size_t* idx = 0, int base = 10);
>
> int stoi(const string& str, std::string::size_type pos, size_t* idx = 0,
> int base = 10);
>
> What do you think about this?
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_1059_1309628599.1443800136697
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The string_view proposal adds overloads for these function=
s for string_view, which would let you have everything you are asking for. =
(http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3685.html#string.conv=
ersions)<br><br>Jared<br><br>On Friday, October 2, 2015 at 8:27:01 AM UTC-7=
, Vlad from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div>The C++ Standard includes=C2=A0a family of conversion func=
tions like std::stoi, std::stol, std::stoul and other similar functions.</d=
iv><div><br></div><div>They allow to convert a string to some arithmetic ty=
pe.</div><div><br></div><div>However it is not always convinient to use the=
m when you are going to apply the function to a string starting from some n=
on-zero position.</div><div><br></div><div>In this case you need to use eit=
her member function substr to get the desired substring. or to use=C2=A0ano=
ther member function c_str that to apply=C2=A0the corresponding C function =
instead of the C++ function.</div><div><br></div><div>So I think you have a=
lready understood that I want to suggest overloading functions that have on=
e more parameter that specifies a position in=C2=A0the string.</div><div><b=
r></div><div>For example function stoi can now=C2=A0 look like</div><div><b=
r></div><div>int stoi(const string&amp; str, size_t* idx =3D 0, int base =
=3D 10);</div><div><br></div><div>int stoi(const string&amp; str, std::stri=
ng::size_type pos, size_t* idx =3D 0, int base =3D 10);<br><br></div><div>W=
hat do you think about this?</div><div><br></div></div></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_1059_1309628599.1443800136697--
------=_Part_1058_518093865.1443800136697--

.

------=_Part_985_693380558.1443801123670
Content-Type: multipart/alternative;
 boundary="----=_Part_986_1685640171.1443801123675"

------=_Part_986_1685640171.1443801123675
Content-Type: text/plain; charset=UTF-8

In my opinion using string_view in this case makes things even more harder

Why does someone need to introduce one more entity that just to apply for
example std::stoi to a string?

It does not make a great sense.

I think that the functions should be overloaded as I am suggesting
irrespective of whether the string_view will be adopted or wil not.


On Friday, October 2, 2015 at 6:35:36 PM UTC+3, Jared Grubb wrote:

> The string_view proposal adds overloads for these functions for
> string_view, which would let you have everything you are asking for. (
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3685.html#string.conversions
> )
>
> Jared
>
> On Friday, October 2, 2015 at 8:27:01 AM UTC-7, Vlad from Moscow wrote:
>>
>> The C++ Standard includes a family of conversion functions like
>> std::stoi, std::stol, std::stoul and other similar functions.
>>
>> They allow to convert a string to some arithmetic type.
>>
>> However it is not always convinient to use them when you are going to
>> apply the function to a string starting from some non-zero position.
>>
>> In this case you need to use either member function substr to get the
>> desired substring. or to use another member function c_str that to
>> apply the corresponding C function instead of the C++ function.
>>
>> So I think you have already understood that I want to suggest overloading
>> functions that have one more parameter that specifies a position in the
>> string.
>>
>> For example function stoi can now  look like
>>
>> int stoi(const string& str, size_t* idx = 0, int base = 10);
>>
>> int stoi(const string& str, std::string::size_type pos, size_t* idx = 0,
>> int base = 10);
>>
>> What do you think about this?
>>
>>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_986_1685640171.1443801123675
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>In my opinion using string_view in this case makes th=
ings even more harder<br></div><div><br></div><div>Why does someone need to=
 introduce one more entity that just to apply for example std::stoi to a st=
ring?</div><div><br></div><div>It does not make a great sense.</div><div><b=
r></div><div>I think that the functions should be overloaded as I am sugges=
ting irrespective of whether the string_view will be adopted or wil not.</d=
iv><div><br></div><div><br>On Friday, October 2, 2015 at 6:35:36 PM UTC+3, =
Jared Grubb wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">The s=
tring_view proposal adds overloads for these functions for string_view, whi=
ch would let you have everything you are asking for. (<a onmousedown=3D"thi=
s.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2Fjtc=
1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3685.html%23string.conversions\46=
sa\75D\46sntz\0751\46usg\75AFQjCNHxpIzfLKJDjVZW2mc3ZuNOGsaRlQ&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%=
2Fopen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3685.html%23s=
tring.conversions\46sa\75D\46sntz\0751\46usg\75AFQjCNHxpIzfLKJDjVZW2mc3ZuNO=
GsaRlQ&#39;;return true;" href=3D"http://open-std.org/jtc1/sc22/wg21/docs/p=
apers/2013/n3685.html#string.conversions" target=3D"_blank" rel=3D"nofollow=
">http://open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2013/<wbr>n3685.html#=
string.conversions</a>)<br><br>Jared<br><br>On Friday, October 2, 2015 at 8=
:27:01 AM UTC-7, Vlad from Moscow wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div d=
ir=3D"ltr"><div>The C++ Standard includes=C2=A0a family of conversion funct=
ions like std::stoi, std::stol, std::stoul and other similar functions.</di=
v><div><br></div><div>They allow to convert a string to some arithmetic typ=
e.</div><div><br></div><div>However it is not always convinient to use them=
 when you are going to apply the function to a string starting from some no=
n-zero position.</div><div><br></div><div>In this case you need to use eith=
er member function substr to get the desired substring. or to use=C2=A0anot=
her member function c_str that to apply=C2=A0the corresponding C function i=
nstead of the C++ function.</div><div><br></div><div>So I think you have al=
ready understood that I want to suggest overloading functions that have one=
 more parameter that specifies a position in=C2=A0the string.</div><div><br=
></div><div>For example function stoi can now=C2=A0 look like</div><div><br=
></div><div>int stoi(const string&amp; str, size_t* idx =3D 0, int base =3D=
 10);</div><div><br></div><div>int stoi(const string&amp; str, std::string:=
:size_type pos, size_t* idx =3D 0, int base =3D 10);<br><br></div><div>What=
 do you think about this?</div><div><br></div></div></blockquote></div></bl=
ockquote></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_986_1685640171.1443801123675--
------=_Part_985_693380558.1443801123670--

.

------=_Part_1034_182989883.1443801610687
Content-Type: multipart/alternative;
 boundary="----=_Part_1035_724783747.1443801610688"

------=_Part_1035_724783747.1443801610688
Content-Type: text/plain; charset=UTF-8

By the way I advice to add in the description of the view_string the
functions I am proposing.:)

On Friday, October 2, 2015 at 6:35:36 PM UTC+3, Jared Grubb wrote:

> The string_view proposal adds overloads for these functions for
> string_view, which would let you have everything you are asking for. (
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3685.html#string.conversions
> )
>
> Jared
>
> On Friday, October 2, 2015 at 8:27:01 AM UTC-7, Vlad from Moscow wrote:
>>
>> The C++ Standard includes a family of conversion functions like
>> std::stoi, std::stol, std::stoul and other similar functions.
>>
>> They allow to convert a string to some arithmetic type.
>>
>> However it is not always convinient to use them when you are going to
>> apply the function to a string starting from some non-zero position.
>>
>> In this case you need to use either member function substr to get the
>> desired substring. or to use another member function c_str that to
>> apply the corresponding C function instead of the C++ function.
>>
>> So I think you have already understood that I want to suggest overloading
>> functions that have one more parameter that specifies a position in the
>> string.
>>
>> For example function stoi can now  look like
>>
>> int stoi(const string& str, size_t* idx = 0, int base = 10);
>>
>> int stoi(const string& str, std::string::size_type pos, size_t* idx = 0,
>> int base = 10);
>>
>> What do you think about this?
>>
>>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_1035_724783747.1443801610688
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>By the way I advice to add in the description of the =
view_string the functions I am proposing.:)</div><div><br></div><div>On Fri=
day, October 2, 2015 at 6:35:36 PM UTC+3, Jared Grubb wrote:</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: =
1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-=
left-style: solid;"><div dir=3D"ltr">The string_view proposal adds overload=
s for these functions for string_view, which would let you have everything =
you are asking for. (<a onmousedown=3D"this.href=3D&#39;http://www.google.c=
om/url?q\75http%3A%2F%2Fopen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2=
F2013%2Fn3685.html%23string.conversions\46sa\75D\46sntz\0751\46usg\75AFQjCN=
HxpIzfLKJDjVZW2mc3ZuNOGsaRlQ&#39;;return true;" onclick=3D"this.href=3D&#39=
;http://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2Fjtc1%2Fsc22%2Fwg=
21%2Fdocs%2Fpapers%2F2013%2Fn3685.html%23string.conversions\46sa\75D\46sntz=
\0751\46usg\75AFQjCNHxpIzfLKJDjVZW2mc3ZuNOGsaRlQ&#39;;return true;" href=3D=
"http://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3685.html#string.conv=
ersions" target=3D"_blank" rel=3D"nofollow">http://open-std.org/jtc1/<wbr>s=
c22/wg21/docs/papers/2013/<wbr>n3685.html#string.conversions</a>)<br><br>Ja=
red<br><br>On Friday, October 2, 2015 at 8:27:01 AM UTC-7, Vlad from Moscow=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex=
; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wid=
th: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>The C++ Standard =
includes=C2=A0a family of conversion functions like std::stoi, std::stol, s=
td::stoul and other similar functions.</div><div><br></div><div>They allow =
to convert a string to some arithmetic type.</div><div><br></div><div>Howev=
er it is not always convinient to use them when you are going to apply the =
function to a string starting from some non-zero position.</div><div><br></=
div><div>In this case you need to use either member function substr to get =
the desired substring. or to use=C2=A0another member function c_str that to=
 apply=C2=A0the corresponding C function instead of the C++ function.</div>=
<div><br></div><div>So I think you have already understood that I want to s=
uggest overloading functions that have one more parameter that specifies a =
position in=C2=A0the string.</div><div><br></div><div>For example function =
stoi can now=C2=A0 look like</div><div><br></div><div>int stoi(const string=
&amp; str, size_t* idx =3D 0, int base =3D 10);</div><div><br></div><div>in=
t stoi(const string&amp; str, std::string::size_type pos, size_t* idx =3D 0=
, int base =3D 10);<br><br></div><div>What do you think about this?</div><d=
iv><br></div></div></blockquote></div></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_1035_724783747.1443801610688--
------=_Part_1034_182989883.1443801610687--

.

On 2015-10-02 11:27, Vlad from Moscow wrote:
> The C++ Standard includes a family of conversion functions like std::stoi,
> std::stol, std::stoul and other similar functions.
>
> They allow to convert a string to some arithmetic type.
>
> However it is not always convinient to use them when you are going to apply
> the function to a string starting from some non-zero position.
>
> [...proposing...]
>
> int stoi(const string& str, size_t* idx = 0, int base = 10);
>
> int stoi(const string& str, std::string::size_type pos, size_t* idx = 0,
> int base = 10);
>
> What do you think about this?

I think that 'stoi(str.view(pos));' is no worse than 'stoi(str, pos)',
is more descriptive, and is more generally useful :-). (I would indeed
like methods to get a partial string_view directly from a string. Too
bad size_type is unsigned, or we could get the full range of Qt's
substring methods / Python's slicing, including far-relative offsets.
OTOH, maybe we can have overloads that take signed types; using them
would limit code to working with strings that are only half of
numeric_limits<size_type>::max in length, but how often are they really
larger?)

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_1130_1382917526.1443811269121
Content-Type: multipart/alternative;
 boundary="----=_Part_1131_208302888.1443811269121"

------=_Part_1131_208302888.1443811269121
Content-Type: text/plain; charset=UTF-8

I can not agree. in my opinion stoi(str.view(pos)) is much worse than the
straightforward  stoi(str, pos).

stoi(str.view(pos)) only confuses readres because str.vew has an additional
semantic that is not required in this case. It only arises questions.
str.view is something else apart from str itself.

This expression stoi(str, pos). is more clear .And moreover relative to the
argument list it is similar to calls of other member functions of the
class   We have a string and we have a position in the string. Why do we
need something else?!

On the other hand  this expression str.view(pos) looks like we are going to
call some method for the argument pos. That is the whole expression
stoi(str.view(pos))  looks as a two step operation. At first we call some
method with argument pos and only then we call the function itself.

On Friday, October 2, 2015 at 9:07:31 PM UTC+3, Matthew Woehlke wrote:

> On 2015-10-02 11:27, Vlad from Moscow wrote:
> > The C++ Standard includes a family of conversion functions like
> std::stoi,
> > std::stol, std::stoul and other similar functions.
> >
> > They allow to convert a string to some arithmetic type.
> >
> > However it is not always convinient to use them when you are going to
> apply
> > the function to a string starting from some non-zero position.
> >
> > [...proposing...]
> >
> > int stoi(const string& str, size_t* idx = 0, int base = 10);
> >
> > int stoi(const string& str, std::string::size_type pos, size_t* idx = 0,
> > int base = 10);
> >
> > What do you think about this?
>
> I think that 'stoi(str.view(pos));' is no worse than 'stoi(str, pos)',
> is more descriptive, and is more generally useful :-). (I would indeed
> like methods to get a partial string_view directly from a string. Too
> bad size_type is unsigned, or we could get the full range of Qt's
> substring methods / Python's slicing, including far-relative offsets.
> OTOH, maybe we can have overloads that take signed types; using them
> would limit code to working with strings that are only half of
> numeric_limits<size_type>::max in length, but how often are they really
> larger?)
>
> --
> Matthew
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_1131_208302888.1443811269121
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I can not agree. in my opinion stoi(str.view(pos)) is=
 much worse than the straightforward=C2=A0 stoi(str, pos). </div><div><br><=
/div><div>stoi(str.view(pos)) only confuses readres because str.vew has an =
additional semantic that is not required in this case. It only arises quest=
ions. str.view is something else apart from str itself.</div><div><br></div=
><div>This expression stoi(str, pos). is more clear .And moreover relative =
to the argument list it is similar to calls of other member functions of th=
e class=C2=A0=C2=A0=C2=A0We have a string and we have a position in the str=
ing. Why do we need something else?!</div><div><br></div><div>On the other =
hand=C2=A0 this expression str.view(pos) looks like we are going to call so=
me method for=C2=A0the argument pos. That is the whole expression </div><di=
v>stoi(str.view(pos))=C2=A0 looks as a two step operation. At first we call=
 some method with argument pos and only then we call the function itself.=
=C2=A0=C2=A0<br><br>On Friday, October 2, 2015 at 9:07:31 PM UTC+3, Matthew=
 Woehlke wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;">On 2015-10-02 11:27, Vlad=
 from Moscow wrote:
<br>&gt; The C++ Standard includes a family of conversion functions like st=
d::stoi,=20
<br>&gt; std::stol, std::stoul and other similar functions.
<br>&gt;=20
<br>&gt; They allow to convert a string to some arithmetic type.
<br>&gt;=20
<br>&gt; However it is not always convinient to use them when you are going=
 to apply=20
<br>&gt; the function to a string starting from some non-zero position.
<br>&gt;=20
<br>&gt; [...proposing...]
<br>&gt;=20
<br>&gt; int stoi(const string&amp; str, size_t* idx =3D 0, int base =3D 10=
);
<br>&gt;=20
<br>&gt; int stoi(const string&amp; str, std::string::size_type pos, size_t=
* idx =3D 0,=20
<br>&gt; int base =3D 10);
<br>&gt;=20
<br>&gt; What do you think about this?
<br>
<br>I think that &#39;stoi(str.view(pos));&#39; is no worse than &#39;stoi(=
str, pos)&#39;,
<br>is more descriptive, and is more generally useful :-). (I would indeed
<br>like methods to get a partial string_view directly from a string. Too
<br>bad size_type is unsigned, or we could get the full range of Qt&#39;s
<br>substring methods / Python&#39;s slicing, including far-relative offset=
s.
<br>OTOH, maybe we can have overloads that take signed types; using them
<br>would limit code to working with strings that are only half of
<br>numeric_limits&lt;size_type&gt;::max in length, but how often are they =
really
<br>larger?)
<br>
<br>--=20
<br>Matthew
<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_1131_208302888.1443811269121--
------=_Part_1130_1382917526.1443811269121--

.

------=_Part_905_235738489.1443814470361
Content-Type: text/plain; charset=UTF-8

I think the main problem is that you can't detect how much of the input string was consumed. There are older proposals trying to solve this as well as handling parsing 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_905_235738489.1443814470361--

.

------=_Part_1218_1193377159.1443815754415
Content-Type: multipart/alternative;
 boundary="----=_Part_1219_2079981498.1443815754416"

------=_Part_1219_2079981498.1443815754416
Content-Type: text/plain; charset=UTF-8

I am sorry I have not understood what exactly you mean. What is the
difference between these two functions

int stoi(const string& str, size_t* idx = 0, int base = 10);

int stoi(const string& str, std::string::size_type pos, size_t* idx = 0,
int base = 10);

that creates the problem?

On Friday, October 2, 2015 at 10:34:30 PM UTC+3, Bengt Gustafsson wrote:

> I think the main problem is that you can't detect how much of the input
> string was consumed. There are older proposals trying to solve this as well
> as handling parsing 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_1219_2079981498.1443815754416
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I am sorry I have not understood what exactly you mea=
n. What is the difference between these two functions</div><div><br></div><=
div><div>int stoi(const string&amp; str, size_t* idx =3D 0, int base =3D 10=
);</div><div><br></div><div>int stoi(const string&amp; str, std::string::si=
ze_type pos, size_t* idx =3D 0, int base =3D 10);</div></div><div><br>that =
creates the problem?</div><div><br>On Friday, October 2, 2015 at 10:34:30 P=
M UTC+3, Bengt Gustafsson wrote:</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(=
204, 204, 204); border-left-width: 1px; border-left-style: solid;">I think =
the main problem is that you can&#39;t detect how much of the input string =
was consumed. There are older proposals trying to solve this as well as han=
dling parsing errors.</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_1219_2079981498.1443815754416--
------=_Part_1218_1193377159.1443815754415--

.

------=_Part_725_780321931.1443816003621
Content-Type: multipart/alternative;
 boundary="----=_Part_726_389617434.1443816003628"

------=_Part_726_389617434.1443816003628
Content-Type: text/plain; charset=UTF-8

On Friday, October 2, 2015 at 2:41:09 PM UTC-4, Vlad from Moscow wrote:
>
> I can not agree. in my opinion stoi(str.view(pos)) is much worse than the
> straightforward  stoi(str, pos).
>

Well, here's the thing. There are dozens of ways of extracting a substring
from a string. And for every one of them, some user, *somewhere*, will want
`stoi` to use their pet version of that extraction.

What makes your "string + interger" extraction better? Who's to say that
everyone thinks that "string + integer" automatically means "offset from
the front of the string"?

By using string_view, we eliminate this problem. Or rather, we foist it on
the *user*, rather than on `stoi`'s interface. So there's no need to argue
over the receiving function; the argument is over std::string's interface.


> stoi(str.view(pos)) only confuses readres because str.vew has an
> additional semantic that is not required in this case. It only arises
> questions. str.view is something else apart from str itself.
>
> This expression stoi(str, pos). is more clear .
>

.... is it? OK, what does it mean? Without looking back through the thread,
I had no idea. Granted, I also didn't know what str.view(pos) means either.
But I'd know what str.first(count) or str.remove_first(count) would return.


> And moreover relative to the argument list it is similar to calls of other
> member functions of the class   We have a string and we have a position in
> the string. Why do we need something else?!
>
> On the other hand  this expression str.view(pos) looks like we are going
> to call some method for the argument pos.
>

That's because you are.


> That is the whole expression
> stoi(str.view(pos))  looks as a two step operation.
>

That's because it is.


> At first we call some method with argument pos and only then we call the
> function itself.
>

That's because you will.

Your problem is that you're trying to conflate two operations: extracting a
substring and converting a (sub) string into an integer. That's wrong..

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_726_389617434.1443816003628
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, October 2, 2015 at 2:41:09 PM UTC-4, Vlad from =
Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>I can not agree. in my opinion stoi(str.view(pos)) is much worse than =
the straightforward=C2=A0 stoi(str, pos).<br></div></div></blockquote><div>=
<br>Well, here&#39;s the thing. There are dozens of ways of extracting a su=
bstring from a string. And for every one of them, some user, <i>somewhere</=
i>, will want `stoi` to use their pet version of that extraction.<br><br>Wh=
at makes your &quot;string + interger&quot; extraction better? Who&#39;s to=
 say that everyone thinks that &quot;string + integer&quot; automatically m=
eans &quot;offset from the front of the string&quot;?<br><br>By using strin=
g_view, we eliminate this problem. Or rather, we foist it on the <i>user</i=
>, rather than on `stoi`&#39;s interface. So there&#39;s no need to argue o=
ver the receiving function; the argument is over std::string&#39;s interfac=
e.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"></blockquote=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>stoi(st=
r.view(pos)) only confuses readres because str.vew has an additional semant=
ic that is not required in this case. It only arises questions. str.view is=
 something else apart from str itself.</div><div><br></div><div>This expres=
sion stoi(str, pos). is more clear .</div></div></blockquote><div><br>... i=
s it? OK, what does it mean? Without looking back through the thread, I had=
 no idea. Granted, I also didn&#39;t know what str.view(pos) means either. =
But I&#39;d know what str.first(count) or str.remove_first(count) would ret=
urn.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>And moreover relative to the argument list it is similar to c=
alls of other member functions of the class=C2=A0=C2=A0=C2=A0We have a stri=
ng and we have a position in the string. Why do we need something else?!</d=
iv><div><br></div><div>On the other hand=C2=A0 this expression str.view(pos=
) looks like we are going to call some method for=C2=A0the argument pos.</d=
iv></div></blockquote><div><br>That&#39;s because you are.<br>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>That is t=
he whole expression </div><div>stoi(str.view(pos))=C2=A0 looks as a two ste=
p operation.</div></div></blockquote><div><br>That&#39;s because it is.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div> At first we call some method with argument pos and only then we call t=
he function itself.</div></div></blockquote><div><br>That&#39;s because you=
 will.<br><br>Your problem is that you&#39;re trying to conflate two operat=
ions: extracting a substring and converting a (sub) string into an integer.=
 That&#39;s wrong..</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_726_389617434.1443816003628--
------=_Part_725_780321931.1443816003621--

.

On 2015-10-02 16:00, Nicol Bolas wrote:
> On Friday, October 2, 2015 at 2:41:09 PM UTC-4, Vlad from Moscow wrote:
>> I can not agree. in my opinion stoi(str.view(pos)) is much worse than the
>> straightforward  stoi(str, pos).
>
> Well, here's the thing. There are dozens of ways of extracting a substring
> from a string. And for every one of them, some user, *somewhere*, will want
> `stoi` to use their pet version of that extraction.
>
> What makes your "string + interger" extraction better? Who's to say that
> everyone thinks that "string + integer" automatically means "offset from
> the front of the string"?
>
> By using string_view, we eliminate this problem. Or rather, we foist it on
> the *user*, rather than on `stoi`'s interface. So there's no need to argue
> over the receiving function; the argument is over std::string's interface.

Exactly (thanks, Nicol, for that great explanation). This is separation
of concerns, which is a good thing (see also again Nicol's comment at
the bottom). Keeping the interfaces lightweight but providing more of
them that can be strung together (a.k.a. the UNIX philosophy) results in
a better, more flexible overall system.

Besides, it's less clear from 'stoi(string, size_t)' what the size_t
parameter is supposed to mean. It's more obvious in e.g.
QString::mid(int, int) that the first parameter is the offset into the
string. (Less so with string::view, due to the name, but still more than
in stoi.)

> Granted, I also didn't know what str.view(pos) means either.

Sure. I like that it's concise, but substr_view, or mid_view, or even
just midv might be better. (Another reason is that 'view' can be like
QString::mid / string::substr, and then we could potentially add lview
and rview like QString::{left,right}. However, that's OT for this thread.)

> But I'd know what str.first(count) or str.remove_first(count) would return.

(Also OT, but personally I prefer take_first... "remove" -> void, "take"
-> what was taken.)

>> On the other hand  this expression str.view(pos) looks like we are going
>> to call some method for the argument pos.
>
> That's because you are.

Exactly. You are obtaining a partial view of the string and then
operating on that. Yes, in a strict technical sense, it may be
infinitesimally more efficient for stoi to just skip some characters,
but separating the operations is a better conceptual match.

> Your problem is that you're trying to conflate two operations: extracting a
> substring and converting a (sub) string into an integer. That's wrong..

Yup :-).

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_1556_2029523887.1443861307994
Content-Type: multipart/alternative;
 boundary="----=_Part_1557_983707285.1443861307994"

------=_Part_1557_983707285.1443861307994
Content-Type: text/plain; charset=UTF-8

It is a wrong point of view. I am not trying to do ywo operations. I am
delegating this work to stoi. I would indeed do these two operations if I
do not suggest the overloaded functions.

By the way it is you who is trying to do two operations.:) And it is more
than evident from your code

stoi(str.view(pos))

So you are truing to hand over your own problems to me. No thank you.

I do not understand why do I need a truck that to do just a step?:)


On Friday, October 2, 2015 at 11:00:04 PM UTC+3, Nicol Bolas wrote:

> On Friday, October 2, 2015 at 2:41:09 PM UTC-4, Vlad from Moscow wrote:
>>
>> I can not agree. in my opinion stoi(str.view(pos)) is much worse than the
>> straightforward  stoi(str, pos).
>>
>
> Well, here's the thing. There are dozens of ways of extracting a substring
> from a string. And for every one of them, some user, *somewhere*, will
> want `stoi` to use their pet version of that extraction.
>
> What makes your "string + interger" extraction better? Who's to say that
> everyone thinks that "string + integer" automatically means "offset from
> the front of the string"?
>
> By using string_view, we eliminate this problem. Or rather, we foist it on
> the *user*, rather than on `stoi`'s interface. So there's no need to
> argue over the receiving function; the argument is over std::string's
> interface.
>
>
>> stoi(str.view(pos)) only confuses readres because str.vew has an
>> additional semantic that is not required in this case. It only arises
>> questions. str.view is something else apart from str itself.
>>
>> This expression stoi(str, pos). is more clear .
>>
>
> ... is it? OK, what does it mean? Without looking back through the thread,
> I had no idea. Granted, I also didn't know what str.view(pos) means either.
> But I'd know what str.first(count) or str.remove_first(count) would return.
>
>
>> And moreover relative to the argument list it is similar to calls of
>> other member functions of the class   We have a string and we have a
>> position in the string. Why do we need something else?!
>>
>> On the other hand  this expression str.view(pos) looks like we are going
>> to call some method for the argument pos.
>>
>
> That's because you are.
>
>
>> That is the whole expression
>> stoi(str.view(pos))  looks as a two step operation.
>>
>
> That's because it is.
>
>
>> At first we call some method with argument pos and only then we call the
>> function itself.
>>
>
> That's because you will.
>
> Your problem is that you're trying to conflate two operations: extracting
> a substring and converting a (sub) string into an integer. That's wrong..
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_1557_983707285.1443861307994
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>It is a wrong point of view. I am not trying to do yw=
o operations. I am delegating this work to stoi. I would indeed do these tw=
o operations if I do not suggest the overloaded functions.</div><div><br></=
div><div>By the way it is you who is trying to do two operations.:) And it =
is more than=C2=A0evident from your code</div><div><br></div><div>stoi(str.=
view(pos))</div><div><br></div><div>So you are truing to=C2=A0hand over=C2=
=A0your own problems=C2=A0to me. No thank you.=C2=A0</div><div><br></div><d=
iv>I do not=C2=A0understand why do I need a truck that to do=C2=A0just a st=
ep?:)</div><div>=C2=A0<br><br>On Friday, October 2, 2015 at 11:00:04 PM UTC=
+3, Nicol Bolas wrote:</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">O=
n Friday, October 2, 2015 at 2:41:09 PM UTC-4, Vlad from Moscow wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-le=
ft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bor=
der-left-style: solid;"><div dir=3D"ltr"><div>I can not agree. in my opinio=
n stoi(str.view(pos)) is much worse than the straightforward=C2=A0 stoi(str=
, pos).<br></div></div></blockquote><div><br>Well, here&#39;s the thing. Th=
ere are dozens of ways of extracting a substring from a string. And for eve=
ry one of them, some user, <i>somewhere</i>, will want `stoi` to use their =
pet version of that extraction.<br><br>What makes your &quot;string + inter=
ger&quot; extraction better? Who&#39;s to say that everyone thinks that &qu=
ot;string + integer&quot; automatically means &quot;offset from the front o=
f the string&quot;?<br><br>By using string_view, we eliminate this problem.=
 Or rather, we foist it on the <i>user</i>, rather than on `stoi`&#39;s int=
erface. So there&#39;s no need to argue over the receiving function; the ar=
gument is over std::string&#39;s interface.<br>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bo=
rder-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-st=
yle: solid;"></blockquote><blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><di=
v>stoi(str.view(pos)) only confuses readres because str.vew has an addition=
al semantic that is not required in this case. It only arises questions. st=
r.view is something else apart from str itself.</div><div><br></div><div>Th=
is expression stoi(str, pos). is more clear .</div></div></blockquote><div>=
<br>... is it? OK, what does it mean? Without looking back through the thre=
ad, I had no idea. Granted, I also didn&#39;t know what str.view(pos) means=
 either. But I&#39;d know what str.first(count) or str.remove_first(count) =
would return.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204,=
 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">=
<div>And moreover relative to the argument list it is similar to calls of o=
ther member functions of the class=C2=A0=C2=A0=C2=A0We have a string and we=
 have a position in the string. Why do we need something else?!</div><div><=
br></div><div>On the other hand=C2=A0 this expression str.view(pos) looks l=
ike we are going to call some method for=C2=A0the argument pos.</div></div>=
</blockquote><div><br>That&#39;s because you are.<br>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1=
ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-l=
eft-style: solid;"><div dir=3D"ltr"><div>That is the whole expression </div=
><div>stoi(str.view(pos))=C2=A0 looks as a two step operation.</div></div><=
/blockquote><div><br>That&#39;s because it is.<br>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex;=
 border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left=
-style: solid;"><div dir=3D"ltr"><div> At first we call some method with ar=
gument pos and only then we call the function itself.</div></div></blockquo=
te><div><br>That&#39;s because you will.<br><br>Your problem is that you&#3=
9;re trying to conflate two operations: extracting a substring and converti=
ng a (sub) string into an integer. That&#39;s wrong..</div></div></blockquo=
te></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_1557_983707285.1443861307994--
------=_Part_1556_2029523887.1443861307994--

.

------=_Part_1651_1225955207.1443862924533
Content-Type: multipart/alternative;
 boundary="----=_Part_1652_228469349.1443862924533"

------=_Part_1652_228469349.1443862924533
Content-Type: text/plain; charset=UTF-8

And here is a simple demonstrative program

#include <iostream>
#include <string>

int main()
{
    std::string s( "Here is number 100 you need to extract" );

    std::cout << stoul( s, s.find_first_of( "0123456789" ) ) <<
std::endl;
}
Its output is

100

It is very clear code with very clear semantic that does not create some
unnecessary entities.

Each piece of the code also is very clear and does not arise a question.

And it does not require a truck as you suggest.:)
..


On Friday, October 2, 2015 at 11:00:04 PM UTC+3, Nicol Bolas wrote:

> On Friday, October 2, 2015 at 2:41:09 PM UTC-4, Vlad from Moscow wrote:
>>
>> I can not agree. in my opinion stoi(str.view(pos)) is much worse than the
>> straightforward  stoi(str, pos).
>>
>
> Well, here's the thing. There are dozens of ways of extracting a substring
> from a string. And for every one of them, some user, *somewhere*, will
> want `stoi` to use their pet version of that extraction.
>
> What makes your "string + interger" extraction better? Who's to say that
> everyone thinks that "string + integer" automatically means "offset from
> the front of the string"?
>
> By using string_view, we eliminate this problem. Or rather, we foist it on
> the *user*, rather than on `stoi`'s interface. So there's no need to
> argue over the receiving function; the argument is over std::string's
> interface.
>
>
>> stoi(str.view(pos)) only confuses readres because str.vew has an
>> additional semantic that is not required in this case. It only arises
>> questions. str.view is something else apart from str itself.
>>
>> This expression stoi(str, pos). is more clear .
>>
>
> ... is it? OK, what does it mean? Without looking back through the thread,
> I had no idea. Granted, I also didn't know what str.view(pos) means either.
> But I'd know what str.first(count) or str.remove_first(count) would return.
>
>
>> And moreover relative to the argument list it is similar to calls of
>> other member functions of the class   We have a string and we have a
>> position in the string. Why do we need something else?!
>>
>> On the other hand  this expression str.view(pos) looks like we are going
>> to call some method for the argument pos.
>>
>
> That's because you are.
>
>
>> That is the whole expression
>> stoi(str.view(pos))  looks as a two step operation.
>>
>
> That's because it is.
>
>
>> At first we call some method with argument pos and only then we call the
>> function itself.
>>
>
> That's because you will.
>
> Your problem is that you're trying to conflate two operations: extracting
> a substring and converting a (sub) string into an integer. That's wrong..
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_1652_228469349.1443862924533
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>And here is a simple demonstrative program</div><div>=
<br></div><div>#include &lt;iostream&gt;</div><div>#include &lt;string&gt;<=
/div><div><br></div><div>int main()<br>{<br>=C2=A0=C2=A0=C2=A0 std::string =
s( &quot;Here is number 100 you need to extract&quot; );<br>=C2=A0=C2=A0=C2=
=A0 <br>=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; stoul( s, s.find_first_of( &q=
uot;0123456789&quot; ) ) &lt;&lt; std::endl;=C2=A0=C2=A0=C2=A0 <br>}=C2=A0=
=C2=A0=C2=A0 <br></div><div>Its output is </div><div><br></div><div>100</di=
v><div><br></div><div>It is very clear code with very clear semantic that d=
oes not create some unnecessary entities.</div><div><br></div><div>Each pie=
ce of the code also is very clear and does not arise a question.</div><div>=
<br></div><div>And it does not require a truck as you suggest.:)</div><div>=
..</div><div><br><br>On Friday, October 2, 2015 at 11:00:04 PM UTC+3, Nicol =
Bolas wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Friday, =
October 2, 2015 at 2:41:09 PM UTC-4, Vlad from Moscow wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; b=
order-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-s=
tyle: solid;"><div dir=3D"ltr"><div>I can not agree. in my opinion stoi(str=
..view(pos)) is much worse than the straightforward=C2=A0 stoi(str, pos).<br=
></div></div></blockquote><div><br>Well, here&#39;s the thing. There are do=
zens of ways of extracting a substring from a string. And for every one of =
them, some user, <i>somewhere</i>, will want `stoi` to use their pet versio=
n of that extraction.<br><br>What makes your &quot;string + interger&quot; =
extraction better? Who&#39;s to say that everyone thinks that &quot;string =
+ integer&quot; automatically means &quot;offset from the front of the stri=
ng&quot;?<br><br>By using string_view, we eliminate this problem. Or rather=
, we foist it on the <i>user</i>, rather than on `stoi`&#39;s interface. So=
 there&#39;s no need to argue over the receiving function; the argument is =
over std::string&#39;s interface.<br>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-=
color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid=
;"></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>stoi(str=
..view(pos)) only confuses readres because str.vew has an additional semanti=
c that is not required in this case. It only arises questions. str.view is =
something else apart from str itself.</div><div><br></div><div>This express=
ion stoi(str, pos). is more clear .</div></div></blockquote><div><br>... is=
 it? OK, what does it mean? Without looking back through the thread, I had =
no idea. Granted, I also didn&#39;t know what str.view(pos) means either. B=
ut I&#39;d know what str.first(count) or str.remove_first(count) would retu=
rn.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>And m=
oreover relative to the argument list it is similar to calls of other membe=
r functions of the class=C2=A0=C2=A0=C2=A0We have a string and we have a po=
sition in the string. Why do we need something else?!</div><div><br></div><=
div>On the other hand=C2=A0 this expression str.view(pos) looks like we are=
 going to call some method for=C2=A0the argument pos.</div></div></blockquo=
te><div><br>That&#39;s because you are.<br>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border=
-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style:=
 solid;"><div dir=3D"ltr"><div>That is the whole expression </div><div>stoi=
(str.view(pos))=C2=A0 looks as a two step operation.</div></div></blockquot=
e><div><br>That&#39;s because it is.<br>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-le=
ft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: so=
lid;"><div dir=3D"ltr"><div> At first we call some method with argument pos=
 and only then we call the function itself.</div></div></blockquote><div><b=
r>That&#39;s because you will.<br><br>Your problem is that you&#39;re tryin=
g to conflate two operations: extracting a substring and converting a (sub)=
 string into an integer. That&#39;s wrong..</div></div></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_1652_228469349.1443862924533--
------=_Part_1651_1225955207.1443862924533--

.

------=_Part_1715_520514668.1443869423627
Content-Type: multipart/alternative;
 boundary="----=_Part_1716_347142126.1443869423627"

------=_Part_1716_347142126.1443869423627
Content-Type: text/plain; charset=UTF-8

Oh, I thought you meant to replace the old idx with a in-parameter pos. For
easiest use I think an inout reference position would be best:

stoi(const string& str, size_t& pos, int base = 10);

You could argue that pos should be a pointer, but that train has sailed due
to the current signature.

I would prefer string_view& with an overload for const string_view& or
string_view&& where you couldn't get the consumption back, but I think that
string_view is not going to be mutable, and in that case I would prefer a
size_t&

stoi(string_view& str, int base = 10);    // Changes str's start point to
reflect consumption
stoi(const string_view& str, int base = 10); // Does not change reveal
consumption.



Den fredag 2 oktober 2015 kl. 21:55:54 UTC+2 skrev Vlad from Moscow:
>
> I am sorry I have not understood what exactly you mean. What is the
> difference between these two functions
>
> int stoi(const string& str, size_t* idx = 0, int base = 10);
>
> int stoi(const string& str, std::string::size_type pos, size_t* idx = 0,
> int base = 10);
>
> that creates the problem?
>
> On Friday, October 2, 2015 at 10:34:30 PM UTC+3, Bengt Gustafsson wrote:
>
>> I think the main problem is that you can't detect how much of the input
>> string was consumed. There are older proposals trying to solve this as well
>> as handling parsing 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_1716_347142126.1443869423627
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Oh, I thought you meant to replace the old idx with a in-p=
arameter pos. For easiest use I think an inout reference position would be =
best:<div><br></div><div>stoi(const string&amp; str, size_t&amp; pos, int b=
ase =3D 10);</div><div><br></div><div>You could argue that pos should be a =
pointer, but that train has sailed due to the current signature.</div><div>=
<br></div><div>I would prefer string_view&amp; with an overload for const s=
tring_view&amp; or string_view&amp;&amp; where you couldn&#39;t get the con=
sumption back, but I think that string_view is not going to be mutable, and=
 in that case I would prefer a size_t&amp;</div><div><br></div><div><div>st=
oi(string_view&amp; str, int base =3D 10); =C2=A0 =C2=A0// Changes str&#39;=
s start point to reflect consumption</div><div>stoi(const string_view&amp; =
str, int base =3D 10); // Does not change reveal consumption.</div><div><br=
></div><div><br></div><div><br>Den fredag 2 oktober 2015 kl. 21:55:54 UTC+2=
 skrev Vlad from Moscow:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div>I am sorry I have not understood what exactly you mean. Wha=
t is the difference between these two functions</div><div><br></div><div><d=
iv>int stoi(const string&amp; str, size_t* idx =3D 0, int base =3D 10);</di=
v><div><br></div><div>int stoi(const string&amp; str, std::string::size_typ=
e pos, size_t* idx =3D 0, int base =3D 10);</div></div><div><br>that create=
s the problem?</div><div><br>On Friday, October 2, 2015 at 10:34:30 PM UTC+=
3, Bengt Gustafsson wrote:</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid">I think the main problem i=
s that you can&#39;t detect how much of the input string was consumed. Ther=
e are older proposals trying to solve this as well as handling parsing erro=
rs.</blockquote></div></blockquote></div></div></div>

<p></p>

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

------=_Part_1716_347142126.1443869423627--
------=_Part_1715_520514668.1443869423627--

.

------=_Part_1586_1021131955.1443870611579
Content-Type: multipart/alternative;
 boundary="----=_Part_1587_601785865.1443870611579"

------=_Part_1587_601785865.1443870611579
Content-Type: text/plain; charset=UTF-8

I am suggesting a minor change of the original funcions. That is all other
parameters are the same. only overloaded functions are added that have one
additional parameter: position in a string.

On Saturday, October 3, 2015 at 1:50:24 PM UTC+3, Bengt Gustafsson wrote:
>
> Oh, I thought you meant to replace the old idx with a in-parameter pos.
> For easiest use I think an inout reference position would be best:
>
> stoi(const string& str, size_t& pos, int base = 10);
>
> You could argue that pos should be a pointer, but that train has sailed
> due to the current signature.
>
> I would prefer string_view& with an overload for const string_view& or
> string_view&& where you couldn't get the consumption back, but I think that
> string_view is not going to be mutable, and in that case I would prefer a
> size_t&
>
> stoi(string_view& str, int base = 10);    // Changes str's start point to
> reflect consumption
> stoi(const string_view& str, int base = 10); // Does not change reveal
> consumption.
>
>
>
> Den fredag 2 oktober 2015 kl. 21:55:54 UTC+2 skrev Vlad from Moscow:
>>
>> I am sorry I have not understood what exactly you mean. What is the
>> difference between these two functions
>>
>> int stoi(const string& str, size_t* idx = 0, int base = 10);
>>
>> int stoi(const string& str, std::string::size_type pos, size_t* idx = 0,
>> int base = 10);
>>
>> that creates the problem?
>>
>> On Friday, October 2, 2015 at 10:34:30 PM UTC+3, Bengt Gustafsson wrote:
>>
>>> I think the main problem is that you can't detect how much of the input
>>> string was consumed. There are older proposals trying to solve this as well
>>> as handling parsing 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_1587_601785865.1443870611579
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I am suggesting a minor change of the original funcions. T=
hat is all other parameters are the same. only overloaded functions are add=
ed that have one additional parameter: position in a string.<br><br>On Satu=
rday, October 3, 2015 at 1:50:24 PM UTC+3, Bengt Gustafsson wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: =
1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-=
left-style: solid;"><div dir=3D"ltr">Oh, I thought you meant to replace the=
 old idx with a in-parameter pos. For easiest use I think an inout referenc=
e position would be best:<div><br></div><div>stoi(const string&amp; str, si=
ze_t&amp; pos, int base =3D 10);</div><div><br></div><div>You could argue t=
hat pos should be a pointer, but that train has sailed due to the current s=
ignature.</div><div><br></div><div>I would prefer string_view&amp; with an =
overload for const string_view&amp; or string_view&amp;&amp; where you coul=
dn&#39;t get the consumption back, but I think that string_view is not goin=
g to be mutable, and in that case I would prefer a size_t&amp;</div><div><b=
r></div><div><div>stoi(string_view&amp; str, int base =3D 10); =C2=A0 =C2=
=A0// Changes str&#39;s start point to reflect consumption</div><div>stoi(c=
onst string_view&amp; str, int base =3D 10); // Does not change reveal cons=
umption.</div><div><br></div><div><br></div><div><br>Den fredag 2 oktober 2=
015 kl. 21:55:54 UTC+2 skrev Vlad from Moscow:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-col=
or: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">=
<div dir=3D"ltr"><div>I am sorry I have not understood what exactly you mea=
n. What is the difference between these two functions</div><div><br></div><=
div><div>int stoi(const string&amp; str, size_t* idx =3D 0, int base =3D 10=
);</div><div><br></div><div>int stoi(const string&amp; str, std::string::si=
ze_type pos, size_t* idx =3D 0, int base =3D 10);</div></div><div><br>that =
creates the problem?</div><div><br>On Friday, October 2, 2015 at 10:34:30 P=
M UTC+3, Bengt Gustafsson wrote:</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(=
204, 204, 204); border-left-width: 1px; border-left-style: solid;">I think =
the main problem is that you can&#39;t detect how much of the input string =
was consumed. There are older proposals trying to solve this as well as han=
dling parsing errors.</blockquote></div></blockquote></div></div></div></bl=
ockquote></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_1587_601785865.1443870611579--
------=_Part_1586_1021131955.1443870611579--

.

------=_Part_1879_450600977.1443881812746
Content-Type: multipart/alternative;
 boundary="----=_Part_1880_1448189281.1443881812753"

------=_Part_1880_1448189281.1443881812753
Content-Type: text/plain; charset=UTF-8

On Saturday, October 3, 2015 at 4:35:08 AM UTC-4, Vlad from Moscow wrote:
>
> It is a wrong point of view. I am not trying to do ywo operations. I am
> delegating this work to stoi.
>

And why should stoi be concerned with *anything* but converting a string to
an integer? Why should it be concerned with offsetting the initial position
of that string by some value first?

Two operations are being done either way, either within stoi or within your
code. Why should stoi be the one who is doing those two, instead of your
code?

Also, stop top-posting. It makes it difficult to understand what you're
responding to. Write your text *under* what you're responding to, not above
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_1880_1448189281.1443881812753
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, October 3, 2015 at 4:35:08 AM UTC-4, Vlad fro=
m Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div>It is a wrong point of view. I am not trying to do ywo operations. I=
 am delegating this work to stoi.</div></div></blockquote><div><br>And why =
should stoi be concerned with <i>anything</i> but converting a string to an=
 integer? Why should it be concerned with offsetting the initial position o=
f that string by some value first?<br><br>Two operations are being done eit=
her way, either within stoi or within your code. Why should stoi be the one=
 who is doing those two, instead of your code?<br><br>Also, stop top-postin=
g. It makes it difficult to understand what you&#39;re responding to. Write=
 your text <i>under</i> what you&#39;re responding to, not above it.<br></d=
iv></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_1880_1448189281.1443881812753--
------=_Part_1879_450600977.1443881812746--

.

------=_Part_8_1976392936.1443882414028
Content-Type: multipart/alternative;
 boundary="----=_Part_9_2034431376.1443882414028"

------=_Part_9_2034431376.1443882414028
Content-Type: text/plain; charset=UTF-8

On Saturday, October 3, 2015 at 5:02:04 AM UTC-4, Vlad from Moscow wrote:
>
> And here is a simple demonstrative program
>
> #include <iostream>
> #include <string>
>
> int main()
> {
>     std::string s( "Here is number 100 you need to extract" );
>
>     std::cout << stoul( s, s.find_first_of( "0123456789" ) ) <<
> std::endl;
> }
> Its output is
>
> 100
>
> It is very clear code with very clear semantic that does not create some
> unnecessary entities.
>
> Each piece of the code also is very clear and does not arise a question.
>

It "arise a question[sic]" with me: what does `stoul` actually *do* with
that integer? Yes, I see you find the first digit in the string. But it's
unclear to me what `stoul` is supposed to do with it.

Whereas:

stoul( s.view().remove_prefix(s.find_first_of( "0123456789" )))

Makes it very clear what's going on.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_2034431376.1443882414028
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, October 3, 2015 at 5:02:04 AM UTC-4, Vlad fro=
m Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div>And here is a simple demonstrative program</div><div><br></div><div>=
#include &lt;iostream&gt;</div><div>#include &lt;string&gt;</div><div><br><=
/div><div>int main()<br>{<br>=C2=A0=C2=A0=C2=A0 std::string s( &quot;Here i=
s number 100 you need to extract&quot; );<br>=C2=A0=C2=A0=C2=A0 <br>=C2=A0=
=C2=A0=C2=A0 std::cout &lt;&lt; stoul( s, s.find_first_of( &quot;0123456789=
&quot; ) ) &lt;&lt; std::endl;=C2=A0=C2=A0=C2=A0 <br>}=C2=A0=C2=A0=C2=A0 <b=
r></div><div>Its output is </div><div><br></div><div>100</div><div><br></di=
v><div>It is very clear code with very clear semantic that does not create =
some unnecessary entities.</div><div><br></div><div>Each piece of the code =
also is very clear and does not arise a question.</div></div></blockquote><=
div><br>It &quot;arise a question[sic]&quot; with me: what does `stoul` act=
ually <i>do</i> with that integer? Yes, I see you find the first digit in t=
he string. But it&#39;s unclear to me what `stoul` is supposed to do with i=
t.<br><br>Whereas:<br><br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled=
-by-prettify">stoul</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</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">view</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 st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #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">find_first_of</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-p=
rettify">&quot;0123456789&quot;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">)))</span></div></code></div><br>Makes it very clear what&#39;s=
 going on.<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_9_2034431376.1443882414028--
------=_Part_8_1976392936.1443882414028--

.

------=_Part_1843_615699781.1443882947354
Content-Type: multipart/alternative;
 boundary="----=_Part_1844_160182435.1443882947355"

------=_Part_1844_160182435.1443882947355
Content-Type: text/plain; charset=UTF-8


On Saturday, October 3, 2015 at 5:16:53 PM UTC+3, Nicol Bolas wrote:
>
> On Saturday, October 3, 2015 at 4:35:08 AM UTC-4, Vlad from Moscow wrote:
>>
>> It is a wrong point of view. I am not trying to do ywo operations. I am
>> delegating this work to stoi.
>>
>
> And why should stoi be concerned with *anything* but converting a string
> to an integer? Why should it be concerned with offsetting the initial
> position of that string by some value first?
>
> These funtions already are designed specially for std::string. But they
have a drawback. You can not specify a position in the string starting from
which you are going to extract a number. This creates for example a
difficulty of using the functions with the same string iteractively.



> Two operations are being done either way, either within stoi or within
> your code. Why should stoi be the one who is doing those two, instead of
> your code?
>
> Delegating this operation to the functions makes your code cleaner and
more clear. You need not spend your time to implement the details. I am
sure that a code that contans many implementation details is difficult to
read. The code should clear demonstrate the imtention of the programmer.


> Also, stop top-posting. It makes it difficult to understand what you're
> responding to. Write your text *under* what you're responding to, not
> above 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_1844_160182435.1443882947355
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Saturday, October 3, 2015 at 5:16:53 PM UTC+3, Nico=
l Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-l=
eft-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Saturday, Oc=
tober 3, 2015 at 4:35:08 AM UTC-4, Vlad from Moscow wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div dir=3D"ltr"><div>It is a wrong point of view. I am not try=
ing to do ywo operations. I am delegating this work to stoi.</div></div></b=
lockquote><div><br>And why should stoi be concerned with <i>anything</i> bu=
t converting a string to an integer? Why should it be concerned with offset=
ting the initial position of that string by some value first?<br><br></div>=
</div></blockquote><div>These funtions already are designed specially for=
=C2=A0std::string. But they have a drawback. You can not specify a position=
 in the string starting from which you are going to extract a number. This =
creates for example a difficulty of using the functions with the same strin=
g iteractively.</div><div>=C2=A0</div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border=
-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style:=
 solid;"><div dir=3D"ltr"><div>Two operations are being done either way, ei=
ther within stoi or within your code. Why should stoi be the one who is doi=
ng those two, instead of your code?<br><br></div></div></blockquote><div>De=
legating this operation to the functions makes your code cleaner=C2=A0and m=
ore clear.=C2=A0You need not spend your time to=C2=A0implement=C2=A0the det=
ails. I am sure that=C2=A0a code that contans many implementation details i=
s difficult to read. The code should clear demonstrate the imtention of the=
 programmer.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><div>Also, stop top-posting. It makes it difficult to understand w=
hat you&#39;re responding to. Write your text <i>under</i> what you&#39;re =
responding to, not above it.<br></div></div></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_1844_160182435.1443882947355--
------=_Part_1843_615699781.1443882947354--

.

------=_Part_1695_309453809.1443883067260
Content-Type: multipart/alternative;
 boundary="----=_Part_1696_1230779702.1443883067261"

------=_Part_1696_1230779702.1443883067261
Content-Type: text/plain; charset=UTF-8



On Saturday, October 3, 2015 at 5:26:54 PM UTC+3, Nicol Bolas wrote:
>
> On Saturday, October 3, 2015 at 5:02:04 AM UTC-4, Vlad from Moscow wrote:
>>
>> And here is a simple demonstrative program
>>
>> #include <iostream>
>> #include <string>
>>
>> int main()
>> {
>>     std::string s( "Here is number 100 you need to extract" );
>>
>>     std::cout << stoul( s, s.find_first_of( "0123456789" ) ) <<
>> std::endl;
>> }
>> Its output is
>>
>> 100
>>
>> It is very clear code with very clear semantic that does not create some
>> unnecessary entities.
>>
>> Each piece of the code also is very clear and does not arise a question.
>>
>
> It "arise a question[sic]" with me: what does `stoul` actually *do* with
> that integer? Yes, I see you find the first digit in the string. But it's
> unclear to me what `stoul` is supposed to do with it.
>
> Whereas:
>
> stoul( s.view().remove_prefix(s.find_first_of( "0123456789" )))
>
> Makes it very clear what's going on.
>

Are you serious? It looks like a joke.:)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_1696_1230779702.1443883067261
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Saturday, October 3, 2015 at 5:26:54 PM UTC+3, Nicol Bolas wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;"><div dir=3D"ltr">On Saturday, October 3, 2015=
 at 5:02:04 AM UTC-4, Vlad from Moscow wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-colo=
r: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><=
div dir=3D"ltr"><div>And here is a simple demonstrative program</div><div><=
br></div><div>#include &lt;iostream&gt;</div><div>#include &lt;string&gt;</=
div><div><br></div><div>int main()<br>{<br>=C2=A0=C2=A0=C2=A0 std::string s=
( &quot;Here is number 100 you need to extract&quot; );<br>=C2=A0=C2=A0=C2=
=A0 <br>=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; stoul( s, s.find_first_of( &q=
uot;0123456789&quot; ) ) &lt;&lt; std::endl;=C2=A0=C2=A0=C2=A0 <br>}=C2=A0=
=C2=A0=C2=A0 <br></div><div>Its output is </div><div><br></div><div>100</di=
v><div><br></div><div>It is very clear code with very clear semantic that d=
oes not create some unnecessary entities.</div><div><br></div><div>Each pie=
ce of the code also is very clear and does not arise a question.</div></div=
></blockquote><div><br>It &quot;arise a question[sic]&quot; with me: what d=
oes `stoul` actually <i>do</i> with that integer? Yes, I see you find the f=
irst digit in the string. But it&#39;s unclear to me what `stoul` is suppos=
ed to do with it.<br><br>Whereas:<br><br><div style=3D"border: 1px solid rg=
b(187, 187, 187); border-image: none; -ms-word-wrap: break-word; background=
-color: rgb(250, 250, 250);"><code><div><span style=3D"color: rgb(0, 0, 0);=
">stoul</span><span style=3D"color: rgb(102, 102, 0);">(</span><span style=
=3D"color: rgb(0, 0, 0);"> s</span><span style=3D"color: rgb(102, 102, 0);"=
>.</span><span style=3D"color: rgb(0, 0, 0);">view</span><span style=3D"col=
or: rgb(102, 102, 0);">().</span><span style=3D"color: rgb(0, 0, 0);">remov=
e_prefix</span><span style=3D"color: rgb(102, 102, 0);">(</span><span style=
=3D"color: rgb(0, 0, 0);">s</span><span style=3D"color: rgb(102, 102, 0);">=
..</span><span style=3D"color: rgb(0, 0, 0);">find_<wbr>first_of</span><span=
 style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0,=
 0);"> </span><span style=3D"color: rgb(0, 136, 0);">&quot;0123456789&quot;=
</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: r=
gb(102, 102, 0);">)))</span></div></code></div><br>Makes it very clear what=
&#39;s going on.<br></div></div></blockquote><div><br></div><div>Are you se=
rious? It looks like a joke.:)=C2=A0</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_1696_1230779702.1443883067261--
------=_Part_1695_309453809.1443883067260--

.

------=_Part_97_565235045.1443883445780
Content-Type: multipart/alternative;
 boundary="----=_Part_98_613969765.1443883445780"

------=_Part_98_613969765.1443883445780
Content-Type: text/plain; charset=UTF-8

On Saturday, October 3, 2015 at 10:35:47 AM UTC-4, Vlad from Moscow wrote:
>
> On Saturday, October 3, 2015 at 5:16:53 PM UTC+3, Nicol Bolas wrote:
>>
>> On Saturday, October 3, 2015 at 4:35:08 AM UTC-4, Vlad from Moscow wrote:
>>>
>>> It is a wrong point of view. I am not trying to do ywo operations. I am
>>> delegating this work to stoi.
>>>
>>
>> And why should stoi be concerned with *anything* but converting a string
>> to an integer? Why should it be concerned with offsetting the initial
>> position of that string by some value first?
>>
>> These funtions already are designed specially for std::string.
>

And that is 99% of what is *wrong* with those functions.

If you're going to add new overloads for these functions, those overloads
should not *exacerbate* the existing flaws; they should *fix them*.

Taking string_view (or becoming template functions that take
basic_string_views) would be a far more reasonable proposal than what
you're talking about.

Two operations are being done either way, either within stoi or within your
>> code. Why should stoi be the one who is doing those two, instead of your
>> code?
>>
>> Delegating this operation to the functions makes your code cleaner and
> more clear.
>

"cleaner and more clear" is a matter of personal opinion. Code that tells
me exactly what it's doing is "cleaner and more clear" to me. If you get a
view and remove prefix characters from it, I know what you're doing.

If you pass an integer to a function, I have to look up its documentation
to find out what it's doing. That's not "more clear" to me.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_98_613969765.1443883445780
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, October 3, 2015 at 10:35:47 AM UTC-4, Vlad from Moscow wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Saturday, O=
ctober 3, 2015 at 5:16:53 PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left=
-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div=
 dir=3D"ltr">On Saturday, October 3, 2015 at 4:35:08 AM UTC-4, Vlad from Mo=
scow wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1=
px;border-left-style:solid"><div dir=3D"ltr"><div>It is a wrong point of vi=
ew. I am not trying to do ywo operations. I am delegating this work to stoi=
..</div></div></blockquote><div><br>And why should stoi be concerned with <i=
>anything</i> but converting a string to an integer? Why should it be conce=
rned with offsetting the initial position of that string by some value firs=
t?<br><br></div></div></blockquote><div>These funtions already are designed=
 specially for=C2=A0std::string.</div></div></blockquote><div><br>And that =
is 99% of what is <i>wrong</i> with those functions.<br><br>If you&#39;re g=
oing to add new overloads for these functions, those overloads should not <=
i>exacerbate</i> the existing flaws; they should <i>fix them</i>.<br><br>Ta=
king string_view (or becoming template functions that take basic_string_vie=
ws) would be a far more reasonable proposal than what you&#39;re talking ab=
out.<br><br></div><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"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wi=
dth:1px;border-left-style:solid"><div dir=3D"ltr"><div>Two operations are b=
eing done either way, either within stoi or within your code. Why should st=
oi be the one who is doing those two, instead of your code?<br><br></div></=
div></blockquote><div>Delegating this operation to the functions makes your=
 code cleaner=C2=A0and more clear.</div></div></blockquote><div><br>&quot;c=
leaner and more clear&quot; is a matter of personal opinion. Code that tell=
s me exactly what it&#39;s doing is &quot;cleaner and more clear&quot; to m=
e. If you get a view and remove prefix characters from it, I know what you&=
#39;re doing.<br><br>If you pass an integer to a function, I have to look u=
p its documentation to find out what it&#39;s doing. That&#39;s not &quot;m=
ore clear&quot; to me.<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_98_613969765.1443883445780--
------=_Part_97_565235045.1443883445780--

.

------=_Part_169_1925034964.1443885377648
Content-Type: multipart/alternative;
 boundary="----=_Part_170_1110670940.1443885377648"

------=_Part_170_1110670940.1443885377648
Content-Type: text/plain; charset=UTF-8


On Saturday, October 3, 2015 at 5:44:06 PM UTC+3, Nicol Bolas wrote:
>
> On Saturday, October 3, 2015 at 10:35:47 AM UTC-4, Vlad from Moscow wrote:
>>
>> On Saturday, October 3, 2015 at 5:16:53 PM UTC+3, Nicol Bolas wrote:
>>>
>>> On Saturday, October 3, 2015 at 4:35:08 AM UTC-4, Vlad from Moscow wrote:
>>>>
>>>> It is a wrong point of view. I am not trying to do ywo operations. I am
>>>> delegating this work to stoi.
>>>>
>>>
>>> And why should stoi be concerned with *anything* but converting a
>>> string to an integer? Why should it be concerned with offsetting the
>>> initial position of that string by some value first?
>>>
>>> These funtions already are designed specially for std::string.
>>
>
> And that is 99% of what is *wrong* with those functions.
>
> Could you elaborate what is wrong with this? Maybe the C++ Standard has a
defect placing these functions in the header <string>.


> If you're going to add new overloads for these functions, those overloads
> should not *exacerbate* the existing flaws; they should *fix them*.
>
> As for me then I see that the overloads make the functions more flexible.
It is what I always need when a number is inside a string.


> Taking string_view (or becoming template functions that take
> basic_string_views) would be a far more reasonable proposal than what
> you're talking about.
>
> Two operations are being done either way, either within stoi or within
>>> your code. Why should stoi be the one who is doing those two, instead of
>>> your code?
>>>
>>> Delegating this operation to the functions makes your code cleaner and
>> more clear.
>>
>
> "cleaner and more clear" is a matter of personal opinion. Code that tells
> me exactly what it's doing is "cleaner and more clear" to me. If you get a
> view and remove prefix characters from it, I know what you're doing.
>
> If you pass an integer to a function, I have to look up its documentation
> to find out what it's doing. That's not "more clear" to me.
>

Without any doubts to understand your example shown above a programmer
needs to read tons of the documentation. At least he must be sure that the
functions you used have not some side effects.

To use a string followed by a position in the string is very natural
because this pattern is used in many functions of class std:;string.

The code you showed has nothing common with the class std::string. It only
makes the program more confused because you introduced a new entity that is
not required to convert a string to an arithmetic type.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_170_1110670940.1443885377648
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br>On Saturday, October 3, 2015 at 5:44:06 PM UTC+3, Nicol Bolas wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-=
left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; b=
order-left-style: solid;">On Saturday, October 3, 2015 at 10:35:47 AM UTC-4=
, Vlad from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On S=
aturday, October 3, 2015 at 5:16:53 PM UTC+3, Nicol Bolas wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;"><div dir=3D"ltr">On Saturday, October 3, 2015 at 4:35:08 =
AM UTC-4, Vlad from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, =
204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"l=
tr"><div>It is a wrong point of view. I am not trying to do ywo operations.=
 I am delegating this work to stoi.</div></div></blockquote><div><br>And wh=
y should stoi be concerned with <i>anything</i> but converting a string to =
an integer? Why should it be concerned with offsetting the initial position=
 of that string by some value first?<br><br></div></div></blockquote><div>T=
hese funtions already are designed specially for=C2=A0std::string.</div></d=
iv></blockquote><div><br>And that is 99% of what is <i>wrong</i> with those=
 functions.<br><br></div></blockquote><div>Could you elaborate what is wron=
g with this? Maybe the C++ Standard has a defect placing these functions in=
 the header &lt;string&gt;.=C2=A0</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div>If you&#39;re going to add new overloads for these functio=
ns, those overloads should not <i>exacerbate</i> the existing flaws; they s=
hould <i>fix them</i>.<br><br></div></blockquote><div>As for me then I see =
that the overloads make the functions more flexible. It is what I always ne=
ed=C2=A0when a number is inside a string.</div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;"><div>Taking string_view (or becoming template functions t=
hat take basic_string_views) would be a far more reasonable proposal than w=
hat you&#39;re talking about.<br><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color:=
 rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><di=
v dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div=
>Two operations are being done either way, either within stoi or within you=
r code. Why should stoi be the one who is doing those two, instead of your =
code?<br><br></div></div></blockquote><div>Delegating this operation to the=
 functions makes your code cleaner=C2=A0and more clear.</div></div></blockq=
uote><div><br>&quot;cleaner and more clear&quot; is a matter of personal op=
inion. Code that tells me exactly what it&#39;s doing is &quot;cleaner and =
more clear&quot; to me. If you get a view and remove prefix characters from=
 it, I know what you&#39;re doing.<br><br>If you pass an integer to a funct=
ion, I have to look up its documentation to find out what it&#39;s doing. T=
hat&#39;s not &quot;more clear&quot; to me.<br></div></blockquote><div><br>=
</div><div>Without any doubts to understand=C2=A0your=C2=A0example shown ab=
ove a programmer needs to read tons of=C2=A0the documentation. At least he =
must be sure that the functions you used=C2=A0have not=C2=A0some side effec=
ts.</div><div><br></div><div>To use a string=C2=A0followed by a position in=
 the string is very natural because this pattern is used in many functions=
=C2=A0of class std:;string.</div><div><br></div><div>The code you showed ha=
s nothing common with the class std::string. It only makes the program more=
 confused because you introduced a new entity that is not required=C2=A0to =
convert a string to an arithmetic type.=C2=A0</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_170_1110670940.1443885377648--
------=_Part_169_1925034964.1443885377648--

.

------=_Part_1793_1162649877.1443886888441
Content-Type: multipart/alternative;
 boundary="----=_Part_1794_898092025.1443886888441"

------=_Part_1794_898092025.1443886888441
Content-Type: text/plain; charset=UTF-8



On Saturday, October 3, 2015 at 5:44:06 PM UTC+3, Nicol Bolas wrote:
>
> On Saturday, October 3, 2015 at 10:35:47 AM UTC-4, Vlad from Moscow wrote:
>>
>> On Saturday, October 3, 2015 at 5:16:53 PM UTC+3, Nicol Bolas wrote:
>>>
>>> On Saturday, October 3, 2015 at 4:35:08 AM UTC-4, Vlad from Moscow wrote:
>>>>
>>>> It is a wrong point of view. I am not trying to do ywo operations. I am
>>>> delegating this work to stoi.
>>>>
>>>
>>> And why should stoi be concerned with *anything* but converting a
>>> string to an integer? Why should it be concerned with offsetting the
>>> initial position of that string by some value first?
>>>
>>> These funtions already are designed specially for std::string.
>>
>
> And that is 99% of what is *wrong* with those functions.
>
> If you're going to add new overloads for these functions, those overloads
> should not *exacerbate* the existing flaws; they should *fix them*.
>
> Taking string_view (or becoming template functions that take
> basic_string_views) would be a far more reasonable proposal than what
> you're talking about.
>
> Two operations are being done either way, either within stoi or within
>>> your code. Why should stoi be the one who is doing those two, instead of
>>> your code?
>>>
>>> Delegating this operation to the functions makes your code cleaner and
>> more clear.
>>
>
> "cleaner and more clear" is a matter of personal opinion. Code that tells
> me exactly what it's doing is "cleaner and more clear" to me. If you get a
> view and remove prefix characters from it, I know what you're doing.
>
> If you pass an integer to a function, I have to look up its documentation
> to find out what it's doing. That's not "more clear" to me.
>

This family of conversion functions is an adaptation of the corresponding C
functions for class std::string.

C function deal with pointers and you can very easy to move the pointer
along a string.

However to do the same with objects std::string you need one more argument
that specifies a position within the string.

Otherwise you need to create a new object or to descend to the level of C
code or to introduce a new entity as you are trying to do for this simple
task.

But class std::string already has all what it needs to do the task.
The only thing you need to provide is to allow the class to use its own
features.


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_1794_898092025.1443886888441
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Saturday, October 3, 2015 at 5:44:06 PM UTC+3, Nicol Bolas wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;">On Saturday, October 3, 2015 at 10:35:47 AM U=
TC-4, Vlad from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204,=
 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">=
On Saturday, October 3, 2015 at 5:16:53 PM UTC+3, Nicol Bolas wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;"><div dir=3D"ltr">On Saturday, October 3, 2015 at 4:35=
:08 AM UTC-4, Vlad from Moscow wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(2=
04, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><div>It is a wrong point of view. I am not trying to do ywo operat=
ions. I am delegating this work to stoi.</div></div></blockquote><div><br>A=
nd why should stoi be concerned with <i>anything</i> but converting a strin=
g to an integer? Why should it be concerned with offsetting the initial pos=
ition of that string by some value first?<br><br></div></div></blockquote><=
div>These funtions already are designed specially for=C2=A0std::string.</di=
v></div></blockquote><div><br>And that is 99% of what is <i>wrong</i> with =
those functions.<br><br>If you&#39;re going to add new overloads for these =
functions, those overloads should not <i>exacerbate</i> the existing flaws;=
 they should <i>fix them</i>.<br><br>Taking string_view (or becoming templa=
te functions that take basic_string_views) would be a far more reasonable p=
roposal than what you&#39;re talking about.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div d=
ir=3D"ltr"><div>Two operations are being done either way, either within sto=
i or within your code. Why should stoi be the one who is doing those two, i=
nstead of your code?<br><br></div></div></blockquote><div>Delegating this o=
peration to the functions makes your code cleaner=C2=A0and more clear.</div=
></div></blockquote><div><br>&quot;cleaner and more clear&quot; is a matter=
 of personal opinion. Code that tells me exactly what it&#39;s doing is &qu=
ot;cleaner and more clear&quot; to me. If you get a view and remove prefix =
characters from it, I know what you&#39;re doing.<br><br>If you pass an int=
eger to a function, I have to look up its documentation to find out what it=
&#39;s doing. That&#39;s not &quot;more clear&quot; to me.<br></div></block=
quote><div><br></div><div>This family of=C2=A0conversion functions is an ad=
aptation of the corresponding=C2=A0C functions for class std::string.</div>=
<div><br></div><div>C function deal with pointers and you can very easy to =
move the pointer along a string.</div><div><br></div><div>However to do the=
 same with objects std::string you need one more=C2=A0argument that=C2=A0sp=
ecifies a position within the string.</div><div><br></div><div>Otherwise yo=
u need to create a new object or to descend to the level of C code or to in=
troduce a new entity as you are trying to do for this simple task.</div><di=
v><br></div><div>But class std::string already has all what it needs to do =
the task. The=C2=A0only thing you need to provide is to allow the class to =
use its own features.</div><div>=C2=A0</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_1794_898092025.1443886888441--
------=_Part_1793_1162649877.1443886888441--

.

------=_Part_2031_626908567.1443894272217
Content-Type: multipart/alternative;
 boundary="----=_Part_2032_969167613.1443894272217"

------=_Part_2032_969167613.1443894272217
Content-Type: text/plain; charset=UTF-8

On Saturday, October 3, 2015 at 11:16:17 AM UTC-4, Vlad from Moscow wrote:
>
>
> On Saturday, October 3, 2015 at 5:44:06 PM UTC+3, Nicol Bolas wrote:
>>
>> On Saturday, October 3, 2015 at 10:35:47 AM UTC-4, Vlad from Moscow wrote:
>>>
>>> On Saturday, October 3, 2015 at 5:16:53 PM UTC+3, Nicol Bolas wrote:
>>>>
>>>> On Saturday, October 3, 2015 at 4:35:08 AM UTC-4, Vlad from Moscow
>>>> wrote:
>>>>>
>>>>> It is a wrong point of view. I am not trying to do ywo operations. I
>>>>> am delegating this work to stoi.
>>>>>
>>>>
>>>> And why should stoi be concerned with *anything* but converting a
>>>> string to an integer? Why should it be concerned with offsetting the
>>>> initial position of that string by some value first?
>>>>
>>>> These funtions already are designed specially for std::string.
>>>
>>
>> And that is 99% of what is *wrong* with those functions.
>>
>> Could you elaborate what is wrong with this? Maybe the C++ Standard has a
> defect placing these functions in the header <string>.
>

I thought it would be obvious.

These functions only work with std::string. They don't work with other
string type that anyone has ever written. They don't work with
std::basic_string<char, ..., MyAllocator>. They don't even have overloads
for `std::u16string` or `std::u32string`.

std::basic_string is, first and foremost, a container. It manages how
character data gets stored. Why should `stoi` care how character data gets
stored, allocated, or anything of that nature? All `stoi` needs is a way to
access a character array.

It's asinine to have to waste time copying a string just because `stoi` has
an over-constrained interface. We don't need to over-constrain the
interface *more*.


>
>
>> If you're going to add new overloads for these functions, those overloads
>> should not *exacerbate* the existing flaws; they should *fix them*.
>>
>> As for me then I see that the overloads make the functions more flexible.
> It is what I always need when a number is inside a string.
>

No, it makes them *less flexible*. It only allows offsetting from the
beginning, not the end.

Just because something is "what I always need" does not mean that it is
"flexible".


>
>
>> Taking string_view (or becoming template functions that take
>> basic_string_views) would be a far more reasonable proposal than what
>> you're talking about.
>>
>> Two operations are being done either way, either within stoi or within
>>>> your code. Why should stoi be the one who is doing those two, instead of
>>>> your code?
>>>>
>>>> Delegating this operation to the functions makes your code cleaner and
>>> more clear.
>>>
>>
>> "cleaner and more clear" is a matter of personal opinion. Code that tells
>> me exactly what it's doing is "cleaner and more clear" to me. If you get a
>> view and remove prefix characters from it, I know what you're doing.
>>
>> If you pass an integer to a function, I have to look up its documentation
>> to find out what it's doing. That's not "more clear" to me.
>>
>
> Without any doubts to understand your example shown above a programmer
> needs to read tons of the documentation. At least he must be sure that the
> functions you used have not some side effects.
>

.... what kind of side effects would any sane implementation have of a
function called `find_first_of`?

There's defensive coding, and then there's *paranoid* coding. You're
talking about the latter. If you assume that behind every possible function
call lurks a sleeping Cthulhu ready to tear your code apart, you'll never
get anywhere.


> To use a string followed by a position in the string is very natural
> because this pattern is used in many functions of class std:;string.
>

And every single such function *also* has an overload that takes an
iterator rather than an integer. Are you now suggesting we do that too?

It should be noted that many people don't like std::string's interface. So
defending your position by citing its interface is like saying "look at how
that garbage dump works. We need to make our code look like that!"

It should also be noted that every such function is a *member function* of
std::basic_string. Thus, the integer value is clearly associated with the
string. It's not "string followed by a position". It's
`string.func_name(position)`. That's a very different thing.

`stoi` is a non-member function.


> The code you showed has nothing common with the class std::string.
>

You say that as though std::string's interface were something to boast
about ;)


> It only makes the program more confused because you introduced a new
> entity that is not required to convert a string to an arithmetic type.
>

That's an implementation detail. Also, if stoi were implemented sanely,
you'd already be implicitly constructing a 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_2032_969167613.1443894272217
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, October 3, 2015 at 11:16:17 AM UTC-4, Vlad from Moscow wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><br>On Saturday, October 3, 201=
5 at 5:44:06 PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(20=
4,204,204);border-left-width:1px;border-left-style:solid">On Saturday, Octo=
ber 3, 2015 at 10:35:47 AM UTC-4, Vlad from Moscow wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">=
<div dir=3D"ltr">On Saturday, October 3, 2015 at 5:16:53 PM UTC+3, Nicol Bo=
las wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1p=
x;border-left-style:solid"><div dir=3D"ltr">On Saturday, October 3, 2015 at=
 4:35:08 AM UTC-4, Vlad from Moscow wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(2=
04,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"=
><div>It is a wrong point of view. I am not trying to do ywo operations. I =
am delegating this work to stoi.</div></div></blockquote><div><br>And why s=
hould stoi be concerned with <i>anything</i> but converting a string to an =
integer? Why should it be concerned with offsetting the initial position of=
 that string by some value first?<br><br></div></div></blockquote><div>Thes=
e funtions already are designed specially for=C2=A0std::string.</div></div>=
</blockquote><div><br>And that is 99% of what is <i>wrong</i> with those fu=
nctions.<br><br></div></blockquote><div>Could you elaborate what is wrong w=
ith this? Maybe the C++ Standard has a defect placing these functions in th=
e header &lt;string&gt;.</div></blockquote><div><br>I thought it would be o=
bvious.<br><br>These functions only work with std::string. They don&#39;t w=
ork with other string type that anyone has ever written. They don&#39;t wor=
k with std::basic_string&lt;char, ..., MyAllocator&gt;. They don&#39;t even=
 have overloads for `std::u16string` or `std::u32string`.<br><br>std::basic=
_string is, first and foremost, a container. It manages how character data =
gets stored. Why should `stoi` care how character data gets stored, allocat=
ed, or anything of that nature? All `stoi` needs is a way to access a chara=
cter array.<br><br>It&#39;s asinine to have to waste time copying a string =
just because `stoi` has an over-constrained interface. We don&#39;t need to=
 over-constrain the interface <i>more</i>.<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rg=
b(204,204,204);border-left-width:1px;border-left-style:solid"><div>If you&#=
39;re going to add new overloads for these functions, those overloads shoul=
d not <i>exacerbate</i> the existing flaws; they should <i>fix them</i>.<br=
><br></div></blockquote><div>As for me then I see that the overloads make t=
he functions more flexible. It is what I always need=C2=A0when a number is =
inside a string.</div></blockquote><div><br>No, it makes them <i>less flexi=
ble</i>. It only allows offsetting from the beginning, not the end.<br><br>=
Just because something is &quot;what I always need&quot; does not mean that=
 it is &quot;flexible&quot;.<br>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204)=
;border-left-width:1px;border-left-style:solid"><div>Taking string_view (or=
 becoming template functions that take basic_string_views) would be a far m=
ore reasonable proposal than what you&#39;re talking about.<br><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-l=
eft:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-lef=
t-style:solid"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(=
204,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr=
"><div>Two operations are being done either way, either within stoi or with=
in your code. Why should stoi be the one who is doing those two, instead of=
 your code?<br><br></div></div></blockquote><div>Delegating this operation =
to the functions makes your code cleaner=C2=A0and more clear.</div></div></=
blockquote><div><br>&quot;cleaner and more clear&quot; is a matter of perso=
nal opinion. Code that tells me exactly what it&#39;s doing is &quot;cleane=
r and more clear&quot; to me. If you get a view and remove prefix character=
s from it, I know what you&#39;re doing.<br><br>If you pass an integer to a=
 function, I have to look up its documentation to find out what it&#39;s do=
ing. That&#39;s not &quot;more clear&quot; to me.<br></div></blockquote><di=
v><br></div><div>Without any doubts to understand=C2=A0your=C2=A0example sh=
own above a programmer needs to read tons of=C2=A0the documentation. At lea=
st he must be sure that the functions you used=C2=A0have not=C2=A0some side=
 effects.</div></blockquote><div><br>... what kind of side effects would an=
y sane implementation have of a function called `find_first_of`?<br><br>The=
re&#39;s defensive coding, and then there&#39;s <i>paranoid</i> coding. You=
&#39;re talking about the latter. If you assume that behind every possible =
function call lurks a sleeping Cthulhu ready to tear your code apart, you&#=
39;ll never get anywhere.<br>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div>To use a string=C2=A0followed by a position in the string i=
s very natural because this pattern is used in many functions=C2=A0of class=
 std:;string.</div></blockquote><div><br>And every single such function <i>=
also</i> has an overload that takes an iterator rather than an integer. Are=
 you now suggesting we do that too?<br><br>It should be noted that many peo=
ple don&#39;t like std::string&#39;s interface. So defending your position =
by citing its interface is like saying &quot;look at how that garbage dump =
works. We need to make our code look like that!&quot;<br><br>It should also=
 be noted that every such function is a <i>member function</i> of std::basi=
c_string. Thus, the integer value is clearly associated with the string. It=
&#39;s not &quot;string followed by a position&quot;. It&#39;s `string.func=
_name(position)`. That&#39;s a very different thing.<br><br>`stoi` is a non=
-member function.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div></div><div>The code you showed has nothing common with the class st=
d::string.</div></blockquote><div><br>You say that as though std::string&#3=
9;s interface were something to boast about ;)<br>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div>It only makes the program more confuse=
d because you introduced a new entity that is not required=C2=A0to convert =
a string to an arithmetic type.</div></blockquote><div><br>That&#39;s an im=
plementation detail. Also, if stoi were implemented sanely, you&#39;d alrea=
dy be implicitly constructing a string_view.<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_2032_969167613.1443894272217--
------=_Part_2031_626908567.1443894272217--

.

------=_Part_273_1224155199.1443894501876
Content-Type: multipart/alternative;
 boundary="----=_Part_274_906985058.1443894501876"

------=_Part_274_906985058.1443894501876
Content-Type: text/plain; charset=UTF-8

On Saturday, October 3, 2015 at 11:41:28 AM UTC-4, Vlad from Moscow wrote:
>
> This family of conversion functions is an adaptation of the
> corresponding C functions for class std::string.
>

> C function deal with pointers and you can very easy to move the pointer
> along a string.
>
> However to do the same with objects std::string you need one more argument
> that specifies a position within the string.
>

If I wanted to code in C, I would be *coding in C*.

C++ has ways of dealing with functions that need access to a sequence in
such a way that does not modify said sequence. We call them "ranges".
std::string_view is such a range.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_274_906985058.1443894501876
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, October 3, 2015 at 11:41:28 AM UTC-4, Vlad fr=
om Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div></div><di=
v>This family of=C2=A0conversion functions is an adaptation of the correspo=
nding=C2=A0C functions for class std::string.</div></blockquote><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div><br></div><div>C function deal with =
pointers and you can very easy to move the pointer along a string.</div><di=
v><br></div><div>However to do the same with objects std::string you need o=
ne more=C2=A0argument that=C2=A0specifies a position within the string.</di=
v></blockquote><div><br>If I wanted to code in C, I would be <i>coding in C=
</i>.<br><br>C++ has ways of dealing with functions that need access to a s=
equence in such a way that does not modify said sequence. We call them &quo=
t;ranges&quot;. std::string_view is such a range.<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_274_906985058.1443894501876--
------=_Part_273_1224155199.1443894501876--

.

------=_Part_318_1783546128.1443897697698
Content-Type: multipart/alternative;
 boundary="----=_Part_319_1708125550.1443897697698"

------=_Part_319_1708125550.1443897697698
Content-Type: text/plain; charset=UTF-8

On Saturday, October 3, 2015 at 8:44:32 PM UTC+3, Nicol Bolas wrote:
>
> On Saturday, October 3, 2015 at 11:16:17 AM UTC-4, Vlad from Moscow wrote:
>>
>>
>> On Saturday, October 3, 2015 at 5:44:06 PM UTC+3, Nicol Bolas wrote:
>>>
>>> On Saturday, October 3, 2015 at 10:35:47 AM UTC-4, Vlad from Moscow
>>> wrote:
>>>>
>>>> On Saturday, October 3, 2015 at 5:16:53 PM UTC+3, Nicol Bolas wrote:
>>>>>
>>>>> On Saturday, October 3, 2015 at 4:35:08 AM UTC-4, Vlad from Moscow
>>>>> wrote:
>>>>>>
>>>>>> It is a wrong point of view. I am not trying to do ywo operations. I
>>>>>> am delegating this work to stoi.
>>>>>>
>>>>>
>>>>> And why should stoi be concerned with *anything* but converting a
>>>>> string to an integer? Why should it be concerned with offsetting the
>>>>> initial position of that string by some value first?
>>>>>
>>>>> These funtions already are designed specially for std::string.
>>>>
>>>
>>> And that is 99% of what is *wrong* with those functions.
>>>
>>> Could you elaborate what is wrong with this? Maybe the C++ Standard has
>> a defect placing these functions in the header <string>.
>>
>
> I thought it would be obvious.
>
> These functions only work with std::string.
>

And what? And what I am speaking about? I am speaking about std::string and
the functions that deal with the std::string.



> They don't work with other string type that anyone has ever written. They
> don't work with std::basic_string<char, ..., MyAllocator>. They don't even
> have overloads for `std::u16string` or `std::u32string`.
>
> std::basic_string is, first and foremost, a container. It manages how
> character data gets stored. Why should `stoi` care how character data gets
> stored, allocated, or anything of that nature? All `stoi` needs is a way to
> access a character array.
>
> It's asinine to have to waste time copying a string just because `stoi`
> has an over-constrained interface. We don't need to over-constrain the
> interface *more*.
>
>
>>
>>
>>> If you're going to add new overloads for these functions, those
>>> overloads should not *exacerbate* the existing flaws; they should *fix
>>> them*.
>>>
>>> As for me then I see that the overloads make the functions more
>> flexible. It is what I always need when a number is inside a string.
>>
>
> No, it makes them *less flexible*. It only allows offsetting from the
> beginning, not the end.
>
> Till now I thought that if I am allowed to do one more thing then my
possibilities are enlarged. You are trying to disprove that.:)


> Just because something is "what I always need" does not mean that it is
> "flexible".
>
>
>>
>>
>>> Taking string_view (or becoming template functions that take
>>> basic_string_views) would be a far more reasonable proposal than what
>>> you're talking about.
>>>
>>> Two operations are being done either way, either within stoi or within
>>>>> your code. Why should stoi be the one who is doing those two, instead of
>>>>> your code?
>>>>>
>>>>> Delegating this operation to the functions makes your code cleaner and
>>>> more clear.
>>>>
>>>
>>> "cleaner and more clear" is a matter of personal opinion. Code that
>>> tells me exactly what it's doing is "cleaner and more clear" to me. If you
>>> get a view and remove prefix characters from it, I know what you're doing.
>>>
>>> If you pass an integer to a function, I have to look up its
>>> documentation to find out what it's doing. That's not "more clear" to me.
>>>
>>
>> Without any doubts to understand your example shown above a programmer
>> needs to read tons of the documentation. At least he must be sure that the
>> functions you used have not some side effects.
>>
>
> ... what kind of side effects would any sane implementation have of a
> function called `find_first_of`?
>
> There's defensive coding, and then there's *paranoid* coding. You're
> talking about the latter. If you assume that behind every possible function
> call lurks a sleeping Cthulhu ready to tear your code apart, you'll never
> get anywhere.
>
>
I am talking about that you are trying to sell me a fur coat when i
need only a missing button .:) And it looks like you will still try to sell
your  fur coat if somebody else ask you about fot rxample gloves.:) I would
not say that who needs a missing button is a paranoic fot the reason that
he does not want to buy your fur coat.:)

And it looks like

> To use a string followed by a position in the string is very natural
>> because this pattern is used in many functions of class std:;string.
>>
>
> And every single such function *also* has an overload that takes an
> iterator rather than an integer. Are you now suggesting we do that too?
>
> It should be noted that many people don't like std::string's interface. So
> defending your position by citing its interface is like saying "look at how
> that garbage dump works. We need to make our code look like that!"
>
> I really feel for this people.:) But why should I suffer if somebody do
not like the string's interface? All I want Is to specify a position in a
string. May I do this?



> It should also be noted that every such function is a *member function*
> of std::basic_string. Thus, the integer value is clearly associated with
> the string. It's not "string followed by a position". It's
> `string.func_name(position)`. That's a very different thing.
>
> `stoi` is a non-member function.
>

Yes stoi is not a member function. But it is designed to work with strings
that can contain at some position a number.:)

>
>
>> The code you showed has nothing common with the class std::string.
>>
>
> Really?:)


> You say that as though std::string's interface were something to boast
> about ;)
>
>
>> It only makes the program more confused because you introduced a new
>> entity that is not required to convert a string to an arithmetic type.
>>
>
> That's an implementation detail. Also, if stoi were implemented sanely,
> you'd already be implicitly constructing a 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_319_1708125550.1443897697698
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Saturday, October 3, 2015 at 8:44:32 PM UTC+3, Nicol Bolas wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;">On Saturday, October 3, 2015 at 11:16:17 AM UTC-4, Vl=
ad from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;"><br>On Saturday, October =
3, 2015 at 5:44:06 PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-co=
lor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"=
>On Saturday, October 3, 2015 at 10:35:47 AM UTC-4, Vlad from Moscow wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div dir=3D"ltr">On Saturday, October 3, 2015 =
at 5:16:53 PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb=
(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div di=
r=3D"ltr">On Saturday, October 3, 2015 at 4:35:08 AM UTC-4, Vlad from Mosco=
w wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8e=
x; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wi=
dth: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>It is a wrong po=
int of view. I am not trying to do ywo operations. I am delegating this wor=
k to stoi.</div></div></blockquote><div><br>And why should stoi be concerne=
d with <i>anything</i> but converting a string to an integer? Why should it=
 be concerned with offsetting the initial position of that string by some v=
alue first?<br><br></div></div></blockquote><div>These funtions already are=
 designed specially for=C2=A0std::string.</div></div></blockquote><div><br>=
And that is 99% of what is <i>wrong</i> with those functions.<br><br></div>=
</blockquote><div>Could you elaborate what is wrong with this? Maybe the C+=
+ Standard has a defect placing these functions in the header &lt;string&gt=
;.</div></blockquote><div><br>I thought it would be obvious.<br><br>These f=
unctions only work with std::string. </div></blockquote><div><br></div><div=
>And what? And what I am speaking about? I am speaking about std::string an=
d the functions that deal with the std::string.</div><div><br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;"><div>They don&#39;t work with othe=
r string type that anyone has ever written. They don&#39;t work with std::b=
asic_string&lt;char, ..., MyAllocator&gt;. They don&#39;t even have overloa=
ds for `std::u16string` or `std::u32string`.<br><br>std::basic_string is, f=
irst and foremost, a container. It manages how character data gets stored. =
Why should `stoi` care how character data gets stored, allocated, or anythi=
ng of that nature? All `stoi` needs is a way to access a character array.<b=
r><br>It&#39;s asinine to have to waste time copying a string just because =
`stoi` has an over-constrained interface. We don&#39;t need to over-constra=
in the interface <i>more</i>.<br>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-colo=
r: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div>If you&#39;re going to ad=
d new overloads for these functions, those overloads should not <i>exacerba=
te</i> the existing flaws; they should <i>fix them</i>.<br><br></div></bloc=
kquote><div>As for me then I see that the overloads make the functions more=
 flexible. It is what I always need=C2=A0when a number is inside a string.<=
/div></blockquote><div><br>No, it makes them <i>less flexible</i>. It only =
allows offsetting from the beginning, not the end.<br><br></div></blockquot=
e><div>Till now I thought that if I am allowed to do=C2=A0one more thing th=
en my possibilities are=C2=A0enlarged. You are trying to disprove that.:)</=
div><div>=C2=A0=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 2=
04); border-left-width: 1px; border-left-style: solid;"><div>Just because s=
omething is &quot;what I always need&quot; does not mean that it is &quot;f=
lexible&quot;.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204=
, 204); border-left-width: 1px; border-left-style: solid;"><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;"><div>Taking string_view (or becoming template=
 functions that take basic_string_views) would be a far more reasonable pro=
posal than what you&#39;re talking about.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border=
-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style:=
 solid;"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(2=
04, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><div>Two operations are being done either way, either within stoi =
or within your code. Why should stoi be the one who is doing those two, ins=
tead of your code?<br><br></div></div></blockquote><div>Delegating this ope=
ration to the functions makes your code cleaner=C2=A0and more clear.</div><=
/div></blockquote><div><br>&quot;cleaner and more clear&quot; is a matter o=
f personal opinion. Code that tells me exactly what it&#39;s doing is &quot=
;cleaner and more clear&quot; to me. If you get a view and remove prefix ch=
aracters from it, I know what you&#39;re doing.<br><br>If you pass an integ=
er to a function, I have to look up its documentation to find out what it&#=
39;s doing. That&#39;s not &quot;more clear&quot; to me.<br></div></blockqu=
ote><div><br></div><div>Without any doubts to understand=C2=A0your=C2=A0exa=
mple shown above a programmer needs to read tons of=C2=A0the documentation.=
 At least he must be sure that the functions you used=C2=A0have not=C2=A0so=
me side effects.</div></blockquote><div><br>... what kind of side effects w=
ould any sane implementation have of a function called `find_first_of`?<br>=
<br>There&#39;s defensive coding, and then there&#39;s <i>paranoid</i> codi=
ng. You&#39;re talking about the latter. If you assume that behind every po=
ssible function call lurks a sleeping Cthulhu ready to tear your code apart=
, you&#39;ll never get anywhere.<br>=C2=A0</div></blockquote><div>I am talk=
ing about that you are trying to sell me a fur coat when i need=C2=A0only a=
 missing button=C2=A0.:) And it looks like you will still try to sell your =
=C2=A0fur coat if somebody else ask you about fot rxample gloves.:) I would=
 not say that who needs a missing button is a paranoic=C2=A0fot the reason=
=C2=A0that he does not want to buy=C2=A0your fur coat.:)=C2=A0</div><div><b=
r></div><div>And it looks like =C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color:=
 rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-=
left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; b=
order-left-style: solid;"><div>To use a string=C2=A0followed by a position =
in the string is very natural because this pattern is used in many function=
s=C2=A0of class std:;string.</div></blockquote><div><br>And every single su=
ch function <i>also</i> has an overload that takes an iterator rather than =
an integer. Are you now suggesting we do that too?<br><br>It should be note=
d that many people don&#39;t like std::string&#39;s interface. So defending=
 your position by citing its interface is like saying &quot;look at how tha=
t garbage dump works. We need to make our code look like that!&quot;<br><br=
></div></blockquote><div>I really feel for this people.:) But why should I =
suffer if somebody do not like=C2=A0the string&#39;s interface? All I want =
Is to specify a position in a string. May I do this?</div><div><br></div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;"><div>It should also be noted th=
at every such function is a <i>member function</i> of std::basic_string. Th=
us, the integer value is clearly associated with the string. It&#39;s not &=
quot;string followed by a position&quot;. It&#39;s `string.func_name(positi=
on)`. That&#39;s a very different thing.<br><br>`stoi` is a non-member func=
tion.<br></div></blockquote><div><br></div><div>Yes stoi is not a member fu=
nction. But it is=C2=A0designed to work with strings that can=C2=A0contain=
=C2=A0at some position a number.:)=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-col=
or: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div></div><div>The code you =
showed has nothing common with the class std::string.</div></blockquote><di=
v><br></div></blockquote><div>Really?:)</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex;=
 border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left=
-style: solid;"><div>You say that as though std::string&#39;s interface wer=
e something to boast about ;)<br>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-colo=
r: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><=
div>It only makes the program more confused because you introduced a new en=
tity that is not required=C2=A0to convert a string to an arithmetic type.</=
div></blockquote><div><br>That&#39;s an implementation detail. Also, if sto=
i were implemented sanely, you&#39;d already be implicitly constructing a s=
tring_view.<br></div></blockquote>

<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_319_1708125550.1443897697698--
------=_Part_318_1783546128.1443897697698--

.

------=_Part_1864_625575829.1443897963014
Content-Type: multipart/alternative;
 boundary="----=_Part_1865_1197715270.1443897963015"

------=_Part_1865_1197715270.1443897963015
Content-Type: text/plain; charset=UTF-8



On Saturday, October 3, 2015 at 8:48:22 PM UTC+3, Nicol Bolas wrote:
>
> On Saturday, October 3, 2015 at 11:41:28 AM UTC-4, Vlad from Moscow wrote:
>>
>> This family of conversion functions is an adaptation of the
>> corresponding C functions for class std::string.
>>
>
>> C function deal with pointers and you can very easy to move the pointer
>> along a string.
>>
>> However to do the same with objects std::string you need one
>> more argument that specifies a position within the string.
>>
>
> If I wanted to code in C, I would be *coding in C*.
>
> C++ has ways of dealing with functions that need access to a sequence in
> such a way that does not modify said sequence. We call them "ranges".
> std::string_view is such a range.
>

I need not a range. I need just a position.:)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_1865_1197715270.1443897963015
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Saturday, October 3, 2015 at 8:48:22 PM UTC+3, Nicol Bolas wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;"><div dir=3D"ltr">On Saturday, October 3, 2015=
 at 11:41:28 AM UTC-4, Vlad from Moscow wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-col=
or: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">=
<div></div><div>This family of=C2=A0conversion functions is an adaptation o=
f the corresponding=C2=A0C functions for class std::string.</div></blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pa=
dding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: =
1px; border-left-style: solid;"><div><br></div><div>C function deal with po=
inters and you can very easy to move the pointer along a string.</div><div>=
<br></div><div>However to do the same with objects std::string you need one=
 more=C2=A0argument that=C2=A0specifies a position within the string.</div>=
</blockquote><div><br>If I wanted to code in C, I would be <i>coding in C</=
i>.<br><br>C++ has ways of dealing with functions that need access to a seq=
uence in such a way that does not modify said sequence. We call them &quot;=
ranges&quot;. std::string_view is such a range.<br></div></div></blockquote=
><div><br></div><div>I need not a range. I need just a position.:)=C2=A0</d=
iv>

<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_1865_1197715270.1443897963015--
------=_Part_1864_625575829.1443897963014--

.

------=_Part_500_333091401.1443907242208
Content-Type: multipart/alternative;
 boundary="----=_Part_501_891154447.1443907242209"

------=_Part_501_891154447.1443907242209
Content-Type: text/plain; charset=UTF-8

On Saturday, October 3, 2015 at 2:41:38 PM UTC-4, Vlad from Moscow wrote:
>
> On Saturday, October 3, 2015 at 8:44:32 PM UTC+3, Nicol Bolas wrote:
>>
>> On Saturday, October 3, 2015 at 11:16:17 AM UTC-4, Vlad from Moscow wrote:
>>>
>>>
>>> On Saturday, October 3, 2015 at 5:44:06 PM UTC+3, Nicol Bolas wrote:
>>>>
>>>> On Saturday, October 3, 2015 at 10:35:47 AM UTC-4, Vlad from Moscow
>>>> wrote:
>>>>>
>>>>> These funtions already are designed specially for std::string.
>>>>>
>>>>
>>>> And that is 99% of what is *wrong* with those functions.
>>>>
>>>> Could you elaborate what is wrong with this? Maybe the C++ Standard has
>>> a defect placing these functions in the header <string>.
>>>
>>
>> I thought it would be obvious.
>>
>> These functions only work with std::string.
>>
>
> And what? And what I am speaking about? I am speaking about std::string
> and the functions that deal with the std::string.
>

.... Please take note of the part of the conversation you're replying to. I
said that those functions being designed only for std::string was exactly
what was wrong with it. You asked for elaboration. And I offered it.

So how does your statement make sense in that context? I responded to the
exact question you asked, then you claim that my response is irrelevant.

Yes, `stoi` and such are designed for std::string. That is *what* is wrong
with them. People need to be able to convert *any* string to
integers/floats/etc, not just std::string. That's *why* it is wrong for
them to be designed for std::string.

I am talking about that you are trying to sell me a fur coat when i
> need only a missing button .:)
>

No, I want to see improvements to `stoi` that will solve your problem *and
those of other people*.

See the difference? You getting the bare minimum needed to help you only
helps you. Getting stoi and friends to work with string_view helps you *and*
helps tons of other people.

Standard library features need to service the needs of more than yourself.

--

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

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

On Saturday, October 3, 2015 at 2:41:38 PM UTC-4, Vlad from Moscow wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On Saturday, October 3, 2015 at =
8:44:32 PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">On Saturday, October 3=
, 2015 at 11:16:17 AM UTC-4, Vlad from Moscow wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-c=
olor:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><br>On=
 Saturday, October 3, 2015 at 5:44:06 PM UTC+3, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex=
;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style=
:solid">On Saturday, October 3, 2015 at 10:35:47 AM UTC-4, Vlad from Moscow=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;b=
order-left-style:solid"><div dir=3D"ltr"><div dir=3D"ltr"></div><div>These =
funtions already are designed specially for=C2=A0std::string.</div></div></=
blockquote><div><br>And that is 99% of what is <i>wrong</i> with those func=
tions.<br><br></div></blockquote><div>Could you elaborate what is wrong wit=
h this? Maybe the C++ Standard has a defect placing these functions in the =
header &lt;string&gt;.</div></blockquote><div><br>I thought it would be obv=
ious.<br><br>These functions only work with std::string. </div></blockquote=
><div><br></div><div>And what? And what I am speaking about? I am speaking =
about std::string and the functions that deal with the std::string.</div></=
blockquote><div><br>... Please take note of the part of the conversation yo=
u&#39;re replying to. I said that those functions being designed only for s=
td::string was exactly what was wrong with it. You asked for elaboration. A=
nd I offered it.<br><br>So how does your statement make sense in that conte=
xt? I responded to the exact question you asked, then you claim that my res=
ponse is irrelevant.<br><br>Yes, `stoi` and such are designed for std::stri=
ng. That is <i>what</i> is wrong with them. People need to be able to conve=
rt <i>any</i> string to integers/floats/etc, not just std::string. That&#39=
;s <i>why</i> it is wrong for them to be designed for std::string.<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div></div><div>I am talk=
ing about that you are trying to sell me a fur coat when i need=C2=A0only a=
 missing button=C2=A0.:)</div></blockquote><div><br>No, I want to see impro=
vements to `stoi` that will solve your problem <i>and those of other people=
</i>.<br><br>See the difference? You getting the bare minimum needed to hel=
p you only helps you. Getting stoi and friends to work with string_view hel=
ps you <i>and</i> helps tons of other people.<br><br>Standard library featu=
res need to service the needs of more than yourself.<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_501_891154447.1443907242209--
------=_Part_500_333091401.1443907242208--

.

------=_Part_2195_759257488.1443951264177
Content-Type: multipart/alternative;
 boundary="----=_Part_2196_1706527559.1443951264178"

------=_Part_2196_1706527559.1443951264178
Content-Type: text/plain; charset=UTF-8



On Sunday, October 4, 2015 at 12:20:42 AM UTC+3, Nicol Bolas wrote:
>
> On Saturday, October 3, 2015 at 2:41:38 PM UTC-4, Vlad from Moscow wrote:
>>
>> On Saturday, October 3, 2015 at 8:44:32 PM UTC+3, Nicol Bolas wrote:
>>>
>>> On Saturday, October 3, 2015 at 11:16:17 AM UTC-4, Vlad from Moscow
>>> wrote:
>>>>
>>>>
>>>> On Saturday, October 3, 2015 at 5:44:06 PM UTC+3, Nicol Bolas wrote:
>>>>>
>>>>> On Saturday, October 3, 2015 at 10:35:47 AM UTC-4, Vlad from Moscow
>>>>> wrote:
>>>>>>
>>>>>> These funtions already are designed specially for std::string.
>>>>>>
>>>>>
>>>>> And that is 99% of what is *wrong* with those functions.
>>>>>
>>>>> Could you elaborate what is wrong with this? Maybe the C++ Standard
>>>> has a defect placing these functions in the header <string>.
>>>>
>>>
>>> I thought it would be obvious.
>>>
>>> These functions only work with std::string.
>>>
>>
>> And what? And what I am speaking about? I am speaking about std::string
>> and the functions that deal with the std::string.
>>
>
> ... Please take note of the part of the conversation you're replying to. I
> said that those functions being designed only for std::string was exactly
> what was wrong with it. You asked for elaboration. And I offered it.
>
> So how does your statement make sense in that context? I responded to the
> exact question you asked, then you claim that my response is irrelevant.
>
> Yes, `stoi` and such are designed for std::string. That is *what* is
> wrong with them. People need to be able to convert *any* string to
> integers/floats/etc, not just std::string. That's *why* it is wrong for
> them to be designed for std::string.
>
> I am talking about that you are trying to sell me a fur coat when i
>> need only a missing button .:)
>>
>
> No, I want to see improvements to `stoi` that will solve your problem *and
> those of other people*.
>
> See the difference? You getting the bare minimum needed to help you only
> helps you. Getting stoi and friends to work with string_view helps you
> *and* helps tons of other people.
>
> Standard library features need to service the needs of more than yourself.
>

The functions initially shall be declared with the parameter pos. It is a
serious standard defect.

So I am going to remedy this defect. It does not depend on whether it is
helpful personally for you or not.

In fact the functions is useless in most cases and the programmers have to
descend to the C level and use for example C function strtoul directly
instead of stoul. So they do not deal with the std::string. They deal with
char *. And moreover in this case the parameter idx is also useless from
the point of view of using objects of type std::string.

It is enough to add one more parameter to the functions and the situation
is changed dramatically.

Here is a simple example. I wrote a simplified implementation of the
overloaded stoul that to demonstrate just the idea.

#include <iostream>
#include <string>

unsigned long stoul( const std::string &s, std::string::size_type pos,
size_t* idx = 0, int base = 10 )
{
    const char *nptr = s.c_str();
    char *end_ptr;

    unsigned long value = std::strtoul( nptr + pos, ( idx == 0 ? NULL :
&end_ptr ), base );

    if ( idx ) *idx = end_ptr - nptr;

    return value;
}

int main()
{
    const char *digits = "0123456789";
    std::string s( "#1, ##2, ###3, ####4, #####5" );

    size_t n = 0;
    for ( std::string::size_type pos = 0; ( pos = s.find_first_of( digits,
pos ) ) != std::string::npos; )
    {
        std::cout << ::stoul( s, pos, &pos ) << ' ';
        ++n;
    }

    std::cout << "\nThere are " << n << " numbers in the string" <<
std::endl;

    std::cout << "The first number is " << ::stoul( s, s.find_first_of(
digits ) ) << std::endl;
    std::cout << "The last number is  " << ::stoul( s, s.find_last_of(
digits ) ) << std::endl;
}

The program output is

1 2 3 4 5
There are 5 numbers in the string
The first number is 1
The last number is  5

There is no any need to introduce new entities that to do this simple task.
All is done in the frames of the class std::string because all already
exists and is enough to do the task.

This idiom

while ( ( pos = s.find_first_of( something, pos ) ) != std::string::npos )
{
    /*...*/
}

or

while ( ( pos = s.find( something, pos ) ) != std::string::npos )
{
    /*...*/
}

occurs numerous times in the code base and very clear for all programmers.

Here is the string itself that is accentuated.

stoul is in fact a static method of the class std::string. It serves
objects of the type.

They need not a third entity or even more entities to do the task.

Keep It Simple, Stuipid!:)

As for this code

stoul( s.view().remove_prefix(s.find_first_of( "0123456789" )))


then it is simply very awful.

For example

What and where does remove_prefix remove?

Is s being changed?

Why is there used remove_prefix when we were not going to remove anything
in our string?

How to use the next position in the string?

Wnat will be with s after this statement?

Why are we introducing new entities like view and remove_prefix when we
already have all what we need?

What idx will the call return?

Will this idx be valid for the view or for the original string?

And at last but not least

How does the overloaded functions prevent you to use such awful or as you
think splendid 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_2196_1706527559.1443951264178
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, October 4, 2015 at 12:20:42 AM UTC+3, Nicol Bolas wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;">On Saturday, October 3, 2015 at 2:41:38 PM UTC=
-4, Vlad from Moscow wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 2=
04); border-left-width: 1px; border-left-style: solid;">On Saturday, Octobe=
r 3, 2015 at 8:44:32 PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-=
color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid=
;">On Saturday, October 3, 2015 at 11:16:17 AM UTC-4, Vlad from Moscow wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pad=
ding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1=
px; border-left-style: solid;"><br>On Saturday, October 3, 2015 at 5:44:06 =
PM UTC+3, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;">On Saturday, Octob=
er 3, 2015 at 10:35:47 AM UTC-4, Vlad from Moscow wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div dir=3D"ltr"><div dir=3D"ltr"></div><div>These funtions alr=
eady are designed specially for=C2=A0std::string.</div></div></blockquote><=
div><br>And that is 99% of what is <i>wrong</i> with those functions.<br><b=
r></div></blockquote><div>Could you elaborate what is wrong with this? Mayb=
e the C++ Standard has a defect placing these functions in the header &lt;s=
tring&gt;.</div></blockquote><div><br>I thought it would be obvious.<br><br=
>These functions only work with std::string. </div></blockquote><div><br></=
div><div>And what? And what I am speaking about? I am speaking about std::s=
tring and the functions that deal with the std::string.</div></blockquote><=
div><br>... Please take note of the part of the conversation you&#39;re rep=
lying to. I said that those functions being designed only for std::string w=
as exactly what was wrong with it. You asked for elaboration. And I offered=
 it.<br><br>So how does your statement make sense in that context? I respon=
ded to the exact question you asked, then you claim that my response is irr=
elevant.<br><br>Yes, `stoi` and such are designed for std::string. That is =
<i>what</i> is wrong with them. People need to be able to convert <i>any</i=
> string to integers/floats/etc, not just std::string. That&#39;s <i>why</i=
> it is wrong for them to be designed for std::string.<br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;"><div></div><div>I am talking about that you are tryin=
g to sell me a fur coat when i need=C2=A0only a missing button=C2=A0.:)</di=
v></blockquote><div><br>No, I want to see improvements to `stoi` that will =
solve your problem <i>and those of other people</i>.<br><br>See the differe=
nce? You getting the bare minimum needed to help you only helps you. Gettin=
g stoi and friends to work with string_view helps you <i>and</i> helps tons=
 of other people.<br><br>Standard library features need to service the need=
s of more than yourself.<br></div></blockquote><div><br></div><div>The func=
tions initially shall be declared with the parameter pos. It is a serious s=
tandard defect. </div><div><br></div><div><div>So I am going to remedy=C2=
=A0this defect. It=C2=A0does not depend on=C2=A0whether it is helpful perso=
nally for you or not.=C2=A0</div><div><br></div></div><div>In fact the func=
tions is useless in most cases and the programmers have to descend to the C=
 level and use=C2=A0for example C function strtoul directly instead of stou=
l. So they do not deal with the std::string. They deal with char *. And mor=
eover in this case the parameter idx is also useless from the point of view=
 of using objects of type std::string.</div><div><br></div><div>It is enoug=
h to add one more parameter to the functions and the situation is changed d=
ramatically.</div><div><br></div><div>Here is a simple example. I wrote a s=
implified implementation of the overloaded stoul that to demonstrate just t=
he idea.</div><div><br></div><div>#include &lt;iostream&gt;<br>#include &lt=
;string&gt;</div><div><br></div><div>unsigned long stoul( const std::string=
 &amp;s, std::string::size_type pos, size_t* idx =3D 0, int base =3D 10 )<b=
r>{<br>=C2=A0=C2=A0=C2=A0 const char *nptr =3D s.c_str();<br>=C2=A0=C2=A0=
=C2=A0 char *end_ptr;<br>=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0 unsigned=
 long value =3D std::strtoul( nptr + pos, ( idx =3D=3D 0 ? NULL : &amp;end_=
ptr ), base );<br>=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0 if ( idx ) *idx=
 =3D end_ptr - nptr;<br>=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=C2=A0 return va=
lue;<br>}</div><div><br></div><div>int main()<br>{<br>=C2=A0=C2=A0=C2=A0 co=
nst char *digits =3D &quot;0123456789&quot;;</div><div>=C2=A0=C2=A0=C2=A0 s=
td::string s( &quot;#1, ##2, ###3, ####4, #####5&quot; );</div><div><br></d=
iv><div>=C2=A0=C2=A0=C2=A0 size_t n =3D 0;</div><div>=C2=A0=C2=A0=C2=A0 for=
 ( std::string::size_type pos =3D 0; ( pos =3D s.find_first_of( digits, pos=
 ) ) !=3D std::string::npos; )<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; ::stoul( s, pos, &amp;pos ) =
&lt;&lt; &#39; &#39;;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ++n;<br=
>=C2=A0=C2=A0=C2=A0 }</div><div><br></div><div>=C2=A0=C2=A0=C2=A0 std::cout=
 &lt;&lt; &quot;\nThere are &quot; &lt;&lt; n &lt;&lt; &quot; numbers in th=
e string&quot; &lt;&lt; std::endl;<br>=C2=A0=C2=A0=C2=A0 <br>=C2=A0=C2=A0=
=C2=A0 std::cout &lt;&lt; &quot;The first number is &quot; &lt;&lt; ::stoul=
( s, s.find_first_of( digits ) ) &lt;&lt; std::endl;<br>=C2=A0=C2=A0=C2=A0 =
std::cout &lt;&lt; &quot;The last number is=C2=A0 &quot; &lt;&lt; ::stoul( =
s, s.find_last_of( digits ) ) &lt;&lt; std::endl;<br>}=C2=A0=C2=A0=C2=A0 </=
div><div><br></div><div>The program output is</div><div><br></div><div>1 2 =
3 4 5 <br>There are 5 numbers in the string<br>The first number is 1<br>The=
 last number is=C2=A0 5</div><div><br></div><div>There is no any need to in=
troduce new entities that to do this simple task. All is done in the frames=
 of the class std::string because all=C2=A0already exists and is enough to =
do the task.</div><div><br></div><div>This idiom</div><div><br></div><div>w=
hile ( ( pos =3D s.find_first_of( something, pos ) ) !=3D std::string::npos=
 ) </div><div>{</div><div>=C2=A0=C2=A0=C2=A0 /*...*/</div><div>}</div><div>=
<br></div><div>or</div><div><div><br></div><div>while ( ( pos =3D s.find( s=
omething, pos ) ) !=3D std::string::npos ) </div><div>{</div><div>=C2=A0=C2=
=A0=C2=A0 /*...*/</div><div>}</div><div><br></div></div><div>occurs=C2=A0nu=
merous times in the=C2=A0code base and very clear for all programmers.</div=
><div><br></div><div>Here is the string itself that is accentuated.</div><d=
iv><br></div><div>stoul is in fact=C2=A0a static method of the class std::s=
tring. It serves objects of the type.</div><div><br></div><div>They need no=
t a third entity or even more entities to do the task. </div><div><br></div=
><div>Keep It Simple, Stuipid!:)</div><div><br></div><div>As for this code<=
/div><div><br></div><div><span style=3D"color: rgb(0, 0, 0);">stoul</span><=
span style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0=
, 0, 0);"> s</span><span style=3D"color: rgb(102, 102, 0);">.</span><span s=
tyle=3D"color: rgb(0, 0, 0);">view</span><span style=3D"color: rgb(102, 102=
, 0);">().</span><span style=3D"color: rgb(0, 0, 0);">remove_prefix</span><=
span style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0=
, 0, 0);">s</span><span style=3D"color: rgb(102, 102, 0);">.</span><span st=
yle=3D"color: rgb(0, 0, 0);">find_<wbr>first_of</span><span style=3D"color:=
 rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 0);"> </span><s=
pan style=3D"color: rgb(0, 136, 0);">&quot;0123456789&quot;</span><span sty=
le=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, 0);=
">)))</span></div><p><span style=3D"color: rgb(102, 102, 0);"><br></span></=
p><div>then it is simply very awful. </div><div><br></div><div>For example =
</div><div><br></div><div>What and where does <span style=3D"color: rgb(0, =
0, 0);">remove_prefix remove? </span></div><div><span style=3D"color: rgb(0=
, 0, 0);"><br></span></div><div><span style=3D"color: rgb(0, 0, 0);">Is s b=
eing changed? </span></div><div><span style=3D"color: rgb(0, 0, 0);"><br></=
span></div><div><span style=3D"color: rgb(0, 0, 0);">Why is there used <spa=
n style=3D"color: rgb(0, 0, 0);">remove_prefix when we were not going to re=
move anything in our string? </span></span></div><div><span style=3D"color:=
 rgb(0, 0, 0);"><span style=3D"color: rgb(0, 0, 0);"><br></span></span></di=
v><div><span style=3D"color: rgb(0, 0, 0);"><span style=3D"color: rgb(0, 0,=
 0);">How to use the next position in the string?</span></span></div><div><=
span style=3D"color: rgb(0, 0, 0);"><span style=3D"color: rgb(0, 0, 0);"><b=
r></span></span></div><div><span style=3D"color: rgb(0, 0, 0);"><span style=
=3D"color: rgb(0, 0, 0);">Wnat will be with s after this statement?</span><=
/span></div><div><span style=3D"color: rgb(0, 0, 0);"><span style=3D"color:=
 rgb(0, 0, 0);"><br></span></span></div><div><span style=3D"color: rgb(0, 0=
, 0);"><span style=3D"color: rgb(0, 0, 0);">Why are we introducing new enti=
ties like view and <span style=3D"color: rgb(0, 0, 0);">remove_prefix when =
we already have all what we need?</span></span></span></div><div><span styl=
e=3D"color: rgb(0, 0, 0);"><span style=3D"color: rgb(0, 0, 0);"><span style=
=3D"color: rgb(0, 0, 0);"><br></span></span></span></div><div><span style=
=3D"color: rgb(0, 0, 0);"><span style=3D"color: rgb(0, 0, 0);"><span style=
=3D"color: rgb(0, 0, 0);">What idx will the call return? </span></span></sp=
an></div><div><span style=3D"color: rgb(0, 0, 0);"><span style=3D"color: rg=
b(0, 0, 0);"><span style=3D"color: rgb(0, 0, 0);"><br></span></span></span>=
</div><div><span style=3D"color: rgb(0, 0, 0);"><span style=3D"color: rgb(0=
, 0, 0);"><span style=3D"color: rgb(0, 0, 0);">Will this idx=C2=A0be valid =
for the view or for the original string?</span></span></span></div><div><sp=
an style=3D"color: rgb(0, 0, 0);"><span style=3D"color: rgb(0, 0, 0);"><spa=
n style=3D"color: rgb(0, 0, 0);"><br></span></span></span></div><div>And at=
 last but not least</div><div><br></div><div>How does the overloaded functi=
ons prevent you to use such awful or as you think splendid code?:)</div><di=
v>=C2=A0<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_2196_1706527559.1443951264178--
------=_Part_2195_759257488.1443951264177--

.

------=_Part_2326_1606143566.1443958194250
Content-Type: multipart/alternative;
 boundary="----=_Part_2327_1298286261.1443958194250"

------=_Part_2327_1298286261.1443958194250
Content-Type: text/plain; charset=UTF-8

I think this kills the suggestion, which involves these overloads:

int stoi(const string& str, size_t* idx = 0, int base = 10);

int stoi(const string& str, std::string::size_type pos, size_t* idx = 0,
int base = 10);


But now:

int v = stoi(str, NULL);

results in a "ambiguous call" error. This is going to break quite a lot of
code, I think. (the reason being #define NULL 0)

Given the existence of string_view::remove_prefix() I think a more
interesting discussion is whether there should be an overload:

stoi(string_view& str, int base = 10);

which uses str.remove_prefix() to indicate how much of the input string was
consumed. This would be a "breaking" change but only visavi code that has
not been written yet and that could assume
that a lvalue string_view passed to stoi() is not to be touched. I think it
would be possible to understand that stoi will change the string_view if
possible. And it provides a very easy to use API for string to number
parsing.



Den fredag 2 oktober 2015 kl. 17:27:01 UTC+2 skrev Vlad from Moscow:
>
> The C++ Standard includes a family of conversion functions like std::stoi,
> std::stol, std::stoul and other similar functions.
>
> They allow to convert a string to some arithmetic type.
>
> However it is not always convinient to use them when you are going to
> apply the function to a string starting from some non-zero position.
>
> In this case you need to use either member function substr to get the
> desired substring. or to use another member function c_str that to
> apply the corresponding C function instead of the C++ function.
>
> So I think you have already understood that I want to suggest overloading
> functions that have one more parameter that specifies a position in the
> string.
>
> For example function stoi can now  look like
>
> int stoi(const string& str, size_t* idx = 0, int base = 10);
>
> int stoi(const string& str, std::string::size_type pos, size_t* idx = 0,
> int base = 10);
>
> What do you think about this?
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_2327_1298286261.1443958194250
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think this kills the suggestion, which involves these ov=
erloads:<div><br></div><div><div>int stoi(const string&amp; str, size_t* id=
x =3D 0, int base =3D 10);</div><div><br></div><div>int stoi(const string&a=
mp; str, std::string::size_type pos, size_t* idx =3D 0, int base =3D 10);<b=
r></div><div><br></div><div><br></div><div>But now:</div><div><br></div><di=
v>int v =3D stoi(str, NULL);</div><div><br></div><div>results in a &quot;am=
biguous call&quot; error. This is going to break quite a lot of code, I thi=
nk. (the reason being #define NULL 0)</div><div><br></div><div>Given the ex=
istence of string_view::remove_prefix() I think a more interesting discussi=
on is whether there should be an overload:</div><div><br></div><div>stoi(st=
ring_view&amp; str, int base =3D 10);</div><div><br></div><div>which uses s=
tr.remove_prefix() to indicate how much of the input string was consumed. T=
his would be a &quot;breaking&quot; change but only visavi code that has no=
t been written yet and that could assume</div><div>that a lvalue string_vie=
w passed to stoi() is not to be touched. I think it would be possible to un=
derstand that stoi will change the string_view if possible. And it provides=
 a very easy to use API for string to number parsing.</div><div><br></div><=
div><br></div><br>Den fredag 2 oktober 2015 kl. 17:27:01 UTC+2 skrev Vlad f=
rom Moscow:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv>The C++ Standard includes=C2=A0a family of conversion functions like std=
::stoi, std::stol, std::stoul and other similar functions.</div><div><br></=
div><div>They allow to convert a string to some arithmetic type.</div><div>=
<br></div><div>However it is not always convinient to use them when you are=
 going to apply the function to a string starting from some non-zero positi=
on.</div><div><br></div><div>In this case you need to use either member fun=
ction substr to get the desired substring. or to use=C2=A0another member fu=
nction c_str that to apply=C2=A0the corresponding C function instead of the=
 C++ function.</div><div><br></div><div>So I think you have already underst=
ood that I want to suggest overloading functions that have one more paramet=
er that specifies a position in=C2=A0the string.</div><div><br></div><div>F=
or example function stoi can now=C2=A0 look like</div><div><br></div><div>i=
nt stoi(const string&amp; str, size_t* idx =3D 0, int base =3D 10);</div><d=
iv><br></div><div>int stoi(const string&amp; str, std::string::size_type po=
s, size_t* idx =3D 0, int base =3D 10);<br><br></div><div>What do you think=
 about this?</div><div><br></div></div></blockquote></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_2327_1298286261.1443958194250--
------=_Part_2326_1606143566.1443958194250--

.

------=_Part_2448_189384582.1443960211187
Content-Type: multipart/alternative;
 boundary="----=_Part_2449_1359715936.1443960211187"

------=_Part_2449_1359715936.1443960211187
Content-Type: text/plain; charset=UTF-8



On Sunday, October 4, 2015 at 2:29:54 PM UTC+3, Bengt Gustafsson wrote:
>
> I think this kills the suggestion, which involves these overloads:
>
> int stoi(const string& str, size_t* idx = 0, int base = 10);
>
> int stoi(const string& str, std::string::size_type pos, size_t* idx = 0,
> int base = 10);
>
>
> But now:
>
> int v = stoi(str, NULL);
>
> results in a "ambiguous call" error. This is going to break quite a lot of
> code, I think. (the reason being #define NULL 0)
>
> It is a good remark but I very doubt that it will indeed break quite a lot
of code.

 I never saw such a record like

int v = stoi(str, NULL);

But in any case if such a statement is present in some code the compiler
will issue an error.

And moreover there is one more positive moment.:) This stimulates to use
nullptr instead of NULL.

Given the existence of string_view::remove_prefix() I think a more
> interesting discussion is whether there should be an overload:
>
> stoi(string_view& str, int base = 10);
>
> which uses str.remove_prefix() to indicate how much of the input string
> was consumed. This would be a "breaking" change but only visavi code that
> has not been written yet and that could assume
> that a lvalue string_view passed to stoi() is not to be touched. I think
> it would be possible to understand that stoi will change the string_view if
> possible. And it provides a very easy to use API for string to number
> parsing.
>
>
Words "constant" and "remove" contradict each other and using them
simultaneously with the same object looks like a bug.

And as I pointed out early it is not clear what idx means in this case.


> Den fredag 2 oktober 2015 kl. 17:27:01 UTC+2 skrev Vlad from Moscow:
>>
>> The C++ Standard includes a family of conversion functions like
>> std::stoi, std::stol, std::stoul and other similar functions.
>>
>> They allow to convert a string to some arithmetic type.
>>
>> However it is not always convinient to use them when you are going to
>> apply the function to a string starting from some non-zero position.
>>
>> In this case you need to use either member function substr to get the
>> desired substring. or to use another member function c_str that to
>> apply the corresponding C function instead of the C++ function.
>>
>> So I think you have already understood that I want to suggest overloading
>> functions that have one more parameter that specifies a position in the
>> string.
>>
>> For example function stoi can now  look like
>>
>> int stoi(const string& str, size_t* idx = 0, int base = 10);
>>
>> int stoi(const string& str, std::string::size_type pos, size_t* idx = 0,
>> int base = 10);
>>
>> What do you think about this?
>>
>>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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_2449_1359715936.1443960211187
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, October 4, 2015 at 2:29:54 PM UTC+3, Be=
ngt Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">I think =
this kills the suggestion, which involves these overloads:<div><br></div><d=
iv><div>int stoi(const string&amp; str, size_t* idx =3D 0, int base =3D 10)=
;</div><div><br></div><div>int stoi(const string&amp; str, std::string::siz=
e_type pos, size_t* idx =3D 0, int base =3D 10);<br></div><div><br></div><d=
iv><br></div><div>But now:</div><div><br></div><div>int v =3D stoi(str, NUL=
L);</div><div><br></div><div>results in a &quot;ambiguous call&quot; error.=
 This is going to break quite a lot of code, I think. (the reason being #de=
fine NULL 0)</div><div><br></div></div></div></blockquote><div>It is a good=
 remark but=C2=A0I very doubt that it will indeed break quite a lot of code=
..</div><div><br></div><div>=C2=A0I never saw such a record like</div><div><=
br></div><div><div>int v =3D stoi(str, NULL);</div><div><br></div><div>But =
in any case if such a statement is present in=C2=A0some code the compiler w=
ill issue an error. </div><div><br></div><div>And moreover there is=C2=A0on=
e more positive moment.:) This stimulates to use nullptr instead of NULL.</=
div><div><br></div></div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div=
><div></div><div>Given the existence of string_view::remove_prefix() I thin=
k a more interesting discussion is whether there should be an overload:</di=
v><div><br></div><div>stoi(string_view&amp; str, int base =3D 10);</div><di=
v><br></div><div>which uses str.remove_prefix() to indicate how much of the=
 input string was consumed. This would be a &quot;breaking&quot; change but=
 only visavi code that has not been written yet and that could assume</div>=
<div>that a lvalue string_view passed to stoi() is not to be touched. I thi=
nk it would be possible to understand that stoi will change the string_view=
 if possible. And it provides a very easy to use API for string to number p=
arsing.</div><div><br></div></div></div></blockquote><div>=C2=A0<div>Words =
&quot;constant&quot; and &quot;remove&quot; contradict each other and using=
 them simultaneously with the same object looks like a bug.</div><div><br><=
/div><div>And as I pointed out early it is not clear what idx means in this=
 case.</div><div><br></div></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, =
204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"l=
tr"><div><div></div><br>Den fredag 2 oktober 2015 kl. 17:27:01 UTC+2 skrev =
Vlad from Moscow:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>The C++=
 Standard includes=C2=A0a family of conversion functions like std::stoi, st=
d::stol, std::stoul and other similar functions.</div><div><br></div><div>T=
hey allow to convert a string to some arithmetic type.</div><div><br></div>=
<div>However it is not always convinient to use them when you are going to =
apply the function to a string starting from some non-zero position.</div><=
div><br></div><div>In this case you need to use either member function subs=
tr to get the desired substring. or to use=C2=A0another member function c_s=
tr that to apply=C2=A0the corresponding C function instead of the C++ funct=
ion.</div><div><br></div><div>So I think you have already understood that I=
 want to suggest overloading functions that have one more parameter that sp=
ecifies a position in=C2=A0the string.</div><div><br></div><div>For example=
 function stoi can now=C2=A0 look like</div><div><br></div><div>int stoi(co=
nst string&amp; str, size_t* idx =3D 0, int base =3D 10);</div><div><br></d=
iv><div>int stoi(const string&amp; str, std::string::size_type pos, size_t*=
 idx =3D 0, int base =3D 10);<br><br></div><div>What do you think about thi=
s?</div><div><br></div></div></blockquote></div></div></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_2449_1359715936.1443960211187--
------=_Part_2448_189384582.1443960211187--

.

On 2015-10-03 17:40, Thiago Macieira wrote:
> (I know there's no std::string::mid() function, but that's a deficiency to be
> addressed elsewhere and also a bit of a philosophical discussion)

Um... substr? (Mind, I also prefer Qt's much better names, but unless I
miss something, it *does* exist. What *is* missing - because we don't
actually *have* string_view yet, and hopefully will be added along with
string_view - is a corresponding function to get a string_view from a
starting offset, a la QString::midRef.)

That said, right() does seem to be missing (taking 'left(n)' to be
shorthand for 'substr(0, n)' and therefore "unnecessary")...

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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 2015-10-04 20:23, Nicol Bolas wrote:
> However, the fact of the matter is this. You explained what you wanted. Six
> separate people, including myself, disagree with you about which is
> clearer, easier for beginners, and/or more useful in general. Not one
> single person has stepped forward to defend your idea.

Hear, hear. I was about to mention that also.

On 2015-10-05 06:25, Vlad from Moscow wrote:
> I am dissapointed!  Six is too few.:).

Six is the number of people that were willing to join the fray. The
remainder almost certainly a) agree with the majority view and so don't
feel the need to reply, as they would not be adding anything meaningful,
b) don't find the proposal of sufficient interest to bother reading the
thread (and so aren't likely to be supportive anyway), or c) are too
disgusted to want anything to do with the melee. Anyone else actually in
favor of your proposal would likely have spoken up by now.

On 2015-10-04 20:23, Nicol Bolas wrote:
> [...] at the end of the day, all you have is a feature who's
> functionality will be duplicated once `string_view` is added to `stoi` and
> so forth.

On top of which, the advent of string_view (and assuming it implicitly
constructs from std::string?) means we ought to be *deprecating
entirely* stoi(std::string, ...), because it is redundant and unnecessary.

You (Vlad) are fighting an uphill battle to expand an area of the
language that is on its way out the door. Lots of luck with that...

On 2015-10-05 06:25, Vlad from Moscow wrote:
> Any good code is a generic code. It is usually reusable.

Exactly. And string_view is (*much*!) more reusable and generic than
std::string.

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post 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 2015-10-03 10:26, Nicol Bolas wrote:
> stoul( s.view().remove_prefix(s.find_first_of( "0123456789" )))

In fairness, that *is* a mess :-). An equivalent of QString::midRef
would be really nice here, i.e. a substr that returns a string_view
instead of a new string.

--
Matthew

--

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

.