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: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Sat, 18 Jun 2005 04:12:24 +0200
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  <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 Jeff Hill
Next: Re: Fundamental Types document / unsigned integers Benjamin Franksen
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 ·