220 18656 <2622848.PbezMDS0We@tjmaciei-mobl4> article
Path: news.gmane.org!not-for-mail
From: Thiago Macieira <thiago@macieira.org>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Re: Parsing Numbers
Date: Wed, 17 Jun 2015 23:42:40 -0700
Lines: 55
Approved: news@gmane.org
Message-ID: <2622848.PbezMDS0We@tjmaciei-mobl4>
References: <eb5c19d6-074f-4ee4-8e2d-6d92349eb4be@isocpp.org> <9761565.z80J1WOjpt@tjmaciei-mobl4> <5582666F.8040501@gmx.net>
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 1434609784 20042 80.91.229.3 (18 Jun 2015 06:43:04 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Thu, 18 Jun 2015 06:43:04 +0000 (UTC)
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBCB4TK757YBRBZGQRGWAKGQE2KZNCAY@isocpp.org Thu Jun 18 08:42:57 2015
Return-path: <std-proposals+bncBCB4TK757YBRBZGQRGWAKGQE2KZNCAY@isocpp.org>
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 <std-proposals+bncBCB4TK757YBRBZGQRGWAKGQE2KZNCAY@isocpp.org>)
	id 1Z5TXB-0005R7-DY
	for gclcip-std-proposals@m.gmane.org; Thu, 18 Jun 2015 08:42:45 +0200
Original-Received: by labsp1 with SMTP id sp1sf18773860lab.3
        for <gclcip-std-proposals@m.gmane.org>; Wed, 17 Jun 2015 23:42:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:from:to:subject:date:message-id:user-agent
         :in-reply-to:references:mime-version:content-type:x-original-sender
         :x-original-authentication-results:reply-to:precedence:mailing-list
         :list-id:x-spam-checked-in-group:list-post:list-help:list-archive
         :list-subscribe:list-unsubscribe;
        bh=T3TrxXh81fD1JgJV6+QaJ79M43MbyRspIgmJE2z+ifs=;
        b=E+NZPc2F3zvixGzles4mfUhTkdNJ0Lk2RkeOCM41E5XU8rk1hnfXMe0wNe+m39bgwo
         TiX9vQe8vZNKrTpJZXMmpQlOAbtpdBoFAJbehvABTeuczpb7vydR2NACkFUw1+ES2j12
         PdMdCefQxMYUNp/6JYZy+UCxF+2i7Ovn3yK2j0YasXkp8jIS0aiqqyCFAl+pLM4eVX+w
         CY/PNa81hpAzVa2ZzSWIJh3whWt+Cl5zSPP2mGqppeksKDkvkWy8NZC6qjAmfrqsAMvY
         pEJEKaqruG0mICWLgzCWwW0oYlSV4P/TJM0v+o8P8AOGrntyv2bw9DkGgN7KqTbhbRuJ
         Z7dA= 
X-Gm-Message-State: ALoCoQm7AMbSUpRaJDMYNaiAjsNWZbbh+yLFSmcxheZzSbBoC5LuZc9uT6dipCyydmI1MZcgz38T
X-Received: by 10.152.219.166 with SMTP id pp6mr8994083lac.1.1434609764986;
        Wed, 17 Jun 2015 23:42:44 -0700 (PDT)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.180.100.227 with SMTP id fb3ls996212wib.23.canary; Wed, 17 Jun
 2015 23:42:44 -0700 (PDT)
X-Received: by 10.180.205.168 with SMTP id lh8mr23916195wic.95.1434609764060;
        Wed, 17 Jun 2015 23:42:44 -0700 (PDT)
Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [78.47.120.188])
        by mx.google.com with ESMTP id ui9si12334106wjc.132.2015.06.17.23.42.43
        for <std-proposals@isocpp.org>;
        Wed, 17 Jun 2015 23:42:43 -0700 (PDT)
Received-SPF: pass (google.com: domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) client-ip=78.47.120.188;
Original-Received: from tjmaciei-mobl4.localnet (unknown [IPv6:2601:1c0:5803:81c9:3135:c9b3:48ac:eab5])
	by gondolin.macieira.info (Postfix) with ESMTPSA id 21D4411B366
	for <std-proposals@isocpp.org>; Wed, 17 Jun 2015 23:42:43 -0700 (PDT)
User-Agent: KMail/4.14.8 (Linux/4.0.4-1-desktop; KDE/4.14.8; x86_64; ; )
In-Reply-To: <5582666F.8040501@gmx.net>
X-Original-Sender: thiago@macieira.org
X-Original-Authentication-Results: mx.google.com;       spf=pass (google.com:
 domain of thiago@macieira.org designates 78.47.120.188 as permitted sender) smtp.mail=thiago@macieira.org
Precedence: list
Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org
List-ID: <std-proposals.isocpp.org>
X-Spam-Checked-In-Group: std-proposals@isocpp.org
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post>, <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>,
 <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:18656
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/18656>

On Thursday 18 June 2015 08:34:23 Jens Maurer wrote:
> So, that means 0 and 1.

Right. So no "yes" or "Yes" or "true" or localised names.

> 
> > I imagine that the front-end template interface would be something like:
> > 
> >
> >       // skip bikeshedding about input, output and error
> >       extern std::expected<uint64_t, code> 
> >       parse_internal(const char *begin, const char *end, 
> >               uint64_t zero, uint64_t max, int base);
> >       extern std::expected<int64_t, code> 
> >       parse_internal(const char *begin, const char *end, 
> >               int64_t min, int64_t max, int base);
> >
> > 
> >
> >       template <typename T> 
> >       typename std::enable_if<std::is_integral<T>::value, 
> >                               std::expected<T, code>>::type
> >       parse_number(std::string_view str, int base)
> >       {
> >               typedef typename
> > std::conditional<std::is_unsigned<T>::value,
> >                       uint64_t, int64_t>::type Int64;
> >               Int64 min = std::numeric_limits<T>::min();
> >               Int64 max = std::numeric_limits<T>::max();
> >               return parse_internal(str.begin(), str.end(), min, max,
> > base); }
> 
> Signed vs. unsigned parsing is probably different enough
> (minus sign) that those two shouldn't be handled by the
> same function.

They aren't. The typedef causes the selection of a different overload based on 
whether it's signed or unsigned. Of course, that's internal detail: what 
matters is whether parse_number<T> is documented/specified to handle the minus 
sign or not for a given T.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

-- 

--- 
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/.

.
