220 9137 article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: String to T conversions - getting it right this time Date: Wed, 5 Feb 2014 18:26:50 -0800 (PST) Lines: 182 Approved: news@gmane.org Message-ID: References: <097fb6c8-56f9-433e-a2f0-8c0f69609bf0@isocpp.org> <2142577.vhDTrNQqlS@tjmaciei-mobl4> <5546001.eD8TgcY3JL@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4287_1011012.1391653610096" X-Trace: ger.gmane.org 1391653605 23100 80.91.229.3 (6 Feb 2014 02:26:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Feb 2014 02:26:45 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRB27FZOLQKGQEHCXEX7A@isocpp.org Thu Feb 06 03:26:53 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ve0-f197.google.com ([209.85.128.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WBEg1-00064R-2J for gclcip-std-proposals@m.gmane.org; Thu, 06 Feb 2014 03:26:53 +0100 Original-Received: by mail-ve0-f197.google.com with SMTP id oz11sf3026185veb.4 for ; Wed, 05 Feb 2014 18:26:52 -0800 (PST) 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 :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=h0A1poJ4tzi7kHO7SbkkSXH1rZAOx9FO+T7+1Oug/Og=; b=XtD9KxNTNpmyQZ6YyR53CgTUSL3PjERuEz+DRBeNa44MmGeQvUjihsvjvIvM8Vm1BE rDXkau4HwrG/DrHrcGz5RrMUiXHlutYThUcSm7R1JUzKlXHiD8m5LPHZIfV6+F3lNGrr EKEXOGMWh1gb4jAXIF7hC8+6cT0xWra+MpdsXUtRIXU00kyatQ9wS3Ywg0306+VLUZo+ rGcyFoNF5AIxaenyykqmZtCY6kts5E0T20omHMKQodxWNiZvDznZ8oAiBt5opOHmyFRA PkzOPAcXrhYKAG1ly0E0YhGfls1Hrhf6Fa8TANrUkrkZaEb+pbphwl21LMxI4OPyHm4f B/tg== 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:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=h0A1poJ4tzi7kHO7SbkkSXH1rZAOx9FO+T7+1Oug/Og=; b=EgTVC4nXOyHTHCpFcTbqQFScH3EE280onfqWJCg+NmWLAazn6UmgRsY/bXI6EsYyxM TzduKlv2opn3E1CoNb4iMSd5Ei84zl810oMjL2VF0p1mz4vIWGUqq4p7zbLs2Tm6puuJ v9oGAJPko/SIrSpBzuehTBoaqkItTZQaWI61+x0sGkM2cNu5pJJGexhabECiXmbJ4fmx F1Q8ZLY9w8jhS4JxK4gTgxm+TLY7sZH9+oTt4wEnT8fzJWHduLePGCR+0HZCKMZMjYFa c7yz/Srnc8zn+dqfkmTaTC3XIZyxRHNKiykaAjoIC85h3VXwZWDGBuqhidkM1Vx8WLhB G/3w== X-Gm-Message-State: ALoCoQl81uMKzUHYm5B2oE9QhM6Vn3BWdTBp3ny3K2esuXZbol+DShVUaGAhqJYpLvoahqnpxl9p X-Received: by 10.236.92.17 with SMTP id i17mr334822yhf.57.1391653612258; Wed, 05 Feb 2014 18:26:52 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.23.175 with SMTP id 44ls374571qgp.24.gmail; Wed, 05 Feb 2014 18:26:51 -0800 (PST) X-Received: by 10.140.36.37 with SMTP id o34mr110773qgo.10.1391653611459; Wed, 05 Feb 2014 18:26:51 -0800 (PST) In-Reply-To: <5546001.eD8TgcY3JL@tjmaciei-mobl4> 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:9137 Archived-At: ------=_Part_4287_1011012.1391653610096 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, February 5, 2014 5:30:54 PM UTC-5, Thiago Macieira wrote: > > Em qua 05 fev 2014, =C3=A0s 21:20:52, Miro Knejp escreveu:=20 > > > The reason being that most C++ standard library implementations will= =20 > > > delegate=20 > > > to strtoll or similar functions (like we do in Qt). Asking for=20 > > > functionality=20 > > > different from strtoll means asking for more complexity from library= =20 > > > developers.=20 > > >=20 > > > Alternatively, make sure that strtoll could be implemented on top of = a=20 > > > plain C=20 > > > library routine that is the backend for your new function. That would= =20 > > > solve=20 > > > the problem of complexity.=20 > >=20 > > While it makes sense and sounds great, you can only implement it in=20 > > terms of strtoll if=20 > >=20 > > 1. The iterators point to contiguous memory, and=20 > > 2. The value type is char, and=20 > > 3. They range is null terminated.=20 > >=20 > > There is currently no reliable way to detect 1 and 3. The contiguous=20 > > iterator category proposal would solve 1, but 3 requires dereferencing= =20 > > the end iterator and thus UB. That limits our options alot. If=20 > > implementability with strtoxx is a requirement you can just drop the=20 > > iterators, templates, locales and mark this thread as closed since the= =20 > > limitations of strtoxx started it in the first place.=20 > > If you go for my alternative proposal, then you skip the need for 3. That= =20 > is,=20 > implementing strtoll on top of a plain C function that operates on=20 > contiguous=20 > memory and receives a begin and end pointer.=20 > > However, I do think 1 and 2 are *reasonable*.=20 I'm fine with 1 and 2 if it turns out genericity is too hard. Possibly with= =20 overloads for the other character types. =20 > I think the whole discussion=20 > about input iterators that this discussion has gone on for the past few= =20 > days=20 > is unnecessary. Simply force people to read into a contiguous-memory=20 > buffer of=20 > one of the base char types.=20 > In all honesty I only care about string_view. Generic iterators are nice=20 (maybe so we can support vector if there's a compelling reason to use= =20 one for something??), but I'll be happily using this interface with=20 string_view all the time and probably little else. =20 > > In specific: I'd like this discussion to assume that the number parsing= =20 > code is=20 > implemented out-of-line. Inline parsing is, forgive me for saying so,=20 > nuts.=20 > You could maybe do it for integers, but you'd never do it for=20 > floating-point=20 > results.=20 > I think at this point we need to do a real study into implementations to=20 answer these questions accurately, particularly with floating point as=20 that's the real bear. How is strtof() implemented on different platforms?= =20 What do gcc and other compilers use for floating point literals? Also you= =20 voted against binary 0b prefix because its not supported by strtol(), but= =20 something is going to be/already is written to support C++14 binary=20 literals. That something can be leveraged here. --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_4287_1011012.1391653610096 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, February 5, 2014 5:30:54 PM UTC-5, Thiag= o Macieira wrote:
Em qua 05 fev 2014, =C3=A0s 2= 1:20:52, Miro Knejp escreveu: 
> > The reason being that most= C++ standard library implementations will 
> > delegate = ;
> > to strtoll or similar functions (like we do in Qt). Asking f= or 
> > functionality 
> > different from strto= ll means asking for more complexity from library 
> > develop= ers. 
> > 
> > Alternatively, make sure that st= rtoll could be implemented on top of a 
> > plain C 
= > > library routine that is the backend for your new function. That w= ould 
> > solve 
> > the problem of complexity.=  
> 
> While it makes sense and sounds great, you can= only implement it in 
> terms of strtoll if 
> =
>  1. The iterators point to contiguous memory, and 
&g= t;  2. The value type is char, and 
>  3. They range i= s null terminated. 
> 
> There is currently no reliab= le way to detect 1 and 3. The contiguous 
> iterator category pr= oposal would solve 1, but 3 requires dereferencing 
> the end it= erator and thus UB. That limits our options alot. If 
> implemen= tability with strtoxx is a requirement you can just drop the 
> = iterators, templates, locales and mark this thread as closed since the = ;
> limitations of strtoxx started it in the first place. 
If you go for my alternative proposal, then you skip the need for 3. That= is, 
implementing strtoll on top of a plain C function that operat= es on contiguous 
memory and receives a begin and end pointer. = ;

