220 33032 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: Thu, 29 Jun 2017 12:27:57 -0700 (PDT) Lines: 183 Approved: news@gmane.org Message-ID: References: <66f9bab2-7220-4bf1-afb7-77c5efa1bac3@isocpp.org> <4473c388-1bc0-24b3-b1f2-fc8bfc834df3@rrsd.com> <23282d1f-aaaa-45a1-a1fe-2056addfe835@isocpp.org> <8c168cd3-6dc2-97ab-848d-7eab8321e114@rrsd.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3894_881021322.1498764478021" X-Trace: blaine.gmane.org 1498764485 18853 195.159.176.226 (29 Jun 2017 19:28:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Jun 2017 19:28:05 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCZ3PBGHYEBBBP5J2XFAKGQEPKDZJXI@isocpp.org Thu Jun 29 21:28:01 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQf6Z-0004Na-62 for gclcip-std-proposals@m.gmane.org; Thu, 29 Jun 2017 21:27:55 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id g124sf75205804ywg.7 for ; Thu, 29 Jun 2017 12:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to: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=GD6FEll+oMEXZmn8ntpl2p5K/EzUOulcuRx2CrdG7iI=; b=DQ1cRdWPHfII68yipR8G6f3IDLbYWB3Nk05/xRYkMfp/e15FFHd+NVQKCpC6gYycAt XIqQGdWs14C55ZRI/Lj0g1AEyc4/6n8x81DoPb7lmJadzPTy2DgBVBLMYPTlmhTSldnn gEqxgJGZXxJQ3EzK/SyUSwomCpaA620CN9G8gubuyzgs+w1QVBURHLauNAAUOPXy6PtH QLWIHTUzCZOYDF/V2mlMxGls1APEszOC5VF2g3J+bqI0c7tkBLfk5cB5Vp7wIZqlTvBT twur8y6HONLU9jJoFFPH2p3d8ikTOj3ObpFR1iwm9Wsr1n3bcMDJF+A8VdCxCOEMcN99 iuRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to: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=GD6FEll+oMEXZmn8ntpl2p5K/EzUOulcuRx2CrdG7iI=; b=k//ErQveZ2Zdg9NhOnBv5N17SL78MusGUud5CK/JvGivR0tUlZlITMCFGXx8Axp5Hd 7ixqsN1nQtKO+nxAoBkFxsddbpTdZ5pbrfbJIakHVFdjb7/Pzopkn3iF599FqUrTzTv7 aHEcr2tKc+mZMaAvi7f7FMogWUBBdZYnprUSRpuwlYcq0mIeBZvYHF9L0fgkInfhGaQO lv5sUQ+2OV5/SE667yRF7cwiV5/DoQ+T6WO6xFseML+xuDQzamHL6umnGXWcSdq659ww xQ+njBtx4bgiEoDv/fk3IYep4ov3Phw/reI5LX4qYPbS5SvjfXEQWB04tYErIS5RxrSM 9iWw== 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: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=GD6FEll+oMEXZmn8ntpl2p5K/EzUOulcuRx2CrdG7iI=; b=rtkJ0ixPZIMy6RBu78W1GZp04dy9hCJuOJAw1l6geXo8wltW+CpryEv6UQOPOw/FlA /mNgUYkcJKgOarmCvb3rQElbgVm99G7gS1MFAeIjJQD7WMvIbFJ89l+Sw823pm1cGntL LvhUD6bmzgJ5nZRX1tAyfGKZG6A8Bc/TUn7i2gFcZ//QQ758sC5yJEKBo4dYYKqd+foc +bFiMM/5yk1swW6jzfie+CkqUPtiyB8bAXbX/X0Ph9so2fY3XhkTtz+PPespICo+gx0b z54mFypowKCUIrqOGxSOqKuwwaoQJC7T+51Wodt7FDGxCL/3UP6GimqOWDpEnXjnXWDK oxhw== X-Gm-Message-State: AKS2vOxUJhz+lAfRec30SoZjte6rrNQAio/xGvJdtllF/iRdbSeQaMQF 8CP7x+aRWDcdnDX1 X-Received: by 10.129.125.194 with SMTP id y185mr11614024ywc.43.1498764480310; Thu, 29 Jun 2017 12:28:00 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.35.21 with SMTP id j21ls1458696ioj.6.gmail; Thu, 29 Jun 2017 12:27:58 -0700 (PDT) X-Received: by 10.36.46.202 with SMTP id i193mr418787ita.8.1498764478532; Thu, 29 Jun 2017 12:27:58 -0700 (PDT) In-Reply-To: <8c168cd3-6dc2-97ab-848d-7eab8321e114@rrsd.com> 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:33032 Archived-At: ------=_Part_3894_881021322.1498764478021 Content-Type: multipart/alternative; boundary="----=_Part_3895_319721557.1498764478021" ------=_Part_3895_319721557.1498764478021 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You are right about the promotion rules, problems arise only when mixing=20 signed and unsigned types. I think I made all the casts explicit, also in order to avoid possible=20 compiler warning, even if there shouldn't be any. Most of the time I enable all possible warnings, and MSVC in particular=20 generates a lot of them. There may be also something about safe promotions,= =20 but I should check it to be sure. I also think that I tried to use only the types that where passed as=20 parameter (and maybe thats the reason why I didn't want to use=20 make_unsigned, but it's an implementation detail), in order to deal cases where a compiler provides some integral=20 type but only the signed or unsigned variant and not boht of them. I have actually no idea if something like this exists somewhere, or if it= =20 does even make sense, but AFAIK there is no rule that states that for every= =20 signed type we need an unsigned, and for every unsigned a signed. Il giorno gioved=C3=AC 29 giugno 2017 21:10:59 UTC+2, Robert Ramey ha scrit= to: > > On 6/29/17 10:00 AM, federico...@gmail.com wrote:=20 > > Hi,=20 > >=20 > > I was just reading your implementation a couple of days ago, it's prett= y=20 > > complicated with all those templated types ;-)=20 > >=20 > > (To be honest I found out of your library in March, when I listened to= =20 > > the podcast episode, but then forgot to give a look to your=20 > implementation)=20 > >=20 > > I noticed you were not comparing the precision of the types like I did,= =20 > > I guess I missed that I could use "make_unsigned".=20 > > I think the only difference is that I'm converting both types to the on= e=20 > > with the biggest range, and accounting that it may be the signed one. I= =20 > > guess it may use less stack space, but I also think that it will never= =20 > > make some difference.=20 > >=20 > > I guess your implementation for comparing integral types and mine are= =20 > > completely interchangeable.=20 > >=20 > > This is unnecessary. C/C++ type promotion rules do exactly this so it's= =20 > redundant to do this in your code. The only problem is that C++=20 > promotion rules sometime change signed to=20 > unsigned and change the value.=20 > The attached code keeps this from happening which is why it works.=20 > > Note that my code guarantees zero runtime overhead in space or time. In= =20 > fact it could even make one's program faster as in the case:=20 > > unsigned int x;=20 > signed int y =3D -1=20 > > y < x // can be eliminated as it will always be true.=20 > > Robert Ramey=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/c0774539-8c72-4467-ba0c-a04042a7cc94%40isocpp.or= g. ------=_Part_3895_319721557.1498764478021 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You are right about the promotion rules, problems arise on= ly when mixing signed and unsigned types.

