RE: data access structures, strings

["Jeff Hill" <johill@lanl.gov>]

FWIW, from my notes...

One could use the std::streambuf interface as the accessor interface for
strings. 

O The accessor object for std::string comes for free
O Accommodates non-contiguous storage of strings
O Interfaces easily to fixed length strings and string literals
O In place numeric to string conversion
O Maybe many useful things are possible if DA plugs in directly to
std::stream
	O For example, dumping DA to a string or a file is only a string
conversion of a PropertyCatalog

However .
O One must create a std::stream in order to numeric convert to/from a
std::streambuf
    O Certain implementations call malloc from constructor std::streambuf
    O That's pretty heavy weight for a temporary accessor object
        O Possibly this can be avoided .
        O With custom allocators or by pre-configuring the locale
        O Needs a 2nd look

Jeff

> -----Original Message-----
> From: Andrew Johnson [mailto:anj@aps.anl.gov]
> Sent: Thursday, September 29, 2005 1:19 PM
> To: Marty Kraimer
> Cc: core-talk@aps.anl.gov
> Subject: Re: data access structures, strings
> 
> Marty Kraimer wrote:
> >
> > Thus all the IOC database needs is a:
> >
> > 1) nonmutable reference counted continguous string. When the reference
> > count goes to 0 the storage can be reclaimed
> 
> Since you're writing thread-safe code, the reference count also has to
> have an associated mutex to protect it from simultaneous updates from
> two threads.  Each string might have its own mutex, or we might rely on
> a single central mutex to protect all reference counts - there are
> advantages and disadvantages to either choice, although the former is
> probably better for performance since there will be many fewer clashes.
> 
> Note that a published study has shown that in a threaded environment the
> time to take and release the mutex around every increment/decrement
> operation completely nullifies the speed advantage of using reference
> counting over copying for a string implementation.  I'm not claiming
> this definitely applies in our case since their usage of the strings
> differed from ours, but the performance hit from that mutex is something
> to bear in mind.  I'm also not convinced that the string itself is the
> right place for the reference count when it's embedded in a larger data
> structure like a field descriptor or record type descriptor.
> 
> We might need more than one implementation of the nonmutable string; one
> where the storage is obtained from the system (new/malloc), and a second
> where the storage is a char* literal that must not be freed when it's no
> longer referenced.  Compiling DBD files generates literals for record
> type names, field names and menu choice strings.  I think we should just
> store the char* pointer in these cases without using any kind of string
> wrapper - if any reference count exists it would have to apply to the
> descriptor as a whole, not just to the name string.
> 
> In my design any const char* buffer or literal can be wrapped with a
> ConstString at the point of use if it has to be passed to a routine that
> takes a StringReader.  Ownership would never be passed that way though.
> 
> > What the IOC database needs for strings is very different than what
> > dataAccess requires.
> 
> However if we can agree on a common string API it will make the iocCore
> code much easier to understand overall, and will probably save us from
> duplication of common tasks.  I believe that my current design is an
> acceptable compromise, and so far nobody has raised any significant
> objections to it.
> 
> - Andrew
> --
> English probably arose from Normans trying to pick up Saxon girls.