Andrew,
That interface does not have the numeric type read and write capabilities
ala StringSegment so there is no way to perform string to numeric type
conversion-in-place as is currently the case in data access support
libraries.
> virtual void assign(const StringReader & src, size_t pos = 0) = 0;
> virtual void assign(const char *str, size_t len) = 0;
Given that StringReader has "extract(char *buf, size_t cap, size_t pos = 0)"
and you (we) will presumably implement StringReader for all the important
types of strings {std::string, string literals FixedString<int>, etc } I
wonder why we need to force the string interfacing person to write
"assign(const char *str, size_t len)" when its easy to use " assign(const
StringReader & src, size_t pos = 0)" for the same purpose.
That was my 5 sec comment. I will be taking a much closer look.
I will be taking a much closer look.
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.
- Replies:
- Re: data access structures, strings Andrew Johnson
- References:
- Re: data access structures, strings Andrew Johnson
- Navigate by Date:
- Prev:
Re: data access structures, strings Andrew Johnson
- Next:
RE: data access structures, strings Jeff Hill
- 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 Andrew Johnson
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|