| 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Standard String |
| From: | Andrew Johnson <[email protected]> |
| To: | EPICS Core Talk <[email protected]> |
| Date: | 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 allYou'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.