I think I made all the cas= ts explicit, also in order to avoid possible compiler warning, even if ther= e shouldn't be any.
Most of the time I enable all possible warnings,= and MSVC in particular generates a lot of them. There may be also somethin= g about safe promotions, but I should check it to be sure.


I als= o think that I tried to use only the types that where passed as parameter (= and maybe thats the reason why I didn't want to use make_unsigned, but = it's an implementation
detail), in order to deal cases where a compi= ler provides some integral type but only the signed or unsigned variant and= not boht of them.
I have actually no idea if something like this exists= somewhere, or if it does even make sense, but AFAIK there is no rule that = states that for every signed type we need an
unsigned, and for every uns= igned a signed.


Il giorno gioved=C3=AC 29 giugno 2017 21:10:59 U= TC+2, Robert Ramey ha scritto:
= On 6/29/17 10:00 AM, federico...@gmail.com wrote:
> Hi,
>=20
> I was just reading your implementation a couple of days ago, it= 9;s pretty=20
> complicated with all those templated types ;-)
>=20
> (To be honest I found out of your library in March, when I listene= d to=20
> the podcast episode, but then forgot to give a look to your implem= entation)
>=20
> I noticed you were not comparing the precision of the types like I= did,=20
> I guess I missed that I could use "make_unsigned".
> I think the only difference is that I'm converting both types = to the one=20
> with the biggest range, and accounting that it may be the signed o= ne. I=20
> guess it may use less stack space, but I also think that it will n= ever=20
> make some difference.
>=20
> I guess your implementation for comparing integral types and mine = are=20
> completely interchangeable.
>=20

This is unnecessary. =C2=A0C/C++ type promotion rules do exactly this s= o it's=20
redundant to do this in your code. =C2=A0The only problem is that C++= =20
promotion rules sometime change signed to
unsigned and change the value.
The attached code keeps this from happening which is why it works.

Note that my code guarantees zero runtime overhead in space or time. In= =20
fact it could even make one's program faster as in the case:

unsigned int x;
signed int y =3D -1

y < x // can be eliminated as it will always be true.

Robert Ramey

--
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/c0774539-8c72-4467-ba0c-a04042a7cc94= %40isocpp.org.
------=_Part_3895_319721557.1498764478021-- ------=_Part_3894_881021322.1498764478021-- .