220 21264 article Path: news.gmane.org!not-for-mail From: Vlad from Moscow Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Overloading of the family of numeric conversion functions std::stoXXX Date: Sun, 4 Oct 2015 05:03:31 -0700 (PDT) Lines: 177 Approved: news@gmane.org Message-ID: References: <3afc0e3d-77aa-4a43-a3f0-c4af8e7b6d72@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2448_189384582.1443960211187" X-Trace: ger.gmane.org 1443960216 21414 80.91.229.3 (4 Oct 2015 12:03:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Oct 2015 12:03:36 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCXLLRHD7IDRBFFLYSYAKGQERGOCCKI@isocpp.org Sun Oct 04 14:03:36 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zii0s-0006AG-DP for gclcip-std-proposals@m.gmane.org; Sun, 04 Oct 2015 14:03:34 +0200 Original-Received: by vkfp126 with SMTP id p126sf199418897vkf.3 for ; Sun, 04 Oct 2015 05:03:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=5WFqH8fSk0vK+QREktLUX7Ms75DAdd+drzVBkikcdyw=; b=KDsX8ZEzTZ7qH0NiwLd5iLJDknm9CQ2IDeCnnnf3Td90yFZykG4RbFrdX/WwutjD19 xdoTkZLUKeDTBqcR4vai8VLPewpOWAndUGIg9mb4G0bx1l1LHQyZyvv6nQTxsAVDQkcP ZDIHezv/2m1Dh52Z99GUoX5KLkWi+68+SbmRUtMlfv56vptuq9Kv7ePPA5Ee0s1vjwK6 G5nJolSiEvqh6kQjePr/U5FJeatMOHehtHBRtu6M5smkdR06pXaiP/z/x61qSLfNpWl9 ViGWr+s1p8WTW2q59plfDq51B2un43AC3QqTWHeYioyjamW8b7pcUO5YKu0VkAENLRkA PLrA== X-Gm-Message-State: ALoCoQlw7/l7YZDAfntzubihDCqYgVIwYQCsYxOgOiFIfL+ZrZ0eZxxxH58kzHl/YOm+RSY38Wv3 X-Received: by 10.129.146.87 with SMTP id j84mr21219690ywg.18.1443960213205; Sun, 04 Oct 2015 05:03:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.142.99 with SMTP id rv3ls944874igb.23.canary; Sun, 04 Oct 2015 05:03:32 -0700 (PDT) X-Received: by 10.50.114.36 with SMTP id jd4mr72265igb.6.1443960212191; Sun, 04 Oct 2015 05:03:32 -0700 (PDT) In-Reply-To: <3afc0e3d-77aa-4a43-a3f0-c4af8e7b6d72@isocpp.org> X-Original-Sender: vlad.moscow@mail.ru Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:21264 Archived-At: ------=_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


On Sunday, October 4, 2015 at 2:29:54 PM UTC+3, Be= ngt Gustafsson wrote:
I think = this kills the suggestion, which involves these overloads:

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

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


But now:

int v =3D stoi(str, NUL= L);

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

It is a good= remark but=C2=A0I very doubt that it will indeed break quite a lot of code= ..

=C2=A0I never saw such a record like
<= br>
int v =3D stoi(str, NULL);

But = in any case if such a statement is present in=C2=A0some code the compiler w= ill issue an error.

And moreover there is=C2=A0on= e more positive moment.:) This stimulates to use nullptr instead of NULL.

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

stoi(string_view& str, int base =3D 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 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.

=C2=A0
Words = "constant" and "remove" contradict each other and using= them simultaneously with the same object looks like a bug.

<= /div>
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=C2=A0a family of conversion functions like std::stoi, st= d::stol, std::stoul and other similar functions.

T= hey 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.
<= 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.

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.

For example= function stoi can now=C2=A0 look like

int stoi(co= nst string& str, size_t* idx =3D 0, int base =3D 10);

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

What do you think about thi= s?

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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/<= /a>.
------=_Part_2449_1359715936.1443960211187-- ------=_Part_2448_189384582.1443960211187-- .