On Saturday 18 June 2005 02:15, Jeff Hill wrote:
> > I would argue that this is also mostly valid in C/C++, where
> > arrays are always indexed starting with zero.
>
> There are many integer variables/parameters, other than array
> indexes, that should never be allowed to be negative, and will cause
> unexpected behavior if they are allowed to be negative.
Yes, of course. Almost none of the functions we write are total. Most
require some precondition on the parameters or the state of the world
or some object, in order to not cause random crashes. The case of
integers that are not allowed to be negative is merely one of them, and
furthermoer one that is quite easily avoided by a modest amount of
programmer discipline. And I know of very few examples where /only/ a
lower bound has to be observed, but no upper.
> > 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.
>
> Such type casts might not be portable. Also, 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.
Yes, the more bugs are detected statically, the better. I need not be
convinced of the merits of static type checking. But with unsigned
integers in addition to signed ones, this gain in safety is very, very
minor. OTOH, including unsigned integers in a generic interface makes
it a lot more complicated. Complicated interfaces cause errors, too.
Note: I agree with your sentiment in general, but I just think in this
case the complication is not worth the cost.
IMO, unsigned integers make sense mostly for low-level programming, such
as register access or memory management code. Thus, you may need it for
programming on the IOC but I doubt it makes much sense for client
applications, except when and where they want to monitor raw hardware
values for diagnostics.
Another question is this: Will DA even work without unsigned integers? I
ask because it is not clear to me which of teh overloaded member
functions would be called if you give an unsigned but there are only
functions for signed ints defined. Will the unsigned values be silently
promoted or casted? Note that this problem does not exist in Java,
because there we simply have no unsigned ints, thus no problem.
So maybe it is correct to have unsigned in the C++ DA, but not in the
Java DA?
Ben
- Replies:
- Re: Fundamental Types document / unsigned integers Benjamin Franksen
- RE: Fundamental Types document / unsigned integers Jeff Hill
- References:
- RE: Fundamental Types document / unsigned integers Jeff Hill
- Navigate by Date:
- Prev:
RE: Fundamental Types / Gateway Jeff Hill
- Next:
Re: V4 Database Access Ralph Lange
- 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 Jeff Hill
- Next:
Re: Fundamental Types document / unsigned integers Benjamin Franksen
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|