Jeff Hill wrote:
The current definition of epicsTypes does NOT include unsigned
types. The reason is Java. If we allow unsigned types it makes
it very difficult to complely support Java.
There is possibly another way of looking at this. With Java we must use an
integer type that has sufficient range to hold the magnitude of the integer
number used in C. This statement is true irregardless of whether the C type
is a signed or unsigned integer. Data Access will of course detect problems
where the integer magnitude in the server does not map to the range of the
data type of the client, and report them as exception call backs.
Two comments.
1) If native type is an unsigned 64 bit, then there is no wider java type
2) If each end is just using the unsigned as a bit mask (Note that Java
provides for this) then throwing exceptions in the intermediate layers
is no good.
We use
unsigned integer types because their domain fits better with the arithmetic
that is being conducted, and not because of their slightly higher positive
range. Relying on the extra range would be flying too close to the trees
IMHO. With bit fields if we have the option to address the bit field by its
offset and length then we will almost never need to perform arithmetic
directly on an unsigned 32 or 64 bit field. That’s a good thing. Otherwise
Java might find itself pickled when communicating with hardware ;-)
I am again haunted by Doug's request for "hello world".
If we provide some basic types ala db_access.h that are already interfaced
by data access then data access shouldn’t need to be seen by naïve users. No
doubt that we will layer a caGet and a caPut which will take "hello world"
as a parameter.
If data is acessed as an epicsType or some combination of epicsTypes,
then hello world should be easy to implement. epicsTypes is a layer
between code and dataAccess.
Marty
- Replies:
- RE: Fundamental Types document Jeff Hill
- References:
- RE: Fundamental Types document Jeff Hill
- Navigate by Date:
- Prev:
RE: Fundamental Types document Jeff Hill
- Next:
RE: Fundamental Types document 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 Jeff Hill
- Next:
RE: Fundamental Types document 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
|