220 18035 <79b0dd51-6723-4ae5-b963-3763d611d8b7@isocpp.org> article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Parsing Numbers Date: Wed, 20 May 2015 08:27:54 -0700 (PDT) Lines: 379 Approved: news@gmane.org Message-ID: <79b0dd51-6723-4ae5-b963-3763d611d8b7@isocpp.org> References: <2264844.2f9Wn7Zsb9@tjmaciei-mobl4> <010af437-2f84-4afe-ae09-3e6f6edeb9b8@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4195_1994461266.1432135674503" X-Trace: ger.gmane.org 1432135685 16105 80.91.229.3 (20 May 2015 15:28:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 May 2015 15:28:05 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRB66P6KVAKGQEOAXHW6I@isocpp.org Wed May 20 17:28:04 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f200.google.com ([209.85.216.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yv5uX-0008Vi-7H for gclcip-std-proposals@m.gmane.org; Wed, 20 May 2015 17:27:57 +0200 Original-Received: by qcbij4 with SMTP id ij4sf46639443qcb.1 for ; Wed, 20 May 2015 08:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=pZZ9+iXpO1hu+cvPQRLUKKdl9ksJViH14MTxg8SpTMY=; b=AXV0I+hYqKzKK4NhgEKhgM856SpEiWAjZY7U6D3nDJWhvO7qW0cMALVLHxzyzGZI6K ZPrBFlgCdcOhiDExm532RvYJEVOwqnX3BNwzxSDTnHFfLMKZ3KQP0kTmiHIkwnL7XV+d PDWRvLoaCkVfWb/EbDHB23BwJC4Z78TOs95b6m18HFqiDxYSrCr0gFd6DFhY02dKNGbR PQaa3FzvX2UWep3lJCQdFrQRBmnoQXA36fwSHFRBYyQWppQCcqx+5Q+TDvGBie6+OKQ+ fYtwHnAkoUNaj2SG4gY1a/9rnkhs1fpQKP0irKfiRliMJ29fInxVCdnZC3nd2/NWcvb0 Xwcw== 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=pZZ9+iXpO1hu+cvPQRLUKKdl9ksJViH14MTxg8SpTMY=; b=dQOeA4tqkAogpInf5BnhwOnziQh9zr/9e3CELjo6dXpNpo06AadpukDHygP+/dpkie 70MYXnOCfSKCturmdykUKm3H1CaJkEN5hPKVUJucuA3125+rEVbERSXWDiNS4wncSsIN 278j1L8Cqu0ZVyrCcGlP0SJtvjQTM216ySK9zmHl9oAEOnZvNUk/+p6vSBWIU7IbsVfW ze3CnlRFdCoy3V8QbwOGgiNYxWYumy/b7zmnF/l+PrDI3wUH8ShV7B/6/K63GNlCk+dF 0L6XnBGZjDptQNBNI8Fh8Y5gzDpkHpJlfOjsfkaRxesDgeHK+PZC0P8/YImowNdQXnff KHNA== X-Gm-Message-State: ALoCoQlQpz5OSIvo6la0d4HO2K5vbIgrWIXhM04JkLjvHhTBi+7swL4wjrpKcRI+Wm6VIqqNezxF X-Received: by 10.52.148.142 with SMTP id ts14mr47991090vdb.4.1432135676217; Wed, 20 May 2015 08:27:56 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.97.75 with SMTP id l69ls928609qge.73.gmail; Wed, 20 May 2015 08:27:55 -0700 (PDT) X-Received: by 10.140.109.35 with SMTP id k32mr366107qgf.34.1432135675262; Wed, 20 May 2015 08:27:55 -0700 (PDT) In-Reply-To: X-Original-Sender: fmatthew5876@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:18035 Archived-At: ------=_Part_4195_1994461266.1432135674503 Content-Type: multipart/alternative; boundary="----=_Part_4196_838251639.1432135674503" ------=_Part_4196_838251639.1432135674503 Content-Type: text/plain; charset=UTF-8 On Wednesday, May 20, 2015 at 8:07:45 AM UTC-4, Olaf van der Spek wrote: > > 2015-05-18 23:16 GMT+02:00 Magnus Fromreide : > > I think iterators/ranges are a better input type. Why should we require > that > > the input is consecutive? > > Simplicity? > I don't know, I presume iostream internals support parsing from > iterators so it might be good to expose that. > > On the other hand the input is often contiguous and existing functions > mostly require contiguous input. > Even if the base implementation uses iterators, string_view (or a string_view compatible) overloads should be provided. Because of that, we could just do a string_view proposal for now and if later someone wants to propose an iterator version the string_view functions could be just reimplemented using the iterator version. It would be really great if this library could make it into the standard at the same time string_view does. Not having string_view compatible number parsing is a major hole in the string_view API. On Wednesday, May 20, 2015 at 8:08:25 AM UTC-4, Olaf van der Spek wrote: > > The proposed function is like: parse(string_view in, size_t* pos = > nullptr, int base = 10); > Nothing is passed by lvalue (or rvalue). > > Using string_view* tail might make sense in certain use cases but not > in others.. > Not sure I follow you here. Do you have any specific use case where a size_t* (or char*) is more appropriate? A string_view object is a better tail string representation because it is a range with invariants built in from the start. Consider the following example, which would be a lot more clumsy if you used a size_t* instead of a string_view*. string_view s = "1 2 3"; auto a = parse(s, &s); s.pop_front(); auto b = parse(s, &s); s.pop_front(); auto c = parse(s, &s); Using a size_t* just means I'm probably going to be constructing a string_view on the next line and now I have to awkwardly deal with stuff like { in.begin() + pos, in.end() } without making mistakes. The tail out param could also be passed as a string_view*, which nullptr signifying "allow tail strings but throw them away". > Let's have a look at some real-world use cases. > > m_downloaded = to_int(value); > m_uploaded = to_int(value); > auto u = find_user(to_int(req_["u"])); > int y0 = to_int(req_["y0"]); > > In most cases the entire input has to be a valid number, so pos / tail > isn't needed. > I agree that retrieving the tail should be optional and not get in the way if you don't need it. This means that if tail is an out parameter we should provide an overload without it. If tail is part of the returned object, it should be easy to extract the value and error_code and ignore the tail. > In most cases the number is used to initialize a new variable, This is a major problem with expected, optional, etc... Its really nice to just be able to say auto x = parse(s); and have x be an int. > so an > out parameter wouldn't work for the output number. > 0 is used to signal a failed conversion. > Generally, using 0 or any other perfectly valid value to signal failure is a really bad idea. It only makes sense when your use case is "Parse the value or give me some default if it fails". In that case, 0 may not be the default value you want so its better to be able to actually specify it. This use case why I invented parse_or() for my libraries. Regardless of how the base version is implemented, this wrapper can still be added for atoi() like convenience. template T parse_or(string_view s, T val_if_error); auto x = parse_or(s, 1.0); //decltype(x) == double Notice how also because of the default, you don't even need to specify the type T. It can be deduced from the constant used to initialize val_if_error. Using such a method emphasizes the value you are returning and that you don't care about errors. > > I think my use cases are best served by an atoi-like convenience > function, so the actual interface of the real parse function wouldn't > matter. > Perhaps atoi/strtol-like convenience functions should be proposed too. > I have this use case often as well, but many other times I'm more focused on correctness and want to report errors to users if they incorrectly specify a number. Both idioms should be easily supported. My parse_or() (or something similar) should serve the atoi() use case with minimal complexity. Do you see any situation where it would not? I think what is needed is for the paper to survey possible several interfaces and show examples of all of the common use cases with each one, carefully pointing out the pros and cons. Only when we have all of the data in front of us with their trade offs of safety, convenience, and readability can we choose one. If you're planning to actually write this paper and want to collaborate, I'd be happy to help with this. What are all of the use cases for an API like this? Here is what I can think of: - Parse a number and throw an exception if error occurs - Parse a number and let me handle errors without exceptions - Parse a number and give me a default value if an error occurs - Parse a number and give me the tail string so I can continue parsing the next object. - Initialize a variable using parse(), preferably using auto / type deduction. - Assign to a pre-existing variable using parse(), preferably with type deduction. -- --- 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_4196_838251639.1432135674503 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wednesday, May 20, 2015 at 8:07:45 AM UTC-4, Ol= af van der Spek wrote:
2015-05-= 18 23:16 GMT+02:00 Magnus Fromreide <ma...@lysator.liu.se>:
> I think iterators/ranges are a better input type. Why should we re= quire that
> the input is consecutive?

