Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Fri, 23 Sep 2005 17:00:12 -0600

> >      s->putChar('v'), s->putChar('a'), s->putChar('l'), ...
> 
> Also, in select situations there isn't anything wrong with "char[20]" ( or
> "malloc(20)" ) with a nill terminator on the end. We will undoubtedly
> provide simple accessor objects implementing the StringSegment interface
> for
> that type of string. There will of course be specialized accessor objects
> for string constants also.

My point here is that if you want direct access to a contiguous string then
use an accessor object implementing StringSegment for that type of string
storage. Use it to copy out of the PropertyId to that type of storage, and
then directly access your private, contiguous, traditional C string storage
as you see fit.

Jeff

> -----Original Message-----
> From: Jeff Hill [mailto:[email protected]]
> Sent: Friday, September 23, 2005 4:44 PM
> To: 'Kay-Uwe Kasemir'; [email protected]
> Subject: RE: data access structures, strings
> 
> 
> Kay,
> 
> > The users must pollute his data's interface with the
> > PropertCatalog interface.
> 
> The typical user will probably not have data structures like RGBCatalog
> deriving from propertyCatalog, but will instead create accessor objects
> that
> implement propertyCatalog and also know RGBCatalog. I have written
> templates
> that automate creation of these accessor objects. I presented examples at
> our last meeting. I hope to have them in the DA manual (and CVS) soon.
> Based
> on past experience, I will receive gripes if I check in something that
> isn't
> finished.
> 
> > Seems to me that yes, dataAccess helps with handling
> > containers with differing types for matching properties;
> > Even containers with differing properties,
> > but that only on the 'top' level.
> > Anything one level down must match.
> 
> I think that it's a good idea to define standard names for the properties
> so
> that client and servers are on the same page. For example, when we say
> "precision" this needs to be well defined so that it means the same thing
> to
> the client and the server. Likewise, standards should be specified for the
> property hierarchy. For example, when we say display limits it should be
> well understood that there is minimum set of subordinate properties
> required
> of conformant servers.
> 
> > That's the situation where a pulling interface
> > would be more obvious, because then I can write
> > the mapping code
> >    destination->r = data_catalog->find("color")->find("red")->toDouble()
> 
> I guess I don't understand the point here since its easy enough to write a
> convenience library that implements "destination->r =
> data_catalog->find("color")->find("red")->toDouble()" on top of the data
> access minimalist interfaces. Note that data access is designed so that
> the
> user needs to do very little to export his data. Many things can be
> layered
> on top of these interfaces to improve usability in select situations.
> 
> > When I ask the propertyId->getName() to get the property name,
> > why not return char * "value"?
> > Instead it's
> >      propertyId->getName(stringSegment s)
> > and then propertyId will call
> >      s->putChar('v'), s->putChar('a'), s->putChar('l'), ...
> > That might sound like a very performant and memory-conserving
> > idea for the channel access library,
> > but the user of the library still would like to get the property
> > name, and the required code probably reverses any CPU & mem savings.
> 
> Several reasons - see item #29 in "Effective C++" for a summary.
> 
> In particular, I worry about:
> 
> a) In multithreaded systems I tend to not write accessor methods that
> return
> handles to internal data. The data might be changing while the user is
> using
> it and does not have a lock.
> 
> b) I also worry that if we hand off a handle to internal data that the
> user
> may still be using the pointer to the string after the property identifier
> has been destroyed.
> 
> c) Returning a pointer to a string does not allow non-contiguous storage
> (improved memory management).
> 
> You can come up with some usage patterns that eliminate some of these
> concerns, but I am not thinking that way. I am trying to create a rock
> solid
> interface design that works with multiple threads and isn't a create
> everything during initialization and nothing gets destroyed type of
system.
> 
> Given the inherent slowness of strings I don't think that block copying
> the
> string out before you use it, in order to avoid the above concerns, is an
> efficiency issue. Furthermore, with a simple implementation based on
> decent
> fixed sized block memory management, I don't think that creating storage
> on
> the fly for strings is inefficient from a memory management perspective.
> Such string implementations would presumably provide convenience routines
> for all of the common string functionalities. I am not interested in
> writing
> a string library. I need an interface to string data that does not
> preclude
> high performance (read properly memory managed) implementations.
> 
> >      s->putChar('v'), s->putChar('a'), s->putChar('l'), ...
> 
> Also, in select situations there isn't anything wrong with "char[20]" ( or
> "malloc(20)" ) with a nill terminator on the end. We will undoubtedly
> provide simple accessor objects implementing the StringSegment interface
> for
> that type of string. There will of course be specialized accessor objects
> for string constants also.
> 
> Finally, its probably a good idea to be consistent about all strings that
> are passed in and out of the library. The advantage of StringSegment is
> that
> it places very little constraint on how strings are stored - and it does
> not
> require much work to interface a particular type of string. StringSegment
> isn't trying to be a string implementation - its only trying to interface
> to
> strings in a minimalist way.
> 
> Furthermore, I gave this list my perspective of the functional
> requirements
> for this type of minimalist approach to interfacing to strings some time
> back. None of this is locked in stone, and I would certainly like to hear
> your perspective(s). By now you undoubtedly know my opinion on interfaces
> that return a pointer to the entire string stored in one contiguous block
> ;-)
> 
> > StringSegment must copy characters out one a time
> 
> 
> a) Once we adopt UTF-8 as the only way that wide characters are stored (I
> think that we have pretty much reached this consensus at this point) then
> the interface will be changed to include a character count in putChar and
> getChar so that characters can be shipped in bulk.
> 
> b) The "StringSegment::read (StringSegment &)" and "StringSegment::write
> (StringSegment &)" interface *do* allow down-casting using dynamic_cast
> for
> a more efficient transfers in the common case where the source and
> destination are the same character string implementation.
> 
> Interested in your perspective(s) on these issues
> 
> HTH (sorry if this was boring for those of you that have heard it before)
> 
> Jeff
> 
> > -----Original Message-----
> > From: Kay-Uwe Kasemir [mailto:[email protected]]
> > Sent: Friday, September 23, 2005 3:13 PM
> > To: [email protected]
> > Subject: data access structures, strings
> >
> > Hi:
> >
> > Assume I have this source data:
> >
> > struct RGB { int r, g, b; };
> > struct data
> > {
> >      double    value;
> >      struct RGB color;
> > };
> >
> > I can implement a property catalog for the sub-struct:
> > class RGBCatalog : public propertyCatalog
> > {   void traverse ( propertyViewer &v) const
> >      {
> >          v.reveal(red_id, rgb->r);
> >          ..
> > and then use that in the PC for the data:
> > class DataCatalog : public propertyCatalog
> > {   // constructor somehow gets pointer to 'data',
> >      // prepares RGBCatalog 'color' for data->color
> >      void traverse ( propertyViewer &v) const
> >      {
> >          v.reveal(value_id, data->value);
> >          v.reveal(color_id, color);
> >          ...
> > OK. If I only want the 'value', I use
> >     data_catalog->find(value_id, ...)
> > and get a 'reveal' callback for the value.
> >
> > What if my target data is
> > struct destination
> > {
> >      double value;
> >      int r, g, b;
> > }
> >
> > Is there a way to get
> >     destination->r =  data -> color.r;
> >     destination->g =  data -> color.g;
> > ?
> > As far as I see it, I can call
> >     data_catalog->find(color_id, ...).
> > That results in
> >     reveal(color_id, propertyCatalog &color)
> > for the whole propertyCatalog for color.
> >
> > Seems to me that yes, dataAccess helps with handling
> > containers with differing types for matching properties;
> > Even containers with differing properties,
> > but that only on the 'top' level.
> > Anything one level down must match.
> >
> > That's the situation where a pulling interface
> > would be more obvious, because then I can write
> > the mapping code
> >    destination->r = data_catalog->find("color")->find("red")->toDouble()
> >
> > ----
> >
> > When I ask the propertyId->getName() to get the property name,
> > why not return char * "value"?
> > Instead it's
> >      propertyId->getName(stringSegment s)
> > and then propertyId will call
> >      s->putChar('v'), s->putChar('a'), s->putChar('l'), ...
> > That might sound like a very performant and memory-conserving
> > idea for the channel access library,
> > but the user of the library still would like to get the property
> > name, and the required code probably reverses any CPU & mem savings.
> >
> > -Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System