220 33223 <0b338a7a-6d2c-44cb-ac96-6ca8bb8b992c@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: federico.kircheis@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: safe integrals comparison Date: Sun, 16 Jul 2017 12:34:14 -0700 (PDT) Lines: 206 Approved: news@gmane.org Message-ID: <0b338a7a-6d2c-44cb-ac96-6ca8bb8b992c@isocpp.org> References: <66f9bab2-7220-4bf1-afb7-77c5efa1bac3@isocpp.org> <4a572c09-5142-4834-a907-93c3cc87e79c@isocpp.org> <0537f2f2-645d-4a75-826b-c7f8fba9291e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_909_1473260855.1500233654919" X-Trace: blaine.gmane.org 1500233662 30322 195.159.176.226 (16 Jul 2017 19:34:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 16 Jul 2017 19:34:22 +0000 (UTC) Cc: federico.kircheis@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCZ3PBGHYEBBBN77V3FQKGQEKPUXSOA@isocpp.org Sun Jul 16 21:34:17 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f197.google.com ([209.85.220.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dWpIx-0007MG-Ru for gclcip-std-proposals@m.gmane.org; Sun, 16 Jul 2017 21:34:12 +0200 Original-Received: by mail-qk0-f197.google.com with SMTP id i128sf47113181qkc.11 for ; Sun, 16 Jul 2017 12:34:17 -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=FMbEf0C1BOsTdlXXg4b6l+1UPlOqjC1Y52Id3kycQgE=; b=FI0cOEn4a2wXwry2pfQN/u3hrYzrQVoazMBaf1CWjjY5JSx7ID+4guOND7chb37Qcs 8drAtI4EHB0ErIDCl9YJntABP4pBaVWIY+BNtUBMDCESb90/d1AkofOFJJveb1HE2qFb jjQlnTJfjHg7sgfACVV5YaztvIzdSM6qyA/uL19tlTqvmrBYnLBmcYnESzuJ3UBbUigv /GOriDIfJOhF1jS1n6zDnDdVaf+CAoN8QLgvNh2KSQCHGPlz2oLICxBHuPz0pL4UUPGf DniAtQIRBhVp/wtnBbkz/vrmNF/H7UF4lqoPdkSrZf5nZVPFH139eIbAXd5B/ip03NhI M6Sg== 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=FMbEf0C1BOsTdlXXg4b6l+1UPlOqjC1Y52Id3kycQgE=; b=exvc/Z4Q3x9FapreErYjaoB3C0HLfqCX9fChqFxuImfpaR6tbFHuEUyu1TqkC2xwa2 rgS9doDhmTqs4IHK2X5YJEZdlDqojF04C+rKPNA0JIaMlV/XF8bfc1/7VF0OoPqNKXs7 UNattdkPHrBPD7yLFlBSpp8J2IQIFHwIrsYqhpIdps2XXF+BKYyKfin8zxdT8SWzts3y tkB8rQMe5ro11Xz/uYQeoi0xutAzpmLydj0c6DOMW48WEPdy41JL9b1YL9E5YNzEuM1r 3NmvkzWKUFbl+103R8VT8gKMQKt44vYWuwwjqdDZt4DdP/3TZOVX7VwBzg521cNrm+mo tgQQ== 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=FMbEf0C1BOsTdlXXg4b6l+1UPlOqjC1Y52Id3kycQgE=; b=hDlGrenqW4ZrTUJBjBuJLz549zS2BjlH8frdzpp9vZ7vPgAI9zuaX24Sxk8HzJGHrt n/Dbc4atG8R/oT3Ym2/xaLfjZW88VdkCG6kFF/93mpGkg25GO9MYGI1kUODSAS15GBYl Nx7Rb+yzdnhuwhaP/hyz56S2QXMqrqtI6rjR9YYPv39NUrTN2gYvatFmTv9m5p/zEETW pwT6+55jrsEO6nbuHpGX49BujAh4dt5G3XkcUr38Gx9AWBPpnBO/XvJHK5qRT0hkV5T0 rTYhGwKYegey2yCasC2TUmdukKl/8BmQHioqzUDGgYFqwi0FnK/nztJTA1d05UgvLNct Opog== X-Gm-Message-State: AIVw113BPtXFmRPfP8TedQ62fCCVngTPKArNLsDSe3GewK1/vvpZ2Kqg YvfcdhET2rJBl/6J X-Received: by 10.200.44.23 with SMTP id d23mr2887716qta.87.1500233656945; Sun, 16 Jul 2017 12:34:16 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.29.142 with SMTP id d136ls2425783iod.39.gmail; Sun, 16 Jul 2017 12:34:15 -0700 (PDT) X-Received: by 10.31.151.199 with SMTP id z190mr69649vkd.7.1500233655398; Sun, 16 Jul 2017 12:34:15 -0700 (PDT) In-Reply-To: <0537f2f2-645d-4a75-826b-c7f8fba9291e@isocpp.org> X-Original-Sender: federico.kircheis@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:33223 Archived-At: ------=_Part_909_1473260855.1500233654919 Content-Type: multipart/alternative; boundary="----=_Part_910_659620989.1500233654919" ------=_Part_910_659620989.1500233654919 Content-Type: text/plain; charset="UTF-8" Hi John, thank you for your feedback and your time. I think the changes were just minor fixups (add references, make some sentences more clear), but to be honest I didn't give the version number a thought. I'll probably increase it. I'm unaware of P0105, I've only found this discussion: https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/TDSkjdJS1M0 I did not know std::numeric_limits::digits, from the description it seems to offer the same functionality of my precision function. I'll run a couple of tests and update my proposal if this is true. Thank you very much. I might add a reference to a separate header file with the complete implementation, I thought it would have been nice to have it directly in the paper. I do not think that those function should work with floating point types, since the arithmetic is completely different because of rounding, infinity values, and nan. The arithmetic of integral types, if no overflow occurs, is error-free, and the comparison operators behave well to each other, for example 'a > 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/0b338a7a-6d2c-44cb-ac96-6ca8bb8b992c%40isocpp.org. ------=_Part_910_659620989.1500233654919 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

