Re: Standard String

[Andrew Johnson <anj@aps.anl.gov>]

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.