220 33222 <0537f2f2-645d-4a75-826b-c7f8fba9291e@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: John McFarlane Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: safe integrals comparison Date: Sun, 16 Jul 2017 11:56:43 -0700 (PDT) Lines: 113 Approved: news@gmane.org Message-ID: <0537f2f2-645d-4a75-826b-c7f8fba9291e@isocpp.org> References: <66f9bab2-7220-4bf1-afb7-77c5efa1bac3@isocpp.org> <4a572c09-5142-4834-a907-93c3cc87e79c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_731_864007483.1500231403769" X-Trace: blaine.gmane.org 1500231412 11256 195.159.176.226 (16 Jul 2017 18:56:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 16 Jul 2017 18:56:52 +0000 (UTC) Cc: federico.kircheis@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDS7B7WQUYOBB3HNV3FQKGQENA3DR2A@isocpp.org Sun Jul 16 20:56:47 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f200.google.com ([209.85.217.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dWoif-0002Mw-2N for gclcip-std-proposals@m.gmane.org; Sun, 16 Jul 2017 20:56:41 +0200 Original-Received: by mail-ua0-f200.google.com with SMTP id c26sf44071839uah.0 for ; Sun, 16 Jul 2017 11:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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; bh=58pReVAs4fH1EFauXRomc2p2wOpreDQ7QLl5DsDPK6w=; b=xyJI+rZ5yfKRWLIPnwrss+9boHlxv2T004IxYizkDXb9hgu2owW7vnUE2ZmbWOh4Qm eseajYONfVtjMEi85B1Bg+iEIafSDlE6OqYSWH+xMSl3Yfle0aRnQ+7HthsZ9kuegQ5n A5qtV3/CCIqihmLLMNJZt+R0SvBsqbpJ3XoujsM5l4BRBQFTRiXtbd7OvEeURhL62qIh uAFMfv80KTwv/JFb8ll4RIszgw6bHidhs0TDLjL1uM+LRIRmpFAIKYIFVGLrYO3J8x5H hJaa/lSOja7PSqyhHAHAhZKSDl23RdPEqw9SyhzKQ8jofBtu1gTPvQyFPRkjF8qW6urh L8Ag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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; bh=58pReVAs4fH1EFauXRomc2p2wOpreDQ7QLl5DsDPK6w=; b=exaJhwxpjECN8FydQqNZuAZOlFdpVSbTS8cy0NFvjNITdoRHvNRvrN5owtDAVSquXx nSRBvs3EI+usI1nR4KRS0AC0KdvpURgCjqiRWiNvQLF0DCJHP8OQw0uXNo5s0Ld+b0NB QNJzieex9rlqOA4j9yxMboOMsYMRJdhNYIt9xytyuIyPu0EYTHCk0HlWkssja5EUIUmj sHWKIwZEn70eZnPeKxjrMjvZbut89wOK/lR+BjL+tYzT5paBVwGGtHSvdZ6hWuW0yAQt u+rtxJyhkFaFGk4QvjjSQSNghAIt1HBhzLjj1KnCQ8R9jltpY5vrrI6uvVsqwjoIYWnR utnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=58pReVAs4fH1EFauXRomc2p2wOpreDQ7QLl5DsDPK6w=; b=dCEPs46MMaYLXGOcCGuG/wKAmhoKtaU/Jazdj3DEY0ZlVltZfFGgDy0h0dkaBnv9Ny XaO193Hi3ht9I+BWFeBkEHuUH5ABEjvHCHxFYBL8eSc6XgBj7pQNW7PhkoiD8gpnoDW5 mVFnqDKt039zEgeeBQPQQylmDdRE/jy1nup4AX0A8PrXBb/eAO7H5QJ1gLQlHxjfX9RU YLCEOVWfV5g5/HCRpdPgQn/ucOk3xCHXIkMqavI/Z8IQjIym0+YSkxIAxG1ZUzULzwh8 E8txgieKFVlcr4WaH0vYpzjIbCq+tVaDJeaxluzMnFTi6+hoi8fART74MwKIV/B2PUCo hJtQ== X-Gm-Message-State: AIVw111LBU5aCwtcXKF5158CcLQLrm1sXY71WD+FWmLuFbV6nHnGfOgB DhldnT9sLwUL4Ljv X-Received: by 10.176.93.47 with SMTP id u47mr11972412uaf.8.1500231406125; Sun, 16 Jul 2017 11:56:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.134.193 with SMTP id q62ls2246142ioi.46.gmail; Sun, 16 Jul 2017 11:56:44 -0700 (PDT) X-Received: by 10.31.169.70 with SMTP id s67mr68296vke.8.1500231404350; Sun, 16 Jul 2017 11:56:44 -0700 (PDT) In-Reply-To: <4a572c09-5142-4834-a907-93c3cc87e79c@isocpp.org> X-Original-Sender: mcfarlane.john@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:33222 Archived-At: ------=_Part_731_864007483.1500231403769 Content-Type: multipart/alternative; boundary="----=_Part_732_2087271091.1500231403770" ------=_Part_732_2087271091.1500231403770 Content-Type: text/plain; charset="UTF-8" On Sunday, July 16, 2017 at 1:00:18 AM UTC-7, federico...@gmail.com wrote: > > Another update to the proposal, > > I've added the references to Robert Ramey's proposal (and a link to an > alternative implementation of the comparison functions in his github > repository) and Herb Sutter's proposal for operator<=>. > Hi Federico, I took a quick look at this revision and had a few comments. If this document has changed by more than a few minor fix-ups, you should probably give it a different paper number to avoid confusion. It is no longer revision #0. I /think/ the correct approach is to call it D0586R1 until you've finished revising it and then submit it as P0586R1. (But I'm usually wrong!) As this mostly seems to be about avoiding cases where overflow would occur, it might be worth also mentioning P0105 and discussing how it relates, e.g. what is the mapping between functions in P0586 and P0105. A possible addition alongside `in_range` might be an `is_losslessly_convertible` which performs a compile-time check to determine if an error is ever possible, e.g. ==false, ==false, ==true. This should determine whether there is a run-time cost. Re. precision, I believe numeric_limits::digits and numeric_limits::is_signed give you everything you might need there. Proposals which are proven to be implementable are a good thing. But you might want to link to a reference implementation -- rather than include the entire example implementation. These functions should be generic: they should either work with floating-point types or there should be consideration of making this possible in the future. Further, it should be possible for users to add their own versions of these functions for types which they wish to be used in place of integers when writing generic code. Thanks, John -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0537f2f2-645d-4a75-826b-c7f8fba9291e%40isocpp.org. ------=_Part_732_2087271091.1500231403770 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, July 16, 2017 at 1:00:18 AM UTC-7, federico...@= gmail.com wrote:
Another update to the proposal,