thank you for your feedback and your time.=

I think the changes were just minor fixups (add references, make so= me sentences more clear), but to be honest I didn't give the version nu= mber a thought. I'll probably increase it.

I'm unaware of P0= 105, I've only found this discussion: https://groups.google.com/a/isocp= p.org/forum/#!topic/std-discussion/TDSkjdJS1M0

I did not know std::n= umeric_limits<T>::digits, from the description it seems to offer the = same functionality of my precision function.
I'll run a couple of te= sts and update my proposal if this is true. Thank you very much.

I m= ight add a reference to a separate header file with the complete implementa= tion, I thought it would have been nice to have it directly in the paper.
I do not think that those function should work with floating point ty= pes, since the arithmetic is completely different because of rounding, infi= nity values, and nan.
The arithmetic of integral types, if no overflow o= ccurs, is error-free, and the comparison operators behave well to each othe= r, for example 'a<b' is equivalent to '!(b<=3Da)' for= every a and b, unfortunately for floats this is not true.
I would there= for prefer not to supply overloaded functions for floating types, but only = for integral types, this way we can eventually add them afterward.
I als= o think that situations where you need to compare different float types are= not so common as with integral types. And since all float types are signed= , there are usually no unsafe conversions.


I didn't think ab= out user-provided types.

Since users can't add types that will p= ass the "std::is_integral" test, everyone if free to add his own = overload in the global or in a separate namespace without risking to pick t= he wrong function.
I think you can provide overloads in the std::namespa= ce, but I do not know exactly on which situations. But I'm unsure if it= would be really useful.

In my mind, there are two situations where = you may want to provide your function

1) A custom comparison operato= r takes the user provided class as a parameter and a integral.
2) The cl= ass is implicitly convertible to some integral type.

Maybe it would = make sense if you do not want to make the conversion explicit, I need to th= ink about it.



On Sunday, July 16, 2017 at 8:56:43 PM UTC+2, = John McFarlane wrote:
On Sunday, July 16, 2017 at 1:00:18 AM UTC-7, federico...@gmail= ..com wrote:
Ano= ther update to the proposal,

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

Hi Federico,
<= br>I took a quick look at this revision and had a few comments.

If t= his document has changed by more than a few minor fix-ups, you should proba= bly give it a different paper number to avoid confusion. It is no longer re= vision #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 avoiding ca= ses 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 P= 0586 and P0105.

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

Re. precision, I = believe numeric_limits::digits and numeric_limits::is_signed give you every= thing you might need there.

Proposals which are proven to be impleme= ntable are a good thing.=C2=A0 But you might want to link to a reference im= plementation -- rather than include the entire example implementation.
<= br>These functions should be generic: they should either work with floating= -point types or there should be consideration of making this possible in th= e future.=C2=A0 Further, it should be possible for users to add their own v= ersions 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 &= 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/0b338a7a-6d2c-44cb-ac96-6ca8bb8b992c= %40isocpp.org.
------=_Part_910_659620989.1500233654919-- ------=_Part_909_1473260855.1500233654919-- .