Difference between revisions of "V4 Requirements for Standard Types"

From EPICSWIKI
(Removed unsigned, speculating about bitset and enum.)
Line 13: Line 13:
== epicsInt16 ==
== epicsInt16 ==


A signed (2s-complement) 16-bit integer type.
A signed 16-bit integer type.
 
== epicsUint16 ==
 
An unsigned 16-bit integer type.


== epicsInt32 ==
== epicsInt32 ==


A signed (2s-complement) 32-bit integer type.
A signed 32-bit integer type.
 
== epicsUint32 ==
 
An unsigned 32-bit integer type.


== epicsInt64 ==
== epicsInt64 ==


A signed (2s-complement) 64-bit integer type.
A signed 64-bit integer type.
 
== epicsUint64 ==
 
An unsigned 64-bit integer type.


== epicsFloat32 ==
== epicsFloat32 ==
Line 45: Line 33:
== epicsOctet ==
== epicsOctet ==


An (unsigned?) 8-bit character type.  This is not intended for numeric operations, just for storing and manipulating Unicode/UTF-8 encoded strings.
An 8-bit character type which may be signed or unsigned depending on the particular platform.  This is not for numeric operations, just for storing and manipulating Unicode/UTF-8 encoded strings.


== epicsString ==
== epicsString ==
Line 52: Line 40:


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 interface that supports both segmented and contiguous buffer management and the requirements of character encoding conversions.  I'll link to that proposal from here when it's ready for public consumption.
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 interface that supports both segmented and contiguous buffer management and the requirements of character encoding conversions.  I'll link to that proposal from here when it's ready for public consumption.
----
Below here, things become more speculative...
== epicsEnum ==
A 16-bit index and a set of choice strings.
== epicsBitset ==
Some way to store a collection of named bits.

Revision as of 21:18, 1 June 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:

epicsBoolean

A boolean type.

epicsInt16

A signed 16-bit integer type.

epicsInt32

A signed 32-bit integer type.

epicsInt64

A signed 64-bit integer type.

epicsFloat32

A 32-bit IEEE floating-point numeric type.

epicsFloat64

A 64-bit IEEE floating-point numeric type.

epicsOctet

An 8-bit character type which may be signed or unsigned depending on the particular platform. This is not for numeric operations, just for storing and manipulating Unicode/UTF-8 encoded strings.

epicsString

A Unicode/UTF-8 encoded 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 interface that supports both segmented and contiguous buffer management and the requirements of character encoding conversions. I'll link to that proposal from here when it's ready for public consumption.


Below here, things become more speculative...

epicsEnum

A 16-bit index and a set of choice strings.

epicsBitset

Some way to store a collection of named bits.