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: "Jeff Hill" <[email protected]>
To: "'Benjamin Franksen'" <[email protected]>, <[email protected]>
Date: Fri, 24 Jun 2005 10:39:02 -0600
> 
> 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++.

First lets be clear that this is only a hypothetical question because a
properly designed DA interface must include all primitive types of the
language that is being interfaced (or in the case of read only access - all
of the promoted types).

Nevertheless, if in C++ the unsigned overload was eliminated then we will
not have an exact match, and the rules become more complicated. The short
summary is that C++ will pick an overload that matches a promoted type
before it will pick an overload via a "standard" (New jersey school of
design) conversion. Since I believe that there is no promoted conversion
from unsigned to a large floating point type such as double then if you
eliminated the unsigned overload one of the risky "standard" (New jersey
school of design) conversions would be used (as you guess). 

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

I believe that unsigned is useful for variables that must never be negative.
This makes sense in C/C++ because argument validation is easier.

I don't see how picking sensible JAVA compatible maximum ranges for positive
magnitude properties contradicts with that. 

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

Data Access *does* currently have a support library implementing assignment
and equivalence between properly interfaced (cataloged) C++ based property
containers.

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

Yes, the latter. We want to interface all of the native primitive types of
each language and implement the clever conversion library.

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

With DA the destination primitive type is determined by the developer that
designed the data structure, and chose to interface it to DA. If the
primitive type he selected has sufficient dynamic range for the property
involved then for many programs the developer need not worry about such
things I suppose.

It *would* be sensible for a robust implementation of DA targeting a
particular language to interface some composite types for the purpose of
receiving properties with dynamic range outside of the built-in primitive
types of that language. The composite types might make clients in certain
target languages harder to write, but perhaps that is what Bob's brother
would categorize as a derelict issue.

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

So all of these "it does not map to language X" concerns are actually very
nicely handled because we have imposed some discipline when interfacing the
data...

Jeff




References:
Re: Fundamental Types document / unsigned integers Benjamin Franksen

Navigate by Date:
Prev: discover, connect, get value. was: Version 4 EPICS Kay-Uwe Kasemir
Next: Re: discover, connect, get value 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 
Navigate by Thread:
Prev: Re: Fundamental Types document / unsigned integers Benjamin Franksen
Next: Re: Fundamental Types document 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 ·