EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Fundamental Types document / unsigned integers
From: "Jeff Hill" <[email protected]>
To: "'Eric Norum'" <[email protected]>, "'Benjamin Franksen'" <[email protected]>
Cc: <[email protected]>
Date: Fri, 17 Jun 2005 18:16:21 -0600
Same answer.

This isn't so much of a CPU efficiency issue as a programming efficiency
issue. If it takes time to write the code to do the check it's less likely
to be checked and strange and mysterious bugs are more likely to find a
place to roost.

> -----Original Message-----
> From: Eric Norum [mailto:[email protected]]
> Sent: Friday, June 17, 2005 3:32 PM
> To: Benjamin Franksen
> Cc: [email protected]
> Subject: Re: Fundamental Types document / unsigned integers
> 
> 
> On Jun 17, 2005, at 4:21 PM, Benjamin Franksen wrote:
> > Regarding Jeff's argument as for the advantages of programming with
> > numbers that are garanteed to be non-negative. I would argue that this
> > is also mostly valid in C/C++, where arrays are always indexed starting
> > with zero. Many languages allow upper /and/ lower index bounds to be
> > arbitrary (signed) integers, or even any other data type, provided the
> > programmer can specify a one-to-one mapping onto a bounded interval of
> > integers. Thus, non-negativity seems to be a somewhat arbitrary
> > guarantee (why not, for instance, strict positivity?). Furthermore,
> > with regard to the efficiency question (only one range-check for upper
> > bound instead of two for upper and lower), in  C/C++ you are always
> > free to apply the zero-cost type cast from signed to unsigned, thereby
> > mapping negative numbers to large positive ones, and then range-test
> > only for the upper bound. This will fail for /exactly/ the cases where
> > the original check failed, as long as you don't rely on the upper half
> > of the possible range, something you (Jeff) suggested is to be avoided
> > anyway.
> 
> The inefficiency is only in typing a few extra characters on your
> keyboard.   Any modern optimizing compiler is going to optimize
> 	if ((i < 0) || (i >= j))
> (where i and j are signed integer values) into a single test without
> you needing to help it by performing the cast.
> 
> --
> Eric Norum <[email protected]>
> Advanced Photon Source
> Argonne National Laboratory
> (630) 252-4793


References:
Re: Fundamental Types document / unsigned integers Eric Norum

Navigate by Date:
Prev: RE: Fundamental Types document / unsigned integers Jeff Hill
Next: RE: Fundamental Types / Gateway Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Fundamental Types document / unsigned integers Eric Norum
Next: RE: Fundamental Types document / unsigned integers Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·