Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 28 Jul 2005 14:34:53 -0600

All,

Here are DA's requirements for a string interface
-------------------------------------------------
O Interface must be compatible with almost any string 
    storage implementation that the user prefers
    O Allow the string implementation to be either contiguous 
        or non-contiguous 
    O Allow simpler and faster implementation should the string be 
        a C string constant
O Compare two strings for equivalence
O Copy one string replacing the contents of another string
O Convert a string to all of the primitive numeric types
    (the string implementation knows best how to implement this and I don't
want to reinvent the wheel if the string is non-contiguous)
    (subordinate properties need to modify this conversion)
O Convert all of the primitive numeric types to a string
    (the string implementation knows best how to implement this and I don't
want to reinvent the wheel if the string is non-contiguous)
    (subordinate properties need to modify this conversion)

Here is DA's string interface wish list
---------------------------------------
O String positioning interface (StreamPosition interface) so that useful
editing, conversion, manipulation libraries might be implemented above the
string interface

For what its worth, attached is the interface DA currently uses for
accessing strings. 

As mentioned before, if we agree that we will use only UTF-8 for wide
characters then I am very willing to change getChar and putChar in
StringSegment to transfer blocks of characters in order to improve
efficiency. 

Furthermore, I completely agree with Andrew's comment that every string
storage implementation should not need to be an iterator. The problem for DA
is that the string must be an atomic type for proper use in templates.
Therefore DA can't have two interfaces for a string. Perhaps the proper
compromise will be of the following. 

Option 1
--------
O change StringSegment to not derive from
StreamPosition/StreamWrite/StreamRead 
O change StringSegment to include factory method for instance of
StreamPosition/StreamWrite/StreamRead?

Option 2
--------
Alternatively, Andrew's concern might be addressed w/o adding a factory
method (I am concerned about memory management overhead). The alternative
would be to *not* include an iterator in the string storage implementation,
but instead the user might create a temporary stack object satisfying the
StringSegment/StreamPosition/StreamWrite/StreamRead interface for the
duration of the call to DA. This temporary object would not contain the
database's string object, but would instead contain a reference to the DB's
string object, and of course an iterator for the DB's string object.

struct StreamPosition {
public:
    // returns the number of elements in the stream
    virtual size_t length () const = 0;
    // get current position
    virtual size_t position () const = 0;
    // set the current stream position
    virtual void movePosition ( size_t newPosition ) = 0;
    // returns the number of immediately viewable 
    // elements after the current position.
    virtual size_t viewable () = 0;
    // remove all elements from current position to the 
    // end of the stream
    virtual void prune () = 0;
    // flush cached output entries 
    virtual void flush () = 0;
};

struct StreamWrite {
public:
    typedef PropertyCatalog < PropertyViewer > catalog_t;
    virtual void write ( 
        const double &, const catalog_t & = catalog_t::voidCatalog ) = 0;
    virtual void write ( 
        const int &, const catalog_t & = catalog_t::voidCatalog ) = 0;
    virtual void write ( 
        const long &, const catalog_t & = catalog_t::voidCatalog ) = 0;
    virtual void write ( 
        const unsigned &, const catalog_t & = catalog_t::voidCatalog ) = 0;
    virtual void write ( 
        const unsigned long &, const catalog_t & = catalog_t::voidCatalog )
= 0;
    virtual void write ( 
        const epicsTime &, const catalog_t & = catalog_t::voidCatalog ) = 0;
    virtual void write ( 
        const struct StringSegment &, const catalog_t & =
catalog_t::voidCatalog ) = 0;
};

struct StreamRead {
public:
    typedef PropertyCatalog < PropertyViewer > catalog_t;
    virtual void read ( 
        double &, const catalog_t & = catalog_t::voidCatalog ) const = 0;
    virtual void read ( 
        int &, const catalog_t & = catalog_t::voidCatalog ) const = 0;
    virtual void read ( 
        long &, const catalog_t & = catalog_t::voidCatalog ) const = 0;
    virtual void read ( 
        unsigned &, const catalog_t & = catalog_t::voidCatalog ) const = 0;
    virtual void read ( 
        unsigned long &, const catalog_t & = catalog_t::voidCatalog ) const
= 0;
    virtual void read ( 
        epicsTime &, const catalog_t & = catalog_t::voidCatalog ) const = 0;
    virtual void read ( 
        struct StringSegment &, const catalog_t & = catalog_t::voidCatalog )
const = 0;
};

struct StringSegment : 
    public StreamPosition, 
    public StreamRead,
    public StreamWrite 
{
    virtual int getChar () const = 0; // returns 0 when end of string is
reached
    virtual void putChar ( int ) = 0;
    virtual StringDiff compare ( const StringSegment & ) const = 0;
};

Jeff
__________________________________________________________
Jeffrey O. Hill               Mail         [email protected]
LANL MS H820                  Voice        505 665 1831
Los Alamos NM 87545 USA       Fax          505 665 5107

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System