Difference between revisions of "V4 Requirements for Standard Types"

From EPICSWIKI
 
Line 47: Line 47:
A UTF-8 encoded Unicode character string.
A UTF-8 encoded Unicode character string.


''Since this type does not map directly to any native C/C++ type, we're going to have to discuss the implementation and facilities we'll provide; let hostilities begin...''
Since this type does not map directly to any native C/C++ type, we're going to have to discuss the implementation and facilities we'll provide. Marty has a proposal for an implementation taking into account Jeff's ideas and the requirements of character encoding conversions that I'll link to here when it's ready for public consumption.

Revision as of 17:33, 19 May 2005

The purpose of this page is to discuss and agree on a set of standard basic data types that will be supported throughout EPICS V4. As at 2005-5-19 the latest implementation of Data Access doesn't support all the types that the V4 database is proposed to support; we should try to converge on a common set.

If you wish to comment, please use the "Post a comment" link under "This Page" in the left-hand column of this page; your comment will be added to the bottom of the Talk page which you can read here.

epicsTypes.h

This header will include a set of typedefs (OS dependent if necessary) as follows:

epicsInt16

A signed (2s-complement) 16-bit integer type.

epicsUint16

An unsigned 16-bit integer type.

epicsInt32

A signed (2s-complement) 32-bit integer type.

epicsUint32

An unsigned 32-bit integer type.

epicsInt64

A signed (2s-complement) 64-bit integer type.

epicsUint64

An unsigned 64-bit integer type.

epicsFloat32

A 32-bit IEEE floating-point numeric type.

epicsFloat64

A 64-bit IEEE floating-poing numeric type.

epicsOctet

An (unsigned?) 8-bit character type. This is not intended for numeric operations, just for use when storing and manipulating UTF-8 encoded character strings.

epicsString

A UTF-8 encoded Unicode character string.

Since this type does not map directly to any native C/C++ type, we're going to have to discuss the implementation and facilities we'll provide. Marty has a proposal for an implementation taking into account Jeff's ideas and the requirements of character encoding conversions that I'll link to here when it's ready for public consumption.