Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Tue, 09 Aug 2005 08:57:11 -0400

On Aug 9, 2005, at 03:56, Ralph Lange wrote:

There are _two_ type spaces [or whatever term is appropriate]

connected to this issue, which are _separate_.

1. One type space contains the fixed set of native "server-side" types

that Data Access is going to support when transporting stuff - across

language and machine borders. We have to define this type space,

together with a clever implementation of a type designator, that

should be comprehensive and easy-to-use. (Kay's further discussion is

about this type space.)

2. The other type space contains some (probably a subset) of the Data

Access implementation language's basic types. These are the types that

a user application will use to store the data, so Data Access will use

these types in the interfaces and will convert between the language

and platform independent fixed types (last paragraph) to the types of

the user's data (this paragraph).

It's not that difficult, is it?

I think that's what I'm presenting on:
http://www.aps.anl.gov/epics/wiki/index.php/V4_Data_Interface

The available data types are fixed & limited:
The DataDescriptor interface will tell the user that it's an
Integer with 16, 32, 64 bits,
a Real with 32 and 64 bits, ...

You can get the exact type, for example a real64_t,
but there's also room for 'convenience' routines
that provide 'double' or 'int', the basic types of the
language where the exact type isn't nailed down.

I'm also happy to repeat once more ;-) :

Do you (and Ben) think that an interface like the DataDescriptor
with getType(), getBitsize(), .. would work?
Or is it necessary to get a
  struct { Type type, int bitsize, ... }
as you suggested earlier?

As for actually getting the data, one group proposes data access
pretty much as it is.

Marty suggested one interface per data type: NaInt16, NaInt32, ...
That's similar to the current Java channel access.

I find it inconvenient, because a lot of user code ends up looking like

this:

    double d;
	if (data.getType() == ...int16...)
          d = (double) ((NaInt16)data.getInterface()).get();
    else if (data.getType() == ...int32...)
          d = (double) ((NaInt32)data.getInterface()).get();
    ...
So if one goes with a 'reader' interface, I'd prefer the

DataReader on

http://www.aps.anl.gov/epics/wiki/index.php/V4_Data_Interface:

    /* try to get the value as double, regardless of native type */
    double d;

 if (reader->getDouble(d)) { /* OK */ } else { /* doesn't convert to

double */ }

-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System