Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 23 Jun 2005 18:40:51 -0600

> -----Original Message-----
> From: Benjamin Franksen [mailto:[email protected]]
> Sent: Friday, June 17, 2005 8:12 PM
> To: [email protected]
> Subject: Re: Fundamental Types document / unsigned integers
> 
> 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.

When producing robust code that is to be used by many users (you never know
what users will do) one must sanity check incoming parameters. This is
easier, and faster, with unsigned interfaces. 

> 
> > > 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.

IMHO, the unsigned type removes complication - it has less range that can be
wrong.

IMHO, most serious code failures occur because:
O untested paths in the code
O unchecked request variables

> 
> 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.

IMHO, the reduced range is desirable in many circumstances.

> 
> Another question is this: Will DA even work without unsigned integers? I
> ask because it is not clear to me which of the 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.
> 

There are overloaded interface virtual functions for all C++ primitive types
(or in some cases all promoted C++ primitive types).

> So maybe it is correct to have unsigned in the C++ DA, but not in the
> Java DA?

Yes, given that a property is defined by standard to have a particular
dynamic range then we will need to avoid standardizing an integer range that
would not be expressible with a JAVA integer. AFAICT that is on 32 bit hosts
just INT_MAX < n <= UINT_MAX. For really big numbers floating point should
be used. 

Didn't I hear someone say that JAVA has a special type for bit masks? If so,
then wouldn't it be possible to implement special conversions in the JAVA
implementation of data access mapping between C++ unsigned integer types and
the JAVA bit mask types.

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System