Simplicity?
I don't know,= I presume iostream internals support parsing from
iterators so it might be good to expose that.

On the other hand the input is often contiguous and existing functions
mostly require contiguous input.

Even if the base implementation uses iterators, s= tring_view (or a string_view compatible) overloads should be provided.
<= br>Because of that, we could just do a string_view proposal for now and if = later someone wants to propose an iterator version the string_view function= s could be just reimplemented using the iterator version. It would be reall= y great if this library could make it into the standard at the same time st= ring_view does. Not having string_view compatible number parsing is a major= hole in the string_view API.
 

On Wednesday, May 20, 2015= at 8:08:25 AM UTC-4, Olaf van der Spek wrote:
The proposed function is like: parse(string_view in, size_t= * pos =3D
nullptr, int base =3D 10);
Nothing is passed by lvalue (or rvalue).

Using string_view* tail might make sense in certain use cases but not
in others..

Not sure I follow you here.
Do you have any sp= ecific use case where a size_t* (or char*) is more appropriate? A string_vi= ew object is a better tail string representation because it is a range with= invariants built in from the start.

Consider the following example,= which would be a lot more clumsy if you used a size_t* instead of a string= _view*.

string_view s =3D= "1 2 3";
auto a =3D parse<int>(s, <= /span>&s);
s.pop_front();
auto b =3D parse= <int>= ;(<= span style=3D"color: #000;" class=3D"styled-by-prettify">s, &s);
s.pop_fr= ont();
auto c =3D parse<int>(s, &am= p;s= );
<= /div>
Using a size_t* just means I'm probably going to be constructing a= string_view on the next line and now I have to awkwardly deal with stuff l= ike { in.begin() + pos, in.end() } without making mistakes.

