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
<2005>
2006
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
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|