Experimental Physics and
Industrial Control System

Doug Murray <[email protected]> · Wed, 20 Jul 2005 06:56:47 -0700

I've been thinking about this issue, and I still believe the client

needs to be able to understand any data type that a server can make

available.

Kay-Uwe Kasemir wrote:

Hi:

Where are we with the type enum?
Before the APS meeting,
Ben & Ralph had suggested a type descriptor
similar to what John Sinclair and I
implemented for EDM:

    typedef struct
    {
        // Character of this PV
        enum { real, integer, enumerated, text, special } type;
        // real ... enumerated: bit size
        // text               : max length, 0 for variable length
        // special            : no clue
        size_t size;
        // Human-readable description. Currently supported:
        // "integer:32"
        // "real:64"  for double
        // "enumerated:16"
        // "text:0"
        const char *description;
    } Type;

... with added info for structs and arrays.

At the APS meeting, Marty presented a simple enum:
   int16
   int32
   uint16
   uint32
   array
   struct
   ...
... which would require additional calls in case you find
an array or struct.
He recently tried to nail the contents down,
when Ben raised concerns which I didn't fully understand.

Now what?

Thanks,
Kay

I also think clients will be written in Java going forward, but

nonetheless here's some C++ and general OO ideas.

First, apart from the enum, I think we need a class to describe a data

type and another to describe an instance. How about the following:

enum EpicsDataType
       {
       EDT_UNKNOWN = 0,

       EDT_BOOL    = 1,
       EDT_OCTET   = 2,
       EDT_INT16   = 3,
       EDT_INT32   = 4,
       EDT_INT64   = 5,
       EDT_FLOAT32 = 6,
       EDT_FLOAT64 = 7,
       EDT_STRING  = 8,
       EDT_TIME    = 9,

       EDT_USERDEF = 10,
       };

In particular, arrays are not included. The class to describe types

could look like this (those who believe the STL is unusable can

substitute their own container class for vector). The second class

describes an instance of a specific type, but not the space associated

with it:

   /*
    * Defines the type, size and contents of
    * an EPICS data element.  It describes a
    * type, not an instance.
    */
   class EpicsSymbolDef
       {
       public:
           bool isArray();            // for convenience
           bool isVector();        // for convenience
           bool isScalar();        // for convenience
           int getNumDims();

 string getDataTypeName(); // not always required; a type

name.

           EpicsDataType getDataType();
           unsigned int getArraySize( unsigned int dimension);
                           // get array size of given array dimension

       protected:
           void setDataType( EpicsDataType thisType);

 void setArrayDimSize( unsigned int dimension, unsigned int

size);

       private:
           EpicsDataType _type;        /* type of this element */

 string _dataTypeName; /* optional name of this data

type */

 vector<unsigned int> _dims; /* a size for each array

dimension */

       };

   /*
    * Describes an instance of an EPICS data
    * element.  It is an EpicsSymbolDef with
    * a specific instance name.  It does not
    * have storage associated with it.
    * Derived classes allocate space and have
    * storage accessor methods to manage the
    * actual data.
    */
   class EpicsSymbol : public EpicsSymbolDef
       {
       public:
           string getName();

       protected:
           /*
            * can only be created by a derived class instance.
            */
           EpicsSymbol( const char *name, const EpicsDataType type);
           ~EpicsSymbol();

       private:
           /*
            * each instance has a name
            */
           string _name;                    /* name of this element */
       };

and finally, each instance would be described in a generic way to

include actual data. Here's a minimal example, and one could imagine a

lot of accessor methods here, including a constructor to fully describe

the type to the inherited constructor (I'm not sure I've got the syntax

right here, but a typedef for each of the enums at the top of this

message would be used to get a specific instance, like 'class

EpicsData<Int16> x;' or similar):

   template<class T>
   class EpicsData : public EpicsSymbol
       {

 public: // missing a copy constructor, and most other

useful methods!

           T& operator[]( int src);
           T& operator=( const T& src);
       protected:
       private:
           <T> *_data;
       };

Also, the user defined (struct) kind of record would need a container of

Symbols, so this isn't really complete in that respect.

I would assume an Epics record definition would then be a container for

the types of these epics values and their properties and

sub-properties... (pardon the scarcity of usable methods here!), as

would the representation of a View. Only the data types are described

here, although an instance of such an object could also be used to

contain actual data, since EpicsSymbol is a base class for

EpicsData<Int16> for example, which can contain actual data.

   class EpicsRecordDef
       {
       public:
       protected:
       private:
           string _recordName;
           vector<EpicsSymbol> _fields;
       };

This would allow a client to understand the data definitions, as well as

give it a scheme to store actual data in a type safe way.

I just realized there's a bit much here for an e-mail message, perhaps I

could post this to the wiki.

-doug

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System