Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 20 Jul 2005 11:11:49 -0500

Kay-Uwe Kasemir wrote:

How would you prefer to handle these?
a) equip the EpicsString class with all the methods
   to change/insert/delete character sequences at any
   position in the string
b) have a
      char buf[...]
   where you can to all the character fiddling,
   then attach a string interface to that in order
   to hand it to the CA Server or other EPICS entity?
   So this String class would actually be non-mutable,
   it only provides read-access to the user-owned buf.

I would prefer b, so we have another example for
my case that the most important task of the string class
it to interface with char *.

c) Design the string class so that it has an internal API giving access

to the raw data buffer. Provide a set of manipulator functions that use

this API to perform the string operations that we need. Permit anyone

else to write additional manipulators for operations they need which we

haven't implemented.

We could do that without giving everyone direct access to the raw data

by requiring the manipulators to implement a particular interface and

then pass a manipulator to the string itself to call, so only the

manipulator gets priviledged access to the buffer.

The EpicsBuffer API that Marty and I designed might be a good starting

point for the design of the internal API.

...segmented string requirement ... CA network input buffer, without

having to copy the character data at all

You're right that the string might arrive in pieces.
Just like the bytes of a double could be wrapped around
the network buffer boundary.

For a double, we expect CA to assemble the pieces back together
and hand us a usable number.
For the string, the end user also most likely needs the whole string.

A double is a fixed size, will always fit into a platform-native type,

and is easy to copy around. A string is not a fixed size, will not

necessarily fit into any platform-native type, and it not necessarily

easy to copy around. Note that if you caget "fred.fields" as a string,

you'll get back something which will be pretty large and is probably

guaranteed to cross at least one network boundary if not several.

Do you leave the assembly of strings, which logically ought to be hidden
in the network/middle ware layer, to the user?

Using the Data Access API, the user will be presented with a property

catalog which contains a string property that holds the segmented data

hot off the wire. The data manipulator that the user passes into that

catalog's traverse (or find) method will 99% of the time just copy that

string into another string in the user's property catalog. That is the

moment when the assembly of the whole string takes place in Jeff's

design, assuming the user's string is stored in a contiguous buffer; if

not, it may have to copy it from one set of segments to a different set.

 Our EpicsBuffer::expose() methods were designed for doing exactly that

kind of copying in an efficient manner.

- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System