220 18289 <25B5796B-3599-4750-8710-9BD6CBDB2C39@gmail.com> article Path: news.gmane.org!not-for-mail From: Miro Knejp Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Parsing Numbers Date: Fri, 29 May 2015 14:38:35 +0200 Lines: 92 Approved: news@gmane.org Message-ID: <25B5796B-3599-4750-8710-9BD6CBDB2C39@gmail.com> References: <555CDDEF.8000002@gmx.net> <555ECB8E.9010606@gmx.net> <55680FE0.9050608@gmx.net> <5568237D.7010802@gmx.net> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1432903131 27227 80.91.229.3 (29 May 2015 12:38:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 May 2015 12:38:51 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC6ONSXJ54LBBT53UGVQKGQEGGLBQYQ@isocpp.org Fri May 29 14:38:44 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wg0-f70.google.com ([74.125.82.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YyJYe-0004rr-JX for gclcip-std-proposals@m.gmane.org; Fri, 29 May 2015 14:38:40 +0200 Original-Received: by wgla2 with SMTP id a2sf18054516wgl.1 for ; Fri, 29 May 2015 05:38:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=yT1L8/ORI7P/tcV07QAnQDRJIEKGkCVGUhp5vsqDsQE=; b=ADTPzNuVhHlqyk3HUc94AfSNvEgN67QZLAmLdO27qpglZCmKBeLIezD99cMeikMnzw LHv83kPXQIlCPyx+A4JlE6GRy0oDMIhh7husl514u2MQMXRPdrlCiis88TD2KZmf/4kv jCJMDTOG1uZsMB7SThHbdOKvXKzhDIe4MsjUAcnrmrMu2jWet6j9IgO6GofEpDYIodn8 8gW3qX9we1zrdEOg9WgU5vB3kiHtpacXxjZDEGZ1pi9PRIWb1aTJNrPnhawpJJmhdpeh V+tss3MTG3kiw77Rr0vJdT2HBxrkze1St2OEriadgYaY9F/K/dpf4oxFw9T1YodcUg53 XvRw== X-Gm-Message-State: ALoCoQlI6TJJ6VJgkX1dim8RAmKM0TXruS005QvZt14SEUmcxBGvpjmCuAyMMjdQr6QQRHr1y5i4 X-Received: by 10.112.42.236 with SMTP id r12mr7232159lbl.2.1432903119919; Fri, 29 May 2015 05:38:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.82.4 with SMTP id e4ls139368wiy.39.gmail; Fri, 29 May 2015 05:38:38 -0700 (PDT) X-Received: by 10.180.107.70 with SMTP id ha6mr6091083wib.20.1432903118863; Fri, 29 May 2015 05:38:38 -0700 (PDT) Original-Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com. [2a00:1450:400c:c05::230]) by mx.google.com with ESMTPS id fr3si3278190wic.113.2015.05.29.05.38.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 May 2015 05:38:38 -0700 (PDT) Received-SPF: pass (google.com: domain of miro.knejp@gmail.com designates 2a00:1450:400c:c05::230 as permitted sender) client-ip=2a00:1450:400c:c05::230; Original-Received: by wifw1 with SMTP id w1so22134133wif.0 for ; Fri, 29 May 2015 05:38:38 -0700 (PDT) X-Received: by 10.180.231.4 with SMTP id tc4mr6169618wic.27.1432903118717; Fri, 29 May 2015 05:38:38 -0700 (PDT) Original-Received: from [172.16.1.100] (vpn.qmob.de. [80.147.156.178]) by mx.google.com with ESMTPSA id ny7sm2955808wic.11.2015.05.29.05.38.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 May 2015 05:38:37 -0700 (PDT) In-Reply-To: <5568237D.7010802@gmx.net> X-Mailer: Apple Mail (2.2098) X-Original-Sender: miro.knejp@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of miro.knejp@gmail.com designates 2a00:1450:400c:c05::230 as permitted sender) smtp.mail=miro.knejp@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:18289 Archived-At: > On 29 May 2015, at 10:29 , Jens Maurer wrote: >=20 > On 05/29/2015 09:22 AM, Olaf van der Spek wrote: >> 2015-05-29 9:06 GMT+02:00 Jens Maurer : >>>> Would this one work for you? >>>> error_code parse(T&, string_view&, int base =3D 10); >>>=20 >>> I prefer the iterator-style approach. The style is well-established >>> in the standard library, can be extended to more general iterators >>> if someone feels so inclined (not me), has fewer issues with over- >>=20 >> Iterator-style is well-established indeed but range-style is more >> convenient IMO. >=20 > Possibly. I find reference parameters where read-modify-write > happens a lot less transparent in the calling code than pass-by-value. > For me, the main purpose of a parser is to advance the state > "where am I", producing parsed values and possibly an error code > while doing so. For my taste, hiding "where am I" in a > read-modify-write parameter is too obtuse if I can help it. >=20 > (Constant ranges, i.e. ranges whose extent is not modified, > are great, though. It's always been painful to pass > .begin(), .end() > to standard algorithms, where might be non-short.) >=20 >> Can't the string_view one be easily generalized too? >=20 > Which way? Have a range_view that takes a pair of arbitrary > iterators of type It? Sure. This feels even farther away > from established STL precedence. >=20 >>> eager aliasing assumptions that prevent compiler optimization, >>=20 >> I still don't get the aliasing problem. Isn't that only an issue with wr= ites? >> Wouldn't doing >> auto it =3D is.begin(); >> auto last =3D is.end(); >> be enough? >=20 > Consider a sequence of parses; let's take "int" for exposition: >=20 > int i1, i2; > string_view s( /* whatever */ ); > parse(i1, s); > parse(i2, s); >=20 > The "string_view" contains "const char *" internally, which is allowed > to alias anything. >=20 > Let's assume the "parse" function is inlined. Ideally, string_view's > components should be kept in registers and never hit memory. > Now, the first "parse" call changes the value of the member of "s" > holding s.begin() (let's call it s.first). This write must hit > memory, because s.first might point to itself or to s.end under > the aliasing rules. >=20 > In the second parse call, the "auto it =3D is.begin()" and > "is.end()" must read from memory afresh, because those values > might have been changed by the write to s.first of the first > parse call. >=20 > End result: string_view's components are not kept in registers. >=20 > When I looked at the issue a while ago in an output() context, > my gcc wasn't clever enough in its points-to analysis to understand > that s.first does not point to the string_view itself. Points-to > analysis is probably fairly brittle anyway, i.e. has to pessimize > quite often. Maybe that has changed meanwhile. I think this argumentation is backwards. You are not doing a write operatio= n through the char pointer, you are replacing the pointer object itself, a = member of s. Even if the char pointer does alias the string_view there is n= o modifying operation taking place on the dereferenced char pointer that wo= uld change the string_view object itself. At least if the full function def= inition is available to the translation unit. So keeping with your assumpti= on that the parse() calls are fully inlined the compiler *can* keep s in re= gisters because of read-only accesses of the char pointer. --=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/. .