220 9142 <20140206073609.GA27985@faust.lysator.liu.se> article Path: news.gmane.org!not-for-mail From: Magnus Fromreide Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: String to T conversions - getting it right this time Date: Thu, 6 Feb 2014 08:36:10 +0100 Lines: 100 Approved: news@gmane.org Message-ID: <20140206073609.GA27985@faust.lysator.liu.se> References: <097fb6c8-56f9-433e-a2f0-8c0f69609bf0@isocpp.org> <52F29D24.2060800@knejp.de> <4549460.QZ3YJeR1sG@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1391672170 13994 80.91.229.3 (6 Feb 2014 07:36:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Feb 2014 07:36:10 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELLREETMBRB3PWZSLQKGQEMNYI4PA@isocpp.org Thu Feb 06 08:36:18 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f69.google.com ([209.85.215.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WBJVO-0002gf-5C for gclcip-std-proposals@m.gmane.org; Thu, 06 Feb 2014 08:36:14 +0100 Original-Received: by mail-la0-f69.google.com with SMTP id mc6sf2055624lab.4 for ; Wed, 05 Feb 2014 23:36:13 -0800 (PST) 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:subject:message-id:mail-followup-to :references:mime-version:in-reply-to:user-agent:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type:content-disposition :content-transfer-encoding; bh=dAsFac0m01RvuqXUdhmVNrp+DrDCOXNi/LMKHUHp6qU=; b=Cl45ZIlPDgTrUnbtZ/E+Wwmnp06eS7VIp7OYnwZRCjJ+0C410vbJO5lK+51AHif+ZR RSadXp0Ju/pLt3CviP5UTLqdcQgKYq3IbMjXJtylS/inZtOjRSFEXVHcT0ASXLkq7FLL oqlvZXjE4uizX3M27dMnpj/mg+h4bgZ6pqBeh/R09KZDNmQecemuSX5U2HuwD+nz4yfF R8adIu0rVdZo4KL/cgR90SeFXWtnduUcHrCuPidfgEB7vUxSlKo0wxwy3QXfXh59AmH9 DLerQ9kvc8S5NKqzitwH0/awLEzAmDyo8M X-Gm-Message-State: ALoCoQl/PRGB8qjqo8+yyap6835q0Y81SCQh8zB+Fb24NGiuuGlVCp8yPA2+BNemMqLPF8Gq3FVX X-Received: by 10.180.11.41 with SMTP id n9mr14118070wib.2.1391672173763; Wed, 05 Feb 2014 23:36:13 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.115.233 with SMTP id jr9ls81561lab.61.gmail; Wed, 05 Feb 2014 23:36:12 -0800 (PST) X-Received: by 10.112.56.237 with SMTP id d13mr4340636lbq.2.1391672172644; Wed, 05 Feb 2014 23:36:12 -0800 (PST) Original-Received: from mail.lysator.liu.se (mail.lysator.liu.se. [2001:6b0:17:f0a0::3]) by mx.google.com with ESMTPS id q5si16449lbr.116.2014.02.05.23.36.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 05 Feb 2014 23:36:12 -0800 (PST) Received-SPF: pass (google.com: domain of magfr@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) client-ip=2001:6b0:17:f0a0::3; Original-Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E3E2240053 for ; Thu, 6 Feb 2014 08:36:11 +0100 (CET) Original-Received: from faust.lysator.liu.se (faust.lysator.liu.se [IPv6:2001:6b0:17:f0a0::d3]) by mail.lysator.liu.se (Postfix) with SMTP id D54CB4002D for ; Thu, 6 Feb 2014 08:36:10 +0100 (CET) Original-Received: by faust.lysator.liu.se (sSMTP sendmail emulation); Thu, 06 Feb 2014 08:36:10 +0100 Mail-Followup-To: std-proposals@isocpp.org In-Reply-To: <4549460.QZ3YJeR1sG@tjmaciei-mobl4> User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: ClamAV using ClamSMTP X-Original-Sender: magfr@lysator.liu.se X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of magfr@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mail=magfr@lysator.liu.se 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: , Content-Disposition: inline Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:9142 Archived-At: On Wed, Feb 05, 2014 at 02:30:54PM -0800, Thiago Macieira wrote: > Em qua 05 fev 2014, =E0s 21:20:52, Miro Knejp escreveu: > > > The reason being that most C++ standard library implementations will= =20 > > > delegate > > > to strtoll or similar functions (like we do in Qt). Asking for=20 > > > functionality > > > different from strtoll means asking for more complexity from library > > > developers. > > >=20 > > > Alternatively, make sure that strtoll could be implemented on top of = a=20 > > > plain C > > > library routine that is the backend for your new function. That would= =20 > > > solve > > > the problem of complexity. > >=20 > > While it makes sense and sounds great, you can only implement it in=20 > > terms of strtoll if > >=20 > > 1. The iterators point to contiguous memory, and > > 2. The value type is char, and > > 3. They range is null terminated. > >=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= is,=20 > implementing strtoll on top of a plain C function that operates on contig= uous=20 > memory and receives a begin and end pointer. >=20 > However, I do think 1 and 2 are *reasonable*. I think the whole discussio= n=20 > about input iterators that this discussion has gone on for the past few d= ays=20 > is unnecessary. Simply force people to read into a contiguous-memory buff= er of=20 > one of the base char types. I would consider it unlucky if parse(istream_iterator(cin), istream_iterator()) didn't work. My use case involves parsing data from part-wise contiguos containers (thin= k std::deque) where the ability to erase the head of the container is useful. I further think that forcing the value type to be 'char' is unreasonable, especially given that there are locales with wide decimal point and thousands separator (ps_AF). > In specific: I'd like this discussion to assume that the number parsing c= ode is=20 > implemented out-of-line. Inline parsing is, forgive me for saying so, nut= s.=20 > You could maybe do it for integers, but you'd never do it for floating-po= int=20 > results.=20 I agree. Maybe something along the lines of struct parser { typedef /* implementaion-defined */ code_point; status_type input(code_point symbol); pair input(code_point* begin, code_point* end); long long value() const; }; Here, code_point is typically the widest character type, but I wouldn't be opposed to further overloads for the input member, one could e.g. imagin= e overloads for char. /MF --=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/. .