220 17962 article Path: news.gmane.org!not-for-mail From: "'Jeffrey Yasskin' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Parsing Numbers Date: Mon, 18 May 2015 15:28:48 -0700 Lines: 82 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1431988152 31089 80.91.229.3 (18 May 2015 22:29:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 May 2015 22:29:12 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDM34EO6QDRBNOP5GVAKGQEVHHG5MQ@isocpp.org Tue May 19 00:29:12 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f200.google.com ([209.85.192.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YuTX5-0005cJ-Cx for gclcip-std-proposals@m.gmane.org; Tue, 19 May 2015 00:29:11 +0200 Original-Received: by pdbfx16 with SMTP id fx16sf413155671pdb.2 for ; Mon, 18 May 2015 15:29:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type: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=cAX+82g3k8mNwr+HC5ffkSjG52ObN1lq+vBqF2Spx5I=; b=lamVTUyh50Wk1Y81c88DhpJ1n/p/0Vjz/bREvZUrfxmrw4ntciccB+pLJnIax2Qkt3 ndj08aOyyogzYTB0sKWu9DJWVJQNtrYefuwxjfqOnRMUNYq8rPmHjP2KbvTg3zsytDjD 5qazYWwPUUrOW5OYoZjDF0iYpTFHoPX7yKTQe/LyCKWZ065h2QQMSE9ZWymfTD+rV3+J VPI6/5uFGUA6VwSGEzQa59yv+JYzAY6i2mkegIFQRj8/KM0S2R9PYDxuUIJKPqrD29wK 67oIolcX+luZUPQ4I4yK88sFhAPhVV4ydyr7n6Fa0L+kG5QEJhOKyYIf1d99bdf4gdkp 3HeA== X-Gm-Message-State: ALoCoQkQNFPIjX9s1YlehF4Pp8qOaRT6PFdnMZ/wfaVU+h10ZZtoA+tUFAfMgf/3IzpGRwhEl/1L X-Received: by 10.66.246.193 with SMTP id xy1mr37014061pac.44.1431988150466; Mon, 18 May 2015 15:29:10 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.79.234 with SMTP id m10ls850628igx.32.gmail; Mon, 18 May 2015 15:29:09 -0700 (PDT) X-Received: by 10.107.170.66 with SMTP id t63mr30040487ioe.31.1431988149569; Mon, 18 May 2015 15:29:09 -0700 (PDT) Original-Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com. [2607:f8b0:4001:c05::22a]) by mx.google.com with ESMTPS id o7si6095355ics.7.2015.05.18.15.29.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 May 2015 15:29:09 -0700 (PDT) Received-SPF: pass (google.com: domain of jyasskin@google.com designates 2607:f8b0:4001:c05::22a as permitted sender) client-ip=2607:f8b0:4001:c05::22a; Original-Received: by igbhj9 with SMTP id hj9so18943076igb.1 for ; Mon, 18 May 2015 15:29:09 -0700 (PDT) X-Received: by 10.43.84.73 with SMTP id aj9mr2897351icc.69.1431988149421; Mon, 18 May 2015 15:29:09 -0700 (PDT) Original-Received: by 10.64.73.2 with HTTP; Mon, 18 May 2015 15:28:48 -0700 (PDT) In-Reply-To: X-Original-Sender: jyasskin@google.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of jyasskin@google.com designates 2607:f8b0:4001:c05::22a as permitted sender) smtp.mail=jyasskin@google.com; dkim=pass header.i=@google.com; dmarc=pass (p=REJECT dis=NONE) header.from=google.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: , X-Original-From: Jeffrey Yasskin Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:17962 Archived-At: On Mon, May 18, 2015 at 3:11 PM, Olaf van der Spek wrote: > 2015-05-19 0:09 GMT+02:00 'Jeffrey Yasskin' via ISO C++ Standard - > Future Proposals : >> On Mon, May 18, 2015 at 2:40 PM, Matthew Woehlke >> wrote: >>> Actually, I agree with the other Matthew Fioravante's suggestion of >>> mutating the input string_view / iterators. (Maybe we should just >>> support this like 'parse(in, &in)' and making sure that is efficient.) >> >> This one gathered an objection at >> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/Hs1s2329FCo/dl9N2GnXfxQJ, >> that the potential aliasing between the const char* and the >> string_view itself can cause problems. I suspect any problems can be >> fixed with a careful implementation, but I'm not certain, so it'd be a >> good thing for the proposal to show tests of. > > I don't get that one, isn't aliasing only an issue in the presence of writes? I could imagine an implementation like: double parse(string_view& s) { for (; !s.empty(); s.remove_prefix(1)) { whatever(s.front()); } } in which the compiler has to assume the s.front() is modified by the s.remove_prefix(1) call. On the other hand, it's easy enough for the implementation to act more like: double parse(string_view& s) { auto b = s.begin(), e = s.end(); for (; b != e; ++b) { whatever(*b); } s = string_view(b, e); } which does seem to avoid any aliasing concerns. That's why it'd be good for the proposal to include some tests. On Mon, May 18, 2015 at 3:16 PM, Olaf van der Spek wrote: > 2015-05-18 22:11 GMT+02:00 'Jeffrey Yasskin' via ISO C++ Standard - >> In the paper that proposes this, it'd be good to see examples of >> parsing code using each of the possible interfaces. That'll help >> produce a more informed decision than just looking at the interfaces >> abstractly. > > The disadvantage of not having a variant with the number as an out > parameter is the requirement of specifying the type. > I've got a lot of cases where the number is stored into a pre-existing variable. > Then again, perhaps this is just a basic building block on which other > variants can be build. Sure, and for primitive types it doesn't really matter, but for symmetry when people write their own parsing functions, it'd be nice to let folks parse non-default-constructible types. Code examples will help make either case. On Mon, May 18, 2015 at 3:17 PM, Olaf van der Spek wrote: > 2015-05-18 23:08 GMT+02:00 Jens Maurer : >> I would appreciate if there would be a compile-time choice for base 2, >> base 8, base 10, base 16, not (only) a facility with a runtime parameter. > > Why? Performance? > Shouldn't the compiler take care of that? If the implementer writes special cases for a few bases, and arranges their function boundaries suitably, the compiler can inline just the top level in order to delete the inactive options. This is something to test though. Jeffrey -- --- 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/. .