However, I do think 1 and 2 are *reasonable*.
I'm fine with 1 and 2 if it turns out genericity is too hard. = Possibly with overloads for the other character types.

=
 
I think the whole discussion&= nbsp;
about input iterators that this discussion has gone on for the pas= t few days 
is unnecessary. Simply force people to read into a cont= iguous-memory buffer of 
one of the base char types. 

In all honesty I only care about string_view. G= eneric iterators are nice (maybe so we can support vector<char> if th= ere's a compelling reason to use one for something??), but I'll be happily = using this interface with string_view all the time and probably little else= ..
 

In specific: I'd l= ike this discussion to assume that the number parsing code is 
impl= emented out-of-line. Inline parsing is, forgive me for saying so, nuts.&nbs= p;
You could maybe do it for integers, but you'd never do it for floatin= g-point 
results. 

I think= at this point we need to do a real s= tudy into implementations to answer these questions accurately, particularl= y with floating point as that's the real bear. How is strtof() implemented = on different platforms? What do gcc and other compilers use for floating po= int literals? Also you voted against binary 0b prefix because its not suppo= rted by strtol(), but something is going to be/already is written to suppor= t C++14 binary literals. That something can be leveraged here.
=

--
 
---
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-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/<= /a>.
------=_Part_4287_1011012.1391653610096-- .