The tail= out param could also be passed as a string_view*, which nullptr signifying= "allow tail strings but throw them away".


Let's have a look at some real-world use cases.

m_downloaded =3D to_int(value);
m_uploaded =3D to_int(value);
auto u =3D find_user(to_int(req_["u"]));
int y0 =3D to_int(req_["y0"]);

In most cases the entire input has to be a valid number, so pos / tail
isn't needed.

I agree that retrieving the tail should be option= al and not get in the way if you don't need it. This means that if tail is = an out parameter we should provide an overload without it. If tail is part = of the returned object, it should be easy to extract the value and error_co= de and ignore the tail.
 
In most cases the number is used to initialize a new variable,

This is a major problem with expected, optional, etc... = Its really nice to just be able to say auto x =3D parse<int>(s); and = have x be an int.

 
so an
out parameter wouldn't work for the output number.
0 is used to = signal a failed conversion.

Generally, using 0 or any other perfectly valid v= alue to signal failure is a really bad idea. It only makes sense when your = use case is "Parse the value or give me some default if it fails". In that = case, 0 may not be the default value you want so its better to be able to a= ctually specify it.

This use case why I invented parse_or() for my l= ibraries. Regardless of how the base version is implemented, this wrapper c= an still be added for atoi() like convenience.

template <typename T>
T parse_or(string_view s, = T val_if_error);
=
auto x =3D parse_or(s, 1.0); //declty= pe(x) =3D=3D double

Notice how also because of the d= efault, you don't even need to specify the type T. It can be deduced from t= he constant used to initialize val_if_error.

Using such a method emp= hasizes the value you are returning and that you don't care about errors.
 

I think my use cases are best served by an atoi-like convenience
function, so = the actual interface of the real parse function wouldn't
matter.
Perhaps atoi/strtol-like convenience functions should be proposed too.

I have this use case often as well, but many othe= r times I'm more focused on correctness and want to report errors to users = if they incorrectly specify a number. Both idioms should be easily supporte= d. My parse_or() (or something similar) should serve the atoi() use case wi= th minimal complexity. Do you see any situation where it would not?

= I think what is needed is for the paper to survey possible several interfac= es=20 and show examples of all of the common use cases with each one, carefully p= ointing out the pros and cons. Only when we have all of the data in front o= f us with their trade offs of safety, convenience,=20 and readability can we choose one.

If you're planning to actually w= rite this paper and want to collaborate, I'd be happy to help with this.
What are all of the use cases for an API like this? Here is what I can= think of:
- Parse a number and throw an exception if error occurs
- = Parse a number and let me handle errors without exceptions
- Parse a num= ber and give me a default value if an error occurs
- Parse a number and = give me the tail string so I can continue parsing the next object.
- Ini= tialize a variable using parse(), preferably using auto / type deduction.- Assign to a pre-existing variable using parse(), preferably with type d= eduction.

--

---
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_4196_838251639.1432135674503-- ------=_Part_4195_1994461266.1432135674503-- .