Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Fri, 24 Jun 2005 03:45:36 +0200

On Friday 24 June 2005 02:40, Jeff Hill wrote:
> > -----Original Message-----
> > From: Benjamin Franksen [mailto:[email protected]]
> > 
> > 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).

Dear Jeff,

note that I somewhat switched sides with this last remark. I know very 
well that DA has overloaded functions for all the primitive types. So 
what if the ones for unsigned integers were missing? An unsigned 
argument *would* be silently casted to an int, I guess. Since this is 
one of the most evil features of C, I would be surprised if they hadn't 
found some stupid reason to keep it that way in C++.

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

Hmm. I may have missed something but doesn't this argument contradict 
the reasons you gave for using unsigned in the first place?

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

Excuse me, but we all seem to forget that there is no DA implementation, 
nor can there be, because it is merely an interface. Right?

So the question boils down to: Do we want an interface that is exactly 
the 'same' for every language. i.e. all the data types fixed to the 
same set of primitive types and non-primitive type constructors? Or do 
we allow (reasonable) deviations, so that for each language DA supports 
the native primitive types, relying on a clever implementation of an 
appropriate conversion library specific to the language/DA?

I'd say: the latter! Otherwise we end up with either crippling DA for 
everything other than C++, or else wasting bandwidth (although not that 
much) and (more important) make it a pain to map hardware registers to 
record fields.

Next question: what to do if a primitive network type does not fit 
nicely into any primitive native type? Answer: Build a composite type 
that /does/ fit on the native side. For (potentially) very large 
integers, on should use unbounded integer type. I bet there are 
apropriate Java libraries available.

Network layer should support everything up to 64 bit, signed and 
unsigned. DA will support a language specific subset and suitable 
library maps between network types and native types, if available, else 
native composite types.

What do you do if your local C++ dialect doesn't understand 64 bit 
numbers? You use a struct, that's how. Simple, stupid. Same in Java 
(s/struct/class/), for (too) large unsigned values. It is not our fault 
that you can't dress them classes up like they were real native 
numbers.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System