Experimental Physics and Industrial Control System
Here is some background on why I did what I did with StringSegment.
There is a fundamental problem. If strings are allowed to be stored in
non-contiguous chunks then its hard to use the C standard library numeric
conversion capabilities. I did look very carefully at using the lowest level
stream string interface in the standard C++ library. That looked initially
like a really excellent idea as we could use their numeric conversion
library. I gave up on that 2 years back when I saw that most implementations
of these accessor classes called malloc to set up the locale stuff (the gnu
implementation by the way sis not at that time call malloc). That could be a
performance problem when temporarily inflating a string accessor for a
simple task such as specifying a property name. So lacking any better idea,
I decided to defer numeric conversion to the string implementation. To hedge
my bet I also include a stream type of interface which would make implanting
numeric conversion using the core interface easier.
My current thought is that if strings are allowed to be non-contiguous then
numeric conversion problem then we will have to either have to access
numeric conversions in the string implementation or else base strings on the
string stream accessor classes in the c++ std library. I suppose that we
could however remove the other string stream interfacing function from the
interface, but that would make the numeric conversion less useful as they
would always start at the beginning of the string.
Jeff
> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Monday, September 26, 2005 5:08 PM
> To: Kay-Uwe Kasemir
> Cc: Jeff Hill; [email protected]
> Subject: Re: data access structures, strings
>
> Kay-Uwe Kasemir wrote:
> >
> > When do you think the stringSegment will be usable?
>
> I'm hoping Jeff will replace his stringSegment in dataAccess with the
> string API that I've been working on. These are the current base
> classes; there will non-member non-friend functions for doing numeric
> conversions, and other convenience functions like operator==:
>
> class StringReader {
> public:
> // String length
> virtual size_t size() const = 0;
>
> // Comparison functions
> virtual bool equals(const StringReader & rhs) const = 0;
> virtual bool contains(const StringReader & rhs, size_t pos) const =
> 0;
> virtual bool contains(const char *str, size_t len, size_t pos = 0)
> const = 0;
>
> // Individual character access
> virtual char operator[] (size_t pos) const = 0;
>
> // Copy out to buffer, no terminator
> virtual size_t extract(char *buf, size_t cap, size_t pos = 0)
> const = 0;
> };
>
> class StringEditor :
> public StringReader {
> public:
> // Length adjustment
> virtual void resize(size_t len, char fill = '\0') = 0;
>
> // Buffer storage management
> virtual size_t capacity() const = 0;
> virtual void reserve(size_t cap) = 0;
>
> // Assignment
> virtual void assign(const StringReader & src, size_t pos = 0) = 0;
> virtual void assign(const char *str, size_t len) = 0;
>
> // Append
> virtual void append(char chr) = 0;
> virtual void append(const StringReader & src, size_t pos = 0) = 0;
> virtual void append(const char *str, size_t len) = 0;
>
> // Overloaded operators
> StringEditor& operator = (const StringReader &rhs);
> StringEditor& operator = (const char *rhs);
> StringEditor& operator += (char chr);
> StringEditor& operator += (const StringReader &rhs);
> StringEditor& operator += (const char *rhs);
> };
>
> I have three tested concrete implementations which use contiguous buffers:
>
> ConstString : Concrete implementation of StringReader for wrapping
> "string literals" and other const char* buffers.
>
> FixedString<int> : Template implementation of StringEditor, using a
> fixed size buffer which is a class data member (no new/delete). The
> size is set at compile time by the template parameter, so this is a safe
> version of a regular char[] buffer.
>
> VariableString : Implementation of StringEditor, using new[] and
> delete[] to provide a contiguous buffer which increases in size as
> needed by multiples of 2.
>
> All the above implementations maintain a hidden \0 terminator byte after
> the end of the string data, and also provide a c_str() function (not
> part of the base class interface) for compatibility with C functions. If
> you created the string, you get to look inside the box; if you're given
> a StringReader or even a StringEditor you don't, and you'll have to copy
> it to pass it to printf().
>
> I am also working on another implementation using multiple fixed size
> buffer segments that are allocated from and returned to a freelist. This
> is the implementation I'm hoping we'll use in the IOC database for
> string fields as it solves the memory fragmentation problem.
>
>
> Comments and questions on the above are welcome.
>
> - Andrew
> --
> English probably arose from Normans trying to pick up Saxon girls.
- References:
- Re: data access structures, strings Andrew Johnson
- Navigate by Date:
- Prev:
RE: data access structures, strings Jeff Hill
- Next:
Re: data access structures, strings Kay-Uwe Kasemir
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: data access structures, strings Andrew Johnson
- Next:
Re: data access structures, strings Kay-Uwe Kasemir
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024