I've added the references to = Robert Ramey's proposal (and a link to an alternative implementation of= the comparison functions in his github repository) and Herb Sutter's p= roposal for operator<=3D>.

Hi Federico= ,

I took a quick look at this revision and had a few comments.
If this document has changed by more than a few minor fix-ups, you should= probably give it a different paper number to avoid confusion. It is no lon= ger revision #0.=C2=A0 I /think/ the correct approach is to call it D0586R1= until you've finished revising it and then submit it as P0586R1.=C2=A0= (But I'm usually wrong!)

As this mostly seems to be about avoid= ing cases where overflow would occur, it might be worth also mentioning P01= 05 and discussing how it relates, e.g. what is the mapping between function= s in P0586 and P0105.

A possible addition alongside `in_range` migh= t be an `is_losslessly_convertible` which performs a compile-time check to = determine if an error is ever possible, e.g. <unsigned,int8>=3D=3Dfal= se, <int8,unsigned>=3D=3Dfalse, <signed,uint8>=3D=3Dtrue.=C2=A0= This should determine whether there is a run-time cost.

Re. precisi= on, I believe numeric_limits::digits and numeric_limits::is_signed give you= everything you might need there.

Proposals which are proven to be i= mplementable are a good thing.=C2=A0 But you might want to link to a refere= nce implementation -- rather than include the entire example implementation= ..

These functions should be generic: they should either work with fl= oating-point types or there should be consideration of making this possible= in the future.=C2=A0 Further, it should be possible for users to add their= own versions of these functions for types which they wish to be used in pl= ace of integers when writing generic code.

Thanks,
John
=

--
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-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/0537f2f2-645d-4a75-826b-c7f8fba9291e= %40isocpp.org.
------=_Part_732_2087271091.1500231403770-- ------=_Part_731_864007483.1500231